Date: Thu, 25 Oct 2007 18:05:25 +0900 From: Pyun YongHyeon <pyunyh@gmail.com> To: Oleg Lomaka <oleg.lomaka@gmail.com> Cc: freebsd-stable@freebsd.org Subject: Re: any hope for nfe/msk? Message-ID: <20071025090525.GF16092@cdnetworks.co.kr> In-Reply-To: <47205A56.6010601@gmail.com> References: <E1IkakO-0005BS-CZ@cs1.cs.huji.ac.il> <20071024084934.GF11234@cdnetworks.co.kr> <471F52DC.4080305@gmail.com> <20071025020637.GA16092@cdnetworks.co.kr> <47203EC3.4010203@gmail.com> <20071025083032.GE16092@cdnetworks.co.kr> <47205A56.6010601@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Oct 25, 2007 at 11:56:54AM +0300, Oleg Lomaka wrote: > Pyun YongHyeon wrote: > >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? > > > > > After kldunload/kldload i've got following and had to revert to original > one (1.18 revision). I'll try to reboot laptop in the evening with your > patch. Is kernel reloading desirable? > The following loading failure comes from lack of DMAable memory resource. msk(4) requires large blocks of contiguous memory to support jumbo frames even though your Yukon FE doesn't have that capability. I have plan to clean up this issue but it needs major restructring. ATM the only way to recover from this would be reboot. To use msk(4) module add the following line to /boot/loader.conf if_msk_load="YES" That would fix loading issue. > found-> vendor=0x104c, dev=0x8039, revid=0x00 > domain=0, bus=10, slot=9, func=0 > class=06-07-00, hdrtype=0x02, mfdev=1 > cmdreg=0x0007, statreg=0x0210, cachelnsz=16 (dwords) > lattimer=0x31 (1470 ns), mingnt=0x44 (17000 ns), maxlat=0x03 > (750 ns) > intpin=a, irq=20 > powerspec 2 supports D0 D1 D2 D3 current D0 > pci0:10:9:0: reprobing on driver added > found-> vendor=0x104c, dev=0x803b, revid=0x00 > domain=0, bus=10, slot=9, func=2 > class=01-80-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0006, statreg=0x0210, cachelnsz=16 (dwords) > lattimer=0x39 (1710 ns), mingnt=0x07 (1750 ns), maxlat=0x04 > (1000 ns) > intpin=a, irq=20 > powerspec 2 supports D0 D1 D2 D3 current D0 > pci0:10:9:2: reprobing on driver added > msk0: <Marvell Technology Group Ltd. Yukon FE Id 0xb7 Rev 0x01> on mskc0 > msk0: failed to allocate DMA'able memory for jumbo buf > device_attach: msk0 attach returned 1 -- Regards, Pyun YongHyeon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071025090525.GF16092>