Comment 1 Mark Linimon 2012-04-07 21:36:24 UTC

Responsible Changed
From-To: freebsd-bugs->freebsd-net

Over to maintainer(s).

Comment 2 Pyun YongHyeon 2012-04-23 02:29:53 UTC

State Changed
From-To: open->feedback

Would you try the diff at the following URL? 
http://svnweb.freebsd.org/base/stable/9/sys/dev/msk/if_msk.c?r1=229524&r2=229874&view=patch 
Also make sure to cold boot your box after applying the patch. 
Warm reboot may not address the issue. 

Comment 3 Pyun YongHyeon 2012-04-23 02:29:53 UTC

Responsible Changed
From-To: freebsd-net->yongari

Grab.

Same problem with FreeBSD 8.3 Stable and (output of pciconf -vlc)

mskc0@pci0:4:0:0:       class=0x020000 card=0x34528086 chip=0x436111ab
rev=0x18 hdr=0x00
    vendor     = 'Marvell Semiconductor (Was: Galileo Technology Ltd)'
    device     = 'Yukon 88E8050 PCI-E ASF Gigabit Ethernet Controller'
    class      = network
    subclass   = ethernet
    cap 01[48] = powerspec 2  supports D0 D1 D2 D3  current D0
    cap 03[50] = VPD
    cap 05[5c] = MSI supports 2 messages, 64 bit
    cap 10[e0] = PCI-Express 1 legacy endpoint max data 128(128) link x1(x1)
ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected

Cold boot helps, but it looks that every boot has to be a cold boot.
Therefore I use ifconfig msk0 -rxcsum and the problem is gone away.

Further I use hw.msk.msi_disable="1" to get rid of the watchdog timeout
problem with link state changed to DOWN/UP.

Running the GENERIC kernel I see on every boot the message
   mskc0: Uncorrectable PCI Express error.
With the msk.pcierr.patch given in kern/119613 the message is
   mskc0: PCI Express error(0x00100000).
Running my own kernel (only network devices miibus,fxp,rl,msk) the PCI
Error message disappears.

-- 
Andreas Longwitz

Comment 5 Vladimir Druzenko 2012-08-01 18:31:04 UTC

I have same issue:
msk0: watchdog timeout
msk0: prefetch unit stuck?
msk0: initialization failed: no memory for Rx buffers

After adding to /boot/loader.conf:
net.inet.tcp.tso=0
hw.pci.enable_msix=0
hw.pci.enable_msi=0
and to rc.conf:
ifconfig_msk0="inet x.x.x.x netmask 255.255.255.0 -tso -txcsum -rxcsum 
-vlanhwtag"
left only:
msk0: watchdog timeout

And "watchdog timeout" occurs not so fast as before, but always after 
1-2 mins of high network load (scp, for example). With low load it work 
already 15 days without "watchdog timeout".

If any from FreeBSD's developers team want, I can give root access to 
this computer for fix this bug.


Other info:
FreeBSD gnat.xxx.local 9.0-STABLE FreeBSD 9.0-STABLE #0: Mon Jul 2 
05:52:45 MSK 2012 root@gnat.xxx.local:/usr/obj/usr/src/sys/GNAT  amd64
(RELENG_9 from Jun 29 2012)

88E8053 PCI-E Gigabit Ethernet Controller integrated on motherboard 
P5GD2-Deluxe.

hostb0@pci0:0:0:0:      class=0x060000 card=0x25808086 chip=0x25808086 
rev=0x04 hdr=0x00
     vendor     = 'Intel Corporation'
     device     = '82915G/P/GV/GL/PL/910GL Memory Controller Hub'
     class      = bridge
     subclass   = HOST-PCI
     cap 09[e0] = vendor (length 9) Intel cap 2 version 1
pcib1@pci0:0:1:0:       class=0x060400 card=0x00008086 chip=0x25818086 
rev=0x04 hdr=0x01
     vendor     = 'Intel Corporation'
     device     = '82915G/P/GV/GL/PL/910GL PCI Express Root Port'
     class      = bridge
     subclass   = PCI-PCI
     cap 0d[88] = PCI Bridge card=0x00008086
     cap 01[80] = powerspec 2  supports D0 D3  current D0
     cap 05[90] = MSI supports 1 message
     cap 10[a0] = PCI-Express 1 root port max data 128(128) link x16(x16)
