Re: 5.x/6.x network stability

From: Robert Watson (rwatson_at_FreeBSD.org)
Date: 10/29/05

  • Next message: Bryan Fullerton: "Re: HEADS UP! 6.0-RELEASE coming"
    Date: Sat, 29 Oct 2005 19:43:40 +0100 (BST)
    To: Carl Makin <carl@xena.IPAustralia.gov.au>
    
    

    On Fri, 28 Oct 2005, Carl Makin wrote:

    > I've been having a heap of trouble with the primary network interface on
    > a box that was running 5.4 and recently upgraded to 6.0-Beta5 where the
    > interface would just go dead. Nothing in ifconfig or syslog or dmesg
    > would indicate a problem, but nothing would go in or out. The only way
    > to fix it was reboot.
    >
    > A week ago, after searching the mailing lists I realised it might be the
    > fact that I was using Netatalk and that might not be MP safe so I set
    > debug.mpsafenet="0" in /boot/loader.conf and the box has been stable
    > ever since.
    >
    > Is anyone looking at the kernel Netatalk code? Is this likely to be the
    > real reason for the problem?

    I've not seen any reports of problems, but have had my hands in it
    recently. I'm happy to help try and debug the issues, but my preference
    (if possible) would be to do this on 6.x and then backport fixes to 5.x.
    While the netatalk code does see testing, it's not all that widely used,
    and so it's possible there are lurking issues. netatalk is, in theory,
    MPSAFE, but there could be lasting race conditions. debug.mpsafenet puts
    Giant back over the stack, but also substantially changes the timing, so a
    race condition in a device driver or the socket code could also be
    indicated. Could you:

    - Submit a PR describing the details.
    - Include output from dmesg, ifconfig, and other information you might
       thing that would be useful. Indicate which interface is the one that is
       hanging.
    - Compile the kernel with INVARIANTS, INVARIANT_SUPPORT, WITNESS, DDB, and
       BREAK_TO_DEBUGGER. See if you get any debugging warnings around when
       the hang occurs. Note: these options have a large performance impact.
    - Once the interfae is dead, can you use it for IP traffic?
    - Once the interface is dead, if you run tcpdump on it, do you see
       traffic?
    - Once the interface is dead, if you generate traffic, do other hosts see
       it?
    - If you generate traffic, does tcpdump see your own traffic?

    Thanks,

    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: Bryan Fullerton: "Re: HEADS UP! 6.0-RELEASE coming"

    Relevant Pages

    • Re: Death of Usenet predicted, film at 11
      ... protocols when they pry them from my dead, ... the heyday of Usenet I used to read more than 15 active groups. ... I must admit I like Gmail's interface, ...
      (sci.lang.japan)
    • Re: DBMS clients
      ... The thing that a db interface does not have monthly updates does not ... necessarily mean that it is dead. ... > a non-dead interface to RDBMS systems. ...
      (comp.lang.tcl)
    • Re: Hard drive failure / system board failure?
      ... message sort of shows that either the SCSI configuration is wrong or ... the interface is dead. ...
      (comp.sys.sgi.hardware)
    • Syskonnect SK0 not passing any data
      ... trying to get my Syskonnect SK-9843 revision 2.0 to work I now have an interface ... but otherwise dead, i.e. passes no traffic. ... I´m planning to use the interface for sniffing but tcpdump just does not receive ... This message was sent using IMP, the Internet Messaging Program. ...
      (freebsd-net)
    • Re: Solaris10-amd64, Driver Installation Problem
      ... It said okay and that i must restart. ... >I also tried the SysKonnect Driver SKGEsolx. ... >On a reboot it was the same, no device, but also no entry in the dmesg. ...
      (comp.unix.solaris)