Ticket #6201 (closed defect: fixed)

Opened 7 years ago

Last modified 4 years ago

No sound, or even freeze after sleep

Reported by: bert Owned by: dsaxena
Priority: blocker Milestone: 9.1.0-cancelled
Component: kernel Version:
Keywords: blocks-:8.2.0 cjbfor9.1.0 Cc: etoys, cjb, dsaxena
Action Needed: reproduce Verified: no
Deployments affected: Blocked By:
Blocking: #9311, #10168


Build joyride 1583, q2d09: I have an etoys script making a short tick sound (w/o reverb) each second. Machine goes to sleep after 35 secs without user input. Touching the pad wakes it up, the script continues visibly, but no sound is heard. Switching away and back to Etoys restores the sound (presumably due to Etoys stopping and starting its sound player on deactivation via dbus).

If instead of the short tick sound I use a longer sound that lasts more than a second, Etoys even freezes after wake up. Switching away and back makes it work again.

I have also seen that occasionally even switching forth and back did not restore sound. In one case MiniTamTam could restore sound, in another case aplay on the command line did. In other cases, MiniTamTam ceased to produce sound, and I also saw aplay playing silently. So I assume this problem is not unique to etoys, though I did not test other activities extensively (and I only have an MP machine for a few days so I did not see the problem earlier).

Change History

follow-up: ↓ 3   Changed 7 years ago by cjb

  • cc dilinger added
  • priority changed from normal to blocker
  • milestone changed from Never Assigned to Update.1

Ugh. This is awful.

You could confirm that the same happens if you, when ssh'd in, do "echo mem > /sys/power/state" instead of having OHM trigger it. If so, this is a bug in kernel audio resume.

  Changed 7 years ago by cjb

Dup of #4247, which looks to have been lost in the FRS->Update.2 mass-retarget.

in reply to: ↑ 1   Changed 7 years ago by bert

Replying to cjb:

You could confirm that the same happens if you, when ssh'd in, do "echo mem > /sys/power/state" instead of having OHM trigger it. If so, this is a bug in kernel audio resume.

Yes, the same thing happens.

  Changed 7 years ago by cjb

  • cc cjb added; dilinger removed
  • owner changed from cjb to dilinger
  • component changed from power manager (OHM) to kernel

  Changed 6 years ago by dsaxena

  • cc dsaxena added

  Changed 6 years ago by dsaxena

Running 703, I've been unable to reproduce this via both mini tam tam or aplay of a wave file and over 100 suspend/resume cycles.

  Changed 6 years ago by bert

  • keywords blocks?:8.2.0 added
  • next_action set to never set

I just happened to run into this again, in joyride-2414. Without sound, Etoys wakes up fine now (yay!).

But if a sound was playing when the suspend happened, Etoys freezes on resume.

To reproduce, make a ticking script that makes sound (i.e. run Etoys, click "make a project", drag out e.g. an Ellipse from the supplies box, right-click the Ellipse to get its halo, click the light-blue eye handle to open a viewer, drag out an "Ellipse make sound" tile and drop it somewhere, click the clock icon in the new script's title bar to make the script tick).

  Changed 6 years ago by gregorio

  • keywords blocks-:8.2.0 added; blocks?:8.2.0 removed
  • milestone changed from 8.2.0 (was Update.2) to 8.2.1

  Changed 6 years ago by cjb

Bert, is this a full machine freeze, or an etoys hang? If the latter, it'd be helpful to see an strace or debugging log from etoys to see what's going wrong, if you can manage to get one. Thanks!

  Changed 6 years ago by bert

Just Etoys hangs. I'll see if I can get something useful.

  Changed 6 years ago by cjb

Thanks. I guess it'll be hard to keep strace going over suspend, but it might also be sufficient to start an strace/gdb after the hang, and then see which call/FD we're stuck on.

  Changed 6 years ago by gregorio

Hi Guys,

Which kind of suspend will cause this bug to become apparent?

See http://wiki.laptop.org/go/Release_Notes/8.2.0#Longer_battery_life for an attempt to explain the different types.

I'm going to document this one in the release notes so please read my explanation there and let me know if you have any comments or edits.



Greg S

  Changed 6 years ago by bert

I was experiencing it on idle-suspend.

  Changed 6 years ago by cjb

It'll be happening on any suspend/resume, so both idle-suspend and sleep.

  Changed 6 years ago by mstone-xmlrpc

  • keywords cjbfor9.1.0 added
  • milestone changed from 8.2.1 to 9.1.0

Pushing out to 9.1.0, per edmcnierney's request.

  Changed 6 years ago by dsaxena

  • owner changed from dilinger to dsaxena
  • status changed from new to assigned
  • next_action changed from never set to reproduce

I am going through all kernel bugs marked as 9.1 or future release and updating their status, next action, etc in preparation of 9.1 bug scrubbing and future release planning.

Next step for this bug is to attempt and reproduce under the latest joyride to see if the problem remains or has been solved via some change in the stack.

  Changed 6 years ago by gregorio

From: http://lists.laptop.org/pipermail/devel/2008-December/022075.html

Etoys has exactly the same problem (etoys is frozen and the line "snd_pcm_writei returned -86" gets written endlessly into the etoys logfile). Sorry, I don't know anything about DBus. To reproduce with Etoys: 1. Open etoys on the Xo 2. Click on "make A Project" 3. Click on "Supplies" 4. Drag and drop the "Sound recorder" 5. Record a sound 6. Play the recording 7. Press XO power button (just short so the XO goes in standby mode with dark screen) 8. Press XO power button (again just short) 9. Etoys is frozen Scratch: We have the frozen Scratch problem very often at the moment because we are using Scratch and record sounds (about 3-5 students of 30 per lesson). It really bad since saving the project is not possible anymore. First I thought it is because we switched on experimental Power Management. But now it is switched off and the problem is still here. It is just Scratch that freezes, Sugar is still working fine. I don't remember having seen this problem on older sugar builds e.g. 656 or 708 and we used Scratch intensively on this builds. Regards, Philipp

  Changed 5 years ago by bert

  • blocking 9311 added

(In #9311) Sounds like the same kernel bug as #6201. Etoys cannot do much about this, the Linux kernel is supposed to restore everything as it was on resuming so an application would not even notice.

OTOH after trashing the recorder, no sound should be recorded anymore. This is worth investigating.

  Changed 4 years ago by bert

  • blocking 10168 added

(In #10168) To me this sounds like another instance of #6201 ...

  Changed 4 years ago by Quozl

  • status changed from assigned to closed
  • resolution set to fixed

Tested in os204, works fine, closing.

Note: See TracTickets for help on using tickets.