[Bug 389643] New: suspend to disk blocks dsl
https://bugzilla.novell.com/show_bug.cgi?id=389643 Summary: suspend to disk blocks dsl Product: openSUSE 10.3 Version: Final Platform: i586 OS/Version: openSUSE 10.3 Status: NEW Severity: Major Priority: P5 - None Component: Kernel AssignedTo: bnc-team-screening@forge.provo.novell.com ReportedBy: mehl@hrz1.hrz.tu-darmstadt.de QAContact: kernel-maintainers@forge.provo.novell.com Found By: Customer System: opensuse 10.3 motherboard MSI K8N Neo2 Platinum with AMD Athlon 64 dsl by cable: modem Motorola SBV5121E router D-Link DI-524 After suspend to disk dsl worked formerly with opensuse 10.2 when having a hook for thaw with network stop network start After suspend to disk dsl works now with Windows XP. This should show that there is _no_ hardware problem. But .. with opensuses 10.3 there is no dsl after awakening after suspend to disk. This is most annoying as the time for complete shutdown and booting far exceeds the time for suspension and awakening. In addition there are programs like ktouch which have no pause feature so that after a boot one must start all over again. A similar problem was treated in bugzilla 342049, but with no relevance for my problem. When the system is able to open a dsl connection when booting it _must_ be possible to have it behave likewise after awakening by using a prope script which I am unfortunately utterly unable to write myself. When this problem cannot be solved for 10.2 it is expected that at least the upcoming 11.0 will not show this bug any more. A. Mehl -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=389643
Robert Vojcik
https://bugzilla.novell.com/show_bug.cgi?id=389643
User seife@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=389643#c1
Stefan Seyfried
https://bugzilla.novell.com/show_bug.cgi?id=389643
User pavel@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=389643#c2
--- Comment #2 from Pavel Machek
https://bugzilla.novell.com/show_bug.cgi?id=389643
User pavel@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=389643#c3
Pavel Machek
https://bugzilla.novell.com/show_bug.cgi?id=389643
Pavel Machek
https://bugzilla.novell.com/show_bug.cgi?id=389643
User mehl@hrz1.hrz.tu-darmstadt.de added comment
https://bugzilla.novell.com/show_bug.cgi?id=389643#c4
--- Comment #4 from Albrecht Mehl
does it help if you unload your network card driver before suspend and reload it after resume? Which network card is used anyway?
Did you already try 11.0 beta3 or do you just assume that the bug is still present in 11.0?
1. I do not use a network card as networking is onboard the MSI motherboard cited. 2. I do not know _exactly_ what you mean by 'unload your network card driver' - please forgive my ignorance. All I did as this was suggested to me was to give the commands networkmanager stop networkmanager start from the console after noticing that dsl failed after resuming. 3. I did not try 11.0 beta 3. I am not assume that the bug is still present there, I just wanted to alert the experts to this problem hoping that someone would get a hand on it - being quite a novice having enough trouble with 10.3 I do not want to have two os's on my machine at the same time. A. Mehl -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=389643
User mehl@hrz1.hrz.tu-darmstadt.de added comment
https://bugzilla.novell.com/show_bug.cgi?id=389643#c5
--- Comment #5 from Albrecht Mehl
does it help if you unload your network card driver before suspend and reload it after resume? Which network card is used anyway?
Did you already try 11.0 beta3 or do you just assume that the bug is still present in 11.0?
1. I do not use a network card as networking is onboard the MSI motherboard cited. 2. I do not know _exactly_ what you mean by 'unload your network card driver' - please forgive my ignorance. All I did as this was suggested to me was to give the commands networkmanager stop networkmanager start from the console after noticing that dsl failed after resuming. 3. I did not try 11.0 beta 3. I am not assume that the bug is still present there, I just wanted to alert the experts to this problem hoping that someone would get a hand on it - being quite a novice having enough trouble with 10.3 I do not want to have two os's on my machine at the same time. (In reply to comment #2 from Pavel Machek)
How is the modem connected to the machine? Over ethernet?
As described in my first posting there is a cable modem and then a router which in turn is connected to the motherboards' input. I assume that the routers' output is ethernet. (In reply to comment #3 from Pavel Machek)
Can you get dsl back to work by network stop/start?
Unfortunately _not_ In finishing I would like to thank for all comments and the time taken for them. A. Mehl -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=389643
User pavel@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=389643#c6
Pavel Machek
https://bugzilla.novell.com/show_bug.cgi?id=389643
Greg Kroah-Hartman
https://bugzilla.novell.com/show_bug.cgi?id=389643
User mehl@hrz1.hrz.tu-darmstadt.de added comment
https://bugzilla.novell.com/show_bug.cgi?id=389643#c7
--- Comment #7 from Albrecht Mehl
2. I'd like you to rmmod/insmod the driver responsible for your ethernet card. (Plus tell us a name of that driver).
3. Trying -beta is not really that hard...
For you as an expert most certainly not. But for me this causes a problem as fearful people like me start thinking 'Will this interfere somehow with the os already installed? I have already a problem which I dared posing to you; will this problem be worthened by installing 11.0?' This kind of thinking will appear to be ridiculous to you .. but it exists and without your reassuring me I wont try. The name of the driver is forcedeth. In case this information could be useful: it is active, modprobe yes, modules modprobe forcedeth Speaking of maybe useful information. People trying to help me asked me for the output of certain commands. Perhaps this information helps you as well. In the output '198.168.0.1' is the IP-address of the router connecting the modem to the computers mainboard. Of course the ???? have been added by me to render the consoles output more readable. In yast2 no provider is present - the existing one has been removed prior to the outputs shown below. The connecting mode of the networkcard - actually there is none - is ifup, _not_ knetworkmanager. Part 1 of the output comes in the net present state, i.e. after reboot. Part 2 comes in the no net state, i.e. after awakening after suspend to disk. 1. Net present, ifup, no provider XXXXXXXXXXXXXXXXXXXXXXXXXXX 1.a ping -c4 193.99.144.85 1.b ping -c4 192.168.0.1 1.c route 1.d cat /etc/resolv.conf ================================================ Passwort: zuse103:~ # ping -c4 193.99.144.85 PING 193.99.144.85 (193.99.144.85) 56(84) bytes of data. 64 bytes from 193.99.144.85: icmp_seq=1 ttl=250 time=7.39 ms 64 bytes from 193.99.144.85: icmp_seq=2 ttl=250 time=7.00 ms 64 bytes from 193.99.144.85: icmp_seq=3 ttl=250 time=8.23 ms 64 bytes from 193.99.144.85: icmp_seq=4 ttl=250 time=8.55 ms --- 193.99.144.85 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 2999ms rtt min/avg/max/mdev = 7.009/7.796/8.551/0.624 ms ?????????????????????????????????????????? zuse103:~ # ping -c4 192.168.0.1 PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data. 64 bytes from 192.168.0.1: icmp_seq=1 ttl=64 time=0.374 ms 64 bytes from 192.168.0.1: icmp_seq=2 ttl=64 time=0.377 ms 64 bytes from 192.168.0.1: icmp_seq=3 ttl=64 time=0.381 ms 64 bytes from 192.168.0.1: icmp_seq=4 ttl=64 time=0.382 ms --- 192.168.0.1 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3003ms rtt min/avg/max/mdev = 0.374/0.378/0.382/0.019 ms ????????????????????????????????????????????????? zuse103:~ # route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.0.0 * 255.255.255.0 U 0 0 0 eth0 link-local * 255.255.0.0 U 0 0 0 eth0 loopback * 255.0.0.0 U 0 0 0 lo default 192.168.0.1 0.0.0.0 UG 0 0 0 eth0 ???????????????????????????????????????????????? zuse103:~ # cat /etc/resolv.conf ### BEGIN INFO # # Modified_by: dhcpcd # Backup: /etc/resolv.conf.saved.by.dhcpcd.eth0 # Process: dhcpcd # Process_id: 3086 # Script: /sbin/modify_resolvconf # Saveto: # Info: This is a temporary resolv.conf created by service dhcpcd. # The previous file has been saved and will be restored later. # # If you don't like your resolv.conf to be changed, you # can set MODIFY_{RESOLV,NAMED}_CONF_DYNAMICALLY=no. This # variables are placed in /etc/sysconfig/network/config. # # You can also configure service dhcpcd not to modify it. # # If you don't like dhcpcd to change your nameserver # settings # then either set DHCLIENT_MODIFY_RESOLV_CONF=no # in /etc/sysconfig/network/dhcp, or # set MODIFY_RESOLV_CONF_DYNAMICALLY=no in # /etc/sysconfig/network/config or (manually) use dhcpcd # with -R. If you only want to keep your searchlist, set # DHCLIENT_KEEP_SEARCHLIST=yes in /etc/sysconfig/network/dhcp or # (manually) use the -K option. # ### END INFO nameserver 192.168.0.1 zuse103:~ # ================================================================ ================================================================ ================================================================ 2. After awakening, no net, ifup, no provider XXXXXXXXXXXXXXXXXXXXXXXXXXX 2.a ping -c4 193.99.144.85 2.b ping -c4 192.168.0.1 2.c route 2.d cat /etc/resolv.conf alle vier in _einer_ Ausgabe der Konsole: ============================================== Passwort: zuse103:~ # ping -c4 193.99.144.85 PING 193.99.144.85 (193.99.144.85) 56(84) bytes of data. From 192.168.0.101: icmp_seq=1 Destination Host Unreachable From 192.168.0.101 icmp_seq=1 Destination Host Unreachable From 192.168.0.101 icmp_seq=2 Destination Host Unreachable From 192.168.0.101 icmp_seq=3 Destination Host Unreachable --- 193.99.144.85 ping statistics --- 3 packets transmitted, 0 received, +4 errors, 100% packet loss, time 2011ms , pipe 3 ??????????????????????????????????????????????????? zuse103:~ # ping -c4 192.168.0.1 PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data. From 192.168.0.101 icmp_seq=3 Destination Host Unreachable From 192.168.0.101 icmp_seq=4 Destination Host Unreachable --- 192.168.0.1 ping statistics --- 4 packets transmitted, 0 received, +2 errors, 100% packet loss, time 3021ms ?????????????????????????????????????????????????????????? zuse103:~ # route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.0.0 * 255.255.255.0 U 0 0 0 eth0 link-local * 255.255.0.0 U 0 0 0 eth0 loopback * 255.0.0.0 U 0 0 0 lo default 192.168.0.1 0.0.0.0 UG 0 0 0 eth0 ????????????????????????????????????????????????????? zuse103:~ # cat /etc/resolv.conf ### BEGIN INFO # # Modified_by: dhcpcd # Backup: /etc/resolv.conf.saved.by.dhcpcd.eth0 # Process: dhcpcd # Process_id: 6705 # Script: /sbin/modify_resolvconf # Saveto: # Info: This is a temporary resolv.conf created by service dhcpcd. # The previous file has been saved and will be restored later. # # If you don't like your resolv.conf to be changed, you # can set MODIFY_{RESOLV,NAMED}_CONF_DYNAMICALLY=no. This # variables are placed in /etc/sysconfig/network/config. # # You can also configure service dhcpcd not to modify it. # # If you don't like dhcpcd to change your nameserver # settings # then either set DHCLIENT_MODIFY_RESOLV_CONF=no # in /etc/sysconfig/network/dhcp, or # set MODIFY_RESOLV_CONF_DYNAMICALLY=no in # /etc/sysconfig/network/config or (manually) use dhcpcd # with -R. If you only want to keep your searchlist, set # DHCLIENT_KEEP_SEARCHLIST=yes in /etc/sysconfig/network/dhcp or # (manually) use the -K option. # ### END INFO nameserver 192.168.0.1 zuse103:~ # ============================================= I hope transmitting so many data is not considered unseemly here. In addition I have an organisational question. This problem was posed to you when my email address was mehl@hrz1.hrz.tu-darmstadt.de In the mean time this has been changed to mehl@freunde.tu-darmstadt.de The old account still exists but will be cleared very soon, probably still during the 'lifetime' of my problem. Until now I have not been able to find a place in bugzilla where I can change just my email address without jeopardizing the connection between bugzilla and myself for this problem so that there would be no more alerts of incoming comments. If there is a way indeed to solve this dilemma I would be very glad to get _detailed_ instructions. In concluding I would like to thank all of you experts again. A. Mehl -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=389643
User seife@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=389643#c8
--- Comment #8 from Stefan Seyfried
https://bugzilla.novell.com/show_bug.cgi?id=389643
User mehl@hrz1.hrz.tu-darmstadt.de added comment
https://bugzilla.novell.com/show_bug.cgi?id=389643#c9
--- Comment #9 from Albrecht Mehl
Does it help if you create a file "/etc/pm/config.d/config" with the content
SUSPEND_MODULES="forcedeth"
(just this one line)? this will unload the module before suspend and reload it after resume. I am not sure if this will work with DSL setups, but it is worth a try.
Hurrah, it does! My problem discussed under several titles in vain in news group is solved at last. I could end here with a Thank you .. but being very grateful I would like to continue. Future user of opensuse 11.0 should be spared this trouble. So I strongly suggest that someone has a look at the beta version to find out whether it might be necessary to add a line similar to the one above to 11.0 so that this problem would not show up at all.
How does your DSL setup look like anyway? Do you have a DSL router (from your "route" output it looks like you have) and just a network configured in YaST or do you use a "dumb" DSL-modem, with the pppoe stuff running on your machine and configured with the YaST DSL module?
The output of "ps aux|grep ppp" when the network is running will probably help us determine that.
Would it help you to get these informations for the work on 11.0 - if this is taken up at all -? There is a point only indirectly related to the problem just solved. When discussing in a news group I was blamed for using the term 'dsl' even though there was no dsl involved as I learned myself from the experts in the group. I then replied that opensuse itself uses this term in yast2, network hardware, dsl(!), overview of the dsl(!)-configuration [translated from German, maybe somewhat wrongly phrased] A guy knowing much more about linux than myself corrected me and wrote that using 'dsl' at this place is wrong and misleading. This rather should read 'alle Breitbandzugänge, die eine Authentifizierung erfordern' which means approximately 'All broad band connections requesting an authenticication'. Maybe this is a bit long and cannot be used as is .. but at least in the comments at the left hand side there should be a clear hint in this direction. I think it would be good to have this point copied and transmitted to the ones actually emploied with the phrasing the window texts. You now much better than I do possible addressees, so maybe you could pass this suggestion along. And then I would be thankful if someone could answer my question at the bottom of my comment#7: now that the problem is solved how can I 'kill' myself as the identity 'mehl@hrz1.hrz.tu-darmstadt.de' is no longer needed? I would like to register using the same user name 'AlbrechtMehl', but cannot find a place on the bugzilla pages where to either delete a person or change his email address. Finally: this has been my first contact with opensuse bugzilla. Will the status of this problem be changed by an 'official' or am I supposed to do something? If so, what? Even so the problem is solved I would still like to get comments to the above. _Very_ grateful A. Mehl -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=389643
User seife@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=389643#c10
Stefan Seyfried
(In reply to comment #8 from Stefan Seyfried)
Does it help if you create a file "/etc/pm/config.d/config" with the content
SUSPEND_MODULES="forcedeth"
(just this one line)? this will unload the module before suspend and reload it after resume. I am not sure if this will work with DSL setups, but it is worth a try.
Hurrah, it does! My problem discussed under several titles in vain in news group is solved at last.
Good. So the forcedeth module has no decent suspend / resume support, it seems.
I could end here with a Thank you .. but being very grateful I would like to continue.
Future user of opensuse 11.0 should be spared this trouble. So I strongly suggest that someone has a look at the beta version to find out whether it might be necessary to add a line similar to the one above to 11.0 so that this problem would not show up at all.
Well, there is quite some work being accomplished over the last few kernelversions wrt. suspend and resume, so it might well be that it just works in 11.0.
The output of "ps aux|grep ppp" when the network is running will probably help us determine that.
Would it help you to get these informations for the work on 11.0 - if this is taken up at all -?
It's not really necessary, i think i understood your configuration.
There is a point only indirectly related to the problem just solved. When discussing in a news group I was blamed for using the term 'dsl' even though there was no dsl involved as I learned myself from the experts in the group. I then replied that opensuse itself uses this term in
yast2, network hardware, dsl(!), overview of the dsl(!)-configuration [translated from German, maybe somewhat wrongly phrased]
But you probably did not need to use this DSL configuration frontend at all, since you only need to configure DHCP on your machine and everything else is handled by your DSL router (the small box you got from your phone company)
A guy knowing much more about linux than myself corrected me and wrote that using 'dsl' at this place is wrong and misleading. This rather should read 'alle Breitbandzugänge, die eine Authentifizierung erfordern' which means approximately 'All broad band connections requesting an authenticication'. Maybe this is a bit long and cannot be used as is .. but at least in the comments at the left hand side there should be a clear hint in this direction.
Well, yes. But it does not matter, since your machine probably does not even need to know how you are connected to the internet - since everything is handled by your router.
And then I would be thankful if someone could answer my question at the bottom of my comment#7: now that the problem is solved how can I 'kill' myself as the identity 'mehl@hrz1.hrz.tu-darmstadt.de' is no longer needed? I would like to register using the same user name 'AlbrechtMehl', but cannot find a place on the bugzilla pages where to either delete a person or change his email address.
The email can be changed in the novell customer center, www.novell.com => Menü => Customer center => Profil Bearbeiten => Anmeldeprofil
Finally: this has been my first contact with opensuse bugzilla. Will the status of this problem be changed by an 'official' or am I supposed to do something? If so, what?
Yes, i will now change the status to "worksforme". It is not really "fixed", but a workaround exists, and i have sufficient hints to be confident that it will just work in 11.0. If you find out that you still need this workarount in 11.0, feel free to reopen this bug. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=389643
User pavel@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=389643#c11
--- Comment #11 from Pavel Machek
participants (1)
-
bugzilla_noreply@novell.com