Endless Trying 100/HALF messages using FCC ethernet on MPC8248
On Jul 24, 2006, at 04:39, Laurent Pinchart wrote: Hi everybody, I'm not sure if this issue is ppc-specific, so forgive me if it should have been reported to the drivers/net/phy maintainer. When using the MPC8248 FCC ethernet ports, the following messages are printed by the kernel on the console when a link is down (ethernet cable unplugged): Trying 100/FULL Trying 100/HALF Trying 100/HALF Trying 100/HALF ... This goes on forever, with a new message every 5 or 10 seconds. The message is printed by drivers/net/phy/phy.c at line 463. Those messages are pretty annoying. Commenting the pr_info() call gave me some rest, but a proper fix is probably needed. For the record, I'm using FCC1 and FCC2 with an LXT973 phy in bit- banging mode. There are two bugs at play, here. One of which has been solved by a patch, which hasn't been accepted yet. However, there's still a bug, in that the PHY layer assumes that autonegotiation will complete if the link is down. I believe you only see the message if you bring up the interface while the link is down. I'm working on a fix for this. Andy
Endless Trying 100/HALF messages using FCC ethernet on MPC8248
On Mon, 24 Jul 2006 11:39:01 +0200 Laurent Pinchart laurent.pinchart at tbox.biz wrote: Hi everybody, I'm not sure if this issue is ppc-specific, so forgive me if it should have been reported to the drivers/net/phy maintainer. When using the MPC8248 FCC ethernet ports, the following messages are printed by the kernel on the console when a link is down (ethernet cable unplugged): Trying 100/FULL Trying 100/HALF Trying 100/HALF Trying 100/HALF ... This goes on forever, with a new message every 5 or 10 seconds. The message is printed by drivers/net/phy/phy.c at line 463. Those messages are pretty annoying. Commenting the pr_info() call gave me some rest, but a proper fix is probably needed. For the record, I'm using FCC1 and FCC2 with an LXT973 phy in bit-banging mode. The thing you'll need is to make driver to trust autonegotiation... IIRC that was addressed in my patches for fs-enet. what's happening: The PAL subsystem tries hard to be wise, an dif there are no link located, it starts to try forced mode, setting various stuff as link params and looking if link appeared or not. To keep consistency, I used the special flag passed via platform info, to just trust what ANEG had find out. Prolly we need to limit the forced aneg as well somehow - say give up after it failed to get link going at 10/HALF or smth like that. -- Sincerely, Vitaly