I can pass additionally on the following observation, if it helps some more clever than I: In a boot where the RTL8102 is going to work, just prior to DHCP initiation in the boot process, it will print: r8169: eth0: link up r8169: eth0: link up Exactly twice. Whereas, in any boot where it is on the road to failure, it will print it exactly once: r8169: eth0: link up No idea what it means, but the observation is very consistent. The dmesg log also supports this. I attach a dmesg.gz log from a successful 2.5.26-rc8 boot, with eth0 working, to support this observation. -Michael -----Original Message----- From: Mario_Limonciello@xxxxxxxx [mailto:Mario_Limonciello@xxxxxxxx] Sent: Thursday, June 26, 2008 8:25 PM To: mgrollman@xxxxxxxxx; matthew@xxxxxx; romieu@xxxxxxxxxxxxx Cc: netdev@xxxxxxxxxxxxxxx; lkml@xxxxxxxxxxx; akpm@xxxxxxxxxxxxxxxxxxxx; linux-pci@xxxxxxxxxxxxxxx Subject: RE: 8169 Intermittent ifup Failure Issue With RTL8102E Chipset in Intel's New D945GCLF Atom Board (Not the Initial Modprobe Crash, Another Problem) This is *not* just specific to your hardware. I've encountered it on two other platforms that have RTL8102's. I posted some comments in another thread the other day. -----Original Message----- From: netdev-owner@xxxxxxxxxxxxxxx [mailto:netdev-owner@xxxxxxxxxxxxxxx] On Behalf Of mgrollman@xxxxxxxxx Sent: Thursday, June 26, 2008 9:58 PM To: 'Matthew Wilcox'; 'Francois Romieu' Cc: netdev@xxxxxxxxxxxxxxx; 'Kasper Sandberg'; akpm@xxxxxxxxxxxxxxxxxxxx; linux-pci@xxxxxxxxxxxxxxx Subject: RE: 8169 Intermittent ifup Failure Issue With RTL8102E Chipset in Intel's New D945GCLF Atom Board (Not the Initial Modprobe Crash, Another Problem) Matthew, The only remedy I have found to date is a system reboot, sometimes a soft one will work, sometimes a full power down is needed. It may take a few boots to get it happy. If I can get it to boot with the Realtek working OK, the system does not seem to fail, even after hours of use. So either it comes up working, or it does not. But I am open to any ideas to try and correct! I have an extra motherboard around, if you guys think it may be in this particular unit's hardware. - Michael -----Original Message----- From: Matthew Wilcox [mailto:matthew@xxxxxx] Sent: Thursday, June 26, 2008 7:35 PM To: Francois Romieu Cc: Michael Grollman; netdev@xxxxxxxxxxxxxxx; Kasper Sandberg; akpm@xxxxxxxxxxxxxxxxxxxx; linux-pci@xxxxxxxxxxxxxxx Subject: Re: 8169 Intermittent ifup Failure Issue With RTL8102E Chipset in Intel's New D945GCLF Atom Board (Not the Initial Modprobe Crash, Another Problem) On Thu, Jun 26, 2008 at 11:59:18PM +0200, Francois Romieu wrote: > (linux-pci Cced) > > Michael Grollman <mgrollman@xxxxxxxxx> : > [...] > > Per instructions, I built an 2.6.26-rc8 system on the target Intel > > hardware, and was able to re-recreate the intermittent failure of the 8201. > > When in failure mode, the lspci -vx' display of the pci registers > > of the > > 8102 is as follows: > > > > 01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. > > RTL8101E PCI Express Fast Ethernet controller (rev ff) (prog-if ff) > > !!! Unknown header type 7f > > 00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > > 10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > > 20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > > 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Mmm. All f's means that the device has fallen off the bus. Nothing is responding when we ask the device about it's config space. What do you do to get this device into this state? -- Intel are signing my paycheques ... these opinions are still mine "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
Attachment:
dmesg-2.6.26r8.realtek-working.gz
Description: GNU Zip compressed data
