From: Carl-Daniel Hailfinger <c-d.hailfinger.kernel.2004@gmx.net>
To: Kalin KOZHUHAROV <kalin@ThinRope.net>
Cc: Mikael Bouillot <xaajimri@corbac.com>,
linux-kernel@vger.kernel.org,
Manfred Spraul <manfred@colorfullife.com>,
Brian Lazara <blazara@nvidia.com>
Subject: Re: Forcedeth driver bug
Date: Wed, 23 Jun 2004 17:57:11 +0200 [thread overview]
Message-ID: <40D9A857.5040901@gmx.net> (raw)
In-Reply-To: <40D99A08.90707@ThinRope.net>
Kalin KOZHUHAROV wrote:
> 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.
Are you sure both come back? If so, what does dmesg say during this time?
Is the system in question under heavy load?
Can you confirm that the ping packet got stuck in the receive path or
could the associated pong reply have gotten stuck in the send path?
>> 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.
It could be a weird interaction with interrupt mitigation, but I doubt it.
Nobody has ever mailed me about such problems with the driver.
> 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.
forcedeth_gigabit_try19.txt is the most recent one.
Changes against try17:
- fix compilation warnings and rename the Kconfig entry
Get it at
http://www.hailfinger.org/carldani/linux/patches/forcedeth/
and please report if it fixes your problem.
Regards,
Carl-Daniel
next prev parent reply other threads:[~2004-06-23 15:58 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-23 14:29 Forcedeth driver bug Mikael Bouillot
2004-06-23 14:46 ` Martin Zwickel
2004-06-23 16:04 ` Mikael Bouillot
2004-06-23 14:56 ` Kalin KOZHUHAROV
2004-06-23 15:57 ` Carl-Daniel Hailfinger [this message]
2004-06-23 16:14 ` Mikael Bouillot
2004-06-23 17:02 ` Mikael Bouillot
2004-07-24 12:37 ` Carl-Daniel Hailfinger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=40D9A857.5040901@gmx.net \
--to=c-d.hailfinger.kernel.2004@gmx.net \
--cc=blazara@nvidia.com \
--cc=kalin@ThinRope.net \
--cc=linux-kernel@vger.kernel.org \
--cc=manfred@colorfullife.com \
--cc=xaajimri@corbac.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox