netdev - Re: e100 (was: eepro100) - Nobody Cares (hardware?)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 7 Aug 2007 07:49:15 -0500
From:	"ericj" <ericj@...cj.net>
To:	"Kok, Auke" <auke-jan.h.kok@...el.com>
Cc:	Jeff Garzik <jeff@...zik.org>, NetDev <netdev@...r.kernel.org>
Subject: Re: e100 (was: eepro100) - Nobody Cares (hardware?)

On Mon, 06 Aug 2007 17:45:09 -0700, Kok, Auke wrote
> [moving to netdev mailinglist]
> Eric,
> 
> please don't forget that an entire team here at Intel is 
> dedicated to supporting e100 and pro/1000 devices from Intel.
> 
> Most of the pro/100 features are documented in the SDM which 
> contains some references to the eeprom parts. Mostly the 
> device doesn't need much configuration from the eeprom to work 
> (unlike gigE parts). The SDM can be downloaded from our sf.net 
> project page:
> 
>
http://sourceforge.net/project/showfiles.php?group_id=42302&package_id=68544
> 
> The issue that you are reporting:
> 
> "My system boots fine but when I try to bring up the onboard 
> ethernet (an EEPro 100 VE) I get a "Nobody Cares" message and 
> the interrupt is disabled."
> 
> However has been recently patched. This should have worked 
> regardless of whether you used e100 or eepro100 (noting that 
> nobody supports eepro100 anymore, you should really use e100 
> for all tests).
> 
> if you look in drivers/pci/quirks.c you'll find that there is 
> specific code for e100 devices. If this quirk doesn't work for 
> you then we'll need to dig into that. For this I'd like you to 
> gather:
> 
> - `ethtool -e eth0` output
> - `lspci -n` output
> 
> this will allow me to check the quirck code and see if it has 
> the right device ID. I'm suspecting that the device ID is 
> missing somehow, or the workaround fails.
> 
> Auke

Thanks for the help.

Here are the lspci -n and ethtool -e outputs. I am attaching both the
results for the 'bad' unit and for another one which is supposedly
identical except for some battery charge circuitry.

The eeprom data on the bad one may be a little odd due to my trying to
make it match that of the good one, including that I forgot what the
real MAC address was supposed to be.

I can get one that I haven't screwed up if you need it, but it will
probably take all day.

--

"A hunch is creativity trying to tell you something" -- Frank Capra

Eric Johnson


Download attachment "lspci_good.txt" of type "application/octet-stream" (585 bytes)

Download attachment "lspci_bad.txt" of type "application/octet-stream" (585 bytes)

Download attachment "ethtool_bad.txt" of type "application/octet-stream" (486 bytes)

Download attachment "ethtool_good.txt" of type "application/octet-stream" (486 bytes)