ecap 0002[100] = VC 1 max VC1
ecap 0005[140] = unknown 1
hdac0@pci0:0:27:0:      class=0x040300 card=0x813d1043 chip=0x26688086 
rev=0x03 hdr=0x00
     vendor     = 'Intel Corporation'
     device     = '82801FB/FBM/FR/FW/FRW (ICH6 Family) High Definition 
Audio Controller'
     class      = multimedia
     subclass   = HDA
     cap 01[50] = powerspec 2  supports D0 D3  current D0
     cap 05[60] = MSI supports 1 message, 64 bit
     cap 10[70] = PCI-Express 1 root endpoint max data 128(128) link x0(x0)
ecap 0002[100] = VC 1 max VC1
ecap 0005[130] = unknown 1
pcib2@pci0:0:28:0:      class=0x060400 card=0x00000000 chip=0x26608086 
rev=0x03 hdr=0x01
     vendor     = 'Intel Corporation'
     device     = '82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 1'
     class      = bridge
     subclass   = PCI-PCI
     cap 10[40] = PCI-Express 1 root port max data 128(128) link x0(x1)
     cap 05[80] = MSI supports 1 message
     cap 0d[90] = PCI Bridge card=0x00000000
     cap 01[a0] = powerspec 2  supports D0 D3  current D0
ecap 0002[100] = VC 1 max VC1
ecap 0005[180] = unknown 1
pcib3@pci0:0:28:1:      class=0x060400 card=0x00000000 chip=0x26628086 
rev=0x03 hdr=0x01
     vendor     = 'Intel Corporation'
     device     = '82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 2'
     class      = bridge
     subclass   = PCI-PCI
     cap 10[40] = PCI-Express 1 root port max data 128(128) link x1(x1)
     cap 05[80] = MSI supports 1 message
     cap 0d[90] = PCI Bridge card=0x00000000
     cap 01[a0] = powerspec 2  supports D0 D3  current D0
ecap 0002[100] = VC 1 max VC1
ecap 0005[180] = unknown 1
uhci0@pci0:0:29:0:      class=0x0c0300 card=0x80a61043 chip=0x26588086 
rev=0x03 hdr=0x00
     vendor     = 'Intel Corporation'
     device     = '82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI'
     class      = serial bus
     subclass   = USB
uhci1@pci0:0:29:1:      class=0x0c0300 card=0x80a61043 chip=0x26598086 
rev=0x03 hdr=0x00
     vendor     = 'Intel Corporation'
     device     = '82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI'
     class      = serial bus
     subclass   = USB
uhci2@pci0:0:29:2:      class=0x0c0300 card=0x80a61043 chip=0x265a8086 
rev=0x03 hdr=0x00
     vendor     = 'Intel Corporation'
     device     = '82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI'
     class      = serial bus
     subclass   = USB
uhci3@pci0:0:29:3:      class=0x0c0300 card=0x80a61043 chip=0x265b8086 
rev=0x03 hdr=0x00
     vendor     = 'Intel Corporation'
     device     = '82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI'
     class      = serial bus
     subclass   = USB
ehci0@pci0:0:29:7:      class=0x0c0320 card=0x80a61043 chip=0x265c8086 
rev=0x03 hdr=0x00
     vendor     = 'Intel Corporation'
     device     = '82801FB/FBM/FR/FW/FRW (ICH6 Family) USB2 EHCI Controller'
     class      = serial bus
     subclass   = USB
     cap 01[50] = powerspec 2  supports D0 D3  current D0
     cap 0a[58] = EHCI Debug Port at offset 0xa0 in map 0x14
pcib4@pci0:0:30:0:      class=0x060401 card=0x00000000 chip=0x244e8086 
rev=0xd3 hdr=0x01
     vendor     = 'Intel Corporation'
     device     = '82801 PCI Bridge'
     class      = bridge
     subclass   = PCI-PCI
     cap 0d[50] = PCI Bridge card=0x00000000
