Bug 184660 - network broken / down after suspend to disk and resume using traditional networking scheme
Summary: network broken / down after suspend to disk and resume using traditional netw...
Status: RESOLVED NORESPONSE
Alias: None
Product: SUSE Linux 10.1
Classification: openSUSE
Component: Network (show other bugs)
Version: Final
Hardware: i386 SuSE Linux 10.1
: P5 - None : Normal with 5 votes (vote)
Target Milestone: ---
Assignee: Christian Zoz
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-06-13 21:00 UTC by Patrick Smart
Modified: 2007-12-29 15:20 UTC (History)
1 user (show)

See Also:
Found By: Customer
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
output of network diagnostic commands before and after suspend to disk (13.38 KB, text/plain)
2006-06-22 21:22 UTC, Patrick Smart
Details
output of network diagnostic commands before and after suspend to disk - v2 (2.69 KB, text/plain)
2006-10-09 22:18 UTC, Patrick Smart
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Patrick Smart 2006-06-13 21:00:04 UTC
When using the suspend to disk feature and then, of course restoring the system, the network is not functionning properly. running rcnetwork restart solves the issue.

Opened this bug following bug 159136 Comment #44.
Comment 1 Timo Hoenig 2006-06-14 09:56:35 UTC
Patrick, could you please check whether $ ethtool <device> shows "Link detected: yes" after resume?
Comment 2 Patrick Smart 2006-06-14 20:59:11 UTC
# ethtool eth0
Settings for eth0:
        Supported ports: [ MII ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
        Advertised auto-negotiation: Yes
        Speed: 100Mb/s
        Duplex: Full
        Port: MII
        PHYAD: 1
        Transceiver: external
        Auto-negotiation: on
        Supports Wake-on: g
        Wake-on: d
        Link detected: yes
Comment 3 Timo Hoenig 2006-06-15 14:52:19 UTC
Was this run of ethtool _after_ resuming the system?  Can you please attach the output of nm-tool after resuming, too?
Comment 4 Patrick Smart 2006-06-15 20:10:59 UTC
Yes, this was run after resuming, when no network connection is available.

# nm-tool
NetworkManager Tool
get_nm_state(): didn't get a reply from NetworkManager.
NetworkManager appears not to be running (could not get its state).

The latter doesn't have a different state when there is a network connection or not. I remember not having changed the network config when installing 10.1. This means that I didn't ask for the network manager to be used.
Comment 5 Michael Gross 2006-06-16 10:13:35 UTC
Does this work if you use the traditional networking scheme?
Comment 6 Patrick Smart 2006-06-16 21:28:08 UTC
I *was* using the traditional networking scheme with the problems described above.

But I just tried with the network manager enabled and this works just fine.
Comment 7 Greg Kroah-Hartman 2006-06-21 23:36:45 UTC
Because Networkmanager works, this is not a kernel issue, but a script issue
somewhere in the "traditional" network scripts.

Reassigning...
Comment 8 Martin Lasarsch 2006-06-22 09:58:19 UTC
timo: is this for you or zoz?
Comment 9 Timo Hoenig 2006-06-22 10:04:58 UTC
netcontrol -> zoz
Comment 10 Christian Zoz 2006-06-22 10:24:26 UTC
Please show me your network interface configuration files /etc/sysconfig/network/ifcfg-*.

Also please call
  ip a; ip r
  ps ax | grep -v "ifplugd\|dhcpcd"
before and after suspend and attach the output to this bug report.
Comment 11 Patrick Smart 2006-06-22 21:22:14 UTC
Created attachment 91253 [details]
output of network diagnostic commands before and after suspend to disk

OK, to perform this, I first went to yast and asked to have the traditional network system and then a rcnetwork restart since I was having bad connectivity.
Comment 12 Christian Zoz 2006-06-23 13:34:54 UTC
Silly me. WTF did i ask you for? The '-v' is wrong in the grep command. Just omit it. I don't know why i wrote it there.
What i wanted to check if all needed daemons are running. ifplugd must not run in your case (STARTMODE=auto) and i guess that dhcpcd runs. At least the interface seems to be set up properly.

Now i need to know more details about the network device. Please show me the output of
  hwinfo --netcard

This is very probably a driver problem. It does not happen with NetworkManager because NM does explicitely suspend and resume the interface. For Netcontrol there is another way to solve auch a problem:
powersaved unloads driver modules in such cases. Have a look in
  /etc/sysconfig/powersave/sleep:UNLOAD_MODULES_BEFORE_*
Note if you want to add your driver module there you have to add also all the modules from the "## Default:" line above. The default will only be used if the variable is empty.
Please checks if it helps if you add your driver module there.
Comment 13 Stefan Behlert 2006-09-14 10:19:31 UTC
Patrick, can you provide the information requested by Christian in comment 12 so we can proceed with the bug?
Comment 14 Patrick Smart 2006-10-09 22:18:39 UTC
Created attachment 101070 [details]
output of network diagnostic commands before and after suspend to disk - v2

Sorry for the delay... I'm happy that you're following that up!
Comment 16 Stefan Behlert 2007-08-02 11:58:51 UTC
Ok, what's the status here?
Comment 17 Patrick Smart 2007-08-02 13:04:33 UTC
If this question is addressed to me:

- I now use the traditional networking scheme because the managed one was bothering me somehow (don't remember precisely but I think I was just losing the network).
- I don't suspend to disk because there is an issue with the legacy nvidia driver I have to use.

Well, if there are some things to test, I am willing to do so but since I was the last one to reply to a question, I don't think I have much to add here until asked  to do so.

Patrick

PS: where is the comment #15?
Comment 18 Christian Zoz 2007-11-27 10:12:31 UTC
Hello Patrick,

comment 15 is restricted to internal. No technical info inside this comment.

This bug was filed against 10.1. Do you still use 10.1? If not, did this also happen with newer versions? (when you were using another gfx driver)

The attachments show that the interface is set up properly after suspend. Therfore i guess that the driver does not survive the suspend.

If you still want to follow up, i would need two things:
- hwinfo --netcard
- a test if adding the module name to this variable helps:
  /etc/sysconfig/powersave/sleep:UNLOAD_MODULES_BEFORE_*
  If you do that please reread comment 12

Alternatively we close this as RESOLVED INVALID, because this seems to be a rare problem. That's also the reason why it took so long to reply, there were always more urgent problems.
Comment 19 Patrick Smart 2007-12-29 14:57:01 UTC
I am now using 10.3. It now works with the traditional scheme and the default config. It doesn't work for the network manager at all. I suppose this should be in the scope of another bug.
Comment 20 Patrick Smart 2007-12-29 15:20:30 UTC
I suppose bug 342049 describe the issue I have now.