any hope for nfe/msk?

Pyun YongHyeon pyunyh at gmail.com
Thu Oct 25 01:30:43 PDT 2007


On Thu, Oct 25, 2007 at 09:59:15AM +0300, Oleg Lomaka wrote:
 > Hello,
 > 
 > Pyun YongHyeon wrote:
 > >On Wed, Oct 24, 2007 at 05:12:44PM +0300, Oleg Lomaka wrote:
 > > > Pyun YongHyeon wrote:
 > > > >On Wed, Oct 24, 2007 at 09:33:48AM +0200, Danny Braniss wrote:
 > > > > > Hi,
 > > > > > 	these drivers don't work under 7.0
 > > > > > As soon as some mild preasure is applied, they start loosing 
 > > > > interrupts, and
 > > > > > in my case the hosts come to a total stand-still, since they are 
 > > > > diskless
 > > > > > and rely on the network.
 > > > > > This happens at 1gb and at 100mg.
 > > > > > 
 > > > > > Maybe the problem is with the shared interrups?
 > > > > > 	
 > > > > > 	irq16: mskc0 uhci0               3308351         13
 > > > > > or
 > > > > > 	irq21: nfe0 ohci0                1584415         24
 > > > > > 
 > > > > > but I have no idea how to uncouple this
 > > > > > 
 > > > >
 > > > >If you see watchdog timeout errors on your console, shared interrupt
 > > > >would be culprit.
 > > > >For msk(4) set hw.msk.legacy_intr="1" in loader.conf or use kenv(1)
 > > > >to set it before loading msk(4) kernel module.
 > > > >For nfe(4) you can switch to polling(4).
 > > > >
 > > > >  
 > > > I have some msk troubles too. On my laptop (acer travelmate 2483wxmi) 
 > > > under heavy cpu & network load msk periodically stops working for few 
 > > > minutes.
 > >
 > >If that happens msk(4) recover from the non-working state?
 > >  
 > Yes, some times in few seconds, some times in 5 - 10 minutes, but always 
 > recovers.
 > > > sysctl -a|grep msk
 > > > <118>msk0: no link ...
 > > > <118>DHCPREQUEST on msk0 to 255.255.255.255 port 67
 > > > <118>DHCPREQUEST on msk0 to 255.255.255.255 port 67
 > > > <118>DHCPDISCOVER on msk0 to 255.255.255.255 port 67 interval 3
 > > > <118>DHCPREQUEST on msk0 to 255.255.255.255 port 67
 > > > <118>msk0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 
 > > > mtu 1500
 > > > msk0: watchdog timeout (missed Tx interrupts) -- recovering
 > > > msk0: watchdog timeout (missed Tx interrupts) -- recovering
 > > > msk0: Rx FIFO overrun!
 > >         ^^^^^^^^^^^^^^^^
 > >This looks bad. Would you show me verbosed boot messages related with
 > >msk(4) and PHY driver as well as "vmstat -i" output.
 > >
 > >  
 > Here are values from just booted laptop. If it will halt msk today 
 > again, I'll resend.
 > 
 > tdevil% vmstat -i
 > interrupt                          total       rate
 > irq1: atkbd0                        3275          1
 > irq12: psm0                        11157          6
 > irq14: ata0                        22500         13
 > irq15: ata1                           85          0
 > irq16: mskc0 uhci+                 17334         10
 > irq18: uhci2                           1          0
 > irq22: pcm0                        46530         27
 > irq23: uhci0 ehci0                 95882         57
 > cpu0: timer                      3322705       1999
 > Total                            3519469       2117
 > 
 > 
 > tdevil% grep -iE "msk|phy" /var/run/dmesg.boot
 > pci0: domain=0, physical bus=0
 > pci2: domain=0, physical bus=2
 > mskc0: <Marvell Yukon 88E8038 Gigabit Ethernet> port 0x2000-0x20ff mem 
 > 0xd0100000-0xd0103fff irq 16 at device 0.0 on pci2
 > mskc0: Reserved 0x4000 bytes for rid 0x10 type 3 at 0xd0100000
 > mskc0: MSI count : 2
 > mskc0: RAM buffer size : 16KB
 > mskc0: Port 0 : Rx Queue 10KB(0x00000000:0x000027ff)
 > mskc0: Port 0 : Tx Queue 10KB(0x00002800:0x00004fff)
 > msk0: <Marvell Technology Group Ltd. Yukon FE Id 0xb7 Rev 0x01> on mskc0
 > msk0: bpf attached
 > msk0: Ethernet address: 00:1b:24:0e:bc:26
 > miibus0: <MII bus> on msk0
 > e1000phy0: <Marvell 88E3082 10/100 Fast Ethernet PHY> PHY 0 on miibus0
 > e1000phy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
 > ukphy0: <Generic IEEE 802.3u media interface> PHY 3 on miibus0
 > ukphy0: OUI 0x001000, model 0x0004, rev. 0
 > ukphy0:  no media present
 > ukphy1: <Generic IEEE 802.3u media interface> PHY 6 on miibus0
 > ukphy1: OUI 0x004400, model 0x0011, rev. 0
 > ukphy1:  no media present
 > mskc0: [MPSAFE]
 > mskc0: [FILTER]
 > pci3: domain=0, physical bus=3
 > pci4: domain=0, physical bus=4
 > pci5: domain=0, physical bus=5
 > pci10: domain=0, physical bus=10
 > 

Thanks for the info. Would please try attached patch?

-- 
Regards,
Pyun YongHyeon
-------------- next part --------------
Index: if_msk.c
===================================================================
RCS file: /home/ncvs/src/sys/dev/msk/if_msk.c,v
retrieving revision 1.18
diff -u -r1.18 if_msk.c
--- if_msk.c	20 Jul 2007 00:25:20 -0000	1.18
+++ if_msk.c	25 Oct 2007 08:25:33 -0000
@@ -1026,8 +1026,6 @@
 	/* Get adapter SRAM size. */
 	val = CSR_READ_1(sc, B2_E_0);
 	sc->msk_ramsize = (val == 0) ? 128 : val * 4;
-	if (sc->msk_hw_id == CHIP_ID_YUKON_FE)
-		sc->msk_ramsize = 4 * 4;
 	if (bootverbose)
 		device_printf(sc->msk_dev,
 		    "RAM buffer size : %dKB\n", sc->msk_ramsize);
@@ -1055,11 +1053,16 @@
 
 	/* Take away the minimum memory for active queues. */
 	avail -= minqsize;
+	if (avail < 0)
+		return (ENOSPC);
 	/* Rx queue gets the minimum + 80% of the rest. */
 	sc->msk_rxqsize =
 	    (avail * MSK_RAM_QUOTA_RX) / 100 + MSK_MIN_RXQ_SIZE;
 	avail -= (sc->msk_rxqsize - MSK_MIN_RXQ_SIZE);
-	sc->msk_txqsize = avail + MSK_MIN_TXQ_SIZE;
+	if (avail <= 0)
+		sc->msk_txqsize = sc->msk_ramsize - sc->msk_rxqsize;
+	else
+		sc->msk_txqsize = avail + MSK_MIN_TXQ_SIZE;
 
 	for (i = 0, next = 0; i < sc->msk_num_port; i++) {
 		sc->msk_rxqstart[i] = next;


More information about the freebsd-stable mailing list