Bug 122183 - alsa sound breaks a minute after resume from S3 suspend
Summary: alsa sound breaks a minute after resume from S3 suspend
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-05-01 17:00 UTC by Rushi Bhatt
Modified: 2007-11-30 22:10 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2004-05-03 18:46:44 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Rushi Bhatt 2004-05-01 17:00:29 UTC
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
kernel

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_MPENTIUMM=y
# CONFIG_SMP is not set
CONFIG_PREEMPT=y
# CONFIG_X86_UP_APIC is not set

CONFIG_PM=y
# CONFIG_SOFTWARE_SUSPEND is not set
CONFIG_PM_DISK=y
CONFIG_PM_DISK_PARTITION="/dev/hda5"
                                                                     
          
Also, I have applied the wakeup_devices patch from
http://bugzilla.kernel.org/show_bug.cgi?id=1415

This was to reason for compiling my custom kernel.

How reproducible:


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
  
Actual results:

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.


Expected results:

All devices should continue working.

Additional info:

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.

Comment 1 Arjan van de Ven 2004-05-01 17:08:51 UTC
I would recommend disabling preempt first; it doesn't gain you (much)
but is one of the high risk factors in breakage like this.

Comment 2 Rushi Bhatt 2004-05-01 19:44:03 UTC
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
simultaneously again.. 

Comment 3 Rushi Bhatt 2004-05-03 17:02:35 UTC
Super!

With the newer kernel (2.6.5-1.347custom from Arjan's repository) with
the following options is reliable (so far..)

CONFIG_MPENTIUMM=y
# 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
sound dies:

 11:      79221          XT-PIC  ehci_hcd, uhci_hcd, uhci_hcd,
uhci_hcd, ohci1394, eth0, yenta, radeon@PCI:1:0:0, Intel 82801DB-ICH4,
eth1
 
Do the following:

1.
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:

/sbin/ifdown eth0
/sbin/ifdown eth1
/usr/sbin/alsactl power off
/bin/sync
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..



Note You need to log in before you can comment on or make changes to this bug.