Kernel 2.6.24-17 - broken resume from suspend to RAM

I think I'm getting this, too. Since the kernel upgrade, resume from suspend results in a blank screen. Restarting X doesn't work. I have to power off.

Running on Lenovo 3000 N100.

After some more investigation it appeared that the machine resumes but it takes ABSURDLY long time (anywhere from 90sec to 8 minutes). There are some ACPI errors in dmesg - see the attachment for a dmesg log after a single STR-Resume.

Same here. I've even tried dropping the nvidia driver so I can say I've tried it with a non-tainted kernel.

I have tried disabling nvidia driver, too, as well as unloading some acpi-related modules and removing cpufrequtils - to no avail. It just hangs for ages in the same code fragment (see dmesg.resumed, the "resume" part)

I guess I can confim this for my last-gen iBook G4. Also with linux-2.6.24-17 (Hardy).

I put the machine to sleep which works just fine. After that I wake it up and the screen turns on again. The text on it is a log line reading "drm_sysfs_suspend". Nothing more.

The machine does not respond to ping or ssh afterwards, neither directly after the wake-up nor 10 or 28 minutes later. There is some disk activity during the whole time span, though.

Another issue is that the machine again wakes up by pressing the touchpad button, which is a regression. Problem here is that the closed lid presses the button when put in a tight bag. This would cause the machine to return from sleep, which is clearly not intended here.

The same problem occurs on my IBM T40 type 2373
"drm_sysfs_suspend"
Linux 2.6.24-16-generic (Hardy)

here too on a Dell Latitude D820, nvidia.

I have had the same problems on a Toshiba L30 10V.

Resume from suspend works perfectly with a vanilla 2.6.24.3, I've tried various different kernel options on the Ubuntu kernel source to no avail.
I believe the problem lies with one of the kernel patches applied by the Ubuntu team.

This is quite a serious issue and there is a thread on the forums about it:
http://ubuntuforums.org/showthread.php?p=4970453#post4970453

I can confirm on my machine, which has the following specs:

