In message: <[email protected]> Joerg Wunsch <[email protected]> writes: : As Joerg Wunsch wrote: : : > OK, at kernel #11 :), I can now say it's the USB subsystem. Just : > leaving "device usb" (and also "device uhci") in makes it work. : > : > So the question appears to be why keeping the USB driver in makes the : > interrupt storm detection work... : : Maybe that's the relationship? : : camel# dmesg | fgrep 'irq 11' : vgapci0: <VGA-compatible display> mem 0xe0000000-0xe0ffffff,0x70000000-0x703fffff,0x70400000-0x704fffff irq 11 at device 0.0 on pci1 : cbb0: <TI1251 PCI-CardBus Bridge> mem 0x50102000-0x50102fff irq 11 at device 2.0 on pci0 : cbb1: <TI1251 PCI-CardBus Bridge> mem 0x50101000-0x50101fff irq 11 at device 2.1 on pci0 : uhci0: <Intel 82371AB/EB (PIIX4) USB controller> port 0x8400-0x841f irq 11 at device 7.2 on pci0 : xe0: <Intel EtherExpress(TM) PRO/100 PC Card Mobile Adapter16> at port 0x100-0x10f iomem 0x20000000-0x20000fff irq 11 function 0 config 1 on pccard1 : : I guess vgapci0 doesn't really use interrupts, so this leaves cbb0/1 : and uhci0 sharing an interrupt. Apparently, the interrupt storm at : cbb gets detected correctly as long as at least another device : installs an interrupt handler on irq 11. : : Does that make any sense as an explanation? : : I can live with the current situation (and proceed in setting up that : machine as a firewall, which was my original intention), although I : could also spend another day into debugging that symptom if someone : can get me some directions.
Does this happen on a cold boot or a warm boot? Warner _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[email protected]"
