With the kernel in beta2, my eepro soundcard consistently stops sending and
/ or receiving any data, this seem to happen at random moments, but can
always be reproduced by copying large files over nfs.
When it happen I get a lot of:
eth0: XMT status = 0x0
eth0: XMT status = 0x1
Ehm make that eepro network card, duh.
This NIC has worked flawlessly for me as my main nic since the 2.0
kernel days, this is the first time it breaks for me.
The only problem it has is that its bnc connecter has been kicked
against once, so sometimes (say once a month) it doesn't make electrical
contact and you have to remove and insert the cabel again. Due to this
it also has slightly more frame errors then you would normally expect. I
guess that this is what bites with the new kernel, something
probably busted the error handling.
This defect is considered MUST-FIX for Winston Beta-5
This is a known generic 2.2.16 kernel issue, get Alan to send you just the
2.2.17 patches for this, or maybe some more since 2.2.17 is supposed to be
overall better then 2.2.16.
Alan, can you help here?
This defect has been re-classified as MUST-FIX for Winston Gold-release
Alan, should I suck the eepro.c changes from 2.2.17pre14 into our
As I understand from acme - yes
Aha! Those changes have been there since July 4 under
the guise of linux-2.2.16-sparc-eepro.patch
So this should be fixed in Pinstripe. I'm therefore
marking this closed; reopen it if Pinstripe does not
fix this bug.
Just tried it with RC1, still no go. Are you sure this patches aren't surrounded
by if($arch == sparc) in the spec file?
How about going back to eepro from the kernel with 6.2, that had some bugs too
(like hanging the machine if you insmod it without an io parameter and your card
is not at the default adres) but atleast it worked.
Alan I can miss this card, I usually just use it to torture kernels since it is
such a "great" card. so if you want it to test the eepro driver, send me a
private mail with your address and stuff.
Is this failing in the install or after the install?
Yes, the patch is applied on all arch's in our spec file.
Also, while part of the patch is ifdef __sparc__, it is
the same in our sparc-eepro patch and in Alan's patch.
Erm, I the sparc-eepro patch is against the eepro100 driver.
I'll go look again at 2.2.17-pre<latest>...
OK, 2.2.16-21.3 and later will include this fix to the driver.
Sorry for the confusion!
Verified, works fine now.
The eepro100 driver in 2.2.16-22 does not work on an 82559 based card here; it
spews card reports no resources/no RX buffers about once per second.
OK, Ben, send me a patch! :-)
Try the e100 driver and see if it works; that's useful info.
This defect is considered MUST-FIX for Florence Gold release
Ben, this bug report was about the eepro, not eepro100. Since it
was fixed for eepro, I'm closing this. If eepro100 is still broken
with that card with the 2.4 kernel, please open a new bug report
against that kernel or simply fix it... :-)
Eepro is broken in 2.4.0. It might be fixed in -ac now but Im not sure
The eepro100 driver is working fine on my test machine with the 2.4.2-x kernels.
Can we consider this issue resolved?
bfox: no, this is not about eepro100! It's about the 10mbit eepro driver.
Tihs bug was about an eepro10 (isa) but I'm not sure anymore what it is about
right now, I guess it can be closed when both the eepro10 (isa) and the eepro100