On Sun, 13 Jun 2004, Don Bowman wrote: > ... OK, this did the trick, i got into db. > ... > The system was locked up, so when i pressed the key > sequence to enter the debugger, it timed out stopping > the other cpus. Everybody is in sched_switch and idle??? > ... > siointr1(c554d800) at siointr1+0xd0 > db> t 0 > sched_switch(c074bfa0) at sched_switch+0x60 > mi_switch(1,0,1,c0c21d2c,c0562ba4) at mi_switch+0x1a0 > sleepq_switch(c074bde0,0,c0c21d54,c054dd12,c074bde0) at sleepq_switch+0x135 > sleepq_timedwait(c074bde0,0,23,0,0) at sleepq_timedwait+0xc > msleep(c074bde0,0,44,c06ecd01,2710) at msleep+0x40a > scheduler(0,c1ec00,c1e000,0,c0436065) at scheduler+0x167 > mi_startup() at mi_startup+0x96 > begin() at begin+0x2c > db> t 1 > sched_switch(c53e0540) at sched_switch+0x60 > mi_switch(1,0,0,ed097c18,c0562b60) at mi_switch+0x1a0 > [... 4 CPUs at sched_switch+0x60] sched_switch holds sched_lock which masks interrupts. This accounts for the processes not being stoppable. I don't see how they can spin in sched_switch() or even all stop at the same place. Perhaps they called somewhere that is looping and the traceback isn't showing everything. This is most likely for cpu_switch(). OTOH, IIRC there is a bug in stopping CPUs that breaks seeing where they are stopped. Try looking at where they reported to be when they are stopped for entering ddb while the system is running normally. BruceReceived on Sun Jun 13 2004 - 11:46:14 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:57 UTC