> >Oopses normally dump me into KDB, and that's not happening.
> >So I don't think there's an oops involved.
**** From Georg Acher:
> What CPU/chipset do you have?
PII/300 (Klamath), PIIX4. Similar failure mode reported on another chipset,
though that problem may now be fixed.
> Have you tried some BIOS/PCI options (latency, posted write etc...).
This BIOS doesn't offer any such pci options.
**** From Mark McClelland:
> When things get this bad, I hook up the serial console and insert a few
> widely spaced printk()'s into the suspect functions. Then I do a binary
> search until I pinpoint the exact point of failure.
The problem is that nothing seems to be happening in _my_ driver when
the system hangs. No requests coming in (to root hub or other device),
or interrupts (see below). No printks fire ... and in the scenario I'm using
lately, none _should_ fire, since for a couple seconds, nothing has gone
into that driver. (Except the root hub timer interrupt, which reported that,
as expected, nothing was reported from reading that PCI register data.)
So there's nothing to actually finger my code, though I'm reasonably
convinced that's where the problem is lurking.
> From my experience, I would be very suspicious of something going very
> wrong in your interrupt handler.
The evidence seems to be that there's no interrupt happening. I did hook
up a serial console, made it printk first thing ... nothing. (This is what's
supposed to be happening: no interrupts from this driver.)
More problematic is that if I stick such prinks into arch/i386/kernel/irq.c
handle_IRQ_event(), that stops seeing interrupts too ... even timer irqs.
They happen right up to the point of lockup though.
Why would a machine lock up like that, with _no_ diagnostic to suggest
that there was a software-detected problem?
- Dave
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
