John wrote:
Auke Kok wrote:
This is what I was afraid of: even though the code allows you to
bypass the EEPROM checksum, the probe fails on a further check to see
if the MAC address is valid.
Since something with this NIC specifically made the EEPROM return all
0xff's, the MAC address is automatically invalid, and thus probe fails.
I don't understand why you think there is something wrong with a
specific NIC?
that was completely not my point - I was merely trying to point out that the original
problem causes a cascade of error events later on, and bypassing the eeprom check in
this case didn't help you at all. Something is wrong in the driver, but I don't
understand yet why it only affects one of the 3 nics in your system.
In 2.6.14.7, e100.ko fails to read the EEPROM on 0000:00:08.0 (eth0)
In 2.6.18.1, e100.ko fails to read the EEPROM on 0000:00:09.0 (eth1)
almost sounds like a bug got fixed and it introduced a regression. this wouldn't be the
right time to pull out git-bisect would it? even loading 2.6.15, 2.6.16, 2.6.17 on it
would give us some good information.
Cheers,
Auke
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
