2005/12/22, Andreas Mohr <email@example.com>:
[resending directly - probably not subscribed to list...]
In fact i'm just using another mail address than the one I subscribed with.
But i don't know how to change subscriptions... Well, I didn't look at it in fact...
On Thu, Dec 22, 2005 at 11:54:25AM +0100, Francois Barre wrote:
> Well, I got some news about that...
> Yesterday night it crashed badly, but I was running the console. I was in
> the hurry to reboot the system, so I could not take time to copy by hand the
> full kernel ooops (full screen, and I guess more). Anyway, the callstack was
> showing acxpci_i_interrupt on top, called by various irq* related stuff, but
> originating from the sbp2 (ieee1394 mass storage driver) module. Now i'm
> starting to wonder.
Hmm, AFAIK the call stack shouldn't "originate" from the sbp2 driver.
Anyway, my glass bowl is broken ;)
Well, the fact is, it does not originate from sbp2. IIRC, first calls talked about ioctl, which are calling sbp2 through the whole block_* and bkdev_* ioctl stuff. Then, somewhere, the stack looks like saying 'hey, I shall also deal with some acxpci interrupts now !'. I really don't remember the calls bridging sbp2 and acx. But as far as I understood it, if an irq is triggered while another one is actually processed, the call stack would be reset (not the right word, I guess I need hollidays), but well whatever, an irq processing shall not be called within another irq processing.
At this time, I think about two things :
- My firewire drives sometimes are long to react. Don't really know why, but from time to time they just take several seconds to answer a question. Especially on high usb traffic. Maybe there's a irq timeout/mishandling somewhere... On sbp2 side ?
- I know it, my hardware (especially cpu) *can* be buggy. I will heavy-test my RAM one of these days, to be shure of it. But maybe the cpu just gets jammed for no reason...
> You should try a cat /proc/interrupts to see whether we even have a shared
> IRQ case here, which might be problematic then.
Good idea. Great idea. Why on earth didn't I think of it by myself...
> Maybe ACKing all IRQ types beforehand is problematic, too (one might want
> to try ACKing them individually, after they have been handled).
What do you mean by ACKing irqs ? Being shure they really appeared and did not raise by any kind of magic ?
By any chance, is there a special irq-paranoid compile option for acx ? I would like it.