Bug 1350490 - bluetooth a2dp broken on arm
Summary: bluetooth a2dp broken on arm
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: sbc
Version: 24
Hardware: armhfp
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Peter Robinson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-06-27 15:02 UTC by Chanho Park
Modified: 2017-08-08 15:06 UTC (History)
3 users (show)

(edit)
Clone Of:
(edit)
Fedora24 ARM
Fedora22 ARM(with newly build sbc)

Linux kernel version: 3.10.93

No GUI environment. Just run pulseaudio and bluez by commandline.
Last Closed: 2017-08-08 15:06:00 UTC


Attachments (Terms of Use)

Description Chanho Park 2016-06-27 15:02:51 UTC
Description of problem:

The sbc(sub band codec) is used by bluetooth A2DP profile.



Version-Release number of selected component (if applicable): sbc-1.3-4


How reproducible:


Steps to Reproduce:
1. connect bluetooth headset using bluez(bluetoothctl)
2. pactl set-card-profile 2 a2dp_sink
3. mplayer -ao pulse test.mp3

Actual results:
AO: [pulse] pa_stream_get_latency() failed: Connection terminated
and bluetooth of pulseaudio received SIGSEGV, Segmentation fault.


Expected results:
The mp3 music file will be played from bt headset.

Additional info:

I've tried several approach to avoid SIGSEGV of pulseaudio process.

Base platform is fedora 24 arm.
1. Use fedora24's sbc-1.3-4.fc24.armv7hl -> SIGSEGV
2. Install fedora23's sbc-1.3-3.fc23.armv7hl -> SIGSEGV
3. Install fedora22's sbc-1.3-2.fc22.armv7hl -> Success
4. Build sbc-1.3-2.fc22 on fedora 22 -> SIGSEGV

The sbc-1.3-2 has been never built again since it was released from fedora22.
As I know, gcc version was changed from gcc-4.9 to gcc-5.3 after released fedora22. I think it could affect the operation of sbc.

