Bug 76137

Summary:	natsemi driver won't work unless in promiscuous mode
Product:	[Retired] Red Hat Linux	Reporter:	Thomas M Steenholdt <tmus>
Component:	kernel	Assignee:	Jeff Garzik <jgarzik>
Status:	CLOSED ERRATA	QA Contact:	Brian Brock <bbrock>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	8.0	CC:	mjb, peterm
Target Milestone:	---
Target Release:	---
Hardware:	i686
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2003-01-31 16:17:00 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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 2.4.18.17.8.0 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:
Always

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
working.

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.