Bug 75482

Summary: natsemi driver fails on hw addr change
Product: [Retired] Red Hat Linux Reporter: Alan Cox <alan>
Component: kernelAssignee: Jeff Garzik <jgarzik>
Status: CLOSED CURRENTRELEASE QA Contact: Brian Brock <bbrock>
Severity: low Docs Contact:
Priority: low    
Version: 8.0CC: peterm, tmus
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2002-10-09 20:08:33 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:
Attachments:
Description Flags
Write MAC address to chip each time interface is up'd, as per standard net driver skeleton
none
[PATCH] increase eeprom delay none

Description Alan Cox 2002-10-08 23:02:25 UTC 
In 8.0 the natsemi driver receive fails if you change its hw address and it is
not in promisc mode. Apparently a fix for this is in the current bitkeeper trees
Comment 1 Jeff Garzik 2002-10-09 15:08:17 UTC 
Created attachment 79644 [details]
Write MAC address to chip each time interface is up'd, as per standard net driver skeleton
Comment 2 Jeff Garzik 2002-10-09 20:08:26 UTC 
Created attachment 79704 [details]
[PATCH] increase eeprom delay
Comment 3 Thomas M Steenholdt 2002-10-16 08:04:32 UTC 
I seem to be having this problem -  I cant use the network unless i start a
tcpdump -i eth0 (are there otherways to force promisc. mode :) ) which of course
is not a valid solution...

Before nagging too much i will download the patches from the report and try them
out - if it works, when do you expect an errata kernel to be released containing
this fix???
Comment 4 Thomas M Steenholdt 2002-10-16 09:57:50 UTC 
btw, I did not change hw address, so maybe i should create a new report - please
advise.

also, i'm having problems applying the patches to the 2.4.18-14 source, were the
patches generated on a different version of the kernel source?
Comment 5 Thomas M Steenholdt 2002-10-17 12:33:21 UTC 
okay - i guess i'll open another report on the slightly different scenario,
thanks for your patience!