> I forgot to mention that most of the debugging steps you suggested had > already been applied - USB debug, USB storage debug, DEBUG_KERNEL, > DEBUG_SLAB, DEBUG_IOVIRT. None of these alters the failure mode in any > perceptible way.
OK, that's useful to know. The first several wouldn't affect behavior, but DEBUG_SLAB and DEBUG_IOVIRT might have (primarily DEBUG_SLAB). > I have not compiled in KDB, as it doesn't sound as if it would be > terribly useful under the circumstances - I'd never be able to look at a > stack dump if the screen is blank and the BIOS running through cold > boot. I'd probably need a hardware debug card as, correct me if I'm > wrong here, the reboots are being triggered by some sort of bus lockup? We don't actually know what's causing them. KDB can intercept some kinds of errors before they morph into secondary failure modes (like rebooting through BIOS) ... there's a reasonable chance it'll get you some useful new info. The problem here is that until we get some hints about what's making that reboot happen, it's hard to get any traction on this problem. In the few cases I've seen such problems in the past, KDB was what turned up the hints. > Me, I'd be more tempted to get my hands on a diagnostic suite that would > exercise various USB commands in ascending complexity until the one that > triggers the reboot is isolated. The EHCI-HCD driver seems to have no > trouble passing back and forth the smaller device-inquiry commands and > handshake. If you find such a suite that runs on Linux, let me know! I suspect that's the kind of thing that won't happen till someone funds it, and it would be _really_ useful to test all the host controller drivers. (To re-iterate, and as I think you're aware, the driver seems to have no trouble even with larger commands except on your particular hardware...) > The kernel evidently doesn't know much about the Hint HB1-SE33, as it > warns "assuming transparent" in its boot messages. Hopefully, it was a > good assumption! Yes, one hopes ... but I don't know much about PCI bridges. > It's built onto the card; short of some time with the Dremel tool and a > schematic set, I'm out of luck there. :-P However, note that when used > with just OHCI in USB 1.x mode, it seems to be very reliable! It's only > when going to 2.0 that the reboots occur. That is, it's only when up to forty times the quantity of PCI traffic may be streaming by that you see these problems? :) You wouldn't happen to be able to borrow a pure USB 2.0 card from someone to sanity test, would you? So far the strangest thing about your hardware appears to be the fact that your PCI card has an internal bridge. > Oh, my SL-75DRV2 *is* purple! It's one of the later, ECN'ed boards. Was it really as loud a color as that picture showed? I've never yet seen add-in PCI cards that were color-sensitive, but as they say, there's always a first time ... :) - Dave ------------------------------------------------------- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
