Ubuntu

via-rhine network adapater won't work on resume

Reported by Emmanuel Pacaud on 2008-09-08
60
This bug affects 9 people
Affects Status Importance Assigned to Milestone
linux (Gentoo Linux)
Invalid
Medium
linux (Ubuntu)
High
Unassigned
Declined for Intrepid by Jeremy Foshee
Declined for Jaunty by Jeremy Foshee
Nominated for Karmic by P4man
Nominated for Lucid by P4man
network-manager (Ubuntu)
Undecided
Unassigned
Declined for Intrepid by Jeremy Foshee
Declined for Jaunty by Jeremy Foshee
Nominated for Karmic by P4man
Nominated for Lucid by P4man

Bug Description

When my machine resume from a suspend to RAM, the wired network adapter doesn't work. Network manager loops forever in it's network configuration state (the two spinning green point).

Description: Ubuntu intrepid (development branch)
Release: 8.10

Linux hobbes 2.6.27-2-generic #1 SMP Thu Aug 28 17:20:02 UTC 2008 i686 GNU/Linux

Changed in linux:
assignee: nobody → ubuntu-kernel-team
importance: Undecided → High
status: New → Triaged
samuelkyl (samuelkyl) wrote :

I had the same problem, and it's working fine after I added irqfixup to my kernel. I have an on board via-rhine NIC.

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.

Andrey Melentyev (longseal) wrote :

I've had the same bug under Gentoo. Here's the link in case someone is interested, there's some information about kernel and so on: http://bugs.gentoo.org/show_bug.cgi?id=199766

I do not use ethernet much, but in case the fix will be available, I can check if it works for me.

Changed in linux:
status: Unknown → Invalid
TJ (tj) wrote :

The irqfixup solution is intended for working around broken device firmware and therefore it could be argued there isn't a bug in the kernel. Andrey also reports interesting scenarios in his Gentoo bug comments:

If module is loaded and interface is down via ifconfig, then after resuming
network doesn't work.
If module is loaded and interface is up, then after resuming network works.
If module is unloaded, I can put laptop into S3 state, the wake it up and then,
after loading module, network works just fine.

Are any users still suffering this bug? If so please report the kernel version(s) affected using:

uname -a

If not, I propose closing this bug as either 'Wont Fix" (firmware issue) or "Fix Released" (no longer experiencing the issue with regular kernel options).

Jeff Trull (jetrull) wrote :

I filed bug 281089 on two resume issues: one network (I have this same via rhine driver) and one USB mouse. My network issue appears to be the same as this bug, judging from the dmesg backtrace. I'm not sure I would agree that this is a firmware issue, though - for me this is a regression from Hardy, where suspend worked properly on the identical hardware.

Adding the following line to /etc/pm/config.d/local works around my problem in Intrepid:

SUSPEND_MODULES="via_rhine"

On Sat, 2009-02-28 at 08:01 +0000, Jeff Trull wrote:
> I filed bug 281089 on two resume issues: one network (I have this same
> via rhine driver) and one USB mouse. My network issue appears to be the
> same as this bug, judging from the dmesg backtrace. I'm not sure I
> would agree that this is a firmware issue, though - for me this is a
> regression from Hardy, where suspend worked properly on the identical
> hardware.

>From the research I'd done so far and the irqfixup solution that always
seems to work, it seems it works because irqfixup tries to find a
matching IRQ handler for unhandled IRQs - the implication being that the
firmware in the device has 'forgotten' which IRQ has been assigned to it
due to the power-off, and doesn't accept the assignment given at resume.

*However*, thanks to Jeff's comment I examined the dmesg log here and in
Jeff's bug #281089 and noticed that at start-up we see the device has
bus ID 0:12.0:

00:12.0 Ethernet controller [0200]: VIA Technologies, Inc. VT6102
[Rhine-II] [1106:3065] (rev 78)

and has an interrupt assigned:

[ 5.208228] via-rhine 0000:00:12.0: PCI INT A -> GSI 23 (level, low) -> IRQ 23
[ 5.208558] eth0: VIA Rhine II at 0xfbb00000, 00:17:31:19:04:36, IRQ 23.

But after resume there is no sign of the IRQ being reassigned.

So, thanks Jeff for prodding me to look closer.

The revised explanation for why irqfixup works is that after resume the
firmware will use a default IRQ since it doesn't get reprogrammed by the
PCI sub-system, and will likely be different to the IRQ the driver is
expecting. irqfixup will match the two together.

As Jeff points out that Hardy doesn't have the issue I've got a
reasonably small window of potential changes to look at to figure out
what changed to cause this.

Changed in linux:
assignee: nobody → intuitivenipple
status: Triaged → In Progress
TJ (tj) wrote :

I've created a DKMS (Dynamic Kernel Module System) package for Intrepid and Jaunty with a patch that *may* fix this issue - please install the package, test, and report your findings and kern.log that covers the suspend/resume period.

The packages are (currently building) in my PPA at:

 https://launchpad.net/~intuitivenipple/+archive/ppa/?field.name_filter=via

