Opened 15 years ago

Closed 6 years ago

#4239 closed bug (fixed)

marvell_yukon driver network connection quickly becomes unresponsive

Reported by: Keifer Owned by: tqh
Priority: normal Milestone: R1
Component: Drivers/Network/marvell_yukon Version: R1/Development
Keywords: Cc: jmpetre@…, pulkomandy@…
Blocked By: Blocking: #6205
Platform: All

Description

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.

Attachments (9)

ifconfig-output.txt (651 bytes ) - added by Keifer 15 years ago.
listdev-output.txt (2.4 KB ) - added by Keifer 15 years ago.
syslog (349.0 KB ) - added by Keifer 15 years ago.
ifconfig.txt (1.3 KB ) - added by jmpetre 15 years ago.
output of failed ping attempt, and output of ifconfig
listdev-output.2.txt (3.4 KB ) - added by jmpetre 15 years ago.
sysinfo-output.txt (2.7 KB ) - added by jmpetre 15 years ago.
syslog.txt (269.9 KB ) - added by jmpetre 15 years ago.
Full syslog
syslog_after_grep_marvell.txt (2.9 KB ) - added by jmpetre 15 years ago.
syslog after a 'grep marvell'
marvell_yukon_r44348plus.patch (274 bytes ) - added by haxworx 12 years ago.
kernel newer than 44348 and this patch fixes my broken NIC

Download all attachments as: .zip

Change History (42)

by Keifer, 15 years ago

Attachment: ifconfig-output.txt added

by Keifer, 15 years ago

Attachment: listdev-output.txt added

by Keifer, 15 years ago

Attachment: syslog added

comment:1 by pulkomandy, 15 years ago

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=

comment:2 by jonas.kirilla, 15 years ago

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.

comment:3 by Keifer, 15 years ago

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.

comment:4 by pulkomandy, 15 years ago

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).

in reply to:  description comment:5 by jmpetre, 15 years ago

Cc: jmpetre@… added
Version: R1/pre-alpha1R1/alpha1

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!

by jmpetre, 15 years ago

Attachment: ifconfig.txt added

output of failed ping attempt, and output of ifconfig

by jmpetre, 15 years ago

Attachment: listdev-output.2.txt added

by jmpetre, 15 years ago

Attachment: sysinfo-output.txt added

by jmpetre, 15 years ago

Attachment: syslog.txt added

Full syslog

by jmpetre, 15 years ago

syslog after a 'grep marvell'

comment:6 by pulkomandy, 15 years ago

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.

comment:7 by axeld, 15 years ago

Component: Drivers/NetworkDrivers/Network/marvell_yukon
Summary: msk driver network connection quickly becomes unresponsivemarvell_yukon driver network connection quickly becomes unresponsive

comment:8 by pulkomandy, 15 years ago

Cc: pulkomandy@… added
Version: R1/alpha1R1/Development

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 ?

comment:9 by Keifer, 15 years ago

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?

comment:10 by pulkomandy, 15 years ago

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.

comment:11 by mbrumbelow, 15 years ago

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.

comment:12 by stippi, 15 years ago

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

comment:13 by pulkomandy, 15 years ago

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.

comment:14 by mbrumbelow, 15 years ago

I am running hrev36263 on all affected machines.

comment:15 by taos, 14 years ago

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).

comment:16 by scottmc, 14 years ago

Resolution: fixed
Status: newclosed

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.

comment:17 by taos, 14 years ago

Resolution: fixed
Status: closedreopened

Using hrev41138 (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 ;-)

Last edited 14 years ago by taos (previous) (diff)

comment:18 by alexixor, 14 years ago

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.

comment:19 by taos, 13 years ago

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.

by haxworx, 12 years ago

kernel newer than 44348 and this patch fixes my broken NIC

comment:20 by axeld, 12 years ago

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

comment:21 by tqh, 12 years ago

Owner: changed from axeld to tqh
Status: reopenedassigned

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

comment:22 by tqh, 12 years ago

Blocking: 6205 added

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

comment:23 by taos, 12 years ago

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.

comment:24 by kallisti5, 12 years ago

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.

comment:25 by vidhoonv, 12 years ago

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!

comment:26 by tqh, 8 years ago

Is this still an issue?

comment:27 by pulkomandy, 8 years ago

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.

in reply to:  26 comment:28 by taos, 8 years ago

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.

comment:29 by tqh, 7 years ago

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

comment:30 by taos, 7 years ago

Yes, at least last month it still happened.

comment:31 by waddlesplash, 6 years ago

Still an issue after FreeBSD 11 upgrade?

comment:32 by taos, 6 years ago

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.

comment:33 by waddlesplash, 6 years ago

Resolution: fixed
Status: assignedclosed

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

Note: See TracTickets for help on using tickets.