lkml.org 
[lkml]   [2000]   [Jul]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: xfree and devel kernels > 2.3.99-pre6
    Date
    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/

    \
     
     \ /
      Last update: 2005-03-22 13:57    [W:5.356 / U:0.024 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site