Skip to contentSkip to conversation

forcedeth problems on 2.6.20-rc6-mm3

DISCUSSION Robert Hancock 6 participants 15 messages Feb 5, 2007 – Feb 16, 2007 1 message not in the archive

Subsystems (2)
Networking Network drivers
lore
Share & tools
lore

Robert Hancock

author
#0 lore raw

Something's busted with forcedeth in 2.6.20-rc6-mm3 for me relative to 2.6.20-rc6. There's no errors in dmesg, but it seems no packets ever get received and so the machine can't get an IP address. I tried reverting all the -mm changes to drivers/net/forcedeth.c, which didn't help. The network controller shares an IRQ with the USB OHCI controller which is receiving interrupts, so it doesn't seem like an interrupt routing problem, though I suppose something wierd could be happening there.

This is on an Asus A8N-SLI Deluxe (CK804 chipset) on x86_64.

Any suggestions on how to debug/what to try reverting to see what's causing this?

Signature · 3 lines
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from [email protected]
Home Page: http://www.roberthancock.com/
#1 lore raw
Quoted 8 lines · On Sun, 04 Feb 2007 23:13:09 -0600 Robert Hancock <[email protected]> wrote:

Something's busted with forcedeth in 2.6.20-rc6-mm3 for me relative to 2.6.20-rc6. There's no errors in dmesg, but it seems no packets ever get received and so the machine can't get an IP address. I tried reverting all the -mm changes to drivers/net/forcedeth.c, which didn't help. The network controller shares an IRQ with the USB OHCI controller which is receiving interrupts, so it doesn't seem like an interrupt routing problem, though I suppose something wierd could be happening there.

Quoted 4 lines

This is on an Asus A8N-SLI Deluxe (CK804 chipset) on x86_64.

Any suggestions on how to debug/what to try reverting to see what's causing this?

There are many forcedeth changes in git-netdev-all.patch. Can you try reverting drivers/net/forcedeth.c back to the unpatched version from 2.6.20-rc6?

Thanks.

author
#2 lore raw
Quoted 6 lines · Andrew Morton
Quoted 4 lines · On Sun, 04 Feb 2007 23:13:09 -0600 Robert Hancock <[email protected]> wrote:

Something's busted with forcedeth in 2.6.20-rc6-mm3 for me relative to 2.6.20-rc6. There's no errors in dmesg, but it seems no packets ever get received and so the machine can't get an IP address. I tried reverting all the -mm changes to drivers/net/forcedeth.c, which didn't help. The network controller shares an IRQ with the USB OHCI controller which is receiving interrupts, so it doesn't seem like an interrupt routing problem, though I suppose something wierd could be happening there.

This is on an Asus A8N-SLI Deluxe (CK804 chipset) on x86_64.

Quoted 8 lines
Quoted 1 line

Any suggestions on how to debug/what to try reverting to see what's causing this?

There are many forcedeth changes in git-netdev-all.patch. Can you try reverting drivers/net/forcedeth.c back to the unpatched version from 2.6.20-rc6?

Thanks.

That's essentially what I did, it didn't appear to help. I assume the problem must lie elsewhere..

Signature · 3 lines
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from [email protected]
Home Page: http://www.roberthancock.com/
#3 lore raw
Quoted 20 lines · On Sun, 04 Feb 2007 23:48:33 -0600 Robert Hancock <[email protected]> wrote:
Quoted 19 lines · Andrew Morton
Quoted 8 lines · On Sun, 04 Feb 2007 23:13:09 -0600 Robert Hancock <[email protected]> wrote:

Something's busted with forcedeth in 2.6.20-rc6-mm3 for me relative to 2.6.20-rc6. There's no errors in dmesg, but it seems no packets ever get received and so the machine can't get an IP address. I tried reverting all the -mm changes to drivers/net/forcedeth.c, which didn't help. The network controller shares an IRQ with the USB OHCI controller which is receiving interrupts, so it doesn't seem like an interrupt routing problem, though I suppose something wierd could be happening there.

Quoted 4 lines

This is on an Asus A8N-SLI Deluxe (CK804 chipset) on x86_64.

Any suggestions on how to debug/what to try reverting to see what's causing this?

There are many forcedeth changes in git-netdev-all.patch. Can you try reverting drivers/net/forcedeth.c back to the unpatched version from 2.6.20-rc6?

