Re: FreeBSD 5.3 hangs on high network load

From: Robert Watson (rwatson_at_FreeBSD.org)
Date: 02/17/05

  • Next message: c0ldbyte: "Re: [FIXED] FreeBSD 5.3 hangs up on high network load" 
    Date: Thu, 17 Feb 2005 11:59:52 +0000 (GMT)
To: Juan Rodriguez <juan.fco.rodriguez@gmail.com>

    On Wed, 16 Feb 2005, Juan Rodriguez wrote:

    > I've cvsup'ed the kernel sources a few hours ago (RELENG_5), and I've
    > recompiled.
    >
    > Now I cannot boot, it gives me "kernel panic" when booting on
    > "rlphy0"....this is really very annoying. I'm at work now, I cannot give
    > you more details...it took me 4 hours to recompile the kernel, so Im not
    > willing to do this again, if you are really interested in debugging, I
    > will need your collaboration, I can give you an account on my system if
    > you want to.

    Most kernel panics can be debugged using easily extracted information from
    a crash. If you're interested in helping to track this problem down so it
    doesn't persist in future releases, you'll want to do the following:

    - Compile the kernel with the following entries in its config file:

      options DDB
      options KDB
      makeoptions DEBUG=-g
      options BREAK_TO_DEBUGGER

    - Ideally, hook up a second system as a serial console for the first
      system, perhaps using a null modem cable. This will allow you to copy
      and paste debugging output into an e-mail message, which can simplify
      things.

    When the system crashes with a panic and the above options are present, it
    will drop to the DDB kernel debugger instead of rebooting or hanging. If
    you're using a serial console, the output of the debugger will be visible
    there. The panic message will be displayed, as well as fault details if
    there was a fault leading to the panic. At that point "trace" will give a
    backtrace. If you could copy and paste that information into an e-mail,
    we can then try to track it down.

    Debugging the wedge/hang you were seeing earlier is also something we can
    try to do using the same technique, but they can be a bit harder to track
    down. In that situation, the break to debugger option above will allow
    you to break to the debugger on the console (ideally, the serial console,
    again, since you can more easily copy-and-paste the output).

    There's a chapter in the FreeBSD handbook on setting up kernel debugging
    so that you can report bugs with sufficient detail that we can debug them.
    Let me know if you have any questions.

    Robert N M Watson

    >
    > thanks
    >
    >
    >
    >
    > On Wed, 16 Feb 2005 07:16:46 -0500 (EST), c0ldbyte
    > <c0ldbyte@myrealbox.com> wrote:
    > > On Wed, 16 Feb 2005, Robert Watson wrote:
    > >
    > > >
    > > > On Wed, 16 Feb 2005, Juan Rodriguez wrote:
    > > >
    > > >> Just for your information (because I guess there's nothing else we can
    > > >> do....), I will describe the setup I've got in case anyone would like to
    > > >> reproduce the problem and try to fix it.
    > > >>
    > > >> I'm using FreeBSD 5.3.0 RELEASE on an Pentium I MMX 233, with 128 MB of
    > > >> RAM (minus 1 MB that my onboard VGA card takes off). The motherboard is
    > > >> ASUS SPv97 (or something like that)
    > > >
    > > > If possible, the first thing would be to try moving to the head of
    > > > 5-STABLE to see if the bug has already been fixed there already or not. A
    > > > significant number of interesting bugs have been fixed since the release
    > > > of 5.3. If that doesn't correct the problem, the next thing to do is to
    > > > take a look at the section of the handbook on reporting kernel panics and
    > > > hangs. It would be quite interesting to know if the machine still
    > > > responds to pings once it has appeared to hang. There have been reported
    > > > problems with realtek network cards, it would probably be premature to
    > > > blame the hardware at this point.
    > > >
    > >
    > > If im correct ive allready heard of this issue being solved. And should
    > > allready be patched in. Checkout the latest RELENG_5_3 and build your
    > > kernel over again and run that for a while "FreeBSD 5.3-RELEASE-p5"
    > > otherwise try a different version of 'samba*' or see if there are some
    > > tweaks in the 'LINT' for the card itself. Im not quite sure why you would
    > > run in safe mode but whatever trips your trigger. 'mount_smbfs' instead
    > > of running 'samba' itself might also help you out a bit.
    > >
    > > Best regards
    > > -- c0ldbyte
    > > _______________________________________________
    > > freebsd-net@freebsd.org mailing list
    > > http://lists.freebsd.org/mailman/listinfo/freebsd-net
    > > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
    > >
    > _______________________________________________
    > freebsd-net@freebsd.org mailing list
    > http://lists.freebsd.org/mailman/listinfo/freebsd-net
    > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
    >

    _______________________________________________
    freebsd-net@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-net
    To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"

  • Next message: c0ldbyte: "Re: [FIXED] FreeBSD 5.3 hangs up on high network load"

    Relevant Pages

    • Re: Random panics with 5.3-REL, SMP
      ... "Random panics" is a little vague as a starting point, ... explicit call to panicby code that has detected a failure of a kernel ... A stack trace can be generated using the "trace" ... - In terms of debugging information, it would be very useful if you could ...
      (freebsd-current)
    • Re: HEADS UP: netipx mega-MFC (1/2)
      ... 5.3-S as of yesterday now panics again. ... Compile your kernel with DDB/KDB, ... Make sure you have a kernel with debugging symbols on-hand. ... serial console or not, but I find that a serial console is very ...
      (freebsd-stable)
    • Re: Big problems with 7.1 locking up :-(
      ... Sometimes these debugging tools are able to convert hangs into panics, which gives us much more ability to debug them. ... Lock order reversals are warnings of potential deadlock due to a lock cycle, but deadlocks may not actually result, either because it's a false positive, or because a cycle didn't actually form. ... Features like WITNESS and INVARIANTS may change the timing of the kernel making certain race conditions less likely; I'd run with them for a bit and see if you can reproduce the hang with them present, as they will make debugging the problem a lot easier, if it's possible. ...
      (freebsd-stable)
    • Re: Incompatibility between ACPI and the X server
      ... > escape to the kernel debugger. ... You can set up a serial console and use that to hit the debugger. ... Check the kernel debugging section of the Handbook for details. ... It sounds like, though, that the ACPI tables on your system are not ...
      (freebsd-current)
    • Re: panic after ifconfig gif0 destroy
      ... Can you recompile a debugging kernel with DDB support? ... panics it will drop the console into the DDB debugger. ... If you can hook it up to a serial console you can just copy&paste ...
      (freebsd-current)