On Sat, 1 Jul 2000 22:07:09 -0400,
Pete Toscano <ptoscano@netsol.com> wrote:
>as a recap, i'm running a dual p3 600 machine (test2 smp kernel), with
>512M ram, asus p2b-d mobo, and matrox g400 max video card.
>
>when x locked up this time, i checked to make sure it was just as dead
>as before... no keyboard response whatsoever (no capslock, no numlock,
>no alt-sysreq) and no mouse movement. from another virtual console on
>my console box, i tried pinging my locked up box. all pings died. i
>couldn't ssh to it, _but_ i was able to log in from console and that
>seemed to work just fine. killing all x-related processes didn't
>release my keyboard and monitor though. i eventually had to reboot from
>console.
Either some interrupts are not being serviced or some code has grabbed
a lock and not let go. When you use the keyboard, does interrupt 1
change (cat /proc/interrupts)? When you ping does the network
interrupt change? If they are not changing then you have a low level
problem, however the fact that you can use the serial console and run
programs indicates that interrupts are being serviced.
If interrupt counts are changing then the problem is a higher level
lock. Enter kdb (control/A on the serial console) and use the ps and
btp commands to list the state of each process, look for any have
section name .text.lock anywhere in the backtrace. set LINES=100
first, btp can produce a fair bit of output.
First find all processes waiting in .text.lock. Then set BTSYMARG=1
and rerun btp on all the processes in .text.lock, save the back trace.
Also take the EIP from the .text.lock entry and disassemble the code
around that area. Use "id" to disassemble the code at
(.text.lock.eip-0x20), you will have to adjust the address you give id
until you get clean ix86 instructions. Mail the backtrace and id
output to l-k, it will tell somebody where the code is hanging.
It is a good idea to capture all the serial console output for future
reference. How you do that depends on the comms program you are
running on the second machine.
Mail me off list if you have problems with kdb.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Jul 07 2000 - 21:00:10 EST