Re: any hope for nfe/msk?
Don Lewis wrote: On 21 Nov, Chris wrote: On 07/11/2007, Pyun YongHyeon <[EMAIL PROTECTED]> wrote: On Wed, Nov 07, 2007 at 02:28:00PM +0200, Oleg Lomaka wrote: > Hello, > > Pyun YongHyeon wrote: > >On Thu, Nov 01, 2007 at 10:59:48AM +0200, Oleg Lomaka wrote: > > > Hello, > > > > > > Pyun YongHyeon wrote: > > > >On Tue, Oct 30, 2007 at 04:01:04PM +0200, Oleg Lomaka wrote: > > > > > > > >[...] > > > > > > > > > I had RxFIFO overrun again :( > > > > > from dmest: > > > > > msk0: Rx FIFO overrun! > > > > > > > >[...] > > > > > > > >Please try attached patch again. Sorry for the trouble. > > > >After applying the patch show me verbosed dmesg output related with > > > >msk(4)/PHY driver. > > > > > > > >Thanks for testing. > > > > > > > pcib1: irq 16 at device 28.0 on pci0 > > > pcib1: domain0 > > > pcib1: secondary bus 2 > > > pcib1: subordinate bus 2 > > > pcib1: I/O decode0x2000-0x2fff > > > pcib1: memory decode 0xd010-0xd01f > > > pcib1: no prefetched decode > > > pci2: on pcib1 > > > pci2: domain=0, physical bus=2 > > > found-> vendor=0x11ab, dev=0x4352, revid=0x14 > > >domain=0, bus=2, slot=0, func=0 > > >class=02-00-00, hdrtype=0x00, mfdev=0 > > >cmdreg=0x0007, statreg=0x4010, cachelnsz=16 (dwords) > > >lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > >intpin=a, irq=11 > > >powerspec 2 supports D0 D1 D2 D3 current D0 > > >MSI supports 2 messages, 64 bit > > >map[10]: type Memory, range 64, base 0xd010, size 14, enabled > > > pcib1: requested memory range 0xd010-0xd0103fff: good > > >map[18]: type I/O Port, range 32, base 0x2000, size 8, enabled > > > pcib1: requested I/O range 0x2000-0x20ff: in range > > > pcib1: slot 0 INTA routed to irq 16 > > > mskc0: port 0x2000-0x20ff mem > > > 0xd010-0xd0103fff irq 16 at device 0.0 on pci2 > > > mskc0: Reserved 0x4000 bytes for rid 0x10 type 3 at 0xd010 > > > mskc0: MSI count : 2 > > > mskc0: RAM buffer size : 4KB > > > mskc0: Port 0 : Rx Queue 2KB(0x:0x07ff) > > > mskc0: Port 0 : Tx Queue 2KB(0x0800:0x0fff) > > > msk0: on mskc0 > > > msk0: bpf attached > > > msk0: Ethernet address: 00:1b:24:0e:bc:26 > > > miibus0: on msk0 > > > e1000phy0: PHY 0 on miibus0 > > > e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > > > ioapic0: routing intpin 16 (PCI IRQ 16) to vector 49 > > > mskc0: [MPSAFE] > > > mskc0: [FILTER] > > > > > > >So far all looks good to me. If you encounter watchdog timeouts > >or Rx FIFO overruns let me know. > > > > > > Got it again: > msk0: Rx FIFO overrun! > I believe this is happening under heavy CPU usage. Now i have firefox > compiling and watched pictures on remote windows box using rdesktop. And > after few minutes got network freeze. If it only happens under heavy system loads it's probably normal. If system is too busy to serve other jobs the msk(4) may not recevie more packets because its receive buffer was full. Probably msk(4) should just count the overrun errors without printing the message such that it would save more CPU cycles. Btw, did you also see watchdog timeout errors? > But it looks i didn't get any packet lost :). Take a look at ping > statistics... funny... I guess something is wrong here. Latency is unacceptable. However I have no idea why ICMP echo reponse takes so long time. Are you using any power saving mechanism(powerd, cpufreq etc)? > tdevil% ping 10.1.1.254 > PING 10.1.1.254 (10.1.1.254): 56 data bytes > 64 bytes from 10.1.1.254: icmp_seq=0 ttl=64 time=35926.404 ms > 64 bytes from 10.1.1.254: icmp_seq=1 ttl=64 time=34925.694 ms > 64 bytes from 10.1.1.254: icmp_seq=2 ttl=64 time=33924.729 ms > 64 bytes from 10.1.1.254: icmp_seq=3 ttl=64 time=32923.814 ms > 64 bytes from 10.1.1.254: icmp_seq=4 ttl=64 time=31922.833 ms > 64 bytes from 10.1.1.254: icmp_seq=5 ttl=64 time=30921.878 ms > 64 bytes from 10.1.1.254: icmp_seq=6 ttl=64 time=29920.923 ms > 64 bytes from 10.1.1.254: icmp_seq=7 ttl=64 time=28919.960 ms > 64 bytes from 10.1.1.254: icmp_seq=8 ttl=64 time=27919.009 ms > 64 bytes from 10.1.1.254: icmp_seq=9 ttl=64 time=26918.042 ms > 64 bytes from 10.1.1.254: icmp_seq=10 ttl=64 time=25917.078 ms > 64 bytes from 10.1.1.254: icmp_seq=11 ttl=64 time=24916.115 ms > 64 bytes from 10.1.1.254: icmp_seq=12 ttl=64 time=23915.144 ms > 64 bytes from 10.1.1.254: icmp_seq=13 ttl=64 time=22914.192 ms > 64 bytes from 10.1.1.254: icmp_seq=14 ttl=64 time=21913.214 ms > 64 bytes from 10.1.1.254: icmp_seq=15 ttl=64 time=20912.278 ms > 64 bytes from 10.1.1.254: icmp_seq=16 ttl=64 time=19911.330 ms > 64 bytes from 10.1.1.254: icmp_seq=17 ttl=64 time=18910.375 ms > 64 bytes from 10.1.1.254: icmp_seq=18 ttl=64 time=17909.419 ms > 64 bytes from 10.1.1.254: icmp_seq=19 ttl=64 time=16853.821 ms > 64 bytes from 10.1.1.254: icmp_seq=20 ttl=64 ti
Re: any hope for nfe/msk?
On 21 Nov, Chris wrote: > On 07/11/2007, Pyun YongHyeon <[EMAIL PROTECTED]> wrote: >> On Wed, Nov 07, 2007 at 02:28:00PM +0200, Oleg Lomaka wrote: >> > Hello, >> > >> > Pyun YongHyeon wrote: >> > >On Thu, Nov 01, 2007 at 10:59:48AM +0200, Oleg Lomaka wrote: >> > > > Hello, >> > > > >> > > > Pyun YongHyeon wrote: >> > > > >On Tue, Oct 30, 2007 at 04:01:04PM +0200, Oleg Lomaka wrote: >> > > > > >> > > > >[...] >> > > > > >> > > > > > I had RxFIFO overrun again :( >> > > > > > from dmest: >> > > > > > msk0: Rx FIFO overrun! >> > > > > >> > > > >[...] >> > > > > >> > > > >Please try attached patch again. Sorry for the trouble. >> > > > >After applying the patch show me verbosed dmesg output related with >> > > > >msk(4)/PHY driver. >> > > > > >> > > > >Thanks for testing. >> > > > > >> > > > pcib1: irq 16 at device 28.0 on pci0 >> > > > pcib1: domain0 >> > > > pcib1: secondary bus 2 >> > > > pcib1: subordinate bus 2 >> > > > pcib1: I/O decode0x2000-0x2fff >> > > > pcib1: memory decode 0xd010-0xd01f >> > > > pcib1: no prefetched decode >> > > > pci2: on pcib1 >> > > > pci2: domain=0, physical bus=2 >> > > > found-> vendor=0x11ab, dev=0x4352, revid=0x14 >> > > >domain=0, bus=2, slot=0, func=0 >> > > >class=02-00-00, hdrtype=0x00, mfdev=0 >> > > >cmdreg=0x0007, statreg=0x4010, cachelnsz=16 (dwords) >> > > >lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> > > >intpin=a, irq=11 >> > > >powerspec 2 supports D0 D1 D2 D3 current D0 >> > > >MSI supports 2 messages, 64 bit >> > > >map[10]: type Memory, range 64, base 0xd010, size 14, >> enabled >> > > > pcib1: requested memory range 0xd010-0xd0103fff: good >> > > >map[18]: type I/O Port, range 32, base 0x2000, size 8, enabled >> > > > pcib1: requested I/O range 0x2000-0x20ff: in range >> > > > pcib1: slot 0 INTA routed to irq 16 >> > > > mskc0: port 0x2000-0x20ff mem >> > > > 0xd010-0xd0103fff irq 16 at device 0.0 on pci2 >> > > > mskc0: Reserved 0x4000 bytes for rid 0x10 type 3 at 0xd010 >> > > > mskc0: MSI count : 2 >> > > > mskc0: RAM buffer size : 4KB >> > > > mskc0: Port 0 : Rx Queue 2KB(0x:0x07ff) >> > > > mskc0: Port 0 : Tx Queue 2KB(0x0800:0x0fff) >> > > > msk0: on >> mskc0 >> > > > msk0: bpf attached >> > > > msk0: Ethernet address: 00:1b:24:0e:bc:26 >> > > > miibus0: on msk0 >> > > > e1000phy0: PHY 0 on miibus0 >> > > > e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto >> > > > ioapic0: routing intpin 16 (PCI IRQ 16) to vector 49 >> > > > mskc0: [MPSAFE] >> > > > mskc0: [FILTER] >> > > > >> > > >> > >So far all looks good to me. If you encounter watchdog timeouts >> > >or Rx FIFO overruns let me know. >> > > >> > > >> > >> > Got it again: >> > msk0: Rx FIFO overrun! >> > I believe this is happening under heavy CPU usage. Now i have firefox >> > compiling and watched pictures on remote windows box using rdesktop. And >> > after few minutes got network freeze. >> >> If it only happens under heavy system loads it's probably normal. If >> system is too busy to serve other jobs the msk(4) may not recevie >> more packets because its receive buffer was full. Probably msk(4) >> should just count the overrun errors without printing the message >> such that it would save more CPU cycles. >> Btw, did you also see watchdog timeout errors? >> >> > But it looks i didn't get any packet lost :). Take a look at ping >> > statistics... funny... >> >> I guess something is wrong here. Latency is unacceptable. However >> I have no idea why ICMP echo reponse takes so long time. Are you >> using any power saving mechanism(powerd, cpufreq etc)? >> >> > tdevil% ping 10.1.1.254 >> > PING 10.1.1.254 (10.1.1.254): 56 data bytes >> > 64 bytes from 10.1.1.254: icmp_seq=0 ttl=64 time=35926.404 ms >> > 64 bytes from 10.1.1.254: icmp_seq=1 ttl=64 time=34925.694 ms >> > 64 bytes from 10.1.1.254: icmp_seq=2 ttl=64 time=33924.729 ms >> > 64 bytes from 10.1.1.254: icmp_seq=3 ttl=64 time=32923.814 ms >> > 64 bytes from 10.1.1.254: icmp_seq=4 ttl=64 time=31922.833 ms >> > 64 bytes from 10.1.1.254: icmp_seq=5 ttl=64 time=30921.878 ms >> > 64 bytes from 10.1.1.254: icmp_seq=6 ttl=64 time=29920.923 ms >> > 64 bytes from 10.1.1.254: icmp_seq=7 ttl=64 time=28919.960 ms >> > 64 bytes from 10.1.1.254: icmp_seq=8 ttl=64 time=27919.009 ms >> > 64 bytes from 10.1.1.254: icmp_seq=9 ttl=64 time=26918.042 ms >> > 64 bytes from 10.1.1.254: icmp_seq=10 ttl=64 time=25917.078 ms >> > 64 bytes from 10.1.1.254: icmp_seq=11 ttl=64 time=24916.115 ms >> > 64 bytes from 10.1.1.254: icmp_seq=12 ttl=64 time=23915.144 ms >> > 64 bytes from 10.1.1.254: icmp_seq=13 ttl=64 time=22914.192 ms >> > 64 bytes from 10.1.1.254: icmp_seq=14 ttl=64 time=21913.214 ms >> > 64 bytes from 10.1.1.254: icmp_seq=15 ttl=64 time=20912.278 ms >> > 64 bytes f
Re: any hope for nfe/msk?
On 07/11/2007, Pyun YongHyeon <[EMAIL PROTECTED]> wrote: > On Wed, Nov 07, 2007 at 02:28:00PM +0200, Oleg Lomaka wrote: > > Hello, > > > > Pyun YongHyeon wrote: > > >On Thu, Nov 01, 2007 at 10:59:48AM +0200, Oleg Lomaka wrote: > > > > Hello, > > > > > > > > Pyun YongHyeon wrote: > > > > >On Tue, Oct 30, 2007 at 04:01:04PM +0200, Oleg Lomaka wrote: > > > > > > > > > >[...] > > > > > > > > > > > I had RxFIFO overrun again :( > > > > > > from dmest: > > > > > > msk0: Rx FIFO overrun! > > > > > > > > > >[...] > > > > > > > > > >Please try attached patch again. Sorry for the trouble. > > > > >After applying the patch show me verbosed dmesg output related with > > > > >msk(4)/PHY driver. > > > > > > > > > >Thanks for testing. > > > > > > > > > pcib1: irq 16 at device 28.0 on pci0 > > > > pcib1: domain0 > > > > pcib1: secondary bus 2 > > > > pcib1: subordinate bus 2 > > > > pcib1: I/O decode0x2000-0x2fff > > > > pcib1: memory decode 0xd010-0xd01f > > > > pcib1: no prefetched decode > > > > pci2: on pcib1 > > > > pci2: domain=0, physical bus=2 > > > > found-> vendor=0x11ab, dev=0x4352, revid=0x14 > > > >domain=0, bus=2, slot=0, func=0 > > > >class=02-00-00, hdrtype=0x00, mfdev=0 > > > >cmdreg=0x0007, statreg=0x4010, cachelnsz=16 (dwords) > > > >lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > > >intpin=a, irq=11 > > > >powerspec 2 supports D0 D1 D2 D3 current D0 > > > >MSI supports 2 messages, 64 bit > > > >map[10]: type Memory, range 64, base 0xd010, size 14, > enabled > > > > pcib1: requested memory range 0xd010-0xd0103fff: good > > > >map[18]: type I/O Port, range 32, base 0x2000, size 8, enabled > > > > pcib1: requested I/O range 0x2000-0x20ff: in range > > > > pcib1: slot 0 INTA routed to irq 16 > > > > mskc0: port 0x2000-0x20ff mem > > > > 0xd010-0xd0103fff irq 16 at device 0.0 on pci2 > > > > mskc0: Reserved 0x4000 bytes for rid 0x10 type 3 at 0xd010 > > > > mskc0: MSI count : 2 > > > > mskc0: RAM buffer size : 4KB > > > > mskc0: Port 0 : Rx Queue 2KB(0x:0x07ff) > > > > mskc0: Port 0 : Tx Queue 2KB(0x0800:0x0fff) > > > > msk0: on > mskc0 > > > > msk0: bpf attached > > > > msk0: Ethernet address: 00:1b:24:0e:bc:26 > > > > miibus0: on msk0 > > > > e1000phy0: PHY 0 on miibus0 > > > > e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > > > > ioapic0: routing intpin 16 (PCI IRQ 16) to vector 49 > > > > mskc0: [MPSAFE] > > > > mskc0: [FILTER] > > > > > > > > > >So far all looks good to me. If you encounter watchdog timeouts > > >or Rx FIFO overruns let me know. > > > > > > > > > > Got it again: > > msk0: Rx FIFO overrun! > > I believe this is happening under heavy CPU usage. Now i have firefox > > compiling and watched pictures on remote windows box using rdesktop. And > > after few minutes got network freeze. > > If it only happens under heavy system loads it's probably normal. If > system is too busy to serve other jobs the msk(4) may not recevie > more packets because its receive buffer was full. Probably msk(4) > should just count the overrun errors without printing the message > such that it would save more CPU cycles. > Btw, did you also see watchdog timeout errors? > > > But it looks i didn't get any packet lost :). Take a look at ping > > statistics... funny... > > I guess something is wrong here. Latency is unacceptable. However > I have no idea why ICMP echo reponse takes so long time. Are you > using any power saving mechanism(powerd, cpufreq etc)? > > > tdevil% ping 10.1.1.254 > > PING 10.1.1.254 (10.1.1.254): 56 data bytes > > 64 bytes from 10.1.1.254: icmp_seq=0 ttl=64 time=35926.404 ms > > 64 bytes from 10.1.1.254: icmp_seq=1 ttl=64 time=34925.694 ms > > 64 bytes from 10.1.1.254: icmp_seq=2 ttl=64 time=33924.729 ms > > 64 bytes from 10.1.1.254: icmp_seq=3 ttl=64 time=32923.814 ms > > 64 bytes from 10.1.1.254: icmp_seq=4 ttl=64 time=31922.833 ms > > 64 bytes from 10.1.1.254: icmp_seq=5 ttl=64 time=30921.878 ms > > 64 bytes from 10.1.1.254: icmp_seq=6 ttl=64 time=29920.923 ms > > 64 bytes from 10.1.1.254: icmp_seq=7 ttl=64 time=28919.960 ms > > 64 bytes from 10.1.1.254: icmp_seq=8 ttl=64 time=27919.009 ms > > 64 bytes from 10.1.1.254: icmp_seq=9 ttl=64 time=26918.042 ms > > 64 bytes from 10.1.1.254: icmp_seq=10 ttl=64 time=25917.078 ms > > 64 bytes from 10.1.1.254: icmp_seq=11 ttl=64 time=24916.115 ms > > 64 bytes from 10.1.1.254: icmp_seq=12 ttl=64 time=23915.144 ms > > 64 bytes from 10.1.1.254: icmp_seq=13 ttl=64 time=22914.192 ms > > 64 bytes from 10.1.1.254: icmp_seq=14 ttl=64 time=21913.214 ms > > 64 bytes from 10.1.1.254: icmp_seq=15 ttl=64 time=20912.278 ms > > 64 bytes from 10.1.1.254: icmp_seq=16 ttl=64 time=19911.330 ms > > 64 bytes from 10.1.1.254: icmp_seq=17 ttl=64 time=18910.375 ms > > 64 bytes f
Re: any hope for nfe/msk?
On Wed, Nov 07, 2007 at 02:28:00PM +0200, Oleg Lomaka wrote: > Hello, > > Pyun YongHyeon wrote: > >On Thu, Nov 01, 2007 at 10:59:48AM +0200, Oleg Lomaka wrote: > > > Hello, > > > > > > Pyun YongHyeon wrote: > > > >On Tue, Oct 30, 2007 at 04:01:04PM +0200, Oleg Lomaka wrote: > > > > > > > >[...] > > > > > > > > > I had RxFIFO overrun again :( > > > > > from dmest: > > > > > msk0: Rx FIFO overrun! > > > > > > > >[...] > > > > > > > >Please try attached patch again. Sorry for the trouble. > > > >After applying the patch show me verbosed dmesg output related with > > > >msk(4)/PHY driver. > > > > > > > >Thanks for testing. > > > > > > > pcib1: irq 16 at device 28.0 on pci0 > > > pcib1: domain0 > > > pcib1: secondary bus 2 > > > pcib1: subordinate bus 2 > > > pcib1: I/O decode0x2000-0x2fff > > > pcib1: memory decode 0xd010-0xd01f > > > pcib1: no prefetched decode > > > pci2: on pcib1 > > > pci2: domain=0, physical bus=2 > > > found-> vendor=0x11ab, dev=0x4352, revid=0x14 > > >domain=0, bus=2, slot=0, func=0 > > >class=02-00-00, hdrtype=0x00, mfdev=0 > > >cmdreg=0x0007, statreg=0x4010, cachelnsz=16 (dwords) > > >lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > >intpin=a, irq=11 > > >powerspec 2 supports D0 D1 D2 D3 current D0 > > >MSI supports 2 messages, 64 bit > > >map[10]: type Memory, range 64, base 0xd010, size 14, enabled > > > pcib1: requested memory range 0xd010-0xd0103fff: good > > >map[18]: type I/O Port, range 32, base 0x2000, size 8, enabled > > > pcib1: requested I/O range 0x2000-0x20ff: in range > > > pcib1: slot 0 INTA routed to irq 16 > > > mskc0: port 0x2000-0x20ff mem > > > 0xd010-0xd0103fff irq 16 at device 0.0 on pci2 > > > mskc0: Reserved 0x4000 bytes for rid 0x10 type 3 at 0xd010 > > > mskc0: MSI count : 2 > > > mskc0: RAM buffer size : 4KB > > > mskc0: Port 0 : Rx Queue 2KB(0x:0x07ff) > > > mskc0: Port 0 : Tx Queue 2KB(0x0800:0x0fff) > > > msk0: on mskc0 > > > msk0: bpf attached > > > msk0: Ethernet address: 00:1b:24:0e:bc:26 > > > miibus0: on msk0 > > > e1000phy0: PHY 0 on miibus0 > > > e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > > > ioapic0: routing intpin 16 (PCI IRQ 16) to vector 49 > > > mskc0: [MPSAFE] > > > mskc0: [FILTER] > > > > > > >So far all looks good to me. If you encounter watchdog timeouts > >or Rx FIFO overruns let me know. > > > > > > Got it again: > msk0: Rx FIFO overrun! > I believe this is happening under heavy CPU usage. Now i have firefox > compiling and watched pictures on remote windows box using rdesktop. And > after few minutes got network freeze. If it only happens under heavy system loads it's probably normal. If system is too busy to serve other jobs the msk(4) may not recevie more packets because its receive buffer was full. Probably msk(4) should just count the overrun errors without printing the message such that it would save more CPU cycles. Btw, did you also see watchdog timeout errors? > But it looks i didn't get any packet lost :). Take a look at ping > statistics... funny... I guess something is wrong here. Latency is unacceptable. However I have no idea why ICMP echo reponse takes so long time. Are you using any power saving mechanism(powerd, cpufreq etc)? > tdevil% ping 10.1.1.254 > PING 10.1.1.254 (10.1.1.254): 56 data bytes > 64 bytes from 10.1.1.254: icmp_seq=0 ttl=64 time=35926.404 ms > 64 bytes from 10.1.1.254: icmp_seq=1 ttl=64 time=34925.694 ms > 64 bytes from 10.1.1.254: icmp_seq=2 ttl=64 time=33924.729 ms > 64 bytes from 10.1.1.254: icmp_seq=3 ttl=64 time=32923.814 ms > 64 bytes from 10.1.1.254: icmp_seq=4 ttl=64 time=31922.833 ms > 64 bytes from 10.1.1.254: icmp_seq=5 ttl=64 time=30921.878 ms > 64 bytes from 10.1.1.254: icmp_seq=6 ttl=64 time=29920.923 ms > 64 bytes from 10.1.1.254: icmp_seq=7 ttl=64 time=28919.960 ms > 64 bytes from 10.1.1.254: icmp_seq=8 ttl=64 time=27919.009 ms > 64 bytes from 10.1.1.254: icmp_seq=9 ttl=64 time=26918.042 ms > 64 bytes from 10.1.1.254: icmp_seq=10 ttl=64 time=25917.078 ms > 64 bytes from 10.1.1.254: icmp_seq=11 ttl=64 time=24916.115 ms > 64 bytes from 10.1.1.254: icmp_seq=12 ttl=64 time=23915.144 ms > 64 bytes from 10.1.1.254: icmp_seq=13 ttl=64 time=22914.192 ms > 64 bytes from 10.1.1.254: icmp_seq=14 ttl=64 time=21913.214 ms > 64 bytes from 10.1.1.254: icmp_seq=15 ttl=64 time=20912.278 ms > 64 bytes from 10.1.1.254: icmp_seq=16 ttl=64 time=19911.330 ms > 64 bytes from 10.1.1.254: icmp_seq=17 ttl=64 time=18910.375 ms > 64 bytes from 10.1.1.254: icmp_seq=18 ttl=64 time=17909.419 ms > 64 bytes from 10.1.1.254: icmp_seq=19 ttl=64 time=16853.821 ms > 64 bytes from 10.1.1.254: icmp_seq=20 ttl=64 time=15854.710 ms > 64 bytes from 10.1.1.254: icmp_seq=21 ttl=64 time=14701.312 ms > 64 bytes from
Re: any hope for nfe/msk?
Hello, Pyun YongHyeon wrote: On Thu, Nov 01, 2007 at 10:59:48AM +0200, Oleg Lomaka wrote: > Hello, > > Pyun YongHyeon wrote: > >On Tue, Oct 30, 2007 at 04:01:04PM +0200, Oleg Lomaka wrote: > > > >[...] > > > > > I had RxFIFO overrun again :( > > > from dmest: > > > msk0: Rx FIFO overrun! > > > >[...] > > > >Please try attached patch again. Sorry for the trouble. > >After applying the patch show me verbosed dmesg output related with > >msk(4)/PHY driver. > > > >Thanks for testing. > > > pcib1: irq 16 at device 28.0 on pci0 > pcib1: domain0 > pcib1: secondary bus 2 > pcib1: subordinate bus 2 > pcib1: I/O decode0x2000-0x2fff > pcib1: memory decode 0xd010-0xd01f > pcib1: no prefetched decode > pci2: on pcib1 > pci2: domain=0, physical bus=2 > found-> vendor=0x11ab, dev=0x4352, revid=0x14 >domain=0, bus=2, slot=0, func=0 >class=02-00-00, hdrtype=0x00, mfdev=0 >cmdreg=0x0007, statreg=0x4010, cachelnsz=16 (dwords) >lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >intpin=a, irq=11 >powerspec 2 supports D0 D1 D2 D3 current D0 >MSI supports 2 messages, 64 bit >map[10]: type Memory, range 64, base 0xd010, size 14, enabled > pcib1: requested memory range 0xd010-0xd0103fff: good >map[18]: type I/O Port, range 32, base 0x2000, size 8, enabled > pcib1: requested I/O range 0x2000-0x20ff: in range > pcib1: slot 0 INTA routed to irq 16 > mskc0: port 0x2000-0x20ff mem > 0xd010-0xd0103fff irq 16 at device 0.0 on pci2 > mskc0: Reserved 0x4000 bytes for rid 0x10 type 3 at 0xd010 > mskc0: MSI count : 2 > mskc0: RAM buffer size : 4KB > mskc0: Port 0 : Rx Queue 2KB(0x:0x07ff) > mskc0: Port 0 : Tx Queue 2KB(0x0800:0x0fff) > msk0: on mskc0 > msk0: bpf attached > msk0: Ethernet address: 00:1b:24:0e:bc:26 > miibus0: on msk0 > e1000phy0: PHY 0 on miibus0 > e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > ioapic0: routing intpin 16 (PCI IRQ 16) to vector 49 > mskc0: [MPSAFE] > mskc0: [FILTER] > So far all looks good to me. If you encounter watchdog timeouts or Rx FIFO overruns let me know. Got it again: msk0: Rx FIFO overrun! I believe this is happening under heavy CPU usage. Now i have firefox compiling and watched pictures on remote windows box using rdesktop. And after few minutes got network freeze. But it looks i didn't get any packet lost :). Take a look at ping statistics... funny... tdevil% ping 10.1.1.254 PING 10.1.1.254 (10.1.1.254): 56 data bytes 64 bytes from 10.1.1.254: icmp_seq=0 ttl=64 time=35926.404 ms 64 bytes from 10.1.1.254: icmp_seq=1 ttl=64 time=34925.694 ms 64 bytes from 10.1.1.254: icmp_seq=2 ttl=64 time=33924.729 ms 64 bytes from 10.1.1.254: icmp_seq=3 ttl=64 time=32923.814 ms 64 bytes from 10.1.1.254: icmp_seq=4 ttl=64 time=31922.833 ms 64 bytes from 10.1.1.254: icmp_seq=5 ttl=64 time=30921.878 ms 64 bytes from 10.1.1.254: icmp_seq=6 ttl=64 time=29920.923 ms 64 bytes from 10.1.1.254: icmp_seq=7 ttl=64 time=28919.960 ms 64 bytes from 10.1.1.254: icmp_seq=8 ttl=64 time=27919.009 ms 64 bytes from 10.1.1.254: icmp_seq=9 ttl=64 time=26918.042 ms 64 bytes from 10.1.1.254: icmp_seq=10 ttl=64 time=25917.078 ms 64 bytes from 10.1.1.254: icmp_seq=11 ttl=64 time=24916.115 ms 64 bytes from 10.1.1.254: icmp_seq=12 ttl=64 time=23915.144 ms 64 bytes from 10.1.1.254: icmp_seq=13 ttl=64 time=22914.192 ms 64 bytes from 10.1.1.254: icmp_seq=14 ttl=64 time=21913.214 ms 64 bytes from 10.1.1.254: icmp_seq=15 ttl=64 time=20912.278 ms 64 bytes from 10.1.1.254: icmp_seq=16 ttl=64 time=19911.330 ms 64 bytes from 10.1.1.254: icmp_seq=17 ttl=64 time=18910.375 ms 64 bytes from 10.1.1.254: icmp_seq=18 ttl=64 time=17909.419 ms 64 bytes from 10.1.1.254: icmp_seq=19 ttl=64 time=16853.821 ms 64 bytes from 10.1.1.254: icmp_seq=20 ttl=64 time=15854.710 ms 64 bytes from 10.1.1.254: icmp_seq=21 ttl=64 time=14701.312 ms 64 bytes from 10.1.1.254: icmp_seq=22 ttl=64 time=13701.003 ms 64 bytes from 10.1.1.254: icmp_seq=23 ttl=64 time=12700.052 ms 64 bytes from 10.1.1.254: icmp_seq=24 ttl=64 time=11699.098 ms 64 bytes from 10.1.1.254: icmp_seq=25 ttl=64 time=10698.148 ms 64 bytes from 10.1.1.254: icmp_seq=36 ttl=64 time=0.463 ms 64 bytes from 10.1.1.254: icmp_seq=37 ttl=64 time=0.379 ms ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: any hope for nfe/msk?
On Thu, Nov 01, 2007 at 10:59:48AM +0200, Oleg Lomaka wrote: > Hello, > > Pyun YongHyeon wrote: > >On Tue, Oct 30, 2007 at 04:01:04PM +0200, Oleg Lomaka wrote: > > > >[...] > > > > > I had RxFIFO overrun again :( > > > from dmest: > > > msk0: Rx FIFO overrun! > > > >[...] > > > >Please try attached patch again. Sorry for the trouble. > >After applying the patch show me verbosed dmesg output related with > >msk(4)/PHY driver. > > > >Thanks for testing. > > > pcib1: irq 16 at device 28.0 on pci0 > pcib1: domain0 > pcib1: secondary bus 2 > pcib1: subordinate bus 2 > pcib1: I/O decode0x2000-0x2fff > pcib1: memory decode 0xd010-0xd01f > pcib1: no prefetched decode > pci2: on pcib1 > pci2: domain=0, physical bus=2 > found-> vendor=0x11ab, dev=0x4352, revid=0x14 >domain=0, bus=2, slot=0, func=0 >class=02-00-00, hdrtype=0x00, mfdev=0 >cmdreg=0x0007, statreg=0x4010, cachelnsz=16 (dwords) >lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >intpin=a, irq=11 >powerspec 2 supports D0 D1 D2 D3 current D0 >MSI supports 2 messages, 64 bit >map[10]: type Memory, range 64, base 0xd010, size 14, enabled > pcib1: requested memory range 0xd010-0xd0103fff: good >map[18]: type I/O Port, range 32, base 0x2000, size 8, enabled > pcib1: requested I/O range 0x2000-0x20ff: in range > pcib1: slot 0 INTA routed to irq 16 > mskc0: port 0x2000-0x20ff mem > 0xd010-0xd0103fff irq 16 at device 0.0 on pci2 > mskc0: Reserved 0x4000 bytes for rid 0x10 type 3 at 0xd010 > mskc0: MSI count : 2 > mskc0: RAM buffer size : 4KB > mskc0: Port 0 : Rx Queue 2KB(0x:0x07ff) > mskc0: Port 0 : Tx Queue 2KB(0x0800:0x0fff) > msk0: on mskc0 > msk0: bpf attached > msk0: Ethernet address: 00:1b:24:0e:bc:26 > miibus0: on msk0 > e1000phy0: PHY 0 on miibus0 > e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > ioapic0: routing intpin 16 (PCI IRQ 16) to vector 49 > mskc0: [MPSAFE] > mskc0: [FILTER] > So far all looks good to me. If you encounter watchdog timeouts or Rx FIFO overruns let me know. -- Regards, Pyun YongHyeon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: any hope for nfe/msk?
Hello, Pyun YongHyeon wrote: On Tue, Oct 30, 2007 at 04:01:04PM +0200, Oleg Lomaka wrote: [...] > I had RxFIFO overrun again :( > from dmest: > msk0: Rx FIFO overrun! [...] Please try attached patch again. Sorry for the trouble. After applying the patch show me verbosed dmesg output related with msk(4)/PHY driver. Thanks for testing. pcib1: irq 16 at device 28.0 on pci0 pcib1: domain0 pcib1: secondary bus 2 pcib1: subordinate bus 2 pcib1: I/O decode0x2000-0x2fff pcib1: memory decode 0xd010-0xd01f pcib1: no prefetched decode pci2: on pcib1 pci2: domain=0, physical bus=2 found-> vendor=0x11ab, dev=0x4352, revid=0x14 domain=0, bus=2, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x4010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 MSI supports 2 messages, 64 bit map[10]: type Memory, range 64, base 0xd010, size 14, enabled pcib1: requested memory range 0xd010-0xd0103fff: good map[18]: type I/O Port, range 32, base 0x2000, size 8, enabled pcib1: requested I/O range 0x2000-0x20ff: in range pcib1: slot 0 INTA routed to irq 16 mskc0: port 0x2000-0x20ff mem 0xd010-0xd0103fff irq 16 at device 0.0 on pci2 mskc0: Reserved 0x4000 bytes for rid 0x10 type 3 at 0xd010 mskc0: MSI count : 2 mskc0: RAM buffer size : 4KB mskc0: Port 0 : Rx Queue 2KB(0x:0x07ff) mskc0: Port 0 : Tx Queue 2KB(0x0800:0x0fff) msk0: on mskc0 msk0: bpf attached msk0: Ethernet address: 00:1b:24:0e:bc:26 miibus0: on msk0 e1000phy0: PHY 0 on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ioapic0: routing intpin 16 (PCI IRQ 16) to vector 49 mskc0: [MPSAFE] mskc0: [FILTER] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: any hope for nfe/msk?
On Tue, Oct 30, 2007 at 04:01:04PM +0200, Oleg Lomaka wrote:
[...]
> I had RxFIFO overrun again :(
> from dmest:
> msk0: Rx FIFO overrun!
[...]
Please try attached patch again. Sorry for the trouble.
After applying the patch show me verbosed dmesg output related with
msk(4)/PHY driver.
Thanks for testing.
--
Regards,
Pyun YongHyeon
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.c20 Jul 2007 00:25:20 - 1.18
+++ if_msk.c31 Oct 2007 03:31:48 -
@@ -368,6 +368,8 @@
struct msk_if_softc *sc_if;
sc_if = device_get_softc(dev);
+ if (phy != PHY_ADDR_MARV)
+ return (0);
return (msk_phy_readreg(sc_if, phy, reg));
}
@@ -406,6 +408,8 @@
struct msk_if_softc *sc_if;
sc_if = device_get_softc(dev);
+ if (phy != PHY_ADDR_MARV)
+ return (0);
return (msk_phy_writereg(sc_if, phy, reg, val));
}
@@ -516,17 +520,14 @@
CSR_WRITE_4(sc, MR_ADDR(sc_if->msk_port, GMAC_CTRL), gmac);
/* Enable PHY interrupt for FIFO underrun/overflow. */
- if (sc->msk_marvell_phy)
- msk_phy_writereg(sc_if, PHY_ADDR_MARV,
- PHY_MARV_INT_MASK, PHY_M_IS_FIFO_ERROR);
+ msk_phy_writereg(sc_if, PHY_ADDR_MARV, PHY_MARV_INT_MASK,
+ PHY_M_IS_FIFO_ERROR);
} else {
/*
* Link state changed to down.
* Disable PHY interrupts.
*/
- if (sc->msk_marvell_phy)
- msk_phy_writereg(sc_if, PHY_ADDR_MARV,
- PHY_MARV_INT_MASK, 0);
+ msk_phy_writereg(sc_if, PHY_ADDR_MARV, PHY_MARV_INT_MASK, 0);
/* Disable Rx/Tx MAC. */
gmac = GMAC_READ_2(sc, sc_if->msk_port, GM_GP_CTRL);
gmac &= ~(GM_GPCR_RX_ENA | GM_GPCR_TX_ENA);
@@ -1018,64 +1019,38 @@
static int
mskc_setup_rambuffer(struct msk_softc *sc)
{
- int totqsize, minqsize;
- int avail, next;
+ int next;
int i;
uint8_t val;
/* 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);
-
- totqsize = sc->msk_ramsize * sc->msk_num_port;
- minqsize = MSK_MIN_RXQ_SIZE + MSK_MIN_TXQ_SIZE;
- if (minqsize > sc->msk_ramsize)
- minqsize = sc->msk_ramsize;
-
- if (minqsize * sc->msk_num_port > totqsize) {
- device_printf(sc->msk_dev,
- "not enough RAM buffer memory : %d/%dKB\n",
- minqsize * sc->msk_num_port, totqsize);
- return (ENOSPC);
- }
-
- avail = totqsize;
- if (sc->msk_num_port > 1) {
- /*
-* Divide up the memory evenly so that everyone gets a
-* fair share for dual port adapters.
-*/
- avail = sc->msk_ramsize;
- }
-
- /* Take away the minimum memory for active queues. */
- avail -= minqsize;
- /* 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;
-
+ /*
+* Give receiver 2/3 of memory and round down to the multiple
+* of 1024. Tx/Rx RAM buffer size of Yukon II shoud be multiple
+* of 1024.
+*/
+ sc->msk_rxqsize = rounddown((sc->msk_ramsize * 1024 * 2) / 3, 1024);
+ sc->msk_txqsize = (sc->msk_ramsize * 1024) - sc->msk_rxqsize;
for (i = 0, next = 0; i < sc->msk_num_port; i++) {
sc->msk_rxqstart[i] = next;
- sc->msk_rxqend[i] = next + (sc->msk_rxqsize * 1024) - 1;
+ sc->msk_rxqend[i] = next + sc->msk_rxqsize - 1;
next = sc->msk_rxqend[i] + 1;
sc->msk_txqstart[i] = next;
- sc->msk_txqend[i] = next + (sc->msk_txqsize * 1024) - 1;
+ sc->msk_txqend[i] = next + sc->msk_txqsize - 1;
next = sc->msk_txqend[i] + 1;
if (bootverbose) {
device_printf(sc->msk_dev,
"Port %d : Rx Queue %dKB(0x%08x:0x%08x)\n", i,
- sc->msk_rxqsize, sc->msk_rxqstart[i],
+ sc->msk_rxqsize / 1024, sc->msk_rxqstart[i],
sc->msk_rxqend[i]);
device_printf(sc->msk_dev,
"Port %d : Tx Queue %dK
Re: any hope for nfe/msk?
Pyun YongHyeon wrote: On Thu, Oct 25, 2007 at 05:30:32PM +0900, To Oleg Lomaka wrote: [...] > > tdevil% grep -iE "msk|phy" /var/run/dmesg.boot > > pci0: domain=0, physical bus=0 > > pci2: domain=0, physical bus=2 > > mskc0: port 0x2000-0x20ff mem > > 0xd010-0xd0103fff irq 16 at device 0.0 on pci2 > > mskc0: Reserved 0x4000 bytes for rid 0x10 type 3 at 0xd010 > > mskc0: MSI count : 2 > > mskc0: RAM buffer size : 16KB > > mskc0: Port 0 : Rx Queue 10KB(0x:0x27ff) > > mskc0: Port 0 : Tx Queue 10KB(0x2800:0x4fff) > > msk0: on mskc0 > > msk0: bpf attached > > msk0: Ethernet address: 00:1b:24:0e:bc:26 > > miibus0: on msk0 > > e1000phy0: PHY 0 on miibus0 > > e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > > ukphy0: PHY 3 on miibus0 > > ukphy0: OUI 0x001000, model 0x0004, rev. 0 > > ukphy0: no media present > > ukphy1: 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? > Any progress here? I guess it's very important to fix the bug as it would affect all Yukon FE based NIC. I've applied your patch again yesterday. There was no halts for few hours already (after ports cvs up and other network/cpu loads). I'll give you a note in a day or two if there will no be any troubles. Thanks for your help. -- Oleg Lomaka, System Administrator Kiev Zoral Development Center Tel: +380-44-4928018 ALEK-RIPE, ALEK-UANIC ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: any hope for nfe/msk?
Pyun YongHyeon wrote: On Tue, Oct 30, 2007 at 10:42:33AM +0200, Oleg Lomaka wrote: > Pyun YongHyeon wrote: > >On Thu, Oct 25, 2007 at 05:30:32PM +0900, To Oleg Lomaka wrote: > > > >[...] > > > > > > tdevil% grep -iE "msk|phy" /var/run/dmesg.boot > > > > pci0: domain=0, physical bus=0 > > > > pci2: domain=0, physical bus=2 > > > > mskc0: port 0x2000-0x20ff > > mem > > 0xd010-0xd0103fff irq 16 at device 0.0 on pci2 > > > > mskc0: Reserved 0x4000 bytes for rid 0x10 type 3 at 0xd010 > > > > mskc0: MSI count : 2 > > > > mskc0: RAM buffer size : 16KB > > > > mskc0: Port 0 : Rx Queue 10KB(0x:0x27ff) > > > > mskc0: Port 0 : Tx Queue 10KB(0x2800:0x4fff) > > > > msk0: on > > mskc0 > > > > msk0: bpf attached > > > > msk0: Ethernet address: 00:1b:24:0e:bc:26 > > > > miibus0: on msk0 > > > > e1000phy0: PHY 0 on > > miibus0 > > > > e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > > > > ukphy0: PHY 3 on miibus0 > > > > ukphy0: OUI 0x001000, model 0x0004, rev. 0 > > > > ukphy0: no media present > > > > ukphy1: 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? > > > > > > >Any progress here? > >I guess it's very important to fix the bug as it would affect all > >Yukon FE based NIC. > > > > > I've applied your patch again yesterday. There was no halts for few > hours already (after ports cvs up and other network/cpu loads). I'll > give you a note in a day or two if there will no be any troubles. > Thanks for your help. > Glad to hear that. Would you show me the verbosed boot messages related with msk(4)? According to your dmesg output I guess you have phantom PHYs attached to msk(4) too. So I'd also like to know the output of "devinfo -rv". I had RxFIFO overrun again :( from dmest: msk0: Rx FIFO overrun! pid 1245 (gnome-vfs-daemon), uid 1001: exited on signal 11 msk0: watchdog timeout (missed Tx interrupts) -- recovering from boot log: pci2: on pcib1 pci2: domain=0, physical bus=2 found-> vendor=0x11ab, dev=0x4352, revid=0x14 domain=0, bus=2, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x4010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 MSI supports 2 messages, 64 bit map[10]: type Memory, range 64, base 0xd010, size 14, enabled pcib1: requested memory range 0xd010-0xd0103fff: good map[18]: type I/O Port, range 32, base 0x2000, size 8, enabled pcib1: requested I/O range 0x2000-0x20ff: in range pcib1: slot 0 INTA routed to irq 16 mskc0: port 0x2000-0x20ff mem 0xd010-0xd0103fff irq 16 at device 0.0 on pci2 mskc0: Reserved 0x4000 bytes for rid 0x10 type 3 at 0xd010 mskc0: MSI count : 2 mskc0: RAM buffer size : 4KB mskc0: Port 0 : Rx Queue 10KB(0x:0x27ff) mskc0: Port 0 : Tx Queue -6KB(0x2800:0x0fff) msk0: on mskc0 msk0: bpf attached msk0: Ethernet address: 00:1b:24:0e:bc:26 miibus0: on msk0 e1000phy0: PHY 0 on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ukphy0: PHY 3 on miibus0 ukphy0: OUI 0x001000, model 0x0004, rev. 0 ukphy0: no media present ukphy1: PHY 6 on miibus0 ukphy1: OUI 0x004400, model 0x0011, rev. 0 ukphy1: no media present ioapic0: routing intpin 16 (PCI IRQ 16) to vector 49 mskc0: [MPSAFE] mskc0: [FILTER] pcib2: irq 17 at device 28.1 on pci0 pcib2: domain0 pcib2: secondary bus 3 pcib2: subordinate bus 3 pcib2: I/O decode0xf000-0xfff pcib2: memory decode 0xd000-0xd and devinfo: tdevil% devinfo -rv nexus0 cryptosoft0 apic0 I/O memory addresses: 0xfec0-0xfec0001f 0xfee0-0xfee003ff legacy0 cpu0 pcib0 pci0 hostb0 pnpinfo vendor=0x8086 device=0x27a0 subvendor=0x1025 subdevice=0x0110 class=0x06 at slot=0 function=0 vgapci0 pnpinfo vendor=0x8086 device=0x27a2 subvendor=0x1025 subdevice=0x0110 class=0x03 at slot=2 function=0 I/O ports: 0x1800-0x1807 I/O memory addresses: 0xc000-0xcfff 0xd030-0xd037 0xd040-0xd043 agp0 drm0 vgapci1 pnpinfo vendor=0x8086 device=0x27a6 subvendor=0x1025 subdevice=0x0110 class=0x038000 at slot=2 function=1 I/O memory addresses: 0xd038-0xd03f drm1 pcm0 pnpinfo vendor=0x8086 device=0x27d8 subvendor=0x1025 subdevice=0x0110 class=0x040300 at slot=27 fun
Re: any hope for nfe/msk?
On Tue, Oct 30, 2007 at 10:42:33AM +0200, Oleg Lomaka wrote: > Pyun YongHyeon wrote: > >On Thu, Oct 25, 2007 at 05:30:32PM +0900, To Oleg Lomaka wrote: > > > >[...] > > > > > > tdevil% grep -iE "msk|phy" /var/run/dmesg.boot > > > > pci0: domain=0, physical bus=0 > > > > pci2: domain=0, physical bus=2 > > > > mskc0: port 0x2000-0x20ff > > mem > > 0xd010-0xd0103fff irq 16 at device 0.0 on pci2 > > > > mskc0: Reserved 0x4000 bytes for rid 0x10 type 3 at 0xd010 > > > > mskc0: MSI count : 2 > > > > mskc0: RAM buffer size : 16KB > > > > mskc0: Port 0 : Rx Queue 10KB(0x:0x27ff) > > > > mskc0: Port 0 : Tx Queue 10KB(0x2800:0x4fff) > > > > msk0: on > > mskc0 > > > > msk0: bpf attached > > > > msk0: Ethernet address: 00:1b:24:0e:bc:26 > > > > miibus0: on msk0 > > > > e1000phy0: PHY 0 on > > miibus0 > > > > e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > > > > ukphy0: PHY 3 on miibus0 > > > > ukphy0: OUI 0x001000, model 0x0004, rev. 0 > > > > ukphy0: no media present > > > > ukphy1: 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? > > > > > > >Any progress here? > >I guess it's very important to fix the bug as it would affect all > >Yukon FE based NIC. > > > > > I've applied your patch again yesterday. There was no halts for few > hours already (after ports cvs up and other network/cpu loads). I'll > give you a note in a day or two if there will no be any troubles. > Thanks for your help. > Glad to hear that. Would you show me the verbosed boot messages related with msk(4)? According to your dmesg output I guess you have phantom PHYs attached to msk(4) too. So I'd also like to know the output of "devinfo -rv". -- Regards, Pyun YongHyeon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: any hope for nfe/msk?
On Thu, Oct 25, 2007 at 05:30:32PM +0900, To Oleg Lomaka wrote: [...] > > tdevil% grep -iE "msk|phy" /var/run/dmesg.boot > > pci0: domain=0, physical bus=0 > > pci2: domain=0, physical bus=2 > > mskc0: port 0x2000-0x20ff mem > > 0xd010-0xd0103fff irq 16 at device 0.0 on pci2 > > mskc0: Reserved 0x4000 bytes for rid 0x10 type 3 at 0xd010 > > mskc0: MSI count : 2 > > mskc0: RAM buffer size : 16KB > > mskc0: Port 0 : Rx Queue 10KB(0x:0x27ff) > > mskc0: Port 0 : Tx Queue 10KB(0x2800:0x4fff) > > msk0: on mskc0 > > msk0: bpf attached > > msk0: Ethernet address: 00:1b:24:0e:bc:26 > > miibus0: on msk0 > > e1000phy0: PHY 0 on miibus0 > > e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > > ukphy0: PHY 3 on miibus0 > > ukphy0: OUI 0x001000, model 0x0004, rev. 0 > > ukphy0: no media present > > ukphy1: 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? > Any progress here? I guess it's very important to fix the bug as it would affect all Yukon FE based NIC. -- Regards, Pyun YongHyeon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: any hope for nfe/msk?
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 ohci01584415 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 > > 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: atkbd03275 1 > > > irq12: psm011157 6 > > > irq14: ata022500 13 > > > irq15: ata1 85 0 > > > irq16: mskc0 uhci+ 17334 10 > > > irq18: uhci2 1 0 > > > irq22: pcm046530 27 > > > irq23: uhci0 ehci0 95882 57 > > > cpu0: timer 3322705 1999 > > > Total3519469 2117 > > > > > > > > > tdevil% grep -iE "msk|phy" /var/run/dmesg.boot > > > pci0: domain=0, physical bus=0 > > > pci2: domain=0, physical bus=2 > > > mskc0: port 0x2000-0x20ff mem > > > 0xd010-0xd0103fff irq 16 at device 0.0 on pci2 > > > mskc0: Reserved 0x4000 bytes for rid 0x10 type 3 at 0xd010 > > > mskc0: MSI count : 2 > > > mskc0: RAM buffer size : 16KB > > > mskc0: Port 0 : Rx Queue 10KB(0x:0x27ff) > > > mskc0: Port 0 : Tx Queue 10KB(0x2800:0x4fff) > > > msk0: on mskc0 > > > msk0: bpf attached > > > msk0: Ethernet address: 00:1b:24:0e:bc:26 > > > miibus0: on msk0 > > > e1000phy0: PHY 0 on miibus0 > > > e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > > > ukphy0: PHY 3 on miibus0 > > > ukphy0: OUI 0x001000, model 0x0004, rev. 0 > > > ukphy0: no media present > > > ukphy1: 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 hav
Re: any hope for nfe/msk?
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 ohci01584415 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 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: atkbd03275 1 > irq12: psm011157 6 > irq14: ata022500 13 > irq15: ata1 85 0 > irq16: mskc0 uhci+ 17334 10 > irq18: uhci2 1 0 > irq22: pcm046530 27 > irq23: uhci0 ehci0 95882 57 > cpu0: timer 3322705 1999 > Total3519469 2117 > > > tdevil% grep -iE "msk|phy" /var/run/dmesg.boot > pci0: domain=0, physical bus=0 > pci2: domain=0, physical bus=2 > mskc0: port 0x2000-0x20ff mem > 0xd010-0xd0103fff irq 16 at device 0.0 on pci2 > mskc0: Reserved 0x4000 bytes for rid 0x10 type 3 at 0xd010 > mskc0: MSI count : 2 > mskc0: RAM buffer size : 16KB > mskc0: Port 0 : Rx Queue 10KB(0x:0x27ff) > mskc0: Port 0 : Tx Queue 10KB(0x2800:0x4fff) > msk0: on mskc0 > msk0: bpf attached > msk0: Ethernet address: 00:1b:24:0e:bc:26 > miibus0: on msk0 > e1000phy0: PHY 0 on miibus0 > e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > ukphy0: PHY 3 on miibus0 > ukphy0: OUI 0x001000, model 0x0004, rev. 0 > ukphy0: no media present > ukphy1: 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
Re: any hope for nfe/msk?
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 ohci01584415 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 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: atkbd03275 1 > irq12: psm011157 6 > irq14: ata022500 13 > irq15: ata1 85 0 > irq16: mskc0 uhci+ 17334 10 > irq18: uhci2 1 0 > irq22: pcm046530 27 > irq23: uhci0 ehci0 95882 57 > cpu0: timer 3322705 1999 > Total3519469 2117 > > > tdevil% grep -iE "msk|phy" /var/run/dmesg.boot > pci0: domain=0, physical bus=0 > pci2: domain=0, physical bus=2 > mskc0: port 0x2000-0x20ff mem > 0xd010-0xd0103fff irq 16 at device 0.0 on pci2 > mskc0: Reserved 0x4000 bytes for rid 0x10 type 3 at 0xd010 > mskc0: MSI count : 2 > mskc0: RAM buffer size : 16KB > mskc0: Port 0 : Rx Queue 10KB(0x:0x27ff) > mskc0: Port 0 : Tx Queue 10KB(0x2800:0x4fff) > msk0: on mskc0 > msk0: bpf attached > msk0: Ethernet address: 00:1b:24:0e:bc:26 > miibus0: on msk0 > e1000phy0: PHY 0 on miibus0 > e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > ukphy0: PHY 3 on miibus0 > ukphy0: OUI 0x001000, model 0x0004, rev. 0 > ukphy0: no media present > ukphy1: 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 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.c20 Jul 2007 00:25:20 - 1.18 +++ if_msk.c25 Oct 2007 08:25:33 - @@ -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. */
Re: any hope for nfe/msk?
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 ohci01584415 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 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: atkbd03275 1 irq12: psm011157 6 irq14: ata022500 13 irq15: ata1 85 0 irq16: mskc0 uhci+ 17334 10 irq18: uhci2 1 0 irq22: pcm046530 27 irq23: uhci0 ehci0 95882 57 cpu0: timer 3322705 1999 Total3519469 2117 tdevil% grep -iE "msk|phy" /var/run/dmesg.boot pci0: domain=0, physical bus=0 pci2: domain=0, physical bus=2 mskc0: port 0x2000-0x20ff mem 0xd010-0xd0103fff irq 16 at device 0.0 on pci2 mskc0: Reserved 0x4000 bytes for rid 0x10 type 3 at 0xd010 mskc0: MSI count : 2 mskc0: RAM buffer size : 16KB mskc0: Port 0 : Rx Queue 10KB(0x:0x27ff) mskc0: Port 0 : Tx Queue 10KB(0x2800:0x4fff) msk0: on mskc0 msk0: bpf attached msk0: Ethernet address: 00:1b:24:0e:bc:26 miibus0: on msk0 e1000phy0: PHY 0 on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ukphy0: PHY 3 on miibus0 ukphy0: OUI 0x001000, model 0x0004, rev. 0 ukphy0: no media present ukphy1: 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 > msk0: watchdog timeout (missed Tx interrupts) -- recovering > msk0: watchdog timeout (missed Tx interrupts) -- recovering > msk0: watchdog timeout (missed Tx interrupts) -- recovering > dev.mskc.0.%desc: Marvell Yukon 88E8038 Gigabit Ethernet > dev.mskc.0.%driver: mskc > dev.mskc.0.%location: slot=0 function=0 > dev.mskc.0.%pnpinfo: vendor=0x11ab device=0x4352 subvendor=0x1025 > subdevice=0x0110 class=0x02 > dev.mskc.0.%parent: pci2 > dev.mskc.0.process_limit: 128 > dev.msk.0.%desc: Marvell Technology Group Ltd. Yukon FE Id 0xb7 Rev 0x01 > dev.msk.0.%driver: msk > dev.msk.0.%parent: mskc0 > dev.miibus.0.%parent: msk0 > > Not sure if it is connected to previous issue. > > uname -a > FreeBSD tdevil.lomaka.org.ua 7.0-BETA1 FreeBSD 7.0-BETA1 #0: Mon Oct 22 > 18:32:01 EEST 2007 > [EMAIL PROTECTED]:/usr/obj/usr/src/sys/TDEVIL-7.kernconf i386 > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: any hope for nfe/msk?
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 ohci01584415 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? > 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 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. > msk0: watchdog timeout (missed Tx interrupts) -- recovering > msk0: watchdog timeout (missed Tx interrupts) -- recovering > msk0: watchdog timeout (missed Tx interrupts) -- recovering > dev.mskc.0.%desc: Marvell Yukon 88E8038 Gigabit Ethernet > dev.mskc.0.%driver: mskc > dev.mskc.0.%location: slot=0 function=0 > dev.mskc.0.%pnpinfo: vendor=0x11ab device=0x4352 subvendor=0x1025 > subdevice=0x0110 class=0x02 > dev.mskc.0.%parent: pci2 > dev.mskc.0.process_limit: 128 > dev.msk.0.%desc: Marvell Technology Group Ltd. Yukon FE Id 0xb7 Rev 0x01 > dev.msk.0.%driver: msk > dev.msk.0.%parent: mskc0 > dev.miibus.0.%parent: msk0 > > Not sure if it is connected to previous issue. > > uname -a > FreeBSD tdevil.lomaka.org.ua 7.0-BETA1 FreeBSD 7.0-BETA1 #0: Mon Oct 22 > 18:32:01 EEST 2007 > [EMAIL PROTECTED]:/usr/obj/usr/src/sys/TDEVIL-7.kernconf i386 > -- Regards, Pyun YongHyeon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: any hope for nfe/msk?
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 ohci01584415 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. 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 metric 0 mtu 1500 msk0: watchdog timeout (missed Tx interrupts) -- recovering msk0: watchdog timeout (missed Tx interrupts) -- recovering msk0: Rx FIFO overrun! msk0: watchdog timeout (missed Tx interrupts) -- recovering msk0: watchdog timeout (missed Tx interrupts) -- recovering msk0: watchdog timeout (missed Tx interrupts) -- recovering dev.mskc.0.%desc: Marvell Yukon 88E8038 Gigabit Ethernet dev.mskc.0.%driver: mskc dev.mskc.0.%location: slot=0 function=0 dev.mskc.0.%pnpinfo: vendor=0x11ab device=0x4352 subvendor=0x1025 subdevice=0x0110 class=0x02 dev.mskc.0.%parent: pci2 dev.mskc.0.process_limit: 128 dev.msk.0.%desc: Marvell Technology Group Ltd. Yukon FE Id 0xb7 Rev 0x01 dev.msk.0.%driver: msk dev.msk.0.%parent: mskc0 dev.miibus.0.%parent: msk0 Not sure if it is connected to previous issue. uname -a FreeBSD tdevil.lomaka.org.ua 7.0-BETA1 FreeBSD 7.0-BETA1 #0: Mon Oct 22 18:32:01 EEST 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/TDEVIL-7.kernconf i386 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: any hope for nfe/msk?
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 ohci01584415 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). -- Regards, Pyun YongHyeon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
