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

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

[Kok, Auke]

[moving to netdev mailinglist]

ericj wrote:
> On Mon, 6 Aug 2007 11:20:58 -0500, ericj wrote
>> On Mon, 06 Aug 2007 12:13:28 -0400, Jeff Garzik wrote
>>> eepro100 is going to be removed.  Please try e100 on 2.6.22 or 
>>> 2.6.23-rc2.
> 
>> I will give the 2.6.23 a try.
> 
> I tried 2.6.23-rc2 and there was no change.
> 
> There is now some question from the hardware guys about whether the
> eeproms were properly configured before shipping the boards. Is there
> any documentation of the eeprom on an EE Pro 100 VE (ICH4) so that I can
> figure out if any of the settings in there might be causing the problem?
> 
> The only fields I know of for sure are the MAC address at the beginning
> and the checksum at the end. I also see from the driver code that there
> is at least one byte controlling wake-on-lan, which I don't care about -
> unless it's the problem.
> 
> Thanks for ethtool, by the way. It's been helpful in looking at this and
> comparing the eeprom to an earlier version of the board that works.

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

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

[ericj]

[-- Attachment #1: Type: text/plain, Size: 2006 bytes --]

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


[-- Attachment #2: lspci_good.txt --]
[-- Type: application/octet-stream, Size: 585 bytes --]

00:00.0 0600: 8086:3580 (rev 02)
00:00.1 0880: 8086:3584 (rev 02)
00:00.3 0880: 8086:3585 (rev 02)
00:02.0 0300: 8086:3582 (rev 02)
00:02.1 0380: 8086:3582 (rev 02)
00:1d.0 0c03: 8086:24c2 (rev 02)
00:1d.1 0c03: 8086:24c4 (rev 02)
00:1d.2 0c03: 8086:24c7 (rev 02)
00:1d.7 0c03: 8086:24cd (rev 02)
00:1e.0 0604: 8086:244e (rev 82)
00:1f.0 0601: 8086:24c0 (rev 02)
00:1f.1 0101: 8086:24cb (rev 02)
00:1f.3 0c05: 8086:24c3 (rev 02)
00:1f.5 0401: 8086:24c5 (rev 02)
01:08.0 0200: 8086:103a (rev 82)
01:0c.0 0280: 1814:0302
01:0d.0 0607: 104c:ac55 (rev 01)
01:0d.1 0607: 104c:ac55 (rev 01)

[-- Attachment #3: lspci_bad.txt --]
[-- Type: application/octet-stream, Size: 585 bytes --]

00:00.0 0600: 8086:3580 (rev 02)
00:00.1 0880: 8086:3584 (rev 02)
00:00.3 0880: 8086:3585 (rev 02)
00:02.0 0300: 8086:3582 (rev 02)
00:02.1 0380: 8086:3582 (rev 02)
00:1d.0 0c03: 8086:24c2 (rev 02)
00:1d.1 0c03: 8086:24c4 (rev 02)
00:1d.2 0c03: 8086:24c7 (rev 02)
00:1d.7 0c03: 8086:24cd (rev 02)
00:1e.0 0604: 8086:244e (rev 82)
00:1f.0 0601: 8086:24c0 (rev 02)
00:1f.1 0101: 8086:24cb (rev 02)
00:1f.3 0c05: 8086:24c3 (rev 02)
00:1f.5 0401: 8086:24c5 (rev 02)
01:08.0 0200: 8086:103a (rev 82)
01:0c.0 0280: 1814:0302
01:0d.0 0607: 104c:ac55 (rev 01)
01:0d.1 0607: 104c:ac55 (rev 01)

[-- Attachment #4: ethtool_bad.txt --]
[-- Type: application/octet-stream, Size: 486 bytes --]

Offset		Values
------		------
0x0000		00 02 b3 c0 ff ee 00 00 00 00 ff ff ff ff ff ff 
0x0010		ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
0x0020		ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
0x0030		ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
0x0040		ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
0x0050		ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
0x0060		ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
0x0070		ff ff ff ff ff ff ff ff ff ff ff ff ff ff 42 09 

[-- Attachment #5: ethtool_good.txt --]
[-- Type: application/octet-stream, Size: 486 bytes --]

Offset		Values
------		------
0x0000		00 1b ec 00 00 57 00 00 00 00 ff ff ff ff ff ff 
0x0010		ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
0x0020		ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
0x0030		ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
0x0040		ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
0x0050		ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
0x0060		ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
0x0070		ff ff ff ff ff ff ff ff ff ff ff ff ff ff 08 48 

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

[ericj]

I want to thank everyone who helped with this.

It was proven to be a hardware issue. The board designer had left a GPIO
pin in an indeterminate state because he was planning to use it later to
do something with the battery charge circuitry.

I apologize for wasting everyone's time.

On Mon, 06 Aug 2007 17:45:09 -0700, Kok, Auke wrote
> [moving to netdev mailinglist]
> 
> ericj wrote:
> > On Mon, 6 Aug 2007 11:20:58 -0500, ericj wrote
> >> On Mon, 06 Aug 2007 12:13:28 -0400, Jeff Garzik wrote
> >>> eepro100 is going to be removed.  Please try e100 on 2.6.22 or 
> >>> 2.6.23-rc2.
> > 
> >> I will give the 2.6.23 a try.
> > 
> > I tried 2.6.23-rc2 and there was no change.
> > 
> > There is now some question from the hardware guys about whether the
> > eeproms were properly configured before shipping the boards. Is there
> > any documentation of the eeprom on an EE Pro 100 VE (ICH4) so that I can
> > figure out if any of the settings in there might be causing the problem?
> > 
> > The only fields I know of for sure are the MAC address at the beginning
> > and the checksum at the end. I also see from the driver code that there
> > is at least one byte controlling wake-on-lan, which I don't care about -
> > unless it's the problem.
> > 
> > Thanks for ethtool, by the way. It's been helpful in looking at this and
> > comparing the eeprom to an earlier version of the board that works.
> 
> 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


--

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

Eric Johnson

Re: e100

[Kok, Auke]

ericj wrote:
> I want to thank everyone who helped with this.
> 
> It was proven to be a hardware issue. The board designer had left a GPIO
> pin in an indeterminate state because he was planning to use it later to
> do something with the battery charge circuitry.
> 
> I apologize for wasting everyone's time.

happens to everyone :)

Thanks for letting us know.

Auke



> 
> On Mon, 06 Aug 2007 17:45:09 -0700, Kok, Auke wrote
>> [moving to netdev mailinglist]
>>
>> ericj wrote:
>>> On Mon, 6 Aug 2007 11:20:58 -0500, ericj wrote
>>>> On Mon, 06 Aug 2007 12:13:28 -0400, Jeff Garzik wrote
>>>>> eepro100 is going to be removed.  Please try e100 on 2.6.22 or 
>>>>> 2.6.23-rc2.
>>>> I will give the 2.6.23 a try.
>>> I tried 2.6.23-rc2 and there was no change.
>>>
>>> There is now some question from the hardware guys about whether the
>>> eeproms were properly configured before shipping the boards. Is there
>>> any documentation of the eeprom on an EE Pro 100 VE (ICH4) so that I can
>>> figure out if any of the settings in there might be causing the problem?
>>>
>>> The only fields I know of for sure are the MAC address at the beginning
>>> and the checksum at the end. I also see from the driver code that there
>>> is at least one byte controlling wake-on-lan, which I don't care about -
>>> unless it's the problem.
>>>
>>> Thanks for ethtool, by the way. It's been helpful in looking at this and
>>> comparing the eeprom to an earlier version of the board that works.
>> 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
> 
> 
> --
> 
> "A hunch is creativity trying to tell you something" -- Frank Capra
> 
> Eric Johnson