> 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 j...@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
