[Bluez-devel] btsco vs. swsusp

[Brad Midgley <bmidgley@xmission.com>]

[-- Attachment #1: Type: text/plain, Size: 242 bytes --]

Hey

Itay was tracking down why he couldn't software-suspend with btsco 
loaded. I wanted to get his result out there in case someone wanted to 
run with it.

I've only used s3 suspend which works as long as the daemon isn't running...

Brad

[-- Attachment #2: Re: bluetooth-alsa for Debian --]
[-- Type: message/rfc822, Size: 4388 bytes --]

From: Itay Ben-Yaacov <pezz@math.wisc.edu>
To: Brad Midgley <bmidgley@xmission.com>
Subject: Re: bluetooth-alsa for Debian
Date: Tue, 03 May 2005 19:19:24 -0500
Message-ID: <1115165964.14560.25.camel@vv617.math.wisc.edu>

In fact, I added some debug messaging to the module.
What I gather from that is that when there is nothing happening, the
thread blocks at the wait_event_interruptible(...), which makes sense.
Once swsusp2 starts freezing stuff, the thread unblocks and repeats the
thread main loop up to 

		if (!sock)
			continue;

where it "continue"s back to the beginning.
This loop just repeats itself indefinitely, until the freezer times out
and gives up.
Then swsusp2 prints the following to dmesg:

Software Suspend 2.1.8: Initiating a software suspend cycle.
Stopping tasks failed.
Tasks that refused to be refrigerated and haven't since exited:
 - snd-bt-scod (#19820) signalled but didn't enter refrigerator.
snd-bt-scod   S F705E000     0 19820      1         20337 17497 (L-TLB)
f705fe58 00000046 00000003 f705e000 00000000 00000286 f705fe44 00000286
       00000000 00000000 f4cc35a0 000000a8 78898b98 00000031 d0abb674
d505acec
       d505ac80 f705e000 f705fea0 f8c74ed6 f8c755c0 f705fe84 00200096
f705e000
Call Trace:
 [<f8c74ed6>] snd_card_bt_sco_thread+0x116/0x320 [snd_bt_sco]
 [<c0125ce0>] autoremove_wake_function+0x0/0x50
 [<c0125ce0>] autoremove_wake_function+0x0/0x50
 [<c01457a3>] clear_page_range+0x1b3/0x1f0
 [<c016c18e>] dput+0x1e/0x210
 [<c010ed97>] recalc_task_prio+0x87/0x140
 [<c011481b>] exit_notify+0x2eb/0x820
 [<c011bb51>] free_uid+0x11/0x60
 [<c010f2f5>] schedule_tail+0x15/0x50
 [<c01028f2>] ret_from_fork+0x6/0x14
 [<f8c74dc0>] snd_card_bt_sco_thread+0x0/0x320 [snd_bt_sco]
 [<f8c74dc0>] snd_card_bt_sco_thread+0x0/0x320 [snd_bt_sco]
 [<c0100d3d>] kernel_thread_helper+0x5/0x18
Please include the following information in bug reports:
- SUSPEND core   : 2.1.8
- Kernel Version : 2.6.11-phichsa-5
- Compiler vers. : 3.3
- Attempt number : 4
- Parameters     : 17 2048 0 1 0 5
- Limits         : 262062 pages RAM. Initial boot: 257795.
- Overall expected compression percentage: 0.
- LZF Compressor enabled.
  Compressed 1021337600 bytes into 359458978 (64 percent compression).
- Swapwriter active.
  Swap available for image: 487964 pages.
- Preemptive kernel.
- Highmem Support.


And the btsco thread blocks again at wait_event_interruptible(...).


So, my uneducated guess: swsusp2 sends some freezing signal to the
thread, but that signal is not handled correctly (or at all).  Does this
make any sense?

Also, any idea why does the thread appear three times on the stack?

Cheers,
Itay