marvell_yukon driver network connection quickly becomes unresponsive

[Keifer]

how to reproduce: 1) with plug in Ethernet cable 2) Launch browser 3) Attempt to load multiple sites

experienced behavior: 1) the browser loads the home page from mozilla.org 2) trying to load additional sites results in the browser reporting the the connection has timed out 3) pinging urls from the terminal also fails to report back

expected behavior: 1) the network connection continues to function normally after the first 60 seconds

additional notes: this is occurring with hrev32290 running a HP mini 1000 netbook with a marvell yukon 88e8040 device.

[pulkomandy]

Same problem here with a Dell inspiron 1525, same chip. Oco also gets it on its Sony Vaio (don't remember the exact model)

Freebsd has the same issue, however it seems to happen after 30minutes which is already much better than us... : ​http://www.freebsd.org/cgi/query-pr.cgi?pr=kern%2F124127&cat=

[jonas.kirilla]

If you can ping (a known good) IP number (on the internet) then it's probably a DNS issue. If your router/firewall box is set to serve you DNS (e.g. 10.0.0.1 or 192.168.0.1) try switching to your ISP's given DNS server(s) (IP-numbers) and see if it improves.

[Keifer]

Running 'ping -c 10 74.125.67.100' and 'ping -c 10 google.com' immediately after boot up works as would be expected.

Doing the same after the connection seemingly fails results in an unknown host error for google.com and 100% packet loss for 74.125.67.100.

[pulkomandy]

It's not related to DNS. The driver will miss an interrupt, and then fail to transfer anything after that. I tested it at home, and at the RMLL booth. Oco is having the same problem too. So the chances that it's a problem with all these router/firewalls. (and it works fine on all these setups under linux).

[jmpetre]

Replying to Keifer:

how to reproduce: 1) with plug in Ethernet cable 2) Launch browser 3) Attempt to load multiple sites

experienced behavior: 1) the browser loads the home page from mozilla.org 2) trying to load additional sites results in the browser reporting the the connection has timed out 3) pinging urls from the terminal also fails to report back

expected behavior: 1) the network connection continues to function normally after the first 60 seconds

additional notes: this is occurring with hrev32290 running a HP mini 1000 netbook with a marvell yukon 88e8040 device.

Same thing happens to me on Alpha. I have attached a few logs. Running R33109. The attached ifconfig.txt shows a ping I was sending to my local gateway, then it stopped working and shows the failed packets. Ifconfig output follows that. Syslog showed some errors on marvell_yukon, so I did a 'grep marvell' on it to filter any related messages.

KERN: [marvell_yukon] (msk) Rx FIFO overrun!

[jmpetre]

output of failed ping attempt, and output of ifconfig

[jmpetre]

Full syslog

[jmpetre]

syslog after a 'grep marvell'

[pulkomandy]

Some more information :

• These are the OpenBSD sourcecode, for reference :

​http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/mii/eephy.c?rev=1.48;content-type=text%2Fplain ​http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/mii/mii.h?rev=1.11;content-type=text%2Fplain ​http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/pci/if_msk.c?rev=1.79;content-type=text%2Fplain

• Philippe Houdoin also encounters the problem and did some investigations. This is a gigabyte chip downgraded to fast ethernet, and they just did it wrong. There are a lot of hacks needed to get it working properly. The Gigabyte version should work fine. The problem is in the PHY layer.

[pulkomandy]

Here is the linux driver for these cards (if of any interest) :

​http://git.kernel.org/?p=linux/kernel/git/romieu/netdev-2.6.git;a=blob_plain;f=drivers/net/sky2.c

This one works well on my laptop. What more could it be doing ?

[Keifer]

Regarding pulkomandy's first comment which points to this being an upstream issue: I'm running FreeBSD 8.0-RELEASE on the machine at the moment, and everything is working as expected.

I see that the drivers have been refreshed from -curent in hrev33716. Did this happen to grab any fixes?

[pulkomandy]

I did refresh the driver to see if that could fix anything. It did not, but it wasn't worse either, so I left it like that anyway. Actually, it looks like there is a problem in our freebsd compat layer, probably interrupt related, that tends to be triggered quite often with this driver.

[mbrumbelow]

I am seeing this problem on a DELL Inspiron laptop and 10 Mini. Under the smallest of load the network stack stalls with no network activity. Syslog reads "KERN: [net/marvell_yukon/0] watchdog timeout (missed Tx interrupts) -- recovering". This seems to affect 4 different Dell Inspiron laptop models.

[stippi]

mbrumbelow, can you give the revision that you are running? There was a recent change which may affect this problem.

[pulkomandy]

No, hrev36261 and still seeing the same problem. The interrupt moved to a new msi one, but it still fails. It seems to work about one time out of ten, and has been like that for some month (oco noticed it). After you manage to download ~1MB of files, you know the driver will work until the next reboot. This points to some race condition in the init of the code.

