Re: Machine Freezes with SMP+APIC enabled.

From: Lefteris Tsintjelis (lefty_at_ene.asda.gr)
Date: 11/17/03

  • Next message: Carol Overes: "Secure updating of OS and ports"
    Date: Mon, 17 Nov 2003 15:47:08 +0200
    To: Doug White <dwhite@gumbysoft.com>
    
    

    Doug White wrote:
    >
    > On Sun, 9 Nov 2003, Lefteris Tsintjelis wrote:
    >
    > > I have been experiencing random machine freezes when using SMP (Hyper
    > > threading) the past week. There are no core dumps or error messages
    > > displayed anywhere. Load is very minimum. When SMP/Hyperthreading is
    > > disabled machine works with no problems at full load.
    >
    > Hm, smells like Giant deadlock.
    >
    Hi Doug,

    and thank you for all the info. The motherboard of the PC decided to
    finally die on me last week so it looks like it was a hardware deadlock.
    I got it replaced and cvsup to the latest STABLE. It has been working
    very STABLE the past couple of days.

    Best Regards,
    Lefteris Tsintjelis

    > dwhite's Form Letter on Debugging Giant Deadlocks
    >
    > If you are experiencing problems with CURRENT locking up hard, it may be
    > due to a deadlock against the Giant mutex, which controls large parts of
    > the kernel. Symptoms include:
    >
    > . No response to any input
    > . System video console
    > . Network (ping)
    >
    > To debug this, you will need to set up a serial console with some special
    > kernel options. Instructions for booting with serial console are in the
    > Handbook, but you will have to compile with the following kernel options:
    >
    > options DDB
    > options BREAK_TO_DEBUGGER
    > options WITNESS
    > options INVARIANTS
    > options INVARIANTS_SUPPORT
    >
    > Make sure your serial console is capable of sending a Break signal. If
    > not, use "ALT_BREAK_TO_DEBUGGER" instead of "BREAK_TO_DEBUGGER".
    >
    > Enable the serial console and boot the system. Turn on terminal logging.
    > In loader, stop the boot and type "boot -v" at the OK prompt to get
    > additional info during the boot process.
    >
    > Once the system is up, trigger the hang. When the system hangs, issue the
    > Break signal (or if you have used ALT_BREAK_TO_DEBUGGER, press Enter ~ ^E
    > b (tilde, Ctrl-E, b)).
    >
    > If you get the db> prompt, then your hang is probably due to a Giant
    > deadlock. If not, then something else may be at fault.
    >
    > Once in db>, run the following two commands and capture their output using
    > your terminal's logging capability:
    >
    > show locks
    > tr
    >
    > Take these and the boot -v output, put them on a webpage, and send a
    > message to current@freebsd.org carefully explaining what you did to
    > trigger the hang.
    >
    > Good luck!
    >
    > >
    > > Best,
    > > Lefteris Tsintjelis
    _______________________________________________
    freebsd-stable@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-stable
    To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"


  • Next message: Carol Overes: "Secure updating of OS and ports"

    Relevant Pages

    • Re: Recursion bug in -rt
      ... > 1) POSIX states that non-recursive pthread_mutexes hang if locked twice. ... > on the waitqueue so as not to hang the kernel. ... > Since there is no POSIX specification for robust pthread_mutexes yet, ... > application that it is trying to deadlock itself. ...
      (Linux-Kernel)
    • Re: deadlock problem
      ... 285270.1 "The Performance Impact of Deadlock ... problem is 'Performance Impact' or it is 'Instance Hang'? ... Detection' but i don`t understand it clearly. ...
      (comp.databases.oracle.server)
    • Re: equivalent of kern.timecounter.method?
      ... wman writes: ... and problems with processes hanging ... >everything (serial console, etc) is locked. ... >I'm not sure the time and the hang are related, ...
      (freebsd-current)
    • Re: Recursion bug in -rt
      ... I've got a more complete patch for deadlock detection for robust futexes. ... POSIX states that non-recursive pthread_mutexes hang if locked twice. ... Since there is no POSIX specification for robust pthread_mutexes yet, returning EWOULDDEADLOCK to a robust mutex is more in the spirit of robustness. ... For robust pthread_mutexes we clean up if the holding thread dies and we return EWOULDDEADLOCK to inform the application that it is trying to deadlock itself. ...
      (Linux-Kernel)
    • Re: Recursion bug in -rt
      ... >>> on the waitqueue so as not to hang the kernel. ... >>> application that it is trying to deadlock itself. ... where you deadlock detection has to be performed ...
      (Linux-Kernel)