Below is GDB debug information of SIGSEGV error of pulseaudio.
Thread 4 "bluetooth" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb0899300 (LWP 3814)]
0xb08a7a58 in sbc_analyze_eight_armv6 () at sbc/sbc_primitives_armv6.c:115
115		__asm__ volatile (
(gdb) bt
#0  0xb08a7a58 in sbc_analyze_eight_armv6 () at sbc/sbc_primitives_armv6.c:115
#1  0x0000fffe in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) disassemble 
Dump of assembler code for function sbc_analyze_eight_armv6:
<snip>
   0xb08a7a40 <+440>:	smlad	r4, lr, r8, r4
   0xb08a7a44 <+444>:	smlad	r5, lr, r9, r5
   0xb08a7a48 <+448>:	ldrd	r8, [r2, #40]	; 0x28
   0xb08a7a4c <+452>:	smlad	r6, lr, r10, r6
   0xb08a7a50 <+456>:	smlad	r7, lr, r11, r7
   0xb08a7a54 <+460>:	ldrd	r10, [r2, #48]	; 0x30
=> 0xb08a7a58 <+464>:	stmia	r1!, {r4, r5}
   0xb08a7a5c <+468>:	smuad	r4, r3, r8
   0xb08a7a60 <+472>:	smuad	r5, r3, r9
---Type <return> to continue, or q <return> to quit---
   0xb08a7a64 <+476>:	ldrd	r8, [r2, #72]	; 0x48
   0xb08a7a68 <+480>:	stmia	r1!, {r6, r7}
   0xb08a7a6c <+484>:	smuad	r6, r3, r10
   0xb08a7a70 <+488>:	smuad	r7, r3, r11
   0xb08a7a74 <+492>:	ldrd	r10, [r2, #80]	; 0x50
   0xb08a7a78 <+496>:	smlad	r4, r12, r8, r4

(gdb) info registers
r0             0xfffc0001	4294705153
r1             0xb705a4af	3070600367
r2             0xb08a8c08	2961869832
r3             0x1ffff	131071
r4             0x201b	8219
r5             0x15467	87143
r6             0xffff5f4d	4294926157
r7             0xfffe8306	4294869766
r8             0x1d4d206f	491593839
r9             0x33badf91	867884945
r10            0xa4adf91	172679057
r11            0xd426206f	3559268463
r12            0x20003	131075
sp             0xb0898bf8	0xb0898bf8
lr             0xffff	65535
pc             0xb08a7a58	0xb08a7a58 <sbc_analyze_eight_armv6+464>
cpsr           0x80000010	-2147483632

It seems alignment error of stmia instruction.

Comment 1 Peter Robinson 2016-06-27 16:16:30 UTC
> The sbc-1.3-2 has been never built again since it was released from fedora22.
> As I know, gcc version was changed from gcc-4.9 to gcc-5.3 after released
> fedora22. I think it could affect the operation of sbc.

That is incorrect, the Release is the -2 on the example above is bumped for every rebuild. So -3 is the rebuild of -2 for F-23, and -4 was the rebuild for F-24, they are all the same code, just rebuilt.

It could be an issue elsewhere, could you please submit a full backtrace using ABRT so we get the full debug symbols.

Also are you using a GUI interface to connect or command line, please provide the details.

Comment 2 Chanho Park 2016-06-27 16:49:48 UTC
I meant sbc-1.3-2 of fedora22. I focused what difference is between original "sbc-1.3-2" and built "sbc-1.3-2" by me. The code was same and everything was same except sbc binary. Please try fedora22 arm with original sbc installation and your build installation.

I'm using ARM headless machine which has a 3.10.93 linux kernel and no GUI environment.

I already install all debuginfo packages for pulseaudio, bluez and sbc.
I can't get full backtrace because the lr register was corrupted.

0xb0943a58 in sbc_analyze_eight_armv6 () at sbc/sbc_primitives_armv6.c:115
115		__asm__ volatile (
(gdb) bt
#0  0xb0943a58 in sbc_analyze_eight_armv6 () at sbc/sbc_primitives_armv6.c:115
#1  0x0000fffe in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) info registers
r0             0xfffc0001	4294705153
r1             0xb70ee4af	3071206575
r2             0xb0944c08	2962508808
r3             0x1ffff	131071
r4             0x201b	8219
r5             0x15467	87143
r6             0xffff5f4d	4294926157
r7             0xfffe8306	4294869766
r8             0x1d4d206f	491593839
r9             0x33badf91	867884945
r10            0xa4adf91	172679057
r11            0xd426206f	3559268463
r12            0x20003	131075
sp             0xb0934bf8	0xb0934bf8
lr             0xffff	65535
pc             0xb0943a58	0xb0943a58 <sbc_analyze_eight_armv6+464>
cpsr           0x80000010	-2147483632

Comment 3 Chanho Park 2016-06-27 17:05:53 UTC
I also found there is no error with neon primitives.
Please try build with below:

make CFLAGS+="-mfpu=neon" %{?_smp_mflags} V=1

Comment 4 Peter Robinson 2016-06-27 20:04:45 UTC
(In reply to Chanho Park from comment #3)
> I also found there is no error with neon primitives.
> Please try build with below:
> 
> make CFLAGS+="-mfpu=neon" %{?_smp_mflags} V=1

We don't support NEON flags in the userspace

Comment 5 Peter Robinson 2016-06-27 20:06:49 UTC
> I'm using ARM headless machine which has a 3.10.93 linux kernel and no GUI
> environment.

Please outline how this userspace environment is configured so the problem can be recreated.

Please also outline the device as this is not a supported Fedora kernel. 

> I already install all debuginfo packages for pulseaudio, bluez and sbc.
> I can't get full backtrace because the lr register was corrupted.

Please submit using the abrt cli and the original Fedora build sbc

Comment 6 GeonhoKim 2016-06-30 05:12:21 UTC
https://bugzilla.redhat.com/show_bug.cgi?id=1290347

This bug was already reported before. 

This is register information when problem was reproduce. 
(gdb) info register
r0             0x0      0
r1             0xab52fd71       2874342769
r2             0xf1080c08       4043836424
r3             0x0      0
r4             0xffffd5ca       4294956490
r5             0xffffee84       4294962820
r6             0x117c   4476
r7             0x2a36   10806
r8             0x1d4d206f       491593839
r9             0x33badf91       867884945
r10            0xa4adf91        172679057
r11            0xd426206f       3559268463
r12            0xffff   65535
sp             0xf1070bf8       0xf1070bf8
lr             0x0      0
pc             0xf107fa58       0xf107fa58 <sbc_analyze_eight_armv6+464>
cpsr           0x80000010       -2147483632
(gdb)

r1 register address is 0xab52fd71. and r1 is arguments for abc_analyze_eight_armv6. 
It mean r1 register have to set aligned address to access memory. 
It is some strange why abc_analyze_eight_armv6 worked failed on f23 and f24.

Comment 7 Chanho Park 2016-07-07 10:40:14 UTC
Below are reproduce sequnces:

1. Connect a bluetooth headset using bluetoothctl
[root@localhost ~]# bluetoothctl 
[NEW] Controller 00:58:D0:84:84:E4 ARTIK710 [default]
[bluetooth]# scan on
Discovery started
[CHG] Controller 00:58:D0:84:84:E4 Discovering: yes
[NEW] Device E9:A7:50:0A:C0:25 Tempo- Unnamed
[NEW] Device 1C:52:16:3E:40:F6 QCY-QY12
[bluetooth]# pair 1C:52:16:3E:40:F6 
Attempting to pair with 1C:52:16:3E:40:F6
[CHG] Device 1C:52:16:3E:40:F6 Connected: yes
[CHG] Device 1C:52:16:3E:40:F6 UUIDs: 00001101-0000-1000-8000-00805f9b34fb
[CHG] Device 1C:52:16:3E:40:F6 UUIDs: 00001108-0000-1000-8000-00805f9b34fb
[CHG] Device 1C:52:16:3E:40:F6 UUIDs: 0000110b-0000-1000-8000-00805f9b34fb
[CHG] Device 1C:52:16:3E:40:F6 UUIDs: 0000110c-0000-1000-8000-00805f9b34fb
[CHG] Device 1C:52:16:3E:40:F6 UUIDs: 0000110e-0000-1000-8000-00805f9b34fb
[CHG] Device 1C:52:16:3E:40:F6 UUIDs: 0000111e-0000-1000-8000-00805f9b34fb
[CHG] Device 1C:52:16:3E:40:F6 ServicesResolved: yes
[CHG] Device 1C:52:16:3E:40:F6 Paired: yes
Pairing successful
[QCY-QY12]# connect 1C:52:16:3E:40:F6 
Attempting to connect to 1C:52:16:3E:40:F6
Connection successful
[CHG] Device E9:A7:50:0A:C0:25 RSSI: -80
[QCY-QY12]# exit

2. set card profile to a2dp_sink
pactl set-card-profile 2 a2dp_sink

3. Play a mp3 file using mplayer
mplayer -ao pulse test.mp3
AO: [pulse] 44100Hz 2ch s16le (2 bytes per sample)
Video: no video
Starting playback...
[  426.560000] Unhandled fault: alignment fault (0x92000061) at 0x00000000ab341501

Audio device got stuck!
AO: [pulse] pa_stream_write() failed: Connection terminated
AO: [pulse] pa_stream_get_latency() failed: Connection terminated

Comment 8 Fedora End Of Life 2017-07-25 21:21:31 UTC
This message is a reminder that Fedora 24 is nearing its end of life.
Approximately 2 (two) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 24. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '24'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 24 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Comment 9 Fedora End Of Life 2017-08-08 15:06:00 UTC
Fedora 24 changed to end-of-life (EOL) status on 2017-08-08. Fedora 24 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


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