Bug 75482 - natsemi driver fails on hw addr change
natsemi driver fails on hw addr change
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
8.0
i386 Linux
low Severity low
: ---
: ---
Assigned To: Jeff Garzik
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-10-08 19:02 EDT by Alan Cox
Modified: 2013-07-02 22:07 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-10-09 16:08:33 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Write MAC address to chip each time interface is up'd, as per standard net driver skeleton (870 bytes, patch)
2002-10-09 11:08 EDT, Jeff Garzik
no flags Details | Diff
[PATCH] increase eeprom delay (1.52 KB, patch)
2002-10-09 16:08 EDT, Jeff Garzik
no flags Details | Diff

  None (edit)
Description Alan Cox 2002-10-08 19:02:25 EDT
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 11:08:17 EDT
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 16:08:26 EDT
Created attachment 79704 [details]
[PATCH] increase eeprom delay
Comment 3 Thomas M Steenholdt 2002-10-16 04:04:32 EDT
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 05:57:50 EDT
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 08:33:21 EDT
okay - i guess i'll open another report on the slightly different scenario,
thanks for your patience!

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