Re: Forcedeth driver bug

From: Kalin KOZHUHAROV (kalin_at_ThinRope.net)
Date: 06/23/04

  • Next message: Christoph Hellwig: "Re: [PATCH 2.6] Altix serial driver" 
    Date:	Wed, 23 Jun 2004 23:56:08 +0900
To: Mikael Bouillot <xaajimri@corbac.com>

    Mikael Bouillot wrote:
    > Hi all,
    >
    > I'm having trouble with the forcedeth driver in kernel version 2.6.7.
    >>From what I can see, it seems that incoming packets sometime get stuck
    > on their way in.
    >
    > What happens is this: some packet enters the NIC, and for some reason,
    > it doesn't come out of the driver. As soon as another incoming packet
    > gets in, both packets are handed down by the driver.
    >
    > It is usually invisible during normal TCP operation, as there are
    > several packets in flight and the stuck packet gets pushed down by the
    > one following it very soon. But for lockstep protocols like SMB, it very
    > annoying as it means you get "blanks" of 2 to 5 seconds during the
    > transfer.
    >
    > I can reproduce this very easily with a modified version of ping. I
    > do a flood ping from another machine to the one with the nvnet NIC, but
    > I modified ping to send a new packet if one gets "lost" only 10 seconds
    > later instead of after 10 ms. The result is that after a couple hundred
    > ping-pong at full speed, one ping gets stuck. After 10 seconds, another
    > ping is sent and both pong come back.
    >
    > This didn't happen with the proprietary nvnet driver on kernel 2.4.24.
    > My hardware is a nForce 2 mobo (in a shuttle SN45G barebones).
    >
    > Is this a know bug? If someone working on it already or should I
    > investigate the matter further? Please CC any reply to me as I'm not on
    > the list.

    Search http://groups.google.com/ or somewhere else in LKML for "new device support for forcedeth.c"

    Try the latest patch ( forcedeth_gigabit_try17.txt was the one I tested last) and report back.
    The driver has undergone quite a lot of patching lately.
    AFAIR, while testing it, similar effect was observed, but the it was way broken anyway.

    Kalin. 

    -- 
||///_ o  *****************************
||//'_/>     WWW: http://ThinRope.net/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
  • Next message: Christoph Hellwig: "Re: [PATCH 2.6] Altix serial driver"

    Relevant Pages

    • Re: Filter Hook
      ... the callback routine is been invoked at DISPATCH_LEVEL. ... If you really have to keep such a queue for the packets, then the IP filter driver is not suitable for your needs since you have to process all the packets in the callback routine without any wait actionand return it to the tcpip driver immediately when the callback routine returns. ... What IRQL are you running at when you crash, ...
      (microsoft.public.development.device.drivers)
    • Re: MAC bridging and sniffing packets with specific Ethertype
      ... That is, the Ethernet adapters are bound to the Mbridge driver (which, since ... Mbridge handles the bridging of packets between the adapters. ...
      (microsoft.public.windowsce.embedded)
    • Re: Test on 10GBE Intel based network card
      ... Who ya gonna call, why me of course, its my driver:) ... ix0: ... Driver dropped packets = 0 ... ix1: ...
      (freebsd-performance)
    • Re: Degradation of TCP connection
      ... and running ifconfigon the target does indeed show ... the huge number of dropped Rx packets, ... RX stall (possibly due to mishandled RX overrun in the driver) ... RX interrupts have stopped firing ...
      (comp.os.vxworks)
    • Re: Degradation of TCP connection
      ... "Each of our boards will have an ethernet driver specific ... once you get a target into a failed state, ... when the VxWorks box stops ACKing packets sent from the Windows box. ...
      (comp.os.vxworks)
    Loading