Re: forcedeth as a module only?

Re: forcedeth as a module only?

[Manfred Spraul]

[-- Attachment #1: Type: text/plain, Size: 883 bytes --]

Christian Kujau wrote:

>are there any known issues with the forcedeth driver when statically
>compiled in? 
>
No.
But there are known issues with link detection: Some users report bad 
performance, and misconfigured links are one possible explanation.

>eth0: forcedeth.c: subsystem: 01462:0250 bound to 0000:00:05.0
>eth0: no link during initialization
>
>  
>
Very interesting.  The message itself is not fatal: It merely means that 
there was no link during ifup. This typically happens when the hardware 
initialization was not yet finished during ifup. Theoretically, an 
interrupt should happen when the hardware initialization is completed 
and that interrupt then sets up the link.
Somehow it doesn't work for you.

Could you try the attached patch? It polls for link changes instead of 
relying on the irq. Additionally, I have enabled some debug output.

--
    Manfred



[-- Attachment #2: patch-test --]
[-- Type: text/plain, Size: 3592 bytes --]

--- 2.6/drivers/net/forcedeth.c	2005-06-05 17:29:12.000000000 +0200
+++ build-2.6/drivers/net/forcedeth.c	2005-06-17 22:44:18.000000000 +0200
@@ -1298,7 +1299,7 @@
 	mii_status = mii_rw(dev, np->phyaddr, MII_BMSR, MII_READ);
 
 	if (!(mii_status & BMSR_LSTATUS)) {
-		dprintk(KERN_DEBUG "%s: no link detected by phy - falling back to 10HD.\n",
+		printk(KERN_DEBUG "%s: no link detected by phy - falling back to 10HD.\n",
 				dev->name);
 		newls = NVREG_LINKSPEED_FORCE|NVREG_LINKSPEED_10;
 		newdup = 0;
@@ -1307,7 +1308,7 @@
 	}
 
 	if (np->autoneg == 0) {
-		dprintk(KERN_DEBUG "%s: nv_update_linkspeed: autoneg off, PHY set to 0x%04x.\n",
+		printk(KERN_DEBUG "%s: nv_update_linkspeed: autoneg off, PHY set to 0x%04x.\n",
 				dev->name, np->fixed_mode);
 		if (np->fixed_mode & LPA_100FULL) {
 			newls = NVREG_LINKSPEED_FORCE|NVREG_LINKSPEED_100;
@@ -1331,7 +1332,7 @@
 		newls = NVREG_LINKSPEED_FORCE|NVREG_LINKSPEED_10;
 		newdup = 0;
 		retval = 0;
-		dprintk(KERN_DEBUG "%s: autoneg not completed - falling back to 10HD.\n", dev->name);
+		printk(KERN_DEBUG "%s: autoneg not completed - falling back to 10HD.\n", dev->name);
 		goto set_speed;
 	}
 
@@ -1342,7 +1343,7 @@
 
 		if ((control_1000 & ADVERTISE_1000FULL) &&
 			(status_1000 & LPA_1000FULL)) {
-			dprintk(KERN_DEBUG "%s: nv_update_linkspeed: GBit ethernet detected.\n",
+			printk(KERN_DEBUG "%s: nv_update_linkspeed: GBit ethernet detected.\n",
 				dev->name);
 			newls = NVREG_LINKSPEED_FORCE|NVREG_LINKSPEED_1000;
 			newdup = 1;
@@ -1352,7 +1353,7 @@
 
 	adv = mii_rw(dev, np->phyaddr, MII_ADVERTISE, MII_READ);
 	lpa = mii_rw(dev, np->phyaddr, MII_LPA, MII_READ);
-	dprintk(KERN_DEBUG "%s: nv_update_linkspeed: PHY advertises 0x%04x, lpa 0x%04x.\n",
+	printk(KERN_DEBUG "%s: nv_update_linkspeed: PHY advertises 0x%04x, lpa 0x%04x.\n",
 				dev->name, adv, lpa);
 
 	/* FIXME: handle parallel detection properly */
@@ -1370,7 +1371,7 @@
 		newls = NVREG_LINKSPEED_FORCE|NVREG_LINKSPEED_10;
 		newdup = 0;
 	} else {
-		dprintk(KERN_DEBUG "%s: bad ability %04x - falling back to 10HD.\n", dev->name, lpa);
+		printk(KERN_DEBUG "%s: bad ability %04x - falling back to 10HD.\n", dev->name, lpa);
 		newls = NVREG_LINKSPEED_FORCE|NVREG_LINKSPEED_10;
 		newdup = 0;
 	}
@@ -1379,7 +1380,7 @@
 	if (np->duplex == newdup && np->linkspeed == newls)
 		return retval;
 
-	dprintk(KERN_INFO "%s: changing link setting from %d/%d to %d/%d.\n",
+	printk(KERN_INFO "%s: changing link setting from %d/%d to %d/%d.\n",
 			dev->name, np->linkspeed, np->duplex, newls, newdup);
 
 	np->duplex = newdup;
@@ -1442,11 +1443,11 @@
 
 	miistat = readl(base + NvRegMIIStatus);
 	writel(NVREG_MIISTAT_MASK, base + NvRegMIIStatus);
-	dprintk(KERN_INFO "%s: link change irq, status 0x%x.\n", dev->name, miistat);
+	printk(KERN_INFO "%s: link change irq, status 0x%x.\n", dev->name, miistat);
 
 	if (miistat & (NVREG_MIISTAT_LINKCHANGE))
 		nv_linkchange(dev);
-	dprintk(KERN_DEBUG "%s: link change notification done.\n", dev->name);
+	printk(KERN_DEBUG "%s: link change notification done.\n", dev->name);
 }
 
 static irqreturn_t nv_nic_irq(int foo, void *data, struct pt_regs *regs)
@@ -2088,8 +2091,8 @@
 		np->irqmask = NVREG_IRQMASK_WANTED_2;
 	if (id->driver_data & DEV_NEED_TIMERIRQ)
 		np->irqmask |= NVREG_IRQ_TIMER;
-	if (id->driver_data & DEV_NEED_LINKTIMER) {
-		dprintk(KERN_INFO "%s: link timer on.\n", pci_name(pci_dev));
+	if (id->driver_data & DEV_NEED_LINKTIMER || 1) {
+		printk(KERN_INFO "%s: link timer on.\n", pci_name(pci_dev));
 		np->need_linktimer = 1;
 		np->link_timeout = jiffies + LINK_TIMEOUT;
 	} else {

Re: forcedeth as a module only?

[Christian Kujau]

Manfred Spraul schrieb:
> Very interesting.  The message itself is not fatal: It merely means that
> there was no link during ifup. This typically happens when the hardware
> initialization was not yet finished during ifup. Theoretically, an
> interrupt should happen when the hardware initialization is completed
> and that interrupt then sets up the link.
> Somehow it doesn't work for you.

could be the hardware's fault too? it's an onboard NIC on an nforce
chipset and the lspci i attached in the last mail looks rather strange
(compared to the r8169 (eth1) entry).

> Could you try the attached patch? It polls for link changes instead of
> relying on the irq. Additionally, I have enabled some debug output.

off to reboot in a second...


thanks,
Christian.

PS: on a side note, did you get my "other" mail concerning your mail address?
-- 
BOFH excuse #122:

because Bill Gates is a Jehovah's witness and so nothing can work on St.
Swithin's day.

Re: forcedeth as a module only?

[Christian Kujau]

Christian Kujau schrieb:
> Manfred Spraul schrieb:
>>
>>Could you try the attached patch? It polls for link changes instead of
>>relying on the irq. Additionally, I have enabled some debug output.

oh jolly, i think it worked!

eth0: forcedeth.c: subsystem: 01462:0250 bound to 0000:00:05.0
netconsole: device eth0 not up yet, forcing it
eth0: no link detected by phy - falling back to 10HD.
eth0: no link during initialization.
eth0: nv_update_linkspeed: PHY advertises 0x0de1, lpa 0x41e1.
eth0: changing link setting from 66536/0 to 65636/1.
eth0: link up.
netconsole: network logging started
[...]
eth0: nv_update_linkspeed: PHY advertises 0x0de1, lpa 0x41e1.
...

the last line gets repeated a couple of times, that must be the printk you
enabled.

thank you!
Christian.

(it's always stunning how a bugreport with that sparse details can lead to
a working kernel patch. cool.)
-- 
BOFH excuse #303:

fractal radiation jamming the backbone

Re: forcedeth as a module only?

[marvin24]

Hello Manfred,

I have an Asus K8N-E Deluxe (nForce3) and had problems with loosing network 
connection from time to time (every 30 minutes or so). The nic is NVENET_7 
(see lspci). Adding the DEV_NEED_LINKTIMER workaround solved the problem for 
me.
What is this workaround doing? Since I also heard of several people having 
such problems, why isn't this fix applied to all forcedeth devices?

Btw. Windows XP x86-64 has the same problem - but didn't found the source yet 
to patch ;-)

Best wishes 

Marc

# uname -a
Linux fb07-iapwap6 2.6.11 #4 Mon Jun 13 17:03:57 CEST 2005 x86_64 GNU/Linux
# lspci -v
0000:00:00.0 Host bridge: nVidia Corporation: Unknown device 00e1 (rev a1)
        Subsystem: Asustek Computer, Inc.: Unknown device 813f
        Flags: bus master, 66MHz, fast devsel, latency 0
        Memory at f0000000 (32-bit, prefetchable) [size=128M]
        Capabilities: [44] #08 [01c0]
        Capabilities: [c0] AGP version 3.0

0000:00:01.0 ISA bridge: nVidia Corporation: Unknown device 00e0 (rev a2)
        Subsystem: Asustek Computer, Inc.: Unknown device 813f
        Flags: bus master, 66MHz, fast devsel, latency 0

0000:00:01.1 SMBus: nVidia Corporation: Unknown device 00e4 (rev a1)
        Subsystem: Asustek Computer, Inc.: Unknown device 813f
        Flags: 66MHz, fast devsel
        I/O ports at 5080 [size=32]
        I/O ports at 5000 [size=64]
        I/O ports at 5040 [size=64]
        Capabilities: [44] Power Management version 2

0000:00:02.0 USB Controller: nVidia Corporation: Unknown device 00e7 (rev a1) 
(prog-if 10 [OHCI])
        Subsystem: Asustek Computer, Inc.: Unknown device 813f
        Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 22
        Memory at ff6fd000 (32-bit, non-prefetchable) [size=4K]
        Capabilities: [44] Power Management version 2

0000:00:02.1 USB Controller: nVidia Corporation: Unknown device 00e7 (rev a1) 
(prog-if 10 [OHCI])
        Subsystem: Asustek Computer, Inc.: Unknown device 813f
        Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 21
        Memory at ff6fe000 (32-bit, non-prefetchable) [size=4K]
        Capabilities: [44] Power Management version 2

0000:00:02.2 USB Controller: nVidia Corporation: Unknown device 00e8 (rev a2) 
(prog-if 20 [EHCI])
        Subsystem: Asustek Computer, Inc.: Unknown device 813f
        Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 20
        Memory at ff6ffc00 (32-bit, non-prefetchable) [size=256]
        Capabilities: [44] #0a [2098]
        Capabilities: [80] Power Management version 2

0000:00:05.0 Bridge: nVidia Corporation: Unknown device 00df (rev a2)
        Subsystem: Asustek Computer, Inc.: Unknown device 80a7
        Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 22
        Memory at ff6fc000 (32-bit, non-prefetchable) [size=4K]
        I/O ports at ec00 [size=8]
        Capabilities: [44] Power Management version 2

0000:00:06.0 Multimedia audio controller: nVidia Corporation: Unknown device 
00ea (rev a1)
        Subsystem: Asustek Computer, Inc.: Unknown device 812a
        Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 21
        I/O ports at e800 [size=256]
        I/O ports at e400 [size=128]
        Memory at ff6fb000 (32-bit, non-prefetchable) [size=4K]
        Capabilities: [44] Power Management version 2

0000:00:08.0 IDE interface: nVidia Corporation: Unknown device 00e5 (rev a2) 
(prog-if 8a [Master SecP PriP])
        Subsystem: Asustek Computer, Inc.: Unknown device 813f
        Flags: bus master, 66MHz, fast devsel, latency 0
        I/O ports at ffa0 [size=16]
        Capabilities: [44] Power Management version 2

0000:00:0b.0 PCI bridge: nVidia Corporation: Unknown device 00e2 (rev a2) 
(prog-if 00 [Normal decode])
        Flags: bus master, 66MHz, medium devsel, latency 16
        Bus: primary=00, secondary=01, subordinate=01, sec-latency=10
        I/O behind bridge: 0000c000-0000cfff
        Memory behind bridge: ff400000-ff4fffff
        Prefetchable memory behind bridge: aeb00000-eeafffff

0000:00:0e.0 PCI bridge: nVidia Corporation: Unknown device 00ed (rev a2) 
(prog-if 00 [Normal decode])
        Flags: bus master, 66MHz, fast devsel, latency 0
        Bus: primary=00, secondary=02, subordinate=02, sec-latency=128
        I/O behind bridge: 0000d000-0000dfff
        Memory behind bridge: ff500000-ff5fffff

0000:00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge
        Flags: fast devsel
        Capabilities: [80] #08 [2101]

0000:00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge
        Flags: fast devsel

0000:00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge
        Flags: fast devsel

0000:00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge
        Flags: fast devsel

0000:01:00.0 VGA compatible controller: ATI Technologies Inc: Unknown device 
4153 (prog-if 00 [VGA])
        Subsystem: PC Partner Limited: Unknown device 0200
        Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 11
        Memory at d0000000 (32-bit, prefetchable) [size=256M]
        I/O ports at c800 [size=256]
        Memory at ff4f0000 (32-bit, non-prefetchable) [size=64K]
        Expansion ROM at ff4c0000 [disabled] [size=128K]
        Capabilities: [58] AGP version 3.0
        Capabilities: [50] Power Management version 2

0000:01:00.1 Display controller: ATI Technologies Inc: Unknown device 4173
        Subsystem: PC Partner Limited: Unknown device 0201
        Flags: bus master, 66MHz, medium devsel, latency 64
        Memory at c0000000 (32-bit, prefetchable) [size=256M]
        Memory at ff4e0000 (32-bit, non-prefetchable) [size=64K]
        Capabilities: [50] Power Management version 2

0000:02:0b.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host 
Controller (rev 80) (prog-if 10 [OHCI])
        Subsystem: Asustek Computer, Inc.: Unknown device 808a
        Flags: bus master, medium devsel, latency 64, IRQ 19
        Memory at ff5ff800 (32-bit, non-prefetchable) [size=2K]
        I/O ports at dc00 [size=128]
        Capabilities: [50] Power Management version 2


Am Freitag, 17. Juni 2005 22:47 schrieben Sie:
> Christian Kujau wrote:
> >are there any known issues with the forcedeth driver when statically
> >compiled in?
>
> No.
> But there are known issues with link detection: Some users report bad
> performance, and misconfigured links are one possible explanation.
>
> >eth0: forcedeth.c: subsystem: 01462:0250 bound to 0000:00:05.0
> >eth0: no link during initialization
>
> Very interesting.  The message itself is not fatal: It merely means that
> there was no link during ifup. This typically happens when the hardware
> initialization was not yet finished during ifup. Theoretically, an
> interrupt should happen when the hardware initialization is completed
> and that interrupt then sets up the link.
> Somehow it doesn't work for you.
>
> Could you try the attached patch? It polls for link changes instead of
> relying on the irq. Additionally, I have enabled some debug output.
>
> --
>     Manfred

Re: forcedeth as a module only?

[Manfred Spraul]

marvin24@gmx.de wrote:

>Hello Manfred,
>
>I have an Asus K8N-E Deluxe (nForce3) and had problems with loosing network 
>connection from time to time (every 30 minutes or so). The nic is NVENET_7 
>(see lspci). Adding the DEV_NEED_LINKTIMER workaround solved the problem for 
>me.
>What is this workaround doing?
>
The network hardware consists out of two parts:
- the PHY, which performs the physical encoding: basically a very smart 
digital/analog converter. It's a seperate chip on your board.
- the MAC (Media Access controller) does the rest: decide which packet 
to send/receive, verify the CRC, do the memory transfer to/from main 
memory, etc. This part is integrated into the nForce chipset.

The PHY detects the link partner and sets itself to the proper network 
speed. If the link partner changes, then the PHY reconfigures itself. 
The change can be a spurious change - bad cabling, too much 
electromagnetic noise, whatever. The driver must notice if the PHY did a 
reconfiguration and reconfigure the MAC. The driver can either wait for 
an interrupt, or poll the PHY once per second and ask if the link speed 
setting must be updated.
For me, interrupts work. But for some users, no interrupts are 
generated. I thought that nForce 3 generates interrupts and thus polling 
is only used for nForce 1/2.

> Since I also heard of several people having 
>such problems, why isn't this fix applied to all forcedeth devices?
>
>  
>
I'll send a patch to Jeff.

>Btw. Windows XP x86-64 has the same problem - but didn't found the source yet 
>to patch ;-)
>
>  
>
Interesting.

--
    Manfred

forcedeth as a module only?

[Christian Kujau]

hi,

are there any known issues with the forcedeth driver when statically
compiled in? i have an onboard GbE ethernet controller (see below) and
forcedeth seems to work pretty fine for this controller. it's 100Mbps
only, but i don't care because my switch is 100Mbps too.

i've noticed that the driver just does not work, when it's compiled with
CONFIG_FORCEDETH=y

eth0: forcedeth.c: subsystem: 01462:0250 bound to 0000:00:05.0
eth0: no link during initialization

recompiling the same kernel (2.6.12-rc6-mm1, x86_64) with
CONFIG_FORCEDETH=m and loading the module without any parameters get the
NIC up. mii-tool does not work in both cases, CONFIG_MII is set to "y".


any hints?

thank you,
Christian.

% lspci -v | grep -A6 0000:00:05.0
0000:00:05.0 Bridge: nVidia Corporation: Unknown device 00df (rev a2)
        Subsystem: Micro-Star International Co., Ltd.: Unknown device 0250
        Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 217
        Memory at f8000000 (32-bit, non-prefetchable) [size=4K]
        I/O ports at d800 [size=8]
        Capabilities: [44] Power Management version 2

(the manual says it's a Marvell 88E111 10/100/1000 onboard NIC)

% mii-tool
SIOCGMIIPHY on 'eth0' failed: Operation not supported
SIOCGMIIPHY on 'eth1' failed: Operation not supported
no MII interfaces found

% ethtool eth0
Settings for eth0:
        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: 100Mb/s
        Duplex: Full
        Port: MII
        PHYAD: 1
        Transceiver: externel
        Auto-negotiation: on
        Supports Wake-on: g
        Wake-on: d
        Link detected: yes

-- 
BOFH excuse #334:

50% of the manual is in .pdf readme files