Quoted 6 lines
Quoted 2 lines

Thanks.

That's essentially what I did, it didn't appear to help. I assume the problem must lie elsewhere..

doh, I missed that.

It's presumably not the driver and nobody else seems to be hitting this, so it must be something peculiar to your setup. But I don't know what it might be, sorry.

A message that is not in the archive (sent off-list or not yet received): [email protected]

#5 lore raw
Quoted 54 lines · David Ford

On 2/5/07, *Andrew Morton* <[email protected] <mailto:[email protected]>> wrote:

On Sun, 04 Feb 2007 23:48:33 -0600 Robert Hancock <[email protected] <mailto:[email protected]>> wrote:

> Andrew Morton wrote:
> > On Sun, 04 Feb 2007 23:13:09 -0600 Robert Hancock <
[email protected] <mailto:[email protected]>> wrote:
> >
> >> Something's busted with forcedeth in 2.6.20-rc6-mm3 for me
relative to
> >> 2.6.20-rc6. There's no errors in dmesg, but it seems no
packets ever get
> >> received and so the machine can't get an IP address. I tried
reverting
> >> all the -mm changes to drivers/net/forcedeth.c, which didn't
help. The
> >> network controller shares an IRQ with the USB OHCI controller
which is
> >> receiving interrupts, so it doesn't seem like an interrupt routing > >> problem, though I suppose something wierd could be happening
there.
> >>
> >> This is on an Asus A8N-SLI Deluxe (CK804 chipset) on x86_64. > >>
> >> Any suggestions on how to debug/what to try reverting to see
what's
> >> causing this?
> >
> > There are many forcedeth changes in git-netdev-all.patch. Can you > > try reverting drivers/net/forcedeth.c back to the unpatched version > > from 2.6.20-rc6?
> >
> > Thanks.
> >
>
> That's essentially what I did, it didn't appear to help. I assume
the
> problem must lie elsewhere..
>

doh, I missed that.

It's presumably not the driver and nobody else seems to be hitting this, so
it must be something peculiar to your setup. But I don't know what it might be, sorry.

Actually it has been reported by several other people here including myself but it seems to have been overlooked here ;)

See the messages with forcedeth in the subject line over the past few weeks.

Quoted 7 lines

I put 2.6.20-gentoo on my machine this weekend with debug printks enabled and right now I have yet to lose connectivity -- going on ~20 hours worth.

Previously I would lose connectivity within minutes of booting up. I had a script set up that detected the ping loss of a gateway and would restart both interfaces (dual onboard nics).

Tonight I will disable the debug printks and see if the system remains online. There was a big patch applied to forcedeth for 2.6.20, previously I was having these issues for several of the -19 series.

David

For all those who are having issues, please try out the attached patch.

Ayaz

-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------

drivers/net/forcedeth.c +7 -3
@@ -3104,13 +3104,17 @@
 	struct fe_priv *np = netdev_priv(dev);
 	u8 __iomem *base = get_hwbase(dev);
 	unsigned long flags;
+	u32 retcode;
 
-	if (np->desc_ver == DESC_VER_1 || np->desc_ver == DESC_VER_2)
+	if (np->desc_ver == DESC_VER_1 || np->desc_ver == DESC_VER_2) {
 		pkts = nv_rx_process(dev, limit);
-	else
+		retcode = nv_alloc_rx(dev);
+	} else {
 		pkts = nv_rx_process_optimized(dev, limit);
+		retcode = nv_alloc_rx_optimized(dev);
+	}
 
