Bug 76137 - natsemi driver won't work unless in promiscuous mode
Summary: natsemi driver won't work unless in promiscuous mode
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
(Show other bugs)
Version: 8.0
Hardware: i686 Linux
Target Milestone: ---
Assignee: Jeff Garzik
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2002-10-17 13:13 UTC by Thomas M Steenholdt
Modified: 2013-07-03 02:07 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-01-31 16:17:00 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Thomas M Steenholdt 2002-10-17 13:13:24 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2b) Gecko/20021010

Description of problem:
My NetGear FA-311 adapter didn't seem to work at first... I had no errors in
dmesg or /var/log/messages, but i couldn't ping to or from the machine... I
wanted to see if i got any other data, broadcasts or something, so I started
tcpdump -i eth0 and suddenly all pings and everything worked fine.

I have tried the 2.4.20-pre11 kernel and the natsemi driver in that seems to
work - i havn't tried the redhat errata kernel yet, but i don't
think that it will make a difference regarding this problem as it seems to be
the same natsemi.c as in the 2.4.18-14 kernel

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. install netgear fa311 adapter and install rh8.0
2. after install ping anything and notice how it just doesn't work
3. run tcpdump -i eth0 on the machine and notice how everything changes :)

Actual Results:  no data is transferred if not in promisc. mode

Expected Results:  data should be transferrer even if not in promisc. mode

Additional info:

Comment 1 Thomas M Steenholdt 2002-10-22 13:25:50 UTC
The failing configuration is an Dual-PPro 200 MHz machine - the error is seen
both with the smp and the uni kernel...

But I have an almost identical setup on a P-MMX 200MHz machine that seems to
work very well... (perhaps i'm missing something in the config-comparison, but
the seem to be very much alike) except that this on actually works without being
put into promisc. mode

Comment 2 Jeff Garzik 2002-10-25 18:02:37 UTC
Can you verify that the problem is fixed by the net driver in stock kernel
version 2.4.20-pre11?  (i.e. 2.4.19 + 2.4.20-pre11 patch)

Comment 3 Thomas M Steenholdt 2002-10-26 12:44:37 UTC
Yes - I have not seen any problems with the driver from stock kernel
2.4.20-pre11... I installed the 2.4.20-pre11 kernel on the system that failed
for me first(and still does) without altering any configuration on that
system... Booting the kernel 2.4.18-14(RedHat) will show the problem!
Booting 2.4.20-pre11 the problem is gone!

Comment 4 Michael Bedy 2002-11-13 03:56:43 UTC
I would like to confirm this bug. Oddly enough, this is also on a Pro-200.
Perhaps it is specific to the processor or PPro chipset? I do not recall the
brandname of my ethernet card, but it is a natsemi chip. It worked fine in
RH7.3, does not in 8.0. Running tcpdump causes the network to suddenly start

I have not yet compiled a "stock" kernel, but I assume that this would work
around my problem, given the above information.

Comment 5 Thomas M Steenholdt 2002-11-13 14:54:25 UTC
Even though the driver seems to have changed slightly in 2.4.19-0.pp.9(rawhide)
over 2.4.19(stock) the driver is still not nearly as updated as the 2.4.20-rc1
version... 1.0.15 vs 1.0.17 (looking inside the .c file) And it still doesn't work.

Actually, the problem might just be what Alan mentions in #75482 - And the
scenario descriped there seems to match some of the fixes in 1.0.17 of the driver

Comment 6 Jeff Garzik 2003-01-31 16:17:00 UTC
This is fixed in our rawhide kernel, which includes the updated natsemi driver
from kernel 2.4.20, and also our latest errata release.

Note You need to log in before you can comment on or make changes to this bug.