isab0@pci0:0:31:0:      class=0x060100 card=0x00000000 chip=0x26408086 
rev=0x03 hdr=0x00
     vendor     = 'Intel Corporation'
     device     = '82801FB/FR (ICH6/ICH6R) LPC Interface Bridge'
     class      = bridge
     subclass   = PCI-ISA
atapci1@pci0:0:31:1:    class=0x01018a card=0x80a61043 chip=0x266f8086 
rev=0x03 hdr=0x00
     vendor     = 'Intel Corporation'
     device     = '82801FB/FBM/FR/FW/FRW (ICH6 Family) IDE Controller'
     class      = mass storage
     subclass   = ATA
ahci0@pci0:0:31:2:      class=0x010601 card=0x26061043 chip=0x26528086 
rev=0x03 hdr=0x00
     vendor     = 'Intel Corporation'
     device     = '82801FR/FRW (ICH6R/ICH6RW) SATA Controller'
     class      = mass storage
     subclass   = SATA
     cap 01[70] = powerspec 2  supports D0 D3  current D0
ichsmb0@pci0:0:31:3:    class=0x0c0500 card=0x80a61043 chip=0x266a8086 
rev=0x03 hdr=0x00
     vendor     = 'Intel Corporation'
     device     = '82801FB/FBM/FR/FW/FRW (ICH6 Family) SMBus Controller'
     class      = serial bus
     subclass   = SMBus
vgapci0@pci0:4:0:0:     class=0x030000 card=0x005c1043 chip=0x5b601002 
rev=0x00 hdr=0x00
     vendor     = 'ATI Technologies Inc'
     device     = 'RV370 5B60 [Radeon X300 (PCIE)]'
     class      = display
     subclass   = VGA
     cap 01[50] = powerspec 2  supports D0 D1 D2 D3  current D0
     cap 10[58] = PCI-Express 1 endpoint max data 128(128) link x16(x16)
     cap 05[80] = MSI supports 1 message, 64 bit
ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected
vgapci1@pci0:4:0:1:     class=0x038000 card=0x005d1043 chip=0x5b701002 
rev=0x00 hdr=0x00
     vendor     = 'ATI Technologies Inc'
     device     = 'RV370 [Radeon X300SE]'
     class      = display
     cap 01[50] = powerspec 2  supports D0 D1 D2 D3  current D0
     cap 10[58] = PCI-Express 1 endpoint max data 128(128) link x16(x16)
mskc0@pci0:2:0:0:       class=0x020000 card=0x81421043 chip=0x436211ab 
rev=0x15 hdr=0x00
     vendor     = 'Marvell Technology Group Ltd.'
     device     = '88E8053 PCI-E Gigabit Ethernet Controller'
     class      = network
     subclass   = ethernet
     cap 01[48] = powerspec 2  supports D0 D1 D2 D3  current D0
     cap 03[50] = VPD
     cap 05[5c] = MSI supports 2 messages, 64 bit
     cap 10[e0] = PCI-Express 1 legacy endpoint max data 128(128) link 
x1(x1)
ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected
none0@pci0:1:0:0:       class=0x020000 card=0x138f1043 chip=0x1fa711ab 
rev=0x07 hdr=0x00
     vendor     = 'Marvell Technology Group Ltd.'
     device     = '88W8310 and 88W8000G [Libertas] 802.11g client chipset'
     class      = network
     subclass   = ethernet
     cap 01[40] = powerspec 2  supports D0 D3  current D0
fwohci0@pci0:1:3:0:     class=0x0c0010 card=0x808b1043 chip=0x8023104c 
rev=0x00 hdr=0x00
     vendor     = 'Texas Instruments'
     device     = 'TSB43AB22A IEEE-1394a-2000 Controller (PHY/Link) 
[iOHCI-Lynx]'
     class      = serial bus
     subclass   = FireWire
     cap 01[44] = powerspec 2  supports D0 D1 D2 D3  current D0