AMD 64 X2 5600+ (OC'ed to 3.2 GHz)
Asus M2N-E nForce 570 Ultra
4GB Corsair XMS DDR2 (800Mhz)
160 GB Western Digital Caviar
e-VGA GeForce 8800 GTS 512
Acer AL2216W LCD
Sound Blaster Audigy SE
Logitech X-540 5.1

I can confirm this as well on toshiba laptop l25-s119
not sure of mobo,
radeon xpress 200m video
atheros wifi card
ac97 audio
realtek 8139 NIC
ati ixp sb400 usb controller

I've tried the Ubuntu PPA 2.6.25-1 kernel and that doesn't resume from suspend either. I'm now using 2.6.24-16 with no issues.

I can confirm this on my Samsung R20. Resume stopped working after the upgrade to 2.6.24-17. Works fine with 2.6.24-16.

Benq Joybook r42, resume broken in 2.6.24-17 too :(

I would just like to add that my resume from suspend doesnt work in 2.6.24-16-generic either, though im sure its the same bug.

Just changed from Gutsy to Hardy and had this problem on an hp tc4400. Fan comes on, screen black,
keyboard (including caps lock light) doesn't work. Have to power off. See no signs of any attempt to
resume in the logs. I changed back from 2.6.24-17 to old kernel (2.6.22-14) and it works.

I also have this problem as well. Resume was working fine in 2.6.24-16.

_Great_ job guys, you have pushed the new kernel to recommended updates but forgot to fix this bug.

Same problem here on two computers.

HP a1150y desktop PC GeForce 6600
Dell Inspiron 8200 laptop. GeForce2 Go

Suspend worked perfectly on the -16 kernel using the Nvidia driver on both computers. Totally broke after upgrading as described. Hard drive spins up and that's about it. The screen never turns back on. No other hardware seems to get woken up.

Confirming.
I have just marked Bug #234615 as duplicate of this bug.

I can confirm that on my FS Esprimo Mobile V5505. It has been doing that since Gutsy though. Typical resume time is between 60 and 120 seconds.

I believe suspend/resume problems have been exacerbated by the switch from FAIR_USER_SCHED to FAIR_CGROUP_SCHED. Please try the following:

echo "SUSPEND_MODULES=ehci-hcd" > /tmp/unload_modules
chmod +x /tmp/unload_modules
sudo mv /tmp/unload_modules /etc/pm/config.d

I can confirm this.

In my installation stopped working:
- switching on the CRT monitor when resuming from the suspend state
- resume from hibernate state (at some phase of restart the system freezes)
All these disfunctions applies to updated 2.6.24-17 kernel with updated nVidia-glx-new driver (updated on 26-May-2008)

With previous kernel 2.6.24-16 both resume processes work well.

My hardware & OS:
--------------------------
Asus mb P5KPL with Intel(R) Core(TM)2 Duo CPU E4500 @ 2.20GHz
Videocard GeForce 8500 GT
CRT Dell P1130
Ubuntu 8.04 (gnome) 64-bit desktop

I can confirm that setting ehci-hcd in unload_modules fixes resume with -17 kernel.

Please, accept this correction of my previous report:

I can confirm the same suspend - resume dysfunction.

I have tried Tim Gardner's setting ehci-hcd in unload_modules, but my PC did not suspend at all. Only screen became black (monitor was on) and HDD was writing intensively for a few minutes and then it lowered activity and nothing else happened. I had to reset the PC.

Hi,
sorry to report, that SUSPEND_MODULES=ehci-hcd or in my case uhci-hcd (USB 1) does not solve the problem on my machine with 2.6.24-17.
With -16 kernel both suspend methods remain functional.

I can confirm the issue on a Toshiba Satellite Pro A100 PSAAA.
Works fine using 2.6.24-16-generic.

Confirm on HP Compaq nc6400 (hardy x86)

Following instructions on https://wiki.ubuntu.com/DebuggingKernelSuspend, dmesg says:
[ 39.175813] Magic number: 0:968:196
[ 39.175815] hash matches /build/buildd/linux-2.6.24/drivers/base/power/main.c:112
[ 39.175846] hash matches device ttys8
[ 39.175852] hash matches device ttypb

Creating the unload_modules file did not work. The only thing that was different was that on resume the hard drive light was constantly on, but I couldn't hear any activity. Screen was still off, nothing responded to any input.

Tim's fix with unload_modules did not work for me either. There were no changes in the symptoms, and I could not check it with the -16 kernel because it would not boot complaining about a screwed NVidia driver (strange).

The unload_modules fix does not work for me either.
Booting the old 2.6.24-16 kernel makes suspend work again so it is very likely that the change from -16 to -17 causes the problem.

To me, the 2.6.24-16-powerpc was just as bad as the -17 but I downgraded to 2.6.22-14-powerpc and now suspend2ram works just fine. Hibernation sadly doen't work, though.

So with no changes other then the kernel and related modules, this seems like a kernel problem.

I can confirm this bug on a gigabyte g33m dsr2 motherboard with core 2 duo processor and ATI graphics card. I can also confirm that Tims fix caused the computer to reduce to just spinning the drive and and required a hard reboot to restore the system.

OK, my next theory is the that scheduler change from CONFIG_FAIR_USER_SCHED to CONFIG_FAIR_CGROUP_SCHED has broken suspend, so I've built a kernel with the original scheduler setting. Please test by loading and running the kernel/lum packages from http://people.ubuntu.com/~rtg/linux-2.6.24-19. For example (if you are running the 64 bit kernel):

wget http://people.ubuntu.com/~rtg/linux-2.6.24-19/linux-image-2.6.24-19-generic_2.6.24-19.33_amd64.deb
wget http://people.ubuntu.com/~rtg/linux-2.6.24-19/linux-ubuntu-modules-2.6.24-19-generic_2.6.24-19.26_amd64.deb
sudo dpkg -i linux-image-2.6.24-19-generic_2.6.24-19.33_amd64.deb linux-ubuntu-modules-2.6.24-19-generic_2.6.24-19.26_amd64.deb
sudo reboot

Tim, is it possible to add a 2.6.24-19 restricted modules package so as to test this with an NVIDIA graphics card?

Attempted 2.6.24-19 upgrade and rebooted to a white screen as there were no drivers for my ATI card. Went into graphics safe mode and attempted suspend. Computer suspended and I then pressed power to resume. It did exactly the same thing as with -17 except when I did hard reboot via the power supply it continued to just idle with the hard drive spinnig. I pulled all power for five minutes to see if I could get the RAM to clear. No luck, when power was resumed system went right back to just spinning the hard drive with a blank screen and no BIOS. I opened the case and pulled the CMOS jumper. That fixed it. System is back online. I uninstalled the -19 kernal cause it's scary.

The kernel you supplied does not fix the issue.
On my custom 2.6.24.3 kernel (in which suspend works) I have this option enabled also so I highly doubt that this is causing the suspend issue.

Attached is the config for my working vanilla kernel if it helps you.

I have just installed the "19" kernel from "Hardy proposed".
Initial testing on my Dell system has suspend working again. But now sound doesn't work....
...."No volume control GStreamer plugins and/or devices found"

Richard Coates [2008-06-12 10:45 -0000]:
> I have just installed the "19" kernel from "Hardy proposed".
> Initial testing on my Dell system has suspend working again. But now sound doesn't work....
> ...."No volume control GStreamer plugins and/or devices found"

Just to make sure, did you upgrade linux-ubuntu-modules and
linux-restricted-modules to 2.6.24-19, too?

I tried upgrading the kernel, linbux-ubuntu-modules and linux-restricted-modules to 2.6.24-19 from hardy-proposed on my Dell D630. Suspend still takes around 45s to resume. I haven't tried resume enough times to confirm that it no longer fails to resume.

Here you go, Martin. ifconfig and ifconfig -a are below; /etc/network/interfaces is attached. (Laptop is a Dell D600 by the way.) Good luck and thanks.

$ ifconfig
lo Link encap:Local Loopback
          inet addr:127.0.0.1 Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING MTU:16436 Metric:1
          RX packets:5829 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5829 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:235527 (230.0 KB) TX bytes:235527 (230.0 KB)

wlan0 Link encap:Ethernet HWaddr 00:90:4b:7b:27:6d
          UP BROADCAST MULTICAST MTU:1500 Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

wmaster0 Link encap:UNSPEC HWaddr 00-90-4B-7B-27-6D-00-00-00-00-00-00-00-00-00-00
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

ifconfig -a
eth0 Link encap:Ethernet HWaddr 00:0d:56:e6:f8:50
          BROADCAST MULTICAST MTU:1500 Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
          Interrupt:11

lo Link encap:Local Loopback
          inet addr:127.0.0.1 Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING MTU:16436 Metric:1
          RX packets:5829 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5829 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:235527 (230.0 KB) TX bytes:235527 (230.0 KB)

wlan0 Link encap:Ethernet HWaddr 00:90:4b:7b:27:6d
          UP BROADCAST MULTICAST MTU:1500 Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

wmaster0 Link encap:UNSPEC HWaddr 00-90-4B-7B-27-6D-00-00-00-00-00-00-00-00-00-00
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

Hi ddumanis,

ddumanis [2008-06-12 17:21 -0000]:
> $ ifconfig
> ifconfig -a

Those look good, the interfaces are present. So this is mainly a
network-manager bug. You said this worked fine with -16? Can you
reboot into -16 to verify this? It might have been broken by another
update in hardy.

> ** Attachment added: "etc/network/interfaces file"

Nothing there, so they should all be handled by network-manager.

@Richardg1952:

Look at your logs to see if you're not concerned by dhcp timeouts problems on network interface(s) if you've got them configured manually (or by a GUI != NM, using /etc/network/interfaces) and you're not using the first one.

If so, take a look at this:
https://bugs.launchpad.net/ubuntu/+source/pm-utils/+bug/236066

Yes, -16 works fine--in fact, I'm using it as my main kernel! I edited grub/menu.lst to default to -16 since I can't get network joy from any kernel later than that.

So, if it is a bug in network-manager, it has to do with how network-manager interacts with the various kernels--as I get good wired and wireless networking after suspend with kernel -16.

Any further info/fixes much appreciated.

Purged and reinstalled network-manager and network-manager-gnome (?). Now all is well, suspend works great with kernel -19. THANK YOU to Martin for correctly pegging this as a network-manager issue.

Or, more likely, an upgrade issue, since network-manager wasn't properly upgrade when going from gutsy to hardy... but that's a different story.

Now unsubscribing from this bug.

As expected, 2.6.24-19 solves the issue and related artefacts for me, too.

Thank you, John for discovering the core reason at #96. Two missing statements, and we are lost in space ;)

Guido

Subject machine: iMac Core2Duo circa October 2007. The details are in the attachment machine.log:

   uname -a
   lspci -v
   lsmod
   lshw
   xorg.conf

Albert: My fgrlx driver is enabled. It works fine. It might be this driver that is not letting me see the display after resume. Its hard to tell when you are flying blind.

In a nutshell, -12 suspends/resumes correctly with this iMac and every kernel after that does not work with this iMac, including the proposed -19.
I have no idea what is going wrong but I am quite willing to be a guinea pig [(:].

-Richard

Again, my current machine is an iMac Core2Duo circa October 2007.

I have resolved my suspend/resume issue thanks to the Hardy proposed -19 kernel, the EnvNG utility, and a web page (URL below).
For me, all 3 were necessary. Now, I can report that:

   -12 worked in the past (we all know that)
   -17 failed as reported by lots of folks
   -18 ditto
   -19 (proposed) fixes my iMac suspend/resume issues in -17 and -18

The kernel needed a cooperative video driver. Given that Intel-ish iMacs require the proprietary ATI driver (fglxr), there is no automatic way to know that your current driver will not work with newer kernels 100% (E.g. resume after suspend fails while everything else works). There are similar issues with nVidia.

Lesson learned:
1 - Run EnvyNG after every kernel upgrade *until* (hopefully) fglxr (or an equivalent) becomes part of the ubuntu family.
2 - Check ACPI configuration to see if a driver is stubborn and not letting go and force it to let go.

Packages needed envng-core, envng-gtk [or envng-qt]
Quote: "install the ATI or the NVIDIA driver EnvyNG is an application written in Python which will download the latest ATI or NVIDIA driver or the Legacy driver (for older cards) (according to the model of your card) from ATI or Nvidia's website and set it up for you handling dependencies (compilers, OpenGL,
etc.) which are required in order to build and use the driver."

ACPI configuration: I also needed the procedure at

   http://ubuntulinuxtipstricks.blogspot.com/2008/03/ati-nvidia-resume-good-news-bad-news.html

which, in a nutshell, contains a procedure to have ACPI to unload the ATI (fglxr) driver on suspend and reload on resume. Intel iMac users, do not set SAVE_VIDEO_PCI_STATE=true in /etc/default/acpi-support or you will probably be sorry [E.g. lock up].

One minor annoyance remains in ACPI. LOCK_SCREEN=false in /etc/default/acpi-support (or just commenting out the original LOCK_SCREEN=true) doesn't seem to work. It still locks the screen no matter what the LOCK_SCREEN condition is.

Sorry if I unnecessarily bothered any of the kernel folks. Our time is precious.

-Richard,
Dating myself: BSD 4.1 driver development on Vaxen 30 years ago just because it was fun

I looked in the gnome-power-manager section of gconf-editor again and what did I find?
The lock screen boxes were now all checked.
I unchecked the box for Suspend and then tried manual suspend.

Problem solved.

But why oh why do we have "lock screen" settings at different levels? It was challenging enough with one place to find by googling.
History, I guess.

The desktop folks need a better human interface to take care of both the desktop level and the ACPI level in a single operation to ensure consistency.

-Richard

Finally got this 2.6.24-19, and it works for me !

Suspend/Resume is good.

2.6.24-19 also fixes the Suspend/Resume regression for me. Thank you :)

On Tue, Jun 17, 2008 at 6:05 PM, Pirouette Cacahuète <email address hidden>
wrote:

> Finally got this 2.6.24-19, and it works for me !
>
> Suspend/Resume is good.
>
> --
> Kernel 2.6.24-17 - broken resume from suspend to RAM
> https://bugs.launchpad.net/bugs/226279
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Package is copied to hardy-updates. Thanks, all!

Unfortunately, 2.6.24-19 still does not work for me. Now what?

I applied all the available updates that came up in Update Manager today (including all the items related to kernel 2.6.24-19), rebooted, selected 2.6.24-19 kernel in GRUB, and logged into my user account in GNOME. Alas, I had no Wireless, as the system did not connect with my Atheros-based card.
I had to restart right away and go back to kernel 2.6.20-16, which is the last kernel that does both Wireless and Suspend/Hibernate (though the latter two are often very slow).

I would appreciate any suggestions on what to try next.

Synaptic shows that I have installed linux-restricted-modules-2.6.24-19-generic (installed version 2.6.24.13-19.42 from Hardy-updates, which is the only one showing as available).

But if I restart with 2.6.24-19-generic, then:

I have no Wireless as mentioned above. Also, clicking on Network Monitor applet on the GNOME panel shows only "SIOCGIFFLAGS error: No such device".

And System > Administration > Hardware Drivers shows only

"Support for Atheros 802.11 wireless LAN cards. Enabled [v]. Status: Not in Use."

Not even listed in Hardware Drivers under 2.6.24-19-generic:

- "Atheros Hardware Access Layer (HAL)" (which is listed and shown as "In use" when I restart with kernel 2.6.20-16-generic)

- "ATI accelerated graphics driver" (which is listed when I restart with kernel 2.6.20-16-generic, though I choose not to use this driver as it prevents Suspend/Hibernate, which is a different story, I think.)

Synaptic also shows that I have installed the following:

linux-image-2.6.24-19-generic (installed version 2.6.24-19.34 from Hardy-updates, which is the only one showing as available).

linux-ubuntu-modules-2.6.24-19-generic (installed version 2.6.24-19.28 from Hardy-proposed; also available but not installed: version 2.6.24-19.27 from Hardy-updates).

There are also two related Headers items installed, though I assume that they should not matter unless you are compiling anything, which I am not. Therefore, I am not bothering to list the details of these items here.

I would be happy to provide any additional info or try anything else that could fix this issue.

Ohb01 [2008-06-19 4:06 -0000]:
> I have no Wireless as mentioned above. Also, clicking on Network Monitor
> applet on the GNOME panel shows only "SIOCGIFFLAGS error: No such
> device".

Do you have the corresponding linux-ubuntu-modules and
linux-restricted-modules as well? Do you have "linux-generic"
installed? (That will pull in everything required)

Ohb01,

Can you please confirm whether it's 2.6.20-16, as opposed to 2.6.24-16, that you're using with success? 2.6.20-16 is a kernel from Ubuntu 7.04; this bug is about a suspend/resume regression introduced after the release of 8.04. If the only kernel you have working is the one from 7.04, then you should definitely open a new bug report since the issues are unlikely to be related.

I fixed wifi on an Acer laptop with madwifi drivers.
try madwifi.org and google your chipset.
its a bit of a convoluted process but it worked ok in the end.

Ohb01 wrote:
> Synaptic shows that I have installed linux-restricted-
> modules-2.6.24-19-generic (installed version 2.6.24.13-19.42 from Hardy-
> updates, which is the only one showing as available).
>
> But if I restart with 2.6.24-19-generic, then:
>
> I have no Wireless as mentioned above. Also, clicking on Network Monitor
> applet on the GNOME panel shows only "SIOCGIFFLAGS error: No such
> device".
>
> And System > Administration > Hardware Drivers shows only
>
> "Support for Atheros 802.11 wireless LAN cards. Enabled [v]. Status: Not
> in Use."
>
> Not even listed in Hardware Drivers under 2.6.24-19-generic:
>
> - "Atheros Hardware Access Layer (HAL)" (which is listed and shown as
> "In use" when I restart with kernel 2.6.20-16-generic)
>
> - "ATI accelerated graphics driver" (which is listed when I restart with
> kernel 2.6.20-16-generic, though I choose not to use this driver as it
> prevents Suspend/Hibernate, which is a different story, I think.)
>
>

Steve Langasek, I confirm that I am forced to use 2.6.20-16 (I looked again: the last digit before the "-" is a 0, not a 4). All I know is that Suspend and Hibernate worked well in 7.10 (not just 7.04), but broke only after upgrading to Hardy. So if this is not a Hardy issue, then what is it?

I just went back through every kernel in the GRUB menu until I found the latest one that still mostly worked for me, which happened to be 2.6.20-16 (though it does have some issues, like auto-rebooting after resume from suspend and Switch User -- plus today, refusing to mount USB storage devices like standard 2 GB SD cards from a card reader).

I would like to ensure that this really is not a duplicate before opening another bug report. I don't even have 2.6.24-16 in my GRUB menu -- where would I get it so I can test it?

Richard Coates, thanks for the tip. Having said this, I chose Ubuntu largely because I had hoped to avoid "googling my chipset" and other "convoluted processes" just to restore my network work after a kernel upgrade. I'm not a software engineer, just a home user hoping for a secure and stable alternative to Windows. I would be happy to try anything within reason, but I would really appreciate detailed, reproducible instructions. Thanks in advance for your help.

There is a detailed step by step howto on the ubuntu forum.
sorry I dont have the link its on my friends laptop.
thats why I suggested googling for ..ubuntu, wifi-chipset-name to bring
it up.

Ohb01 wrote:
> Richard Coates, thanks for the tip. Having said this, I chose Ubuntu
> largely because I had hoped to avoid "googling my chipset" and other
> "convoluted processes" just to restore my network work after a kernel
> upgrade. I'm not a software engineer, just a home user hoping for a
> secure and stable alternative to Windows. I would be happy to try
> anything within reason, but I would really appreciate detailed,
> reproducible instructions. Thanks in advance for your help.
>
>

Ohb01,

Thanks for your willingness to help get to the bottom of this problem!

The 2.6.24-16 kernel was the kernel included when Ubuntu 8.04 released. If you don't already have it installed, you should be able to install it from the command line using 'sudo apt-get install linux-image-2.6.24-16-generic linux-restricted-modules-2.6.24-16-generic', or by selecting the packages of the same names in synaptic (System -> Administration -> Synaptic Package Manager).

If 2.6.24-16 also doesn't work for you, then your problems are unrelated to this bug report. Actually, any problems you're experiencing with wireless are probably unrelated anyway, since this bug report is specifically about suspend/resume issues.

For your interest, if suspend/resume does not work on your computer
with 2.6.24-19 (i. e. Hardy fully up to date), then you might try
finding a set of "quirks" which makes it work for you. I recommend
taking a look at
http://people.freedesktop.org/~hughsient/quirk/quirk-suspend-debug.html.

If you find a set of quirks, please open a bug against hal-info,
attach your lshal output, and the set of quirks you discovered.

Steve Langasek,

Thanks for your detailed instructions. I installed linux-image-2.6.24-16-generic and linux-restricted-modules-2.6.24-16-generic. Wireless works, as does Resume from Suspend/Hibernate (and it's fast!), even wireless after resume works - reconnects to my wireless network within a minute.

BUT: No sound. (Speaker icon is crossed out in GNOME top panel; trying to open Volume Control, I get "No GStreamer plugin and/or devices found".) Also, still no mounting of SD card from USB-based card reader. And it detects my camera but then f-spot does nothing to actually download photos.

Now what?

I've tried to fix the lack of Sound myself, following the "Comprehensive Sound Problem Solutions Guide" at http://ubuntuforums.org/showpost.php?p=1191847&postcount=1 , but the result was a messed-up GNOME (no Face Browser to select user at Login, and no way to fix this without editing /etc/gdm/gdm.conf manually. In addition, sudo nautilus has also stopped working. Details in my Forum post at http://ubuntuforums.org/showpost.php?p=5229702&postcount=11 . <sigh> <getting discouraged>

Ohb01,

I'm sorry, sound debugging questions are definitely out of scope for this bug report. It sounds like the forums are the right place to continue debugging this (in spite of some setbacks with GDM!).

Hi,

The suspend/resume problem continues in Intrepid.

For Asus M2NPV-VM, nVidia GeForce 6150, I found the following solution - maybe it helps:
Simply update the BIOS (from revision 0504 to revision 1301) as recommended at
http://fixunix.com/kernel/337502-swsusp-amd-x2-64-2-6-24-regression.html

BTW, on that machine I still have problems with pm-utils, therefore I use acpi-support:
In /usr/lib/hal/scripts/linux/hal-system-power-hibernate-linux
replace /usr/sbin/pm-hibernate $QUIRKS
by /etc/acpi/hibernate.sh force
In /usr/lib/hal/scripts/linux/hal-system-power-suspend-linux
replace /usr/sbin/pm-suspend $QUIRKS
by /etc/acpi/sleep.sh force

I use these settings in /etc/defaul/acpi-support:
ACPI_SLEEP=true
ACPI_SLEEP_MODE=mem
SAVE_VBE_STATE=false
POST_VIDEO=false
SAVE_VIDEO_PCI_STATE=true
USE_DPMS=false

This bug is officially also acts in the name of bug #226279. What to do when this bug is officially fixed, but MY BUG #226279 is still a bug for me! The kernel that's said to fix bug #226279 does NOT fix bug #221213, which is the situation reported by me!

So: as long as bug #221213 is concerned, and for my Acer, Hardy is broken, only Gutsy and Intrepid have working kernels.

HOW CAN THIS BUG REPORT READ "FIX RELEASED" WHEN NOT ALL OF ITS 15 "DUPLICATES" ARE CONFIRMED TO BE FIXED TOO?

(Sorry for shouting, but the policy of marking bugs as "duplicates" is too lax.)

Hi All,

I'm closing the Intrepid nomination because there has been no reference that this is an issue with the 2.6.27 Intrepid kernel. This bug should have been resolved in Hardy. If this is not the case for you please open a new report. Additionally, if your bug was marked a duplicate of this report and your bug is not yet resolved, please undup your bug from this one.

Another thing to note about suspend/resume issues is that even though you may be experiencing the same symptom as everyone else, it really is usually hardware specific. For that reason, it's helpful that when subscribing to existing bug reports, or marking bugs as a duplicate of another, you should make sure you have the same hardware as the original bug reporter. If this is not the case it is best to open a new bug report (or not mark a bug as a duplicate). Otherwise bug reports become bloated and hard to follow with subscribers reporting against multiple pieces of hardware which are likely running different drivers and will be requiring different fixes. Thanks again for your cooperation, we really appreciate it.