any hope for nfe/msk?
Oleg Lomaka
oleg.lomaka at gmail.com
Thu Oct 25 01:57:57 PDT 2007
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?
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
More information about the freebsd-stable
mailing list