atapci0@pci0:1:5:0:     class=0x010400 card=0x81361043 chip=0x31141095 
rev=0x02 hdr=0x00
     vendor     = 'Silicon Image, Inc.'
     device     = 'SiI 3114 [SATALink/SATARaid] Serial ATA Controller'
     class      = mass storage
     subclass   = RAID
     cap 01[60] = powerspec 2  supports D0 D1 D2 D3  current D0

# grep msk /var/run/dmesg.boot
mskc0: <Marvell Yukon 88E8053 Gigabit Ethernet> port 0xc800-0xc8ff mem 
0xd7efc000-0xd7efffff irq 17 at device 0.0 on pci2
msk0: <Marvell Technology Group Ltd. Yukon EC Id 0xb6 Rev 0x01> on mskc0
msk0: Ethernet address: 00:11:d8:4a:cd:c4
miibus0: <MII bus> on msk0

This issue is still occurring on my 8-STABLE box.  The patch suggested in
the feedback state change is already present, and the machine still doesn't
last very long under any kind of load.

 

Maybe it's just time to get that Marvell part out of my machine?  Guess I
overestimated the quality of the Marvell support.

 

What more debugging help can I offer?  It's the exact same message (and same
bit of code), but I don't have the datasheet.

 

-- 

Steve Watt KD6GGD  PP-ASEL-IA          ICBM: 121W 56' 57.5" / 37N 20' 15.3"

Internet: steve @ Watt.COM                        Whois: SW32-ARIN

   Free time?  There's no such thing.  It just comes in varying prices...

 

On Tue, Oct 16, 2012 at 04:10:01PM +0000, Steve Watt wrote:
> The following reply was made to PR kern/166727; it has been noted by GNATS.
> 
> From: "Steve Watt" <steve@Watt.COM>
> To: <bug-followup@FreeBSD.org>, <xxjack12xx@gmail.com>
> Cc:  
> Subject: Re: kern/166727: [msk] msk driver keeps erroring
> Date: Tue, 16 Oct 2012 08:37:27 -0700
> 
>  

[...]

>  This issue is still occurring on my 8-STABLE box.  The patch suggested in
>  the feedback state change is already present, and the machine still doesn't
>  last very long under any kind of load.

Ok.

>  Maybe it's just time to get that Marvell part out of my machine?  Guess I
>  overestimated the quality of the Marvell support.

Marvell didn't ever release publicly available data sheet and seems
to have no interests to support FreeBSD at this moment(no data
sheet, no engineering sample, no reply for technical questions
etc).
msk(4) is result of joint effort between open source developers and
users.  Because it's not rare to see several silicon bugs on
specific chip sets, it is driver's responsibility to write a
workaround code or disable some offloading features to get stable
operation.  All these workaround comes from user' feedback and trial
and errors. So, without vendor support,  it shall take time to get
stable driver but I'll try to improve current situation.

>  What more debugging help can I offer?  It's the exact same message (and same
>  bit of code), but I don't have the datasheet.

Unfortunately I have no clue for the issue at this moment. I'll
disable RX checksum offloading in near future since it seems it
triggers more problems. But watchdog timeouts looks completely
different issue to me.
The only thing I can think of is cold-boot(remove power cord and
wait more than 30 seconds and boot).

Comment 8 Pyun YongHyeon 2012-10-18 01:55:46 UTC

State Changed
From-To: feedback->open

Feedback received.

Comment 9 Pyun YongHyeon 2013-03-15 00:11:41 UTC

State Changed
From-To: open->patched

I've disabled RX checksum offloading for Yukon 88E8053 controller 
so I believe it wouldn't trigger the issue again. It was already 
merged to both stable/9 and stable/8. 
Steve, are you still seening the issue on latest stable/9?

I'm still getting this on FreeBSD 10.0

The same problem here. I had it on 10-RELEASE amd64 and now on 10.1-RC2.

uname -a:
FreeBSD myhost.mydomain.tld 10.1-RC2 FreeBSD 10.1-RC2 #0 r272876: Fri Oct 10 01:12:21 UTC 2014 root@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64

pciconf -lv:
[..]
mskc0@pci0:9:0:0:    class=0x020000 card=0xc072144d chip=0x435411ab rev=0x00 hdr=0x00
    vendor     = 'Marvell Technology Group Ltd.'
    device     = '88E8040 PCI-E Fast Ethernet Controller'
    class      = network
    subclass   = ethernet

Comment 12 Pyun YongHyeon 2014-10-21 08:47:25 UTC

I think the issue mentioned in Bug 166727 has no relation with Alnis's issue and it was fixed long time ago. I know there are a couple of msk(4) instability reports on more recent FreeBSD releases. Given that there was almost no functional msk(4) change for a very long time the issue may be different one.

Alnis, I guess it would be better to show more details on your issue rather than referring to "the same program".  I think you wouldn't see "prefetch unit stuck?" or "initialization failed: no memory for Rx buffers" message on your hardware.
If it shows different issue, file a different report would be better, IMO.

Well, there are already several PRs about "watchdog timeout" with msk0, so I thought it wouldn't be a good idea to add one more.

At the moment, I have both 9.3-RELEASE and 10.1-RC2 on the same machine. When I boot from 9.3-RELEASE, I don't experience any problems with msk0; for example, I can scp a 200 MB file to it with 9.5 MB/s speed. When I boot from 10.1-RC2 and try to scp a 5 MB file to it:

-only ~300-400 packets are sent (e.g., 374, as shown on "slurm -i msk0")
-speed is ~500 KB/s
-transmission continues for less than a second
-within 10 seconds, "msk0: watchdog timeout" message is printed and repeated every 10 seconds on ttyv0 until I reboot the machine.

No, I don't have "prefetch unit stuck" and "initialization failed: no memory for Rx buffers". Does it mean my problem is unrelated? Is it solved long ago? As I read on Forums, some people have it solved and reappearing (https://forums.freebsd.org/threads/msk0-watchdog-timeout.10183/).

Pyun, did you make any changes?
For me, the problem seems to have gone away in RC3 (10.1-RC3 FreeBSD 10.1-RC3 #0 r273437: Tue Oct 21 23:55:15 UTC 2014     root@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64).

Comment 15 Pyun YongHyeon 2014-10-28 00:24:55 UTC

Glad to hear your issue has gone on RC3.
No, I didn't touch msk(4) at all.  I guess some other change in kernel may have fixed it.

Sorry to say, for me the issue has reappeared in 10.1-RELEASE. I tried to replace miibus with that from RC3 but the result was exactly the same.

Comment 17 Kurt Jaeger 2015-04-12 18:25:59 UTC

see

https://lists.freebsd.org/pipermail/freebsd-stable/2015-April/082226.html

for a suggested solution.

Comment 18 Kurt Jaeger 2015-04-13 09:25:33 UTC

https://lists.freebsd.org/pipermail/freebsd-stable/2015-April/082230.html

says: Problem still persists, with:
mskc0 at pci0:9:0:0:    class=0x020000 card=0xc072144d chip=0x435411ab 
rev=0x00 hdr=0x00
     vendor     = 'Marvell Technology Group Ltd.'
     device     = '88E8040 PCI-E Fast Ethernet Controller'
     class      = network
     subclass   = ethernet

on 10.1p9-amd64.

Comment 19 Eitan Adler 2018-05-28 19:50:19 UTC

batch change:

For bugs that match the following
-  Status Is In progress 
AND
- Untouched since 2018-01-01.
AND
- Affects Base System OR Documentation

DO:

Reset to open status.


Note:
I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.

The problem is still there in 11.2 release.
My configuration:
 - motherboard gigabyte ga-965p-s3
 - onboard nic marvel 8056 gigabit lan
 - amd64
 - 8gb ram

Symptoms are all the same : any significant traffic via the nic causes hangs of data transfers and lost connections.

Comment 21 Mark Linimon 2024-10-10 19:57:40 UTC

^Triage: committer's bit was taken into safekeeping some time ago.

To submitter: is this aging PR still relevant?

I no longer use that network card so I'm not sure. I guess it can be closed since I can't reproduce and nobody else has commented on this.