> There is a posting public about Intel ethernet adapters and their
> packets of death:
>
> http://blog.krisk.org/2013/02/packets-of-death.html
>
> Now, how can we test the EEPROM from FreeBSD, similar to the
> ethtool of Linux ?
There is no such tool.
If you want to dump EEPROM contents, you can do so via one of the
following ways for em(4) NICs or igb(4) NICs, as root:
sysctl dev.XXX.Y.nvm=1 (for recent/newer FreeBSD)
sysctl dev.XXX.Y.debug=2 (for older FreeBSD)
Where XXX is either "em" or "igb" depending on your NIC and
Y is the
interface number (e.g. 0 = em0, 1 = em1, etc.).
After this, run "dmesg" and look at the output at the bottom. You
will
see something like this:
Interface EEPROM Dump:
Offset
0x0000 3000 d248 d022 0d30 f746 00f5 ffff ffff
0x0010 0100 ffff 026b 108c 15d9 108c 8086 83df
0x0020 0008 2000 7e14 0048 1000 00d8 0000 2700
0x0030 6cc9 3150 0722 040b 0984 0000 c000 0706
Please see this page, search for "EEPROM", which documents a different
bug pertaining the Intel 82573 where some EEPROMs were shipped with a
power-saving bit enabled. Read it, do not skim it, because it explains
the EEPROM dump endian difference WRT Linux ethtool vs. FreeBSD's driver:
https://wiki.freebsd.org/BugBusting/Commonly_reported_issues
There is no way on FreeBSD to change EEPROM contents. You will need to
use Linux ethtool for this, or -- strongly recommended -- ask Intel for
their DOS-based utility that fixes the "packet of death" setting in
the
EEPROM and follow their instructions. You can also ask your NIC (or
motherboard) vendor and make it their problem (I'm willing to bet a lot
of them aren't aware of it).
To whom it may concern: these sysctls really need to be documented.
They have sysctl -d descriptions but they need to be documented in
man pages. I can write the man page updates if need be.
<rant>
Now, as far as the "packet of death" thing is concerned: cry me a
river.
Why is it people today think that hardware devices are immune to bugs?
Is it because they're solid-state, thus give off the impression "there
can be no problems?" I don't get it. *sighs* This sort of stuff
seems
to come as a surprise to younger generations or people who really do
believe "chips never have problems". It seems to me that it stems
from,
as the generations have progressed, less and less people actually
understanding how things work (all the way down to th bare metal). All
this bloody abstracted programming and abstracted ideas do nothing but
hide how things work. Really pisses me off.
It might be more of a "wow, I didn't expect this to be a problem so
low-level" surprise, which just further fuels my point -- people seem to
think things Just Work(tm) today, when in my experience things today
***do not*** Just Work(tm). Most things are Extremely Broken(tm).
Just be glad the issue is with an EEPROM setting and not silicon-level,
otherwise you'd be flat out screwed barring driver-level workarounds.
</rant>
--
| Jeremy Chadwick jdc at koitsu.org |
| UNIX Systems Administrator http://jdc.koitsu.org/ |
| Mountain View, CA, US |
| Making life hard for others since 1977. PGP 4BD6C0CB |
