On 8/19/07, Mick <[EMAIL PROTECTED]> wrote: > 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.
Make sure you pass this info along to the kernel-side maintainer of the 8139 driver you are using so that they can get the issue fixed. You can find the maintainer in the source file - in this case, /usr/src/linux/drivers/8139too.c - looks like it's Jeff Garzik. -James > > 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 > > -- [EMAIL PROTECTED] mailing list
