> From: Ross Brattain <[EMAIL PROTECTED]> > > [ oops with ohci ] > > ksymoops 2.4.1 on i586 2.4.5-ac15. ... Looking at that code, it seems there's only one place that "shr $0x1c" happens in that code (for TD_CC_GET), which narrows this down a bit: this oops looks like it's right after the first dma_to_td() call, and seems to be because urb->hcpriv (for an urb being unlinked) is bogus. If your compiler is generating code like mine, then there's another bogus value sitting in a register, making me wonder if something (else) isn't trashing memory. This happened too soon after OHCI startup for that code to have much of a chance (or reason!) to do that. Does this happen with the current Linus kernel? (2.4.6-pre, or 2.4.5; Alan hasn't synced to 2.4.6-pre, I seem to recall.) Or when you don't connect that Belkin stuff to the UHCI controller? You didn't say what you were doing to trigger this behavior. There's also some BIOS level strangeness here: > Jun 20 16:05:55 ross kernel: PCI: Found IRQ 11 for device 00:0a.0 > Jun 20 16:05:55 ross kernel: IRQ routing conflict in pirq table for device 00:0a.0 > Jun 20 16:05:55 ross kernel: usb-ohci.c: USB OHCI at membase 0xd085b000, IRQ 9 > Jun 20 16:05:55 ross kernel: usb-ohci.c: usb-00:0a.0, OPTi Inc. 82C861 Quite a lot of hardware seems to be on IRQ 9; sharing should be no problem, but "routing conflict" doesn't sound good. It might be good to try putting that card into a different slot, or to run with various memory debugging hooks (like forcible slab poisoning, easy to config in the AC kernels) enabled. - Dave _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: http://lists.sourceforge.net/lists/listinfo/linux-usb-users