You can either enable my PPA via apt and use

 sudo apt-get update && sudo apt-get via-rhine-dkms

or - probably simpler - just download the DKMS .deb file for the Ubuntu release you are testing by expanding the PPA package summary and saving the .deb directly to your PC.

'Down' the network interface and unload the existing module if necessary (to allow it to be replaced):

 sudo ifdown eth0
 sudo modprobe -r via-rhine

Install the package using:

 sudo dpkg -i <package-file-name>

You should see something similar to this:

====================

Selecting previously deselected package via-rhine-dkms.
(Reading database ... 174410 files and directories currently installed.)
Unpacking via-rhine-dkms (from .../via-rhine-dkms_1.4.4-0ubuntu1~ppa1i_all.deb) ...
Setting up via-rhine-dkms (1.4.4-0ubuntu1~ppa1i) ...
Loading new via-rhine-1.4.4 DKMS files...

Creating symlink /var/lib/dkms/via-rhine/1.4.4/source ->
                 /usr/src/via-rhine-1.4.4

DKMS: add Completed.
Installing prebuilt kernel module binaries (if any)
Building module...

Kernel preparation unnecessary for this kernel. Skipping...

Building module:
cleaning build area....
make KERNELRELEASE=2.6.28-7-generic -C /lib/modules/2.6.28-7-generic/build M=/var/lib/dkms/via-rhine/1.4.4/build.....
cleaning build area....

DKMS: build Completed.
Installing module...

via-rhine.ko:
Running module version sanity check.
 - Original module
   - Found /lib/modules/2.6.28-7-generic/kernel/drivers/net/via-rhine.ko
   - Storing in /var/lib/dkms/via-rhine/original_module/2.6.28-7-generic/x86_64/
   - Archiving for uninstallation purposes
 - Installation
   - Installing to /lib/modules/2.6.28-7-generic/updates/dkms/

depmod.......

DKMS: install Completed.

Processing triggers for man-db .

====================

Now load the module and 'up' the interface:

 sudo modprobe via-rhine
 sudo ifup eth0

Test the network to ensure it still works correctly and then do a shutdown/restart of the PC to ensure things are fresh.

Once restarted do a suspend/resume test and report the results.

Graham C (chckens) wrote :

Many thanks TJ for looking into this. Unfortunately, I'm still seeing this issue after installing via-rhine-dkms 1.4.4-0ubuntu1~ppa2i, having removed via-rhine from my SUSPEND_MODULES in /etc/pm/config.d/.

I'm not able to say whether I had this problem on Hardy, as other issues were preventing S3 suspend from working on my board then.

I'll attach the relevant bit of my kern.log, though it's basically the same as Emmanuel's original one. I'm keen to see this fixed, so any other information that could be useful, or other proposed fixes for testing, please let me know.

TJ (tj) wrote :

On Sun, 2009-03-01 at 17:55 +0000, chckens wrote:
> Many thanks TJ for looking into this. Unfortunately, I'm still seeing
> this issue after installing via-rhine-dkms 1.4.4-0ubuntu1~ppa2i, having
> removed via-rhine from my SUSPEND_MODULES in /etc/pm/config.d/.

Thanks for testing it. I didn't think the particular patch this DKMS
package introduces would solve it, but I wanted to give it a try since
it was posted to the LKML by a developer with this chip-set.

There are some other patches which are more invasive to the driver I
want to try next. In the next few days I'll create another DKMS package
that includes those and we can test again.

TJ (tj) wrote :

Quick confirmation I'm still working on this. Not had the time required to study and re-work the other possible patches to fit this driver.

TJ (tj) on 2009-03-23
tags: added: test-suspend-seconds
Andrej (andrejz) wrote :

I have same problem with the latest beta Ubuntu 9.4 Jaunty. Only what have changed since 8.10 that there is no problem with two spinning points, now it shows this correctly - that i am connected, but network doesn't work. I was googled and i have found solution in bug 281089 in launchpad.

Thus, here is workaround that works for me.

Create file /etc/pm/config.d/local with content:

SUSPEND_MODULES="via_rhine"

and try suspend/resume.

Shane Par-Due (shanepardue) wrote :

Andrej's workaround worked for me too.

bofphile (bofphile) wrote :

The workaround worked for me also with my network card: VT6102 [Rhine-II] (integrated on a Asrock 775-Dual VSTA).
I'm using Jaunty and I had the same issue with Intrepid.

P4man (duvel123) wrote :

Another confirmation of this bug, and the workaround as posted by Andrej.. well, works around it :)

Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 7c)
kernel: 2.6.28-11-generic

ismoke101 (ismoke101-gmail) wrote :

Andrej or to anyone, can you please help me, i posted for a rhine problem but i dont know where to put it, my problem is here, can you help me about this? http://ubuntuforums.org/showthread.php?t=1227037

P4man (duvel123) wrote :

I confirm this bug (and its workaround, thanks andreij!). Existed in Hardy, Intrepid, Jaunty and still there in Karmic alpha 3. I also have the VT6102 [Rhine-II] integrated on a Asrock 775-Dual VSTA.

Not aimed at anyone in particular, but its funny how almost every bug I encountered when I first started using ubuntu over 2 years ago still hasn't been fixed, even though all of them were confirmed and most of them seem trivial to solve and/or there are easy workarounds. I dont understand why such a workaround isn't included in the distribution? If a real fix can't be found in all this time, why not include that "SUSPEND_MODULES="via_rhine"" line by default? Are we trying to punish VIA or its customers?

Cosmin (cstroe) wrote :

My current desktop system uses the via_rhine driver for the network interface, and I experiencing something similar to this problem, although I am not suspending my system. My internet will randomly freeze and I have to reload the kernel module before I can start using the interface again.

One of the times I got some interesting looking messages from a dmesg output, but only saved the partial output.

I haven't yet been able to find a way of consistently reproducing the bug. So far the only thing I have done is add "via_rhine debug=3" to my /etc/modules file, in order to get more debug information.

I will watch this thread and post more information if I am able to get more. The freezes are very random. Sometimes everything is ok for days, other times it happens every 5 minutes.

P4man (duvel123) wrote :

Happy 1 year anniversary bug #267779:
Still present in Karmic 5
Workaround still works.

Shane Par-Due (shanepardue) wrote :

This might not be related to this bug, but after the workaround I still have problems. It seems applications crash upon opening. The network card reconnects, but the OS is not functional until I reboot. It happens on fresh installs and on other distros as well.

P4man (duvel123) wrote :

TJ are you still working on this?

bofphile (bofphile) wrote :

I've just installed Karmic and this bug is still there. Fortunately, the workaround works just fine as before.

P4man (duvel123) on 2009-11-19
Changed in linux (Ubuntu):
assignee: TJ (intuitivenipple) → nobody
P4man (duvel123) wrote :

I took the liberty of unassigning TJ since he is not replying and no progress has been made since,.. well a long time.
Just so people dont get the wrong impression that this bug is actively being worked on by him.

P4man (duvel123) on 2009-11-26
Changed in linux (Ubuntu):
status: In Progress → Confirmed
nikoss (kozanitikoblog) wrote :

I have the same problem.
I create a file /etc/pm/config.d/local with content:
SUSPEND_MODULES="via_rhine"
but doesn' t work.
How can i install via-rhine-dkms for karmic koala 9.10?

sabraq (sabraq) wrote :

Hi, via-rhine-dkms doesn't work. Try this, that works for me :

1. create file /etc/pm/sleep.d/11ethernet

2. Put this into :

#!/bin/bash
case $1 in
    suspend)
        rmmod via_rhine
        ;;
    resume)
        modprobe via_rhine
        ;;
esac

3. save and make it executable chmod +x

4. I hope it's working for you, and sorry for my english:)

nikoss (kozanitikoblog) wrote :

thanks sabraq!!

Jeremy Foshee (jeremyfoshee) wrote :

I've not seen an update from the reporter since opening this bug.

Emanuell
   Can you verify if the fix mentioned by sabraq helps? Please also test this against the current alpha of the Lucid release and possibly against the latest mainline build.

I look forward to the results of your testing,

-JFo

Changed in linux (Ubuntu):
status: Confirmed → Incomplete
tags: added: verification-needed
Mitch Towner (kermiac) wrote :

Removed "verification-needed" tag, invalidated network-manager task

tags: removed: verification-needed
Changed in network-manager (Ubuntu):
status: New → Invalid

Jeremy,

I'm currently using lucid, but I'm not able to suspend/hibernate anymore on this machine, so I can't check this issue.

P4man (duvel123) wrote :

I just tried this on Lucid beta1. The problem still exists, no network after waking up from sleep mode.
When I run

rmmod via_rhine
modprobe via_rhine

after resuming, the network works again. so I assume sabraq's work around will work as well (havent tested it yet, will test later).

P4man (duvel123) wrote :

Forgot to confirm that sabraq's script works like a charm (tested on lucid beta2). Thanks a lot for that!

sabraq (sabraq) wrote :

Hi guys, I'm using this simple script still on Karmic (installed by upgrade), don't know if it's still needed, but I think so. The script was created according to instructions to Archilnux (and some of my invention), it's not a charm:D.

sabraq (sabraq) wrote :

eee, not Karmic, I mean Lucid 10.04 of course...

Jason Harvey (jason-alioth) wrote :

This bug also affects me. The module unload/reload seems to solve it. Running 10.04 x86, fully updated.

Changed in linux (Gentoo Linux):
importance: Unknown → Medium
Brendan Howell (w-brendan) wrote :

This bug still exists in 11.04! The fix specified in comment #26 works great. Can somebody find a way to put this in to the mainline?

This bug was filed against a series that is no longer supported and so is being marked as Won't Fix. If this issue still exists in a supported series, please file a new bug.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Changed in linux (Ubuntu):
status: Incomplete → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.