Re: [gentoo-user] NIC problems after MS Windows update
HI all, I have the self-same problem with this card on a dual boot windows98 / gentoo system. In fact, I have TWO 8139 cards installed and the problem is present with both. Windows actually disactivates only the one it uses, and not the other. On another mailing list I found someone suggesting that activating the wake on lan option in the windows network card options solves the problem, and in fact it does. Anyway, seems it is not only an XP update problem, it seems to be a more general windows thing. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] NIC problems after MS Windows update
Hi, Mick wrote: On Monday 20 August 2007, James Ausmus wrote: 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 . . . [snip...] 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 Done. Any update on this issue ? I'm using gentoo-sources-2.6.22-r5 (r2) and I'm seeing the same problem (with gentoo-sources-2.6.21-r4 the same). Regards, Ovidiu -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] NIC problems after MS Windows update
On Monday 20 August 2007, James Ausmus wrote: 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 . . . [snip...] 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 Done. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] NIC problems after MS Windows update
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 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 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 aff1 8000 2000 2000 2000 2000 0x020: 34f76000 34f76600 34f76c00 34f77200 3490 0100 fff0 0x040: 74c0 931364e2 008d10c0 00d0c510 0010 0x060: 900f 01e1780d 41e1 0700 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 2000 incomplete, 0 bytes. Tx entry #1 status 2000 incomplete, 0 bytes. Tx entry #2 status 2000 incomplete, 0 bytes. Tx entry #3 status 2000 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.
Re: [gentoo-user] NIC problems after MS Windows update
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 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 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 aff1 8000 2000 2000 2000 2000 0x020: 34f76000 34f76600 34f76c00 34f77200 3490 0100 fff0 0x040: 74c0 931364e2 008d10c0 00d0c510 0010 0x060: 900f 01e1780d 41e1 0700 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 2000 incomplete, 0 bytes. Tx entry #1 status 2000 incomplete, 0 bytes. Tx entry #2 status 2000 incomplete, 0 bytes. Tx entry #3 status 2000 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.
Re: [gentoo-user] NIC problems after MS Windows update
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 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 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 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] NIC problems after MS Windows update
Hi Mike, I don't know if this helps but I have a Realtek 8169 in my box and if I hibernate windows and then boot up gentoo my card isn't working. If I boot windows again and shut it down (not hibernate) and then boot up gentoo again the card is working. it seems that windows reserves the card when hibernating and only give it back to normal state with a normal shutdown. regards jakob -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] NIC problems after MS Windows update
On Sunday 29 July 2007 14:43, Jakob wrote: Hi Mike, I don't know if this helps but I have a Realtek 8169 in my box and if I hibernate windows and then boot up gentoo my card isn't working. If I boot windows again and shut it down (not hibernate) and then boot up gentoo again the card is working. it seems that windows reserves the card when hibernating and only give it back to normal state with a normal shutdown. Thanks jakob, every time I tried it in Gentoo, I had first shutdown WinXP normally. I even removed the WinXP driver installed by MS Update and installed the latest one on the Realtek website: http://www.realtek.com.tw/downloads/downloadsView.aspx?Langid=1PNid=6PFid=6Level=5Conn=4DownTypeID=3GetDown=false Unfortunately, that made no difference in both OS'. Then I updated the Gentoo kernel to the latest stable version (2.6.21-gentoo-r4) but still no cigar. Anything else I could try? How do I troubleshoot it? -- Regards, Mick pgpeCpTJeImxa.pgp Description: PGP signature
Re: [gentoo-user] NIC problems after MS Windows update
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
Re: [gentoo-user] NIC problems after MS Windows update
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 HTH. Rumen -- [EMAIL PROTECTED] mailing list
