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 - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
