I was really impressed with osuse 11 because when I played with the livecd and then installed most everything I wanted worked.
I can’t say for certain that it was the last kernel upgrade, I’m using x86_64 btw, but now suspend or sleep doesn’t work and I know it did.
I can choose sleep from the shutdown menu but besides putting up a panel to log back in by it doesn’t actually suspend.
The other day I had closed the lid on this HP Pavilion dv6707us (specs here) and put it in it’s bag when I got home I realized it was still running and very warm too!
I have closed the lid previous to this last update and I know it had suspended and resumed ok then.
I have a ubuntu install on this laptop. In ubuntu it will actually suspend but getting it to successfully resume has been a toss of the dice. I don’t know how to troubleshoot this in suse or if there is anything I can do?
Thanks for the response Magic31. I did go through some of the info from that link. Unfortunately calling pm-suspend as root doesn’t do anything and s2ram -n outputs unknown machine. So I must have been wrong about it suspending before-the front lights acted like the laptop was in suspend the hard drive and fan stopped but I was delusional. Sorry it’s frustrating but it’s the nature of the beast. Thanks for your help.
If one of those options work you can create a file ‘config’ in /etc/pm/config.d, edit it and add ’ S2RAM_OPTS="-f -a 3" ’ (or other working switch you have found) as line to the file.
It will then apply that switch when suspending…
I appreciate your knowledge in this area.
s2ram -f -a 3 as root does indeed put the laptop into full suspend.
I created that file, as root, and edited with vim adding that line.
#created file & entry 7-11-08 with advice from opensuse forum
S2RAM_OPTS= “-f-a 3”
Spacing between symbols is sometimes a little confusing so I tried that line with and without a space after the “=” sign but closing the lid or selecting sleep does not activate suspend with either edit.
I just retried that and suspend does not work from selecting suspend or closing the lid. All that happens from those is the panel pops up requiring a password to get back to the desktop. The s2ram -f -a 3 command does work though and that’s something.
Power settings were the 1st thing I checked they’re ok.
The spacing was the problem closing the lid does suspend the laptop now.
Thank for the help on this!
I do have unfortunately another problem now. When I open the lid I get this:
An internal system error has occurred
A problem we were not expecting has occurred.
Please report this bug with the error description.
openSUSE-11.0-Oss: Valid metadata not found at specified URL(s)
And my network connection (I’m using madwifi) is no longer working. I can’t bring it back up without rebooting. I think there’s another file I have to add that module to? In debian it’s /etc/default/acpi-? I forget the exact filename but that doesn’t exsist in opensuse.
Sounds like you’re nearly there with your suspend issues. Regarding the ‘PackageKit’ error, you could try using the Zypper backend instead. From the opensuseupdater icon, you can select ‘Configure Applet’ to change this setting.
It is well known that some hardware can cause problems with power management. The solution to your madwifi wireless networking issue is explained here. You just need to add the script to your /etc/pm/power.d directory.
I had more time this morning and read through the info at the provided link-thanks again for that. I made sure the script is executable but there isn’t any change. Wireless still doesn’t work after resume. I did install madwifi from source but the page did show that method as one option, and I don’t see how that would matter for the purpose of unloading and loading the ath_pci module anyway. Everyone here has been very helpful and I appreciate that. Getting a laptop to work completely in linux is one PITA but it is interesting and I continue to learn more.
If anyone has anymore ideas on this I’m still ready to plunge into it. Thanks very much!
I want to thank everyone who responded. Opensuse is a great release with an excellent community too.
I think using linux on laptops is quite a bit more complicated than running on a desktop. I am fairly hardware savy having built over half dozen computers and have used linux for over 8 years.
IMO configuring a laptop is too fussy and I realize most of the fault for that goes to the hardware.
Opensuse almost got this laptop usable and that’s saying a lot for opensuse development. I’m defiantely selling this laptop and if I do get another pc laptop (I’m back using a mac for now-great battery life with them) I will probably only consider intel cpus and wireless cards. Carry on opensuse-you rock!
No one seemed to have any answers to this-I tried at linuxquestions which is a great place to ask questions too.
What I did as a sort of last resort was to place that script in the two other directories in /etc/pm/ (config.d & sleep.d) and now it works YAY!
That script probably only needs to be in either sleep.d (my guess) or config.d but since nothing seems to be harmed I’ll leave it the way it is.
I am using opensuse 11.0 x86_64 so if anyone else has this problem try using those directories.
Sorry, I hadn’t understood you still had a question about this!
You are right about needing to put the script for wireless in sleep.d.
The config.d folder is to place s2ram/pm override options and the sleep.d is for extra ‘hook’ scripts (like stopping/starting services and/or unloading drivers).
Have another close look at what the pm-utils says about this : Pm-utils - openSUSE Now that you’ve done some configuring it will probably hit home
Is suspend now working as it should? If you don’t mind you can post the contents of the files you’ve put in config.d & sleep.d.
We could have some ‘tuning’ suggestions to optimize sleep/wakeup
The post and link provided by deano_ferrari said the ath_pci unloading/loading script should be placed in power.d. That was what the opensuse guide at the link stated too. All I have placed in any of those directories is that script. Suspend/resume seems to work but today when I opened the lid I couldn’t use the mouse or keyboard and had to do a hard reboot.
Hmmm… or they changed it or we are not looking at the same page as I’m seeing sleep.d being referenced there (on the Atheros madwifi - openSUSE page). Oh well… you have it working, so that is good
As for the mouse/keyboard. There is a glitch that has been noticed with usb input devices when resuming from standby (openSUSE 11.0), starting from the bottom of the file check or search the /var/log/messages for errors on usb.
Not sure if there is a bug open for it but ifo so I’ll post it here. In the meantime I’m curious to know I you have any errors in your /var/log/messages file related to usb.
As a workaround to be able to reboot in a nice manner, try plugging in a USB mouse and do the shutdown that way, or in the power management set the power button to do a shutdown (instead of prompting)
Magic31, Yeah they did change it there recently too since I went back to that page a day ago. Well now I know for sure that it needs to be in sleep.d-would be nice if they mentioned corrections/edits.
Anyway I did cat messages | grep usb in var/log but it’s still a large file. Is there a way to do attachments here?
For the date the freeze happened I see this:
Jul 22 13:43:58 linux-9e9z kernel: last sysfs file: /sys/devices/pci0000:00/0000:00:02.0/usb1/1-4/1-4:1.0/input/input11/capabilities/sw
Jul 22 13:43:58 linux-9e9z kernel: Modules linked in: ath_pci ip6t_LOG xt_tcpudp xt_pkttype ipt_LOG xt_limit binfmt_misc af_packet snd_pcm_oss snd_mixer_oss snd_seq snd_seq_device ip6t_REJECT nf_conntrack_ipv6 ipt_REJECT xt_state iptable_mangle iptable_nat nf_nat iptable_filter ip6table_mangle nf_conntrack_netbios_ns nf_conntrack_ipv4 nf_conntrack ip_tables cpufreq_conservative cpufreq_userspace ip6table_filter cpufreq_powersave ip6_tables powernow_k8 x_tables ipv6 fuse loop dm_mod sr_mod cdrom amd74xx ide_pci_generic ide_core pata_acpi snd_hda_intel uvcvideo snd_pcm ath5k snd_timer compat_ioctl32 video snd_page_alloc mac80211 pata_amd snd_hwdep sdhci nvidia(P) videodev snd ohci1394 v4l1_compat output wlan_scan_sta k8temp joydev sg i2c_core ieee1394 forcedeth mmc_core wmi ricoh_mmc battery ac button soundcore cfg80211 ath_rate_sample ata_generic wlan ath_hal(P) usbhid hid ff_memless sd_mod ehci_hcd ohci_hcd usbcore edd ahci libata scsi_mod dock ext3 mbcache jbd fan thermal processor [last unloaded: ath_pci]
Jul 22 15:44:30 linux-9e9z kernel: usb 1-4: USB disconnect, address 3
Jul 22 16:53:40 linux-9e9z kernel: usb 1-4: new low speed USB device using ohci_hcd and address 4
Jul 22 16:53:40 linux-9e9z kernel: usb 1-4: configuration #1 chosen from 1 choice
Jul 22 16:53:40 linux-9e9z kernel: input: Logitech USB Receiver as /devices/pci0000:00/0000:00:02.0/usb1/1-4/1-4:1.0/input/input10
Jul 22 16:53:40 linux-9e9z kernel: input,hidraw0: USB HID v1.11 Mouse [Logitech USB Receiver] on usb-0000:00:02.0-4
Jul 22 16:53:40 linux-9e9z kernel: hiddev96hidraw1: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:00:02.0-4
Jul 22 16:53:40 linux-9e9z kernel: usb 1-4: New USB device found, idVendor=046d, idProduct=c51b
Jul 22 16:53:40 linux-9e9z kernel: usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Jul 22 16:53:40 linux-9e9z kernel: usb 1-4: Product: USB Receiver
Jul 22 16:53:40 linux-9e9z kernel: usb 1-4: Manufacturer: Logitech
Jul 22 19:28:53 linux-9e9z kernel: usb 1-4: USB disconnect, address 4
Jul 22 22:05:37 linux-9e9z kernel: usb 1-4: new low speed USB device using ohci_hcd and address 5
Jul 22 22:05:37 linux-9e9z kernel: usb 1-4: configuration #1 chosen from 1 choice
Jul 22 22:05:37 linux-9e9z kernel: input: Logitech USB Receiver as /devices/pci0000:00/0000:00:02.0/usb1/1-4/1-4:1.0/input/input11
Jul 22 22:05:37 linux-9e9z kernel: input,hidraw0: USB HID v1.11 Mouse [Logitech USB Receiver] on usb-0000:00:02.0-4
Jul 22 22:05:37 linux-9e9z kernel: hiddev96hidraw1: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:00:02.0-4
Jul 22 22:05:37 linux-9e9z kernel: usb 1-4: New USB device found, idVendor=046d, idProduct=c51b
Jul 22 22:05:37 linux-9e9z kernel: usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Jul 22 22:05:37 linux-9e9z kernel: usb 1-4: Product: USB Receiver
Jul 22 22:05:37 linux-9e9z kernel: usb 1-4: Manufacturer: Logitech
Jul 23 08:46:49 linux-9e9z kernel: Restarting tasks … <6>usb 1-4: USB disconnect, address 5
Jul 23 08:46:49 linux-9e9z kernel: usb 1-4: new low speed USB device using ohci_hcd and address 6
Jul 23 08:46:49 linux-9e9z kernel: usb 1-4: configuration #1 chosen from 1 choice
Jul 23 08:46:49 linux-9e9z kernel: input: Logitech USB Receiver as /devices/pci0000:00/0000:00:02.0/usb1/1-4/1-4:1.0/input/input12
Jul 23 08:46:49 linux-9e9z kernel: input,hidraw0: USB HID v1.11 Mouse [Logitech USB Receiver] on usb-0000:00:02.0-4
Jul 23 08:46:49 linux-9e9z kernel: hiddev96hidraw1: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:00:02.0-4
Jul 23 08:46:49 linux-9e9z kernel: usb 1-4: New USB device found, idVendor=046d, idProduct=c51b
Jul 23 08:46:49 linux-9e9z kernel: usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Jul 23 08:46:49 linux-9e9z kernel: usb 1-4: Product: USB Receiver
Jul 23 08:46:49 linux-9e9z kernel: usb 1-4: Manufacturer: Logitech
I don’t know if any of that is useful though. Plus Today when I open the lid (from suspend/sleep) it came back ok. So I guess it’s not a consistent problem. Thanks again!
I think I’m back to believing that in linux resume and wireless is too fussy. It’s also aggravating I am on the road today with this laptop which I though was working, but when I opened it up just now it resumed ok but wireless was not working. Finally (after a few minutes) the network I wanted to connect to was found but it wanted a passphrase-for an open network. I had to reboot and then it worked. If you have to always reboot to get services working-something is wrong.
Normally it’s a question of finding the correct services to stop and start… If you’re system is not on the whitelist it can get tricky to get a good suspend/resume going, but many times you will have success. Don’t get too stressed out with it and try when you have time… if not, booting normally should be quick enough as a ‘workaround’.
With openSUSE 11.0 my laptop suspends without extra tuning, but this was the contents of the file that I had placed in the sleep.d for 10.3
case $1 in
service network stop
modprobe -r ipw3945
service network stop
modprobe -r ipw3945
echo "oh, suspend to disk is over, we are resuming..."
service network start
service network start
*) echo "somebody is calling me totally wrong."
ipw3945 is my wifi driver that needed to be unloaded and reloaded along with the network service. Notice the module loading before starting the network service and visa versa.
The message I meant to look for would look something like this:
hub 5-0:1.0: unable to enumerate USB device on port xx
…but I’m not seeing that in the logs.
You could compare a copy of /var/log/messages and /var/log/pm-suspend from a good resume against one after lossing mouse and keyboard.
Thanks again Magic31, I know the madwifi module is ath_pci and I could certainly edit the script you provided and insert that module but you’re using 10.3 so I don’t know if that would work. Also I have the other script which seems similar. Maybe I should remove the script from /etc/pm/power.d & config.d? I will try doing that since the guide now says sleep.d is where it belongs.
As I said it’s not a consistent problem either-since I was able to resume and have wireless working at times.