no suspend/sleep now

[rad1er]

Originally Posted by deano_ferrari

Hi rad1er

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.

Hopefully, that will do the trick for you.

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!

[rad1er]

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!

[rad1er]

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.

[Magic31]

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

Cheers,
Wj

[rad1er]

Originally Posted by Magic31

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

Cheers,
Wj

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.

[Magic31]

Originally Posted by rad1er

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)

[rad1er]

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
linux-9e9z:/var/log #

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!

[rad1er]

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.

[Magic31]

Originally Posted by rad1er

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

#!/bin/bash
case $1 in
    hibernate)
        service network stop
        modprobe -r ipw3945
        sleep 1
        ;;
    suspend)
        service network stop
        modprobe -r ipw3945
        sleep 1
        ;;
    thaw)
        echo "oh, suspend to disk is over, we are resuming..."
        sleep 1
        modprobe ipw3945
        sleep 2
        service network start
        ;;
    resume)
        sleep 1
        modprobe ipw3945
        sleep 2
        service network start
        ;;
    *)  echo "somebody is calling me totally wrong."
        ;;
esac

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.

Wishing you luck,
Wj

[rad1er]

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.