Problems with the demo CD and qemu
Cedric.Roux at eurecom.fr
Fri Feb 11 20:05:31 CET 2005
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.
(By the way, the l4linux kernel won't compile with 4k stacks,
you never call irq_ctx_init, maybe you should call it in
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.
> <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,
More information about the l4-hackers