L4-Linux worked on 486!
edmundo at rano.demon.co.uk
edmundo at rano.demon.co.uk
Mon Aug 16 01:30:36 CEST 1999
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
More information about the l4-hackers
mailing list