My ASUS board has one of these:
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)
Subsystem: ASUSTeK Computer Inc. Unknown device 81aa
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin A routed to IRQ 16
Region 0: I/O ports at 9800 [size=256]
Region 2: Memory at ff3ff000 (64-bit, non-prefetchable) [size=4K]
Expansion ROM at ff3c0000 [disabled] [size=128K]
Capabilities: [40] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0-,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [48] Vital Product Data
Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+ Queue=0/1 Enable-
Address: 0000000000000000 Data: 0000
Capabilities: [60] Express Endpoint IRQ 0
Device: Supported: MaxPayload 1024 bytes, PhantFunc 0, ExtTag+
Device: Latency L0s <1us, L1 unlimited
Device: AtnBtn+ AtnInd+ PwrInd+
Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported-
Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
Device: MaxPayload 128 bytes, MaxReadReq 4096 bytes
Link: Supported Speed 2.5Gb/s, Width x4, ASPM L0s, Port 0
Link: Latency L0s unlimited, L1 unlimited
Link: ASPM Disabled RCB 64 bytes CommClk+ ExtSynch-
Link: Speed 2.5Gb/s, Width x1
Capabilities: [84] Vendor Specific Information
It works perfectly in 2.6.23.
It does not work in 2.6.24-rc2. Dunno about -rc1 or earlier -git*.
Without CONFIG_PCI_MSI, it works slightly, enough to ping it a couple of times,
but it then dies when used for anything real:
r8169 Gigabit Ethernet driver 2.2LK loaded
r8169 0000:01:00.0: no MSI. Back to INTx.
...
eth0: RTL8168b/8111b at 0xf884a000, 00:17:31:64:e0:bc, XID 30000000 IRQ 16
...
r8169: eth0: link up
...
kernel: NETDEV WATCHDOG: eth0: transmit timed out
r8169: eth0: link up
...
Not usable from this point on.
With CONFIG_PCI_MSI=y, it also fails, and then isn't even detected (not in lspci)
on subsequent reboots. A power cycle is required to get it to show up again.
Help?
Mark Lord wrote:
> My ASUS board has one of these:
>
> 01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
> RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)
> Subsystem: ASUSTeK Computer Inc. Unknown device 81aa
> Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop-
..
> ...
> r8169: eth0: link up
> ...
> kernel: NETDEV WATCHDOG: eth0: transmit timed out
> r8169: eth0: link up
> ...
> Not usable from this point on.
>
> With CONFIG_PCI_MSI=y, it also fails, and then isn't even detected (not in lspci)
> on subsequent reboots. A power cycle is required to get it to show up again.
..
Ahh.. this seems to have been around for a while already,
as there's an unresolved bug entry from -rc1 for this exact problem.
http://bugzilla.kernel.org/show_bug.cgi?id=9257
Fix r8169 regression on ASUS motherboards.
The r8169 ethernet driver worked fine in 2.6.23, but fails
in 2.6.24-rc* for the onboard ethernet of ASUS P5B series motherboards.
This patch fixes it again.
Signed-off-by: Mark Lord <[email protected]>
--- broken/drivers/net/r8169.c 2007-11-07 12:32:29.000000000 -0500
+++ linux/drivers/net/r8169.c 2007-11-07 12:55:07.000000000 -0500
@@ -1325,6 +1325,7 @@
rtl8169sb_hw_phy_config(ioaddr);
break;
case RTL_GIGA_MAC_VER_11:
+ break;
case RTL_GIGA_MAC_VER_12:
case RTL_GIGA_MAC_VER_17:
rtl8168b_hw_phy_config(ioaddr);
Mark Lord <lkml <at> rtr.ca> writes:
> My ASUS board has one of these:
>Realtek Semiconductor Co., Ltd. RTL8111/8168B
>PCI Express Gigabit
> With CONFIG_PCI_MSI=y, it also fails, and then isn't even
detected lspci)
> on subsequent reboots. A power cycle is required to get
>it to show up again.
> Help?
Hello,
I have a asus a6t with RTL8111/8168B
PCI Express Gigabit and I have had a similar
problem.
PCI-MSI-edge seems to break this ethernet card.
My card has stopped to work, I have powered off
my notebook for hours, but I am not been lucky,
because it has showed up only one time and then in
next reboot with kernel 2.6.23 is disappeared again
(in this kernel there is not problem with this
ethernet card ).
I have reflashed bios and fortunately this card
now works again. contacted one realtek developer,
but he hasn't replied. I am been lucky
to not send my notebook in repairing.
It's very bad !
Mark Lord <[email protected]> :
> Fix r8169 regression on ASUS motherboards.
>
> The r8169 ethernet driver worked fine in 2.6.23, but fails
> in 2.6.24-rc* for the onboard ethernet of ASUS P5B series motherboards.
> This patch fixes it again.
[...]
> --- broken/drivers/net/r8169.c 2007-11-07 12:32:29.000000000 -0500
> +++ linux/drivers/net/r8169.c 2007-11-07 12:55:07.000000000 -0500
> @@ -1325,6 +1325,7 @@
> rtl8169sb_hw_phy_config(ioaddr);
> break;
> case RTL_GIGA_MAC_VER_11:
> + break;
> case RTL_GIGA_MAC_VER_12:
> case RTL_GIGA_MAC_VER_17:
> rtl8168b_hw_phy_config(ioaddr);
I am not convinced, the broken ones include some RTL_GIGA_MAC_VER_12
too, namely XID = 0x38000000.
I would much prefer to revert the broken commit completely (which I am
currently isolating).
--
Ueimor
cecco <[email protected]> :
[...]
> I have a asus a6t with RTL8111/8168B
> PCI Express Gigabit and I have had a similar
> problem.
> PCI-MSI-edge seems to break this ethernet card.
> My card has stopped to work, I have powered off
> my notebook for hours, but I am not been lucky,
> because it has showed up only one time and then in
> next reboot with kernel 2.6.23 is disappeared again
> (in this kernel there is not problem with this
> ethernet card ).
Did you unplug the battery ?
--
Ueimor
Francois Romieu wrote:
> Mark Lord <[email protected]> :
>> Fix r8169 regression on ASUS motherboards.
>>
>> The r8169 ethernet driver worked fine in 2.6.23, but fails
>> in 2.6.24-rc* for the onboard ethernet of ASUS P5B series motherboards.
>> This patch fixes it again.
> [...]
>> --- broken/drivers/net/r8169.c 2007-11-07 12:32:29.000000000 -0500
>> +++ linux/drivers/net/r8169.c 2007-11-07 12:55:07.000000000 -0500
>> @@ -1325,6 +1325,7 @@
>> rtl8169sb_hw_phy_config(ioaddr);
>> break;
>> case RTL_GIGA_MAC_VER_11:
>> + break;
>> case RTL_GIGA_MAC_VER_12:
>> case RTL_GIGA_MAC_VER_17:
>> rtl8168b_hw_phy_config(ioaddr);
>
> I am not convinced, the broken ones include some RTL_GIGA_MAC_VER_12
> too, namely XID = 0x38000000.
..
Tested and working here on VER_11. I don't have a VER_12, so I left that as-is.
If you want to fix that as well, just move the new "break;" down one line.
The rest of the broken commit works fine without the new call
to rtl8168b_hw_phy_config(ioaddr).
It's been weeks now, so please FIX it now.
Thanks.
Mark Lord wrote:
> Francois Romieu wrote:
>..
>> I am not convinced, the broken ones include some RTL_GIGA_MAC_VER_12
>> too, namely XID = 0x38000000.
..
Here is the updated patch for both VER_11 and VER_12.
Let's get this in, as the driver has been broken for weeks now.
* * * *
Fix r8169 regression on ASUS motherboards.
Second attempt. This one fixes both VER_11 and VER_12 MACs.
The r8169 ethernet driver worked fine in 2.6.23, but fails
in 2.6.24-rc* for the onboard ethernet of ASUS P5B series motherboards.
This patch fixes it again.
Signed-off-by: Mark Lord <[email protected]>
--- broken/drivers/net/r8169.c 2007-11-03 16:24:16.000000000 -0400
+++ linux/drivers/net/r8169.c 2007-11-07 17:22:59.000000000 -0500
@@ -1326,6 +1326,7 @@
break;
case RTL_GIGA_MAC_VER_11:
case RTL_GIGA_MAC_VER_12:
+ break;
case RTL_GIGA_MAC_VER_17:
rtl8168b_hw_phy_config(ioaddr);
break;
Mark Lord <[email protected]> :
> Mark Lord wrote:
> >Francois Romieu wrote:
> >..
> >>I am not convinced, the broken ones include some RTL_GIGA_MAC_VER_12
> >>too, namely XID = 0x38000000.
> ..
>
> Here is the updated patch for both VER_11 and VER_12.
> Let's get this in, as the driver has been broken for weeks now.
I have not been waiting for you and I am not interested in your
controversy.
I'll find the offending commit and revert it. It is that simple.
--
Ueimor
Mark Lord wrote:
> Mark Lord wrote:
>> Francois Romieu wrote:
>> ..
>>> I am not convinced, the broken ones include some RTL_GIGA_MAC_VER_12
>>> too, namely XID = 0x38000000.
> ..
>
> Here is the updated patch for both VER_11 and VER_12.
> Let's get this in, as the driver has been broken for weeks now.
>
> * * * *
>
> Fix r8169 regression on ASUS motherboards.
>
> Second attempt. This one fixes both VER_11 and VER_12 MACs.
>
> The r8169 ethernet driver worked fine in 2.6.23, but fails
> in 2.6.24-rc* for the onboard ethernet of ASUS P5B series motherboards.
> This patch fixes it again.
>
> Signed-off-by: Mark Lord <[email protected]>
>
> --- broken/drivers/net/r8169.c 2007-11-03 16:24:16.000000000 -0400
> +++ linux/drivers/net/r8169.c 2007-11-07 17:22:59.000000000 -0500
> @@ -1326,6 +1326,7 @@
> break;
> case RTL_GIGA_MAC_VER_11:
> case RTL_GIGA_MAC_VER_12:
> + break;
> case RTL_GIGA_MAC_VER_17:
> rtl8168b_hw_phy_config(ioaddr);
> break;
..
I've now received a couple of private emails from people reporting
full success with this patch.
Cheers
Francois Romieu wrote:
> Mark Lord <[email protected]> :
>> Mark Lord wrote:
>>> Francois Romieu wrote:
>>> ..
>>>> I am not convinced, the broken ones include some RTL_GIGA_MAC_VER_12
>>>> too, namely XID = 0x38000000.
>> ..
>>
>> Here is the updated patch for both VER_11 and VER_12.
>> Let's get this in, as the driver has been broken for weeks now.
>
> I have not been waiting for you and I am not interested in your
> controversy.
>
> I'll find the offending commit and revert it. It is that simple.
..
I think the rest of the commit was fine -- there seems to be some
nice cleanups there to make it easier to maintain.
Just the new register writes (rtl8168b_hw_phy_config()) are mucking things up.
Prevent those from happening, and all is well.
Cheers
Mark Lord <[email protected]> :
[...]
> I've now received a couple of private emails from people reporting
> full success with this patch.
Ok, I have pushed the patch below for Jeff to pull at korg.
>From 1dd7681bc2ff171341ea5cae957f8ecb5c0c102e Mon Sep 17 00:00:00 2001
From: Mark Lord <[email protected]>
Date: Thu, 8 Nov 2007 01:03:04 +0100
Subject: [PATCH] r8169: revert 7da97ec96a0934319c7fbedd3d38baf533e20640 (partly)
Various symptoms depending on the .config options:
- the card stops working after some (short) time
- the card does not work at all
- the card disappears (nothing in lspci/dmesg)
A real power-off is needed to recover the card.
Signed-off-by: Mark Lord <[email protected]>
Signed-off-by: Francois Romieu <[email protected]>
---
drivers/net/r8169.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 9dbab3f..a37cf82 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -1328,6 +1328,7 @@ static void rtl_hw_phy_config(struct net_device *dev)
break;
case RTL_GIGA_MAC_VER_11:
case RTL_GIGA_MAC_VER_12:
+ break;
case RTL_GIGA_MAC_VER_17:
rtl8168b_hw_phy_config(ioaddr);
break;
--
1.5.3.3
--
Ueimor
Am Wed, 07 Nov 2007 11:07:07 -0500
schrieb Mark Lord <[email protected]>:
> My ASUS board has one of these:
>
> 01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
> RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)
> Subsystem: ASUSTeK Computer Inc. Unknown device 81aa Control: I/O+
> Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR-
> FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast
> >TAbort- <TAbort- <MAbort- >SERR- <PERR- Interrupt: pin A routed to
> >IRQ 16 Region 0: I/O ports at 9800 [size=256]
> Region 2: Memory at ff3ff000 (64-bit, non-prefetchable)
> [size=4K] Expansion ROM at ff3c0000 [disabled] [size=128K]
> Capabilities: [40] Power Management version 2
> Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA
> PME(D0-,D1+,D2+,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0
> DScale=0 PME- Capabilities: [48] Vital Product Data
> Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+
> Queue=0/1 Enable- Address: 0000000000000000 Data: 0000
> Capabilities: [60] Express Endpoint IRQ 0
> Device: Supported: MaxPayload 1024 bytes, PhantFunc
> 0, ExtTag+ Device: Latency L0s <1us, L1 unlimited
> Device: AtnBtn+ AtnInd+ PwrInd+
> Device: Errors: Correctable- Non-Fatal- Fatal-
> Unsupported- Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
> Device: MaxPayload 128 bytes, MaxReadReq 4096 bytes
> Link: Supported Speed 2.5Gb/s, Width x4, ASPM L0s,
> Port 0 Link: Latency L0s unlimited, L1 unlimited
> Link: ASPM Disabled RCB 64 bytes CommClk+ ExtSynch-
> Link: Speed 2.5Gb/s, Width x1
> Capabilities: [84] Vendor Specific Information
>
> It works perfectly in 2.6.23.
> It does not work in 2.6.24-rc2. Dunno about -rc1 or earlier -git*.
>
> Without CONFIG_PCI_MSI, it works slightly, enough to ping it a couple
> of times, but it then dies when used for anything real:
>
> r8169 Gigabit Ethernet driver 2.2LK loaded
> r8169 0000:01:00.0: no MSI. Back to INTx.
> ...
> eth0: RTL8168b/8111b at 0xf884a000, 00:17:31:64:e0:bc, XID
> 30000000 IRQ 16 ...
> r8169: eth0: link up
> ...
> kernel: NETDEV WATCHDOG: eth0: transmit timed out
> r8169: eth0: link up
> ...
> Not usable from this point on.
Same problem here with a MSI K9AGM2 board. The problem appeared in
2.6.24-rc1 (http://bugzilla.kernel.org/show_bug.cgi?id=9257).
It seems to be better in -rc2, at least the chip is detected again. I
can assign an IP to that interface and bring it up, but no data traffic
is possible. After some tests in both directions, ifconfig reports 157.6
KiB RX bytes, but TX bytes is 0, so sent packets seem to disappear
quite early.
Thanks,
Hans
Am Thu, 8 Nov 2007 08:52:56 +0100
schrieb Hans-J?rgen Koch <[email protected]>:
> Am Wed, 07 Nov 2007 11:07:07 -0500
> schrieb Mark Lord <[email protected]>:
>
> > My ASUS board has one of these:
> >
> > 01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
> > RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)
> > Subsystem: ASUSTeK Computer Inc. Unknown device 81aa Control: I/O+
> > Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping-
> > SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast
> > >TAbort- <TAbort- <MAbort- >SERR- <PERR- Interrupt: pin A routed to
> > >IRQ 16 Region 0: I/O ports at 9800 [size=256]
> > Region 2: Memory at ff3ff000 (64-bit, non-prefetchable)
> > [size=4K] Expansion ROM at ff3c0000 [disabled] [size=128K]
> > Capabilities: [40] Power Management version 2
> > Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA
> > PME(D0-,D1+,D2+,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0
> > DScale=0 PME- Capabilities: [48] Vital Product Data
> > Capabilities: [50] Message Signalled Interrupts: Mask-
> > 64bit+ Queue=0/1 Enable- Address: 0000000000000000 Data: 0000
> > Capabilities: [60] Express Endpoint IRQ 0
> > Device: Supported: MaxPayload 1024 bytes, PhantFunc
> > 0, ExtTag+ Device: Latency L0s <1us, L1 unlimited
> > Device: AtnBtn+ AtnInd+ PwrInd+
> > Device: Errors: Correctable- Non-Fatal- Fatal-
> > Unsupported- Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
> > Device: MaxPayload 128 bytes, MaxReadReq 4096 bytes
> > Link: Supported Speed 2.5Gb/s, Width x4, ASPM L0s,
> > Port 0 Link: Latency L0s unlimited, L1 unlimited
> > Link: ASPM Disabled RCB 64 bytes CommClk+ ExtSynch-
> > Link: Speed 2.5Gb/s, Width x1
> > Capabilities: [84] Vendor Specific Information
> >
> > It works perfectly in 2.6.23.
> > It does not work in 2.6.24-rc2. Dunno about -rc1 or earlier -git*.
> >
> > Without CONFIG_PCI_MSI, it works slightly, enough to ping it a
> > couple of times, but it then dies when used for anything real:
> >
> > r8169 Gigabit Ethernet driver 2.2LK loaded
> > r8169 0000:01:00.0: no MSI. Back to INTx.
> > ...
> > eth0: RTL8168b/8111b at 0xf884a000, 00:17:31:64:e0:bc, XID
> > 30000000 IRQ 16 ...
> > r8169: eth0: link up
> > ...
> > kernel: NETDEV WATCHDOG: eth0: transmit timed out
> > r8169: eth0: link up
> > ...
> > Not usable from this point on.
>
> Same problem here with a MSI K9AGM2 board. The problem appeared in
> 2.6.24-rc1 (http://bugzilla.kernel.org/show_bug.cgi?id=9257).
>
> It seems to be better in -rc2, at least the chip is detected again. I
> can assign an IP to that interface and bring it up, but no data
> traffic is possible. After some tests in both directions, ifconfig
> reports 157.6 KiB RX bytes, but TX bytes is 0, so sent packets seem
> to disappear quite early.
The patch just submitted by Francois Romieu fixes the problem.
Thanks,
Hans
Am Thu, 8 Nov 2007 01:21:12 +0100
schrieb Francois Romieu <[email protected]>:
> Mark Lord <[email protected]> :
> [...]
> > I've now received a couple of private emails from people reporting
> > full success with this patch.
>
> Ok, I have pushed the patch below for Jeff to pull at korg.
>
> >From 1dd7681bc2ff171341ea5cae957f8ecb5c0c102e Mon Sep 17 00:00:00
> >2001
> From: Mark Lord <[email protected]>
> Date: Thu, 8 Nov 2007 01:03:04 +0100
> Subject: [PATCH] r8169: revert
> 7da97ec96a0934319c7fbedd3d38baf533e20640 (partly)
>
> Various symptoms depending on the .config options:
> - the card stops working after some (short) time
> - the card does not work at all
> - the card disappears (nothing in lspci/dmesg)
>
> A real power-off is needed to recover the card.
This patch fixes the same problem on my MSI board.
>
> Signed-off-by: Mark Lord <[email protected]>
> Signed-off-by: Francois Romieu <[email protected]>
Acked-by: Hans J. Koch <[email protected]>
> ---
> drivers/net/r8169.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
> index 9dbab3f..a37cf82 100644
> --- a/drivers/net/r8169.c
> +++ b/drivers/net/r8169.c
> @@ -1328,6 +1328,7 @@ static void rtl_hw_phy_config(struct net_device
> *dev) break;
> case RTL_GIGA_MAC_VER_11:
> case RTL_GIGA_MAC_VER_12:
> + break;
> case RTL_GIGA_MAC_VER_17:
> rtl8168b_hw_phy_config(ioaddr);
> break;
Francois Romieu wrote:
>
> Ok, I have pushed the patch below for Jeff to pull at korg.
>
>>From 1dd7681bc2ff171341ea5cae957f8ecb5c0c102e Mon Sep 17 00:00:00 2001
> From: Mark Lord <[email protected]>
> Date: Thu, 8 Nov 2007 01:03:04 +0100
> Subject: [PATCH] r8169: revert 7da97ec96a0934319c7fbedd3d38baf533e20640 (partly)
>
> Various symptoms depending on the .config options:
> - the card stops working after some (short) time
> - the card does not work at all
> - the card disappears (nothing in lspci/dmesg)
>
> A real power-off is needed to recover the card.
>
> Signed-off-by: Mark Lord <[email protected]>
> Signed-off-by: Francois Romieu <[email protected]>
> ---
> drivers/net/r8169.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
> index 9dbab3f..a37cf82 100644
> --- a/drivers/net/r8169.c
> +++ b/drivers/net/r8169.c
> @@ -1328,6 +1328,7 @@ static void rtl_hw_phy_config(struct net_device *dev)
> break;
> case RTL_GIGA_MAC_VER_11:
> case RTL_GIGA_MAC_VER_12:
> + break;
> case RTL_GIGA_MAC_VER_17:
> rtl8168b_hw_phy_config(ioaddr);
> break;
..
Stop the presses: Another person has now reported back to me.
This guy has the VER_17 chip inside a notebook, and the same problem.
So the unified fix for all of these is to just get rid of rtl8168b_hw_phy_config(),
as that code is all that is really different from 2.6.23 (where all is okay).
Updated patch below.
* * * * *
Fix r8169B regression on ASUS motherboards (and MSI, and..)
Third/final iteration.
This replaces the earlier versions of this patch.
This one fixes *all* versions of r6169 *B* variant,
restoring the init code back to what it was in 2.6.23.
The r8169 ethernet driver worked fine in 2.6.23, but fails
in 2.6.24-rc* for the onboard ethernet of some ASUS (MAC_VER_11)
and MSI (MAC_VER_12) motherboards, and also for some notebooks
(MAC_VER_17) that use this chip.
Various symptoms depending on the .config options:
- the card stops working after some (short) time
- the card does not work at all
- the card disappears (nothing in lspci/dmesg)
A real power-off is needed to recover the card.
This patch fixes it again.
Signed-off-by: Mark Lord <[email protected]>
--- linux-2.6.24-rc2/drivers/net/r8169.c 2007-11-06 22:56:24.000000000 -0500
+++ linux/drivers/net/r8169.c 2007-11-08 09:05:08.000000000 -0500
@@ -1247,13 +1247,6 @@
}
static void rtl8168b_hw_phy_config(void __iomem *ioaddr)
{
- struct phy_reg phy_reg_init[] = {
- { 0x1f, 0x0000 },
- { 0x10, 0xf41b },
- { 0x1f, 0x0000 }
- };
-
- rtl_phy_write(ioaddr, phy_reg_init, ARRAY_SIZE(phy_reg_init));
}
static void rtl8168cp_hw_phy_config(void __iomem *ioaddr)
Mark Lord <[email protected]> :
[snip snip]
> Stop the presses: Another person has now reported back to me.
> This guy has the VER_17 chip inside a notebook, and the same problem.
>
> So the unified fix for all of these is to just get rid of
> rtl8168b_hw_phy_config(),
> as that code is all that is really different from 2.6.23 (where all is
> okay).
>
> Updated patch below.
Thanks. I'll push an update for it and probably a fix for a different
annoyance before going to bed.
It will help future developments if you can convince the shadow man to
send a few informations: I have no known tester for the VER_17 chip.
As a side note, people should really really really consider posting on
[email protected] when reporting test results.
--
Ueimor