sio / puc wedging on both -current and -stable
Mike Tancsa
mike at sentex.net
Fri Jun 4 02:56:04 GMT 2004
Just a followup my previous post. Still havent quite figured out exactly
what is going on, but perhaps something with the USB code? This is on a
number of ICH4 boards I have on at least 3 different chipset variants. The
MB BIOSes are also all up to date.
Just a quick recap. I can fairly easily trigger an interrupt storm on
these machines with USB enabled in the BIOS. If I disable it, I dont have
a problem and all works well.... However, what I accidently came across
today, was that if I load the USB drivers as a kld, I can *not* wedge the
machine. Note the bottom of the following diff
diff dmesg.kld dmesg.static
< pci0: <UHCI USB controller> at 29.0 irq 10
< pci0: <UHCI USB controller> at 29.1 irq 5
< pci0: <UHCI USB controller> at 29.2 irq 12
---
> uhci0: <Intel 82801DB (ICH4) USB controller USB-A> port 0xb800-0xb81f
irq 10 at device 29.0 on pci0
> usb0: <Intel 82801DB (ICH4) USB controller USB-A> on uhci0
> usb0: USB revision 1.0
> uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
> uhub0: 2 ports with 2 removable, self powered
> uhci1: <Intel 82801DB (ICH4) USB controller USB-B> port 0xb000-0xb01f
irq 5 at device 29.1 on pci0
> usb1: <Intel 82801DB (ICH4) USB controller USB-B> on uhci1
> usb1: USB revision 1.0
> uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
> uhub1: 2 ports with 2 removable, self powered
> uhci2: <Intel 82801DB (ICH4) USB controller USB-C> port 0xb400-0xb41f
irq 12 at device 29.2 on pci0
> usb2: <Intel 82801DB (ICH4) USB controller USB-C> on uhci2
> usb2: USB revision 1.0
> uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
> uhub2: 2 ports with 2 removable, self powered
67,83d78
< uhci0: <Intel 82801DB (ICH4) USB controller USB-A> port 0xb800-0xb81f irq
10 at device 29.0 on pci0
< usb0: <Intel 82801DB (ICH4) USB controller USB-A> on uhci0
< usb0: USB revision 1.0
< uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
< uhub0: 2 ports with 2 removable, self powered
< uhci1: <Intel 82801DB (ICH4) USB controller USB-B> port 0xb000-0xb01f irq
5 at device 29.1 on pci0
< usb1: <Intel 82801DB (ICH4) USB controller USB-B> on uhci1
< usb1: USB revision 1.0
< uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
< uhub1: 2 ports with 2 removable, self powered
< uhci2: <Intel 82801DB (ICH4) USB controller USB-C> port 0xb400-0xb41f irq
12 at device 29.2 on pci0
< uhci2: Could not allocate irq
< device_probe_and_attach: uhci2 attach returned 6
< uhci2: <Intel 82801DB (ICH4) USB controller USB-C> port 0xb400-0xb41f irq
12 at device 29.2 on pci0
< uhci2: Could not allocate irq
< device_probe_and_attach: uhci2 attach returned 6
< stray irq 7
arnold2%
Why when I load the USB drivers as a kld, does it get an error about
allocating an IRQ ? But when I have the drivers statically compiled, there
is no error. Furthermore, when loaded as a kld, I am *not* able to wedge
the box with an interrupt storm.
arnold2% diff pci.kld pci.static
21c21
< none0 at pci0:29:2: class=0x0c0300 card=0x0074a0a0 chip=0x24c78086
rev=0x02 hdr=0x00
---
> uhci2 at pci0:29:2: class=0x0c0300 card=0x0074a0a0 chip=0x24c78086
rev=0x02 hdr=0x00
41c41
< none1 at pci0:31:3: class=0x0c0500 card=0x0074a0a0 chip=0x24c38086
rev=0x02 hdr=0x00
---
> none0 at pci0:31:3: class=0x0c0500 card=0x0074a0a0 chip=0x24c38086
rev=0x02 hdr=0x00
arnold2%
arnold2% cat pci.static
chip0 at pci0:0:0: class=0x060000 card=0x0074a0a0 chip=0x25608086 rev=0x03
hdr=0x00
vendor = 'Intel Corporation'
device = '82845G/GL/GV/GE/PE DRAM Controller / Host-Hub I/F Bridge'
class = bridge
subclass = HOST-PCI
agp0 at pci0:2:0: class=0x030000 card=0x3402a0a0 chip=0x25628086 rev=0x03
hdr=0x00
vendor = 'Intel Corporation'
device = '82845G/GL/GV/GE/PE Integrated Graphics Device'
class = display
subclass = VGA
uhci0 at pci0:29:0: class=0x0c0300 card=0x0074a0a0 chip=0x24c28086
rev=0x02 hdr=0x00
vendor = 'Intel Corporation'
device = '82801DB/DBM (ICH4/M) USB UHCI Controller #1'
class = serial bus
subclass = USB
uhci1 at pci0:29:1: class=0x0c0300 card=0x0074a0a0 chip=0x24c48086
rev=0x02 hdr=0x00
vendor = 'Intel Corporation'
device = '82801DB/DBM (ICH4/M) USB UHCI Controller #2'
class = serial bus
subclass = USB
uhci2 at pci0:29:2: class=0x0c0300 card=0x0074a0a0 chip=0x24c78086
rev=0x02 hdr=0x00
vendor = 'Intel Corporation'
device = '82801DB/DBM (ICH4/M) USB UHCI Controller #3'
class = serial bus
subclass = USB
pcib1 at pci0:30:0: class=0x060400 card=0x00000000 chip=0x244e8086
rev=0x82 hdr=0x01
vendor = 'Intel Corporation'
device = '82801BA/CA/DB/EB/ER (ICH2/3/4/5/5R) Hub Interface to PCI
Bridge'
class = bridge
subclass = PCI-PCI
isab0 at pci0:31:0: class=0x060100 card=0x00000000 chip=0x24c08086
rev=0x02 hdr=0x00
vendor = 'Intel Corporation'
device = '82801DB (ICH4) LPC Interface Bridge'
class = bridge
subclass = PCI-ISA
atapci0 at pci0:31:1: class=0x01018a card=0x0074a0a0 chip=0x24cb8086
rev=0x02 hdr=0x00
vendor = 'Intel Corporation'
device = '82801DB (ICH4) UltraATA/100 EIDE Controller'
class = mass storage
subclass = ATA
none0 at pci0:31:3: class=0x0c0500 card=0x0074a0a0 chip=0x24c38086
rev=0x02 hdr=0x00
vendor = 'Intel Corporation'
device = '82801DB/DBM (ICH4/M) SMBus Controller'
class = serial bus
subclass = SMBus
puc0 at pci1:0:0: class=0x070002 card=0x00000000 chip=0x01201407 rev=0x00
hdr=0x00
vendor = 'Lava Computer Manufacturing Inc'
class = simple comms
subclass = UART
puc1 at pci1:0:1: class=0x070002 card=0x00000000 chip=0x01211407 rev=0x00
hdr=0x00
vendor = 'Lava Computer Manufacturing Inc'
class = simple comms
subclass = UART
rl0 at pci1:1:0: class=0x020000 card=0x813910ec chip=0x813910ec rev=0x10
hdr=0x00
vendor = 'Realtek Semiconductor'
device = 'RT8139 (A/B/C/813x/C+) Fast Ethernet Adapter'
class = network
subclass = ethernet
sio8 at pci1:5:0: class=0x078000 card=0x0000151f chip=0x0000151f rev=0x00
hdr=0x00
vendor = 'Topic Semiconductor Corp'
class = simple comms
fxp0 at pci1:8:0: class=0x020000 card=0x0317a0a0 chip=0x103a8086 rev=0x82
hdr=0x00
vendor = 'Intel Corporation'
device = '82801DB LAN Controller with 82562ET/EZ (CNR) PHY'
class = network
subclass = ethernet
---Mike
At 11:50 PM 17/05/2004, Bruce Evans wrote:
>On Mon, 17 May 2004, Mike Tancsa wrote:
>
> > We are building a box that needs many serial ports to talk to some legacy
> > low speed (9600) serial devices. Our application (a small daemon written
> > in c) happily talks to the devices and all works well. However, if one of
> > the external devices die or is unplugged, the FreeBSD box will at seemingly
> > irregular intervals lockup hard. The only way to unlock the machine is to
> > either hit the reset button (the keyboard is locked solid-- not even num
> > lock works) *or* if I jiggle the DB9 connector enough so that enough noise
> > shorts across the serial port *or* plug the serial port into a working
> > device that I imagine sends some data on the serial port. The machine then
> > returns to a normal state and all is well. This does NOT happen with the
> > onboard serial ports. Only with a PUC device (we have tried several and
> > its the same result)
> >
> > Does this jog anyone's memory as to what the problem might be ?
>
>It's an interrupt storm of some sort. PCI interrupts are more likely to
>cause one than ISA interrupts because they are more likely to be level
>triggered.
>
> > I have a remote debugger setup and I can send a break and drop the unit
> > into debugger, but kernel debugging is a little beyond our skillset.
>
>Does this break into the locked machine? If so...
>
> > db> trace
> > siointr1(c11d0000,d56dacb0,c02b49e6,c11d0000,10) at siointr1+0xc5
> > siointr(c11d0000,10,a005,c,10060) at siointr+0xc
> > Xfastintr4(c11d0c00,d56dacd8,c02a741a,c11d0c00,c0a3f240) at Xfastintr4+0x16
> > siointr(c11d0c00) at siointr+0xc
>
>... Type "s", then hold down the Enter key to repeat the "s" command until
>control returns here, then keep holding down the Enter key until something
>loops (may take many hundreds of commands). Record all the output using
>a serial console (don't type it in) and send it to me.
>
> > puc_intr(c11af000,63103a,c11d0c00,0,d56dad68) at puc_intr+0x4e
>
>If control returns here, then siointr hasn't looped internally; keep
>going.
>
> > intr_mux(c0a3f240,0,630010,c1360010,c0170010) at intr_mux+0x1f
>
>If control returns here, then the loop is external so it is harder to
>debug (but this is the most likely case).
>
>Going through intr_mux() means that the interrupt is not fast
>(options PUC_FASTINTR). Try that.
>
> > Xresume12() at Xresume12+0x2b
>
>Stop if it gets back here.
>
> > --- interrupt, eip = 0xc02b5b2a, esp = 0xd56dad38, ebp = 0xd56dad68 ---
> > vec12(c11ce980,3,2000,cbf03a00,d56634c0) at vec12+0x2
> > cnopen(c11ce980,3,2000,cbf03a00,0) at cnopen+0x6a
>
>It may be significant that the hang seems to occur while openig the console
>device. Do you have a serial console on the puc device? I thought that
>this doesn't work.
>
> > Any pointers on how to track this down ? It happens both in RELENG_4 from
> > May 12th and 5.2-CURRENT FreeBSD 5.2-CURRENT #1: Thu May 13
>
>Did it work before then? The driver hasn't changed since long before then.
>
>Bruce
More information about the freebsd-current
mailing list