Date: Sun, 19 Nov 2000 19:39:41 -0500 From: mike ryan <msr@elision.org> To: Warner Losh <imp@village.org> Cc: stable@FreeBSD.ORG Subject: Re: 4.2-BETA hangs on boot Message-ID: <20001119193941.A38978@medianstrip.net> In-Reply-To: <200011192205.eAJM5QG03609@billy-club.village.org>; from imp@village.org on Sun, Nov 19, 2000 at 03:05:26PM -0700 References: <20001117172251.A34915@medianstrip.net> <20001116204344.B62344@bonsai.knology.net> <20001116195957.A62344@bonsai.knology.net> <200011170209.eAH297q51130@drugs.dv.isc.org> <20001116204344.B62344@bonsai.knology.net> <200011172203.PAA77619@harmony.village.org> <20001117172251.A34915@medianstrip.net> <200011172314.QAA78313@harmony.village.org> <20001119042505.A7076@medianstrip.net> <200011192205.eAJM5QG03609@billy-club.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 11/19/00, Warner Losh wrote:
> In message <20001119042505.A7076@medianstrip.net> mike ryan writes:
>
> : for what it's worth, here's the behavior i'm seeing: on my vaio
> : z505hs with a ricoh rl5c475 pci-cardbus bridge, polling mode works
> : fine with the "plug & play o/s" bios option set to "yes". when i
> : set that bios option to "no" (so usb works), the machine will
> : occasionally (but not always) hang on boot after the pccard0 probe,
> : with no cards inserted. i haven't tried booting with cards
> : inserted. when the machine boots successfully, it will always hang
> : on a card insertion.
>
> Odd, my always works in polling mode. I have the same bridge, but the
> PCG-505TS instead of the x505hs.
>
> The PnP "no" setting causes more of the devices to have interrupts
> assigned and routed. The "yes" setting doesn't. You are running into
> interrupt hell that has little to do with the actual card bus bridge
> and more to do with FreeBSD's inability to cope properly before
> -current of about BSDcon.
i'm not entirely sure i understand. "pnp o/s = no" causes the bios
to assign an irq to the pcic controller, meaning the pcic controller
raises that interrupt on insertions/removals, but the driver,
operating in polling mode, never clears the interrupt so the machine
wedges trying to service it? if this is correct, how does ddb
manage to unwedge things?
the fix in -current is the pci interrupt routing code which allows
us to set "pnp os = yes" in the bios and let freebsd make irq
assignments only for devices it understands? any chance this will
MFC-ed?
> : when a card insertion does freeze the machine, i can still drop to
> : ddb. once in ddb, i can "next" a lot, and eventually ddb will
> : disappear, the machine will be unfrozen, the freshly inserted card
> : will probe and attach, and everything will continue normally except
> : that a random process will have died on SIGTRAP. same thing on card
> : removal. dropping to ddb and hitting "continue" doesn't work, only
> : "next". this seems odd.
>
> Where are you dropping into ddb at? That would be useful information.
here's the beginning of a sample ddb session (transcribed by hand):
Debugger("manual escape to debugger")
Stopped at Debugger+0x34: movb $0,in_Debugger.396
db> t
Debugger(c02ca249) at Debugger+0x34
scgetc(c033d600,2,c071a840,c03369a0,ffffffff) at scgetc+0x38e
sckbdevent(c03369a0,0,c033d600,c071a840,c0bb0000) at sckbdevent+0x1b9
atkbd_intr(c03369a0,0,c02d75b4,c027fc5f,c03369a0) at atkdb_intr+0x22
atkdb_isa_intr(c03369a0,684200,c02d0010,c0130010,10) at atkbd_isa_intr+0x18
Xresume1() at Xresume1+0x2b
--- interrupt, eip = 0xc0236e3b, esp = 0xc02d75a0, ebp = 0xc02d75b4 ---
uhci_intr(c0bb0000,684200,0,0,0) at uhci_intr+0x47
intr_max(c071a840,0,c01f0010,400010,400010) at intr_mux+0x1d
Xresume9() at Xresume9+0x2b
--- interrupt, eip = 0xc0289276, esp = 0xc02d7614, ebp = 0 ---
default_halt() at default_halt+0x2
db> n
After 2 instructions (0 loads, 0 stores)
Stopped at Debugger+0x3c: ret
db> n
After 81 instructions (0 loads, 0 stores)
Stopped at scgetc+0x4af: ret
db> n
After 13 instructions (0 loads, 0 stores)
Stopped at sckbdevent+0x1da: ret
db> n
After 7 instructions (0 loads, 0 stores)
Stopped at atkbd_intr+0x89: ret
db> n
After 2 instructions (0 loads, 0 stores)
Stopped at atkdb_isa_intr+0x19: ret
db> n
After 24 instructions (0 loads, 0 stores)
Stopped at doreti_iret: iret
db> t
doreti_iret(8,202,c071a840,400200,ffffffff) at doreti_iret
uhci_intr(c0bb0000,684200,0,0,0) at uhci_intr+0x47
intr_mux(c071a840,0,c01f0010,400010,400010) at intr_mux+0x1d
Xresume9() at Xresume9+0x2b
--- interrypt, eip = 0xc0289276, esp = 0xc02d7614, ebp = 0 ---
default_halt() at default_halt+0x2
db> n
After 11 instructions (0 loads, 0 stores)
Stopped at uhci_intr+0x11f: ret
db> n
After 112596 instructions (0 loads, 0 stores)
Stopped at intr_mux+0x33: ret
db> n
After 1906 instructions (0 loads, 0 stores)
Stopped at doreti_iret: iret
db> t
doreti_iret(8,246,c0289271,f,681) at doreti_iret
default_halt() at default_halt+0x2
db> n
After 1 instructions (0 loads, 0 stores)
Stopped at intr_mux+0x2: ret
db> n
After 92 instructions (0 loads, 0 stores)
Stopped at cpu_switch_load_gs+0x35: ret
db> t
cpu_switch_load_gs(c85cac60,c85cac60,0,0,19) at cpu_switch_load_gs+0x35
mi_switch(0,c02338e0,c0157a91,c3489390,6e4200) at mi_switch+0x174
tsleep(c02ef7f8,4,c02bcf00,1f4) at tsleep+0x19d
vm_pageout(0) at vm_pageout+0x1e0
fork_trampoline() at fork_tramploine+0x8
db>
relevant excerpts from "nm /kernel":
c0236df4 T uhci_intr
...
c027fc34 t Xresume1
...
c0289274 T default_halt
c0289278 T cpu_switch
...
c02d3800 r config
c02d7620 D .tmpstk
...
c03369a0 b default_kbd
...
c033d600 b main_softc
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001119193941.A38978>