At long last I managed to find a work around to this problem, which was probably caused by Microsoft deciding to become environmentally friendly . . .
If this problem applies to your NIC then you may want to read on: On Sunday 12 August 2007, Rumen Yotov wrote: > On (11/08/07 08:55) Mick wrote: > > On Sunday 29 July 2007 17:46, Rumen Yotov wrote: > > > On (29/07/07 18:05) Jakob wrote: > > > > > Anything else I could try? How do I troubleshoot it? > > > > > > > > Have a look at the log files is always a good way to troubleshoot ;-) > > > > what does dmesg and /var/log/messages say about eth0 or 8139? > > > > -- > > > > [EMAIL PROTECTED] mailing list > > > > > > Hi, > > > > > > Could also try the latest (~x86) kernel - 2.6.22-r2 > > > > I've had a chance to look at this machine again. I haven't transferred > > the relevant gentoo-sources to compile 2.6.22-r2, so I am still on > > 2.6.21-r4. These are some relevant logs. The entries after [drm] were > > created when I manually tried to load the device and run dhcpcd: > > > > dmesg > > =============================================== > > eth0: link up, 100Mbps, full-duplex, lpa 0x41E1 > > [drm] Setting GART location based on new memory map > > [drm] Loading R300 Microcode > > [drm] writeback test succeeded in 1 usecs > > NETDEV WATCHDOG: eth0: transmit timed out > > [drm] Loading R300 Microcode > > eth0: link up, 100Mbps, full-duplex, lpa 0x41E1 > > NETDEV WATCHDOG: eth0: transmit timed out > > eth0: Transmit timeout, status 0d 0000 c07f media 10. > > eth0: Tx queue start entry 4 dirty entry 0. > > eth0: Tx descriptor 0 is 00082156. (queue head) > > eth0: Tx descriptor 1 is 00082156. > > eth0: Tx descriptor 2 is 00082156. > > eth0: Tx descriptor 3 is 00082156. > > eth0: link up, 100Mbps, full-duplex, lpa 0x41E1 > > =============================================== > > > > /var/log/syslog > > =============================================== > > Aug 11 08:33:27 compaq eth0: link up, 100Mbps, full-duplex, lpa 0x41E1 > > Aug 11 08:33:39 compaq dhcpcd[6552]: eth0: dhcpcd 3.0.16 starting > > Aug 11 08:33:39 compaq dhcpcd[6552]: eth0: hardware address = > > 00:11:2f:d7:f1:af > > Aug 11 08:33:39 compaq dhcpcd[6552]: eth0: broadcasting for a lease > > Aug 11 08:33:57 compaq NETDEV WATCHDOG: eth0: transmit timed out > > Aug 11 08:33:59 compaq dhcpcd[6552]: eth0: timed out > > Aug 11 08:33:59 compaq dhcpcd[6552]: eth0: exiting > > Aug 11 08:34:00 compaq eth0: Transmit timeout, status 0d 0000 c07f media > > 10. Aug 11 08:34:00 compaq eth0: Tx queue start entry 4 dirty entry 0. > > Aug 11 08:34:00 compaq eth0: Tx descriptor 0 is 00082156. (queue head) > > Aug 11 08:34:00 compaq eth0: Tx descriptor 1 is 00082156. > > Aug 11 08:34:00 compaq eth0: Tx descriptor 2 is 00082156. > > Aug 11 08:34:00 compaq eth0: Tx descriptor 3 is 00082156. > > Aug 11 08:34:24 compaq cron[6224]: (root) MAIL (mailed 76 bytes of output > > but go > > t status 0x0001 ) > > =============================================== > > -- > > Regards, > > Mick > > Hi, > > I had some very strange problems with Davicom net-card, but only with > 2.6.21-r4. > Both 2.6.20-r8 & 2.6.22-r2 work flawlessly. > The connection breaks suddenly (suspect some ACPI issue). > Check b.g.o > HTH. Rumen I moved the source and ebuild files using a USB stick and emerged the 2.6.22-r2 kernel. Unfortunately, it didn't make a difference. dmesg and syslog show that the card is recognised and the driver is loaded. dhcpcd fails to obtain an address. I even ran the rtl-diag to see if it shows anything: ======================================== # rtl8139-diag -aemv rtl8139-diag.c:v2.13 2/28/2005 Donald Becker ([EMAIL PROTECTED]) http://www.scyld.com/diag/index.html Index #1: Found a RealTek RTL8139 adapter at 0xe400. RealTek chip registers at 0xe400 0x000: d72f1100 0000aff1 80000000 00000000 00002000 00002000 00002000 00002000 0x020: 34f76000 34f76600 34f76c00 34f77200 34900000 01000000 0000fff0 00000000 0x040: 74c00000 00000000 931364e2 00000000 008d10c0 00000000 00d0c510 00100000 0x060: 9000000f 01e1780d 000041e1 00000000 00000700 000107c8 64f60c59 8b732760. Realtek station address 00:11:2f:d7:f1:af, chip type 'rtl8139C+'. Receiver configuration: Reception disabled Rx FIFO threshold 16 bytes, maximum burst 16 bytes, 8KB ring Transmitter disabled with normal settings, maximum burst 16 bytes. Tx entry #0 status 00002000 incomplete, 0 bytes. Tx entry #1 status 00002000 incomplete, 0 bytes. Tx entry #2 status 00002000 incomplete, 0 bytes. Tx entry #3 status 00002000 incomplete, 0 bytes Flow control: Tx disabled Rx disabled. The chip configuration is 0x10 0x8d, MII half-duplex mode. No interrupt sources are pending. Decoded EEPROM contents: PCI IDs -- Vendor 0x10ec, Device 0x8139. PCI Subsystem IDs -- Vendor 0x103c, Device 0x2a0b. PCI timer settings -- minimum grant 32, maximum latency 64. General purpose pins -- direction 0xe5 value 0x12. Station Address 00:11:2F:D7:F1:AF. Configuration register 0/1 -- 0x8d / 0xc2. EEPROM active region checksum is 0945. The RTL8139 does not use a MII transceiver. It does have internal MII-compatible registers: Basic mode control register 0x9000. Basic mode status register 0x780d. Autonegotiation Advertisement 0x01e1. Link Partner Ability register 0x41e1. Autonegotiation expansion 0x0000. Disconnects 0x0000. False carrier sense counter 0x0000. NWay test register 0x0700. Receive frame error count 0x0000. ======================================== To add to the confusion you'll notice that it says I have a chip type 'rtl8139C+'. Well, dmesg tells me: eth0: Identified 8139 chip type 'RTL-8101' and so does syslog: compaq eth0: Identified 8139 chip type 'RTL-8101' So, who do I trust? All of this is a bit academic of course, because 8139CP will not run and 8139too was until recently running fine. SOLUTION: Since all of this started with an update of the MS Windows drivers I thought that the problem has to do with some firmware or new setting, that the MS Windows drivers inflicted on the card. Some relevant searching brought me to this page http://www.scyld.com/modules.html and the comments under The "D3-cold" problem. Well, no sooner had I rebooted, after pulling the plug for a few seconds to make sure the machine powers down completely, the card was at long last recognised and an IP address obtained. It seems then that the MS Windows driver shuts down the power to the card and the Linux driver does not/cannot switch it back on. A point to note is that I have always enabled the setting "PnP OS" in the BIOS thinking that it is better for Linux to determine what happens with the devices directly. Perhaps I should disable this until the driver is sorted out. Thank you all for your help. -- Regards, Mick
signature.asc
Description: This is a digitally signed message part.
