I've investigated the ready queue after hitting "irq still active" by doing "p (class thread_t*)0xc0000000" and "p $.ready_next" repeatedly. In each case the threads corresponding to irqs 5 and 14 seemed to be ready. In one case, so was the thread corresponding to irq 0.
Just to confirm: irq 5 = 0xc014a800, irq 14 = 0xc014f000
I think I'm dealing with irq 5 when the error occurs because the value 0x20 is in eax and ebx.
So presumably I should investigate the kernel stack for irq thread 14, which was apparently preempted in some mysterious fashion by an interrupt thread of lower priority. I see there's a kernel_sp in thread_t. Can anyone tell me how to get gdb to analyse that stack for me, to save me picking out the values that look like program addresses from the hex dump by hand?
By the way, /proc/interrupts says:
CPU0 0: 38599 L4-IPC-timeout timer 1: 348 L4-IPC-IRQ keyboard 2: 0 L4-IPC-IRQ non-Linux 3: 0 L4-IPC-IRQ non-Linux 5: 26 L4-IPC-IRQ NE2000 8: 0 L4-IPC-IRQ non-Linux 13: 0 L4-IPC-IRQ math error 14: 18002 L4-IPC-IRQ ide0
I haven't been able to contact os.inf.tu-dresden.de, so I'm still using the same irq.c as before I went on holiday. It seems to be 1.16 with Michael's patch that was sent to l4-hackers on 1999-07-23 plus the following patch:
--- irq.c.mh Sat Jul 31 18:53:15 1999 +++ irq.c Sun Aug 15 18:53:35 1999 @@ -1199,10 +1199,6 @@ __sti(); #endif
-#ifdef SANITY - irqs_in_progress &= ~(1 << TIMER_IRQ); -#endif - l4_i386_ipc_receive(L4_NIL_ID, 0, &dummy, &dummy, L4_IPC_TIMEOUT(0,0,4*39,12,0,0), /* ca. 10 ms */ @@ -1242,7 +1238,11 @@ handle_irq(TIMER_IRQ, cpu); /* we're unblocked -- execute handler */
spin_unlock(&irq_controller_lock); - + +#ifdef SANITY + irqs_in_progress &= ~(1 << TIMER_IRQ); +#endif + execute_bottom_halves(TIMER_IRQ); } } /* timer_irq_thread */
Edmund