Hi again L4 Hackers,
here is what's going on.
ethernet card (ne2k-pci) sends an IRQ (number 9).
The IRQ thread passes wait_for_irq_message_hw then calls do_IRQ.
do_IRQ does its stuff, then calls irq_exit.
In irq_exit, we have a softirq pending (don't ask me why, that's just
the way it is), so we call do_softirq.
We then enter net_tx_action.
I then pass the details. To be short, we enter the TCP/IP stack,
do some stuff, then go back into the ethernet driver code,
in ei_start_xmit (8390.c).
This function calls disable_irq_nosync, which calls
desc->handler->disable, which is in fact do_l4lx_irq_dev_disable.
This one will call switch_to_irq_idle_loop.
I don't exactly know what happens next (lack of time), but if
I remove the call to switch_to_irq_idle_loop (and of course
the corresponding call to switch_to_irq_thread) in
do_l4lx_irq_dev_disable (respectively do_l4lx_irq_dev_enable)
everything works fine (well, I don't get crashes when I do
my telnet anymore).
My questions are:
1 - why to call this switch_to_irq_idle_loop? what's
the purpose of it?
2 - if I remove this call, do I get a wrong system or
is it ok? what do I lose if it is ok (speed?)?
3 - a comment in switch_to_irq_idle_loop says:
/* Looks like interrupts are disabled multiple times in 2.6 */
shouldn't you use a counter in switch_to_irq_thread and
only do the switch if it's back to zero? (I mean, imagine 2
calls to switch_to_irq_idle_loop followed by 1 call to
switch_to_irq_thread, should it really come back from idle
at this point?)
Thank you by advance.
Best regards,
Cedric.
(By the way, the l4linux kernel won't compile with 4k stacks,
you never call irq_ctx_init, maybe you should call it in
init_IRQ?)
On Thu, 10 Feb 2005, Cedric Roux wrote:
> Hello L4 Hackers,
>
> here follows a description of what I did. My questions come to the end
> of the message. Sorry for the length, but I wanted to be clear.
[SNIP]
> <0>Kernel panic: Aiee, killing interrupt handler!
> <0>In interrupt handler - not syncing
>
> I would like to know:
> 1 - what's going on? I suspected some kind of weird IRQ firing because
> of the use of qemu, but as far as my investigations have told me,
> it doesn't seem to be that. I believed that one IRQ went to fast
> after a first one, so the linux was not yet out of the driver
> code, but the interrupts were enabled, thus crashing everything.
> I think I was wrong, no?
> 2 - how to solve this. What code/doc should I read to debug it, where
> to dig. I am a bit confused for now.
>
> Thank you by advance for your help.
>
> Best regards,
> Cedric.
_______________________________________________
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
