I know there are people on this list who have a heck of
a lot more experience developing/debugging kernel PCI
drivers than I do. So thought I'd see if there are any good
suggestions.
I've got a scenario that's puzzling me, it's a hard kernel hang
that gives me no clue as to what's going wrong. This is on
a single processor, compiled with SMP (so spinlocks run),
with KDB, spinlock debugging, and basically every debug
hook enabled. (AC kernel series, I'm not quite up-to-date
but the failure mode has been around for some time.)
The driver is the EHCI driver, so there are PCI level
interactions. I don't think this is a case of the device
giving me endless interrupts, though I'll verify that
again. When the machine locks up, no keyboard tricks
(pause to kdb, or alt-sysrq) wake the machine up, and
the nmi watchdog doesn't bark (so presumably not a
spinlock).
How should I try to figure out what's going on here?
Is this "need some hardware analyser" territory?
Re-reading the code hasn't helped much, though it's
help nail a few other problems.
This is an error path (of course!), after unlinking an
URB from hardware queues. The lockup happens
a second or two(!) after the last controller request;
I called wait_ms() in a loop from the only thread
issuing such requests, and it didn't print twice.
Naturally when things work, I get many MBytes/sec
of throughput, and most errors don't make this
happen, but this particular problem is frustrating.
- Dave
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
