Re: HEADS UP: netipx mega-MFC (1/2)

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

  • Next message: Godwin Stewart: "Re: Any hosting companies offering FreeBSD 5.3 yet?"
    Date: Sat, 26 Feb 2005 10:39:38 +0000 (GMT)
    To: Bob Johnson <bob89@bobj.org>
    
    

    On Sat, 26 Feb 2005, Bob Johnson wrote:

    > I'm wasn't planning to be near that system again until Monday, although
    > if you need details about my configuration I can dig them out remotely
    > and send them to you. I'm not brave enough to risk another panic when
    > I'm not physically there to reset the system, but if you are willing to
    > work on it this weekend I'm willing to drive over there and test it. I
    > would REALLY like to see the Netware stuff working in 5.4R.
    >
    > A few weeks ago I had the same panic when I tried to set up Netware
    > support on 5.3-Release. It went away when I updated to -stable then (I
    > believe it was around Jan 24), but the packets going out on the wire
    > were not quite right, so I couldn't actually use it for networking.

    So to confirm what I think you're saying:

    - 5.3-R panicked configuring ipx/ncp/nwfs against a Netware server.
    - 5.3-S up until my recent changes didn't panic, but there appeared to be
      on-the-wire corruption.
    - 5.3-S (5.4-P) as of yesterday now panics again.

    So it sounds like were still dealing with at least two problems: some sort
    of panic, and an on-the-wire problem. I think the first course of
    business is to get the panic fixed -- chances are, it's a pointer botch of
    some sort, if you're seeing a fault. Here are some things that you could
    do to help me debug these problems:

    (1) Compile your kernel with DDB/KDB, and configure a dump partition.
        Make sure you have a kernel with debugging symbols on-hand. If you've
        not done this before, instructions can be found in the handbook. Many
        bugs can be debugged using just DDB/KDB, but a dump for post-mortem
        analysis can be quite helpful for more complex bugs. Even if we don't
        manage to get kernel dumps, we'll need the kernel with debugging
        symbols to convert addresses into lines of source code.

    (2) When reporting a panic, please report the exact steps it took to get
        to the panic. I can imagine a number of bugs we might have that might
        trigger at different points, and I'm not currently clear on which it
        is. For example, the IPX code might panic when ifconfig runs to
        configure an address, or the panic might happen at file system mount
        time when you call mount_nwfs. Or does the panic happen later
        on first file access, or after some period of activity? Knowing which
        of these it is would be very helpful in narrowing down the source of
        the problem.

    (3) When reporting a panic, it's helpful to have as much of the trap or
        panic output as possible. I don't know if you're currently using a
        serial console or not, but I find that a serial console is very
        helpful in gathering debugging information, as it makes it easy to
        copy and paste output. If you get into DDB following the panic, the
        commands "show pcpu", "ps", and "trace" are almost always good
        starting points for debugging. With a serial console, sending that
        output by e-mail will be dramatically easier :-). When not running
        with a serial console, many people will use digital cameras to take
        pictures of debugger output, because that's till more convenient than
        trying to write it down or type it in (lots of hex digits :-).

    I'll be pretty available this weekend to help with debugging this. Not
    sure if you've done it yet, but it might be useful to boot the previous
    kernel and just make sure that the panic only happens with the new kernel,
    and that it wasn't triggered by some other change in your environment.
    That seems fairly unlikely, but it's good to check assumptions because it
    can save a lot of time and confusion :-).

    Robert N M Watson

    _______________________________________________
    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: Godwin Stewart: "Re: Any hosting companies offering FreeBSD 5.3 yet?"

    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: 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)
    • Re: Panic on boot with new ACPI-CA
      ... >> kernel and modules. ... Memguard sets page permissions so we can ... > available and I don't have a serial console here. ... Rebuilt everything and I see no panics now. ...
      (freebsd-current)
    • Re: Logging a kernel panic (remotely)
      ... panics from time to time. ... Unfortunately we have no remote console. ... I'll try and get a serial console hooked up at some point but I may not be ... The problem as I understand it is that when a kernel ...
      (Debian-User)
    • Re: Logging a kernel panic (remotely)
      ... panics from time to time. ... Is there a way to get the kernel to either to to write the panic to disk or to log it remotely? ... I'll try and get a serial console hooked up at some point but I may not be able to get on site for a few weeks. ...
      (Debian-User)