edmundo@rano.demon.co.uk writes:
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?
Gdb has a command "frame <frame-address>" which should make it possible to select a different stack frame. However, this feature seems to be broken for x86 (at least in Gdb 4.17).
I have made a hack to Gdb which lets you use a command "frame <frame-address> <program-counter>"; this command selects a different frame, and you can use "up" and "down" to look at nested or parent frames (sorry, no "backtrace"!). This hack only seems to work if the current frame is valid, but at least it's something to start from. I've appended a patch below.
It probably would be worthwile to develop a real fix for Gdb...
I haven't been able to contact os.inf.tu-dresden.de,
The network should have been back up since Monday morning.
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:
I've applied your patch. Thanks!
[ from a different email: ]
Also, has anyone other than me experienced the "irq still active" problem? I have seen mention of a PIC bug in certain Intel 486s; it would be nice to know for certain that this problem isn't specific to just my hardware ...
No, it's not: I've just been able to reproduce your problem. (This took a while because I first had to fix a different synchronization problem I ran into when I induced the test load you described -- `cksum' + heavy CVS usage on network-mounted disk.)
I'll have a look at the problem (and the data you provided -- thanks for digging in!) and post again when I know more.
Later, Michael
l4-hackers@os.inf.tu-dresden.de