Red Hat Bugzilla – Bug 122183
alsa sound breaks a minute after resume from S3 suspend
Last modified: 2007-11-30 17:10:41 EST
Description of problem:
My IBM R40 (2722-6YU) goes to sleep okay (using echo -n mem >
/sys/power/state via the event I defined for the LID in /etc/acpi/events.
Please be kind to me, this is my first bug report :-)
It also comes back normally (remarkably normally, with X, sound,
aironet 350 mini PCI and ethernet all working fine). The trouble
begins about a minute after coming back. All the devices start dying
mysteriously. There are no messages in /var/log/messages or in
/var/log acpid when this happens.
Version-Release number of selected component (if applicable):
FC2 test 3. apt-get dist-upgraded last night. By customising Arjan's
2.6.5-1.343custom #2 Fri Apr 30 02:55:50 EDT 2004 i686 i686 i386
GNU/Linux, with following (i think) important changes.
# CONFIG_SMP is not set
# CONFIG_X86_UP_APIC is not set
# CONFIG_SOFTWARE_SUSPEND is not set
Also, I have applied the wakeup_devices patch from
This was to reason for compiling my custom kernel.
Steps to Reproduce:
1. IBM R40 (2722-6YU). Use the custom kernel with patch, otherwise
it'll sleep but not wakeup.
2. Close the lid (or press the lid button, keep it pressed), wait for
30 seconds to let it sleep quietly.
3. Open the lid, let things come back.
4. Start playing mp3/ogg using xmms
Everything comes back as normal, sound resumes. After about a minute,
sound mysteriously dies, wireless as well as ethernet dies
simultaneously. Harddrive continues to work normally, trackpoint works
normally too. Haven't tried the USB mouse.
No messages in /var/log/messages.
alsactl power off
alsactl power on
restores the sound for about 5 seconds, then it dies again. Unable to
rmmod sound related modules, as it looks like Gnome locks the module
for its internal purposes and I am unable to find out which
application to kill in order to remove the sound modules. Exiting the
usual suspects (xmms, mixers, disabling gnome sound events) doesn't
help in removing sound modules.
All devices should continue working.
Either this is a bug with Gnome continuously hogging sound modules, or
it's a but with the alsa kernel modules. I don't know how, but will be
happy to help test this out.
I would recommend disabling preempt first; it doesn't gain you (much)
but is one of the high risk factors in breakage like this.
With disabled preempt there is not difference. With pci=noacpi passed
to kernel at boot, there is no difference in behaviour either.
Also, it looks like the PCI bus settings change across a
suspend/resume as checked by lspci -vvxxx. Is there a way to set the
PCI config to the original using the diff files or something?
Interestingly, once the sound dies, it is possible to resurrect it for
about half a minute by going through another suspend/resume cycle.
Then, sound, ethernet e100 and wireless ethernet all die
With the newer kernel (2.6.5-1.347custom from Arjan's repository) with
the following options is reliable (so far..)
# CONFIG_PREEMPT is not set
# CONFIG_X86_UP_APIC is not set
The thing slept overnight, and woke up with almost no battery left
(looks like it drains about 6W while in S3 vs about 17 while awake.
Good enough for the bike ride home.) The wakeup patch linked through
the problem statement is still required, and applies cleanly. Would it
be possible to incorporate it into one of the future kernels?
The real problem is the lost interrupt, as the count in
/proc/interrupts for the followin stops incrementing the same time
11: 79221 XT-PIC ehci_hcd, uhci_hcd, uhci_hcd,
uhci_hcd, ohci1394, eth0, yenta, radeon@PCI:1:0:0, Intel 82801DB-ICH4,
Do the following:
echo LID > /proc/acpi/wakeup_devices
echo SLPB > /proc/acpi/wakeup_devices
2. Disconnect power
3. use the following event in acpid to go to sleep:
/usr/sbin/alsactl power off
echo -n mem > /sys/power/state
/usr/sbin/alsactl power on
4. Don't leave usb devices plugged in while going to sleep. something
unnatural happens in that case..
Now for suspend to disk..