-	if (nv_alloc_rx(dev)) {
+	if (retcode) {
 		spin_lock_irqsave(&np->lock, flags);
 		if (!np->in_shutdown)
 			mod_timer(&np->oom_kick, jiffies + OOM_REFILL);
#6 lore raw
Quoted 1 line · Ayaz Abdulla

For all those who are having issues, please try out the attached patch.

Will try.
I reverted to 2.6.19 w/o suspend/resume patch last weekend to make sure on 2.6.19 forcedeth is stable and noticed something odd:

Because I didn't include the suspend/resume patch I obviously had to a down/rmmod/modprobe/up cycle after each resume and I noticed that the behaviour seems to alternate between resumes:

Behaviour 1:
After modprobe I get two interface 'eth0' and 'eth1' for the two ports, as expected.

Behaviour 2:
After modprobe I get one interface 'eth3' (which should be 'eth1') and one interface with increasing numbers (which should be 'eth0', last resume it was 'eth12' IIRC).

As I said if I get behaviour 1 on one resume I get behaviour 2 on the next resume and vice versa. That seems rather odd to me.

On a not quite related note, forcedeth shows a different ethtool output (compared to e100), when no cable is connected to the port:

forcedeth, no cable connected:

|Settings for eth1:
|	Supported ports: [ MII ]
|	Supported link modes:   10baseT/Half 10baseT/Full 
|	                        100baseT/Half 100baseT/Full 
|	                        1000baseT/Full 
|	Supports auto-negotiation: Yes
|	Advertised link modes:  10baseT/Half 10baseT/Full 
|	                        100baseT/Half 100baseT/Full 
|	                        1000baseT/Full 
|	Advertised auto-negotiation: Yes
|	Speed: Unknown! (65535)
|	Duplex: Unknown! (255)
|	Port: MII
|	PHYAD: 1
|	Transceiver: external
|	Auto-negotiation: on
|	Supports Wake-on: g
|	Wake-on: d
|	Link detected: no

e100, no cable connected:

|Settings for eth0:
|        Supported ports: [ TP MII ]
|        Supported link modes:   10baseT/Half 10baseT/Full 
|                                100baseT/Half 100baseT/Full 
|        Supports auto-negotiation: Yes
|        Advertised link modes:  10baseT/Half 10baseT/Full 
|                                100baseT/Half 100baseT/Full 
|        Advertised auto-negotiation: Yes
|        Speed: 10Mb/s
|        Duplex: Half
|        Port: MII
|        PHYAD: 1
|        Transceiver: internal
|        Auto-negotiation: on
|        Supports Wake-on: g
|        Wake-on: g
|        Current message level: 0x00000007 (7)
|        Link detected: no

Note that e100 returns the lowest possible speed if no link is detected, while forcedeth seems to return -1, which ethtool doesn't seem to recognise as a valid response (I guess, why else would it show the number after 'Unknown!').

Signature · 2 lines
Tobias						PGP: http://9ac7e0bc.uguu.de
このメールは十割再利用されたビットで作られています。
#7 lore raw
Quoted 4 lines · Tobias Diedrich
Quoted 1 line · Ayaz Abdulla

For all those who are having issues, please try out the attached patch.

Will try.

Does not apply cleanly against 2.6.20, is this one fixed up right?

drivers/net/forcedeth.c.new renamed from drivers/net/forcedeth.c.orig +8 -2
@@ -2603,10 +2603,16 @@
 	struct fe_priv *np = netdev_priv(dev);
 	u8 __iomem *base = get_hwbase(dev);
 	unsigned long flags;
+	u32 retcode;
 
-	pkts = nv_rx_process(dev, limit);
+	if (np->desc_ver == DESC_VER_1 || np->desc_ver == DESC_VER_2) {
+		pkts = nv_rx_process(dev, limit);
+		retcode = nv_alloc_rx(dev);
+	} else {
+		retcode = nv_alloc_rx_optimized(dev);
+	}
 
-	if (nv_alloc_rx(dev)) {
+	if (retcode) {
 		spin_lock_irqsave(&np->lock, flags);
 		if (!np->in_shutdown)
 			mod_timer(&np->oom_kick, jiffies + OOM_REFILL);
Signature · 2 lines
Tobias						PGP: http://9ac7e0bc.uguu.de
このメールは十割再利用されたビットで作られています。
#8 lore raw
Quoted 6 lines · Tobias Diedrich
Quoted 3 lines · Tobias Diedrich
Quoted 1 line · Ayaz Abdulla

For all those who are having issues, please try out the attached patch.

Will try.

Does not apply cleanly against 2.6.20, is this one fixed up right?

It probably needs to be top of 2.6.20-git-latest or 2.6.20-rc6-mm3.

IOW, the forcedeth changes in question are not in 2.6.20, and you need to apply the patch on top of the latest batch of forcedeth changes.

Jeff

#9 lore raw
Quoted 4 lines · Jeff Garzik
Quoted 3 lines · Tobias Diedrich
Quoted 2 lines · Tobias Diedrich
Quoted 1 line · Ayaz Abdulla

For all those who are having issues, please try out the attached patch.

Quoted 8 lines
Quoted 3 lines
Quoted 1 line

Will try.

Does not apply cleanly against 2.6.20, is this one fixed up right?

It probably needs to be top of 2.6.20-git-latest or 2.6.20-rc6-mm3.

IOW, the forcedeth changes in question are not in 2.6.20, and you need to apply the patch on top of the latest batch of forcedeth changes.

Well, it hasn't blown up on me despite being applied to 2.6.20... The problem I was seeing might even be fixed in 2.6.20 vanilla, since the last version I saw it in was 2.6.20-rc6 and then I reverted to 2.6.19 to make sure that one is ok (see [email protected]).

Signature · 2 lines
Tobias						PGP: http://9ac7e0bc.uguu.de
このメールは十割再利用されたビットで作られています。
#10 lore raw
Quoted 11 lines · Tobias Diedrich
Quoted 10 lines · Jeff Garzik
Quoted 6 lines · Tobias Diedrich
Quoted 3 lines · Tobias Diedrich
Quoted 1 line · Ayaz Abdulla

For all those who are having issues, please try out the attached patch.

Will try.

Does not apply cleanly against 2.6.20, is this one fixed up right?

It probably needs to be top of 2.6.20-git-latest or 2.6.20-rc6-mm3.

Quoted 8 lines
Quoted 2 lines

IOW, the forcedeth changes in question are not in 2.6.20, and you need to apply the patch on top of the latest batch of forcedeth changes.

Well, it hasn't blown up on me despite being applied to 2.6.20... The problem I was seeing might even be fixed in 2.6.20 vanilla, since the last version I saw it in was 2.6.20-rc6 and then I reverted to 2.6.19 to make sure that one is ok (see [email protected]).

And having run vanilla 2.6.20 since my last mail, I haven't seen the problem on that one either.
So I _guess_ the particular problem I was seeing was fixed somewhere between 2.6.20-rc6 and 2.6.20. But since I can't reliably trigger it, I can't say that for sure.

Signature · 2 lines
Tobias						PGP: http://9ac7e0bc.uguu.de
このメールは十割再利用されたビットで作られています。
author
#11 lore raw
In reply to Ayaz Abdulla
Quoted 3 lines · Ayaz Abdulla

For all those who are having issues, please try out the attached patch.

Ayaz

Seems to solve the problem for me (not heavily tested, but certainly isn't totally dead as it was before).

Signature · 3 lines
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from [email protected]
Home Page: http://www.roberthancock.com/
#12 lore raw
In reply to Robert Hancock
Quoted 7 lines · Robert Hancock

Something's busted with forcedeth in 2.6.20-rc6-mm3 for me relative to 2.6.20-rc6. There's no errors in dmesg, but it seems no packets ever get received and so the machine can't get an IP address. I tried reverting all the -mm changes to drivers/net/forcedeth.c, which didn't help. The network controller shares an IRQ with the USB OHCI controller which is receiving interrupts, so it doesn't seem like an interrupt routing problem, though I suppose something wierd could be happening there.

IIRC, forcedeth tries to use MSI by default. Perhaps the hardware is using it, but the kernel thinks enabling it didn't work? I think there's a module option for forcedeth to disable MSI, which might be worth a try to see if it has any effect.

-Daniel
*This .sig left intentionally blank*

author
#13 lore raw
Quoted 11 lines · Daniel Barkalow
Quoted 7 lines · Robert Hancock

Something's busted with forcedeth in 2.6.20-rc6-mm3 for me relative to 2.6.20-rc6. There's no errors in dmesg, but it seems no packets ever get received and so the machine can't get an IP address. I tried reverting all the -mm changes to drivers/net/forcedeth.c, which didn't help. The network controller shares an IRQ with the USB OHCI controller which is receiving interrupts, so it doesn't seem like an interrupt routing problem, though I suppose something wierd could be happening there.

IIRC, forcedeth tries to use MSI by default. Perhaps the hardware is using it, but the kernel thinks enabling it didn't work? I think there's a module option for forcedeth to disable MSI, which might be worth a try to see if it has any effect.

I must have messed something up when testing before - reverting to forcedeth.c from 2.6.20-rc6 does indeed fix the problem. And it doesn't seem like no packets at all are received with the -mm3 version (driver version 0.60), either - if I do a tcpdump I can get Ethernet packets showing up, but I can't ping my router so it seems like something isn't getting through properly. With the 2.6.20-rc6 version (driver version 0.59) it works fine. I switched back and forth between versions and this seems repeatable.

I don't think it's MSI related, the CK804 version of these controllers doesn't support MSI and the driver shouldn't be trying to use it. I tried the MSI and MSI-X disable options on the 0.60 driver, but that didn't help.

Signature · 3 lines
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from [email protected]
Home Page: http://www.roberthancock.com/
#14 lore raw
Quoted 25 lines · On Mon, 05 Feb 2007 18:35:06 -0600 Robert Hancock <[email protected]> wrote:
Quoted 10 lines · Daniel Barkalow
Quoted 7 lines · Robert Hancock

Something's busted with forcedeth in 2.6.20-rc6-mm3 for me relative to 2.6.20-rc6. There's no errors in dmesg, but it seems no packets ever get received and so the machine can't get an IP address. I tried reverting all the -mm changes to drivers/net/forcedeth.c, which didn't help. The network controller shares an IRQ with the USB OHCI controller which is receiving interrupts, so it doesn't seem like an interrupt routing problem, though I suppose something wierd could be happening there.

Quoted 4 lines

IIRC, forcedeth tries to use MSI by default. Perhaps the hardware is using it, but the kernel thinks enabling it didn't work? I think there's a module option for forcedeth to disable MSI, which might be worth a try to see if it has any effect.

I must have messed something up when testing before - reverting to forcedeth.c from 2.6.20-rc6 does indeed fix the problem. And it doesn't seem like no packets at all are received with the -mm3 version (driver version 0.60), either - if I do a tcpdump I can get Ethernet packets showing up, but I can't ping my router so it seems like something isn't getting through properly. With the 2.6.20-rc6 version (driver version 0.59) it works fine. I switched back and forth between versions and this seems repeatable.

Quoted 5 lines

I don't think it's MSI related, the CK804 version of these controllers doesn't support MSI and the driver shouldn't be trying to use it. I tried the MSI and MSI-X disable options on the 0.60 driver, but that didn't help.

OK, thanks. Jeff, please note that the forcedeth changes in git-netdev-all have a problem.

#15 lore raw
Quoted 28 lines · On Mon, 5 Feb 2007 16:52:24 -0800 Andrew Morton <[email protected]>…
Quoted 25 lines · On Mon, 05 Feb 2007 18:35:06 -0600 Robert Hancock <[email protected]> wrote:
Quoted 10 lines · Daniel Barkalow
Quoted 7 lines · Robert Hancock

Something's busted with forcedeth in 2.6.20-rc6-mm3 for me relative to 2.6.20-rc6. There's no errors in dmesg, but it seems no packets ever get received and so the machine can't get an IP address. I tried reverting all the -mm changes to drivers/net/forcedeth.c, which didn't help. The network controller shares an IRQ with the USB OHCI controller which is receiving interrupts, so it doesn't seem like an interrupt routing problem, though I suppose something wierd could be happening there.

Quoted 4 lines

IIRC, forcedeth tries to use MSI by default. Perhaps the hardware is using it, but the kernel thinks enabling it didn't work? I think there's a module option for forcedeth to disable MSI, which might be worth a try to see if it has any effect.

I must have messed something up when testing before - reverting to forcedeth.c from 2.6.20-rc6 does indeed fix the problem. And it doesn't seem like no packets at all are received with the -mm3 version (driver version 0.60), either - if I do a tcpdump I can get Ethernet packets showing up, but I can't ping my router so it seems like something isn't getting through properly. With the 2.6.20-rc6 version (driver version 0.59) it works fine. I switched back and forth between versions and this seems repeatable.

Quoted 8 lines
Quoted 5 lines

I don't think it's MSI related, the CK804 version of these controllers doesn't support MSI and the driver shouldn't be trying to use it. I tried the MSI and MSI-X disable options on the 0.60 driver, but that didn't help.

OK, thanks. Jeff, please note that the forcedeth changes in git-netdev-all have a problem.

Well all the forcedeth patches seems to have wandered into mainline anyway.

Please test current git (or tomorrow's git snapshot), see if it works?