[mbrumbelow]

I am running hrev36263 on all affected machines.

[taos]

Just for information: Running hrev37573 on a Samsung NC10 (equipped with the same infamous marvell yukon 88e8040 chip) still shows the known behaviour. One time out of ten, ethernet works for hours without a single problem as already described by pulkomandy. Otherwise, ethernet fails after transferring a few kB.
Oddly enough, so far it has always worked when I booted into Haiku for the first time after I installed a new revision. Up to about one month ago, I used to install Haiku on a physical partition by mounting it as a write-through vmdk file in a virtual installation of Haiku in VirtualBox. I completely wiped the physical partition, then I copied everything from the virtual installation to the physical installation. After booting from the physical partition for the first time I could always install optional packages without problems. Only when booting for the second time ethernet would eventually fail.
I noticed that if I update an existing installation of Haiku (without removing all files first), ethernet will probably fail after the first reboot. So I tried to mimic a virgin installation of Haiku by removing the old home folder (including all configuration files) and replacing it with an untouched one from a nightly image file. At first, it seemed to work as ethernet connections were stable after the restart. When this method eventually failed for the first time after the fifth or sixth test, however, I realized that this was no solution - it must have been a mere coincidence. Anyway, replacing the home folder before rebooting gave me a slight increase in ethernet reliability (~25% chance of a functioning ethernet connection after restart).

[scottmc]

I have a laptop with this same chipset and after the recent networking changes i've had it run for 3+ days without a reboot or network loss, so closing this one as fixed. If anyone still has issues with this same chipset, please open a new ticket and provide details on your hardware setup.

[taos]

Using 41138 (gcc2hybrid).

Samsung NC10, marvell yukon 88e8040. Running from physical hard disk or flash drive.

I still see these issues. Of course my record for uninterrupted network connection is more than five days - but only after rebooting four times to get the network running for more than 10 minutes in the first place. However, so you really learn to appreciate the fast boot times of haiku ;-)

[alexixor]

I am running 41287 on a HP ProBook 4510s, which has a marvel yukon 88e8072 net work card, and I also have these tx interrupted messages.

I noticed that if I cold boot the laptop then it happens less frequently.

If it starts correctly then it works for days.

[taos]

Using hrev43744 (gcc2hybrid).

After the recent switch to the FreeBSD 9.0 branch for a number of network drivers, I decided to give ethernet on my Samsung NC10 another chance. So far, I haven't run into any connection issues with my marvell yukon 88e8040 chip.

The only problem encountered so far: If the ethernet cable hasn't already been connected during boot, there is no /dev/net/marvell_yukon/0. I think I remember a similar bug report where ethernet was only detected if wifi was disabled or a cable plugged in before boot - but that was no marvell yukon specific problem.

[haxworx]

kernel newer than 44348 and this patch fixes my broken NIC

[axeld]

haxworx: can you please test with hrev44350 or newer (without your patch), and check if that also fixes your issue?

[tqh]

I think this should be fixed. As Axel said, please verify.

[tqh]

(In #6205) Seems to be a duplicate of #4239.

[taos]

Using hrev44618 (gcc2hybrid).

On my Samsung NC10, I again see the problems with an unresponsive network connection. Can't say when it started again because I mostly used wifi connections in the past few months.

[kallisti5]

could you try the recent R1A4.1 release and let us know your results?

If you see the issue still, you may want to try disabling IO-APIC to see if that fixes the issue.

[vidhoonv]

Hi, I started using Haiku today on my Dell inspiron 1525 laptop. (beginner) I confirmed that it has marvell 88e8040 ethernet controller. I still face the same issue. I have installed Haiku alpha 4.1

As suggested in the last comment, I tried IO-APIC (in boot manager options) but it was a futile exercise.

any work around for this problem? thanks!

[tqh]

Is this still an issue?

[pulkomandy]

At the moment I can't easily run Haiku on that machine, it has since been repurposed as my home-server. Maybe ask oco or wait for feedback from one of the other reporters.

[taos]

Replying to tqh:

Is this still an issue?

Yes. Tested with Haiku hrev51053 gcc2hybrid (anyboot iso written to usb thumb drive). However, at least my network card is now also found if the cable wasn't plugged in during boot.

[tqh]

There has been fixes in network since 10 months. Is this still an issue?

[taos]

Yes, at least last month it still happened.

[waddlesplash]

Still an issue after FreeBSD 11 upgrade?

[taos]

I've replied in #13987: It worked in hrev51980, but I could only test during one day, so I can't really be sure if the issue is completely gone.

[waddlesplash]

Well, let me know if it shows up again. Otherwise, closing as fixed.