From: Ayaz Abdulla <hidden> Date: 2007-02-09 04:56:28
David Ford wrote:
On 2/5/07, *Andrew Morton* <akpm@linux-foundation.org
<mailto:akpm@linux-foundation.org>> wrote:
On Sun, 04 Feb 2007 23:48:33 -0600 Robert Hancock <hancockr@shaw.ca
<mailto:hancockr@shaw.ca>> wrote:
> Andrew Morton wrote:
> > On Sun, 04 Feb 2007 23:13:09 -0600 Robert Hancock <
hancockr@shaw.ca <mailto:hancockr@shaw.ca>> 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.
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.
-----------------------------------------------------------------------------------
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!').
--
Tobias PGP: http://9ac7e0bc.uguu.de
このメールは十割再利用されたビットで作られています。
From: Jeff Garzik <hidden> Date: 2007-02-09 14:50:40
Tobias Diedrich wrote:
Tobias Diedrich wrote:
quoted
Ayaz Abdulla wrote:
quoted
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
From: Robert Hancock <hidden> Date: 2007-02-10 04:41:04
Ayaz Abdulla wrote:
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).
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/
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.
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
20070130183208.GE11814@melchior.yamamaya.is-a-geek.org).
--
Tobias PGP: http://9ac7e0bc.uguu.de
このメールは十割再利用されたビットで作られています。
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.
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
20070130183208.GE11814@melchior.yamamaya.is-a-geek.org).
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.
--
Tobias PGP: http://9ac7e0bc.uguu.de
このメールは十割再利用されたビットで作られています。