Bugzilla – Bug 184660
network broken / down after suspend to disk and resume using traditional networking scheme
Last modified: 2007-12-29 15:20:30 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.
Patrick, could you please check whether $ ethtool <device> shows "Link detected: yes" after resume?
# 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
Was this run of ethtool _after_ resuming the system? Can you please attach the output of nm-tool after resuming, too?
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.
Does this work if you use the traditional networking scheme?
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.
Because Networkmanager works, this is not a kernel issue, but a script issue somewhere in the "traditional" network scripts. Reassigning...
timo: is this for you or zoz?
netcontrol -> zoz
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.
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.
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.
Patrick, can you provide the information requested by Christian in comment 12 so we can proceed with the bug?
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!
Ok, what's the status here?
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?
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.
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.
I suppose bug 342049 describe the issue I have now.