# Stopping bluetooth rfcomm = kernel panic in linux 3.8.13

## eccerr0r

I'm not sure this is Gentoo specific as there seems to be some hints that this affects other Linux...

Anyway I am using bluetooth (USB) rfcomm to connect my 3G GSM cellular phone to my computer.

I did add a networkmanager patch to enable bluetooth (btusb/usb attached) rfcomm, but I wouldn't think a userspace application should cause an oops...  Without the patch, my GSM modem would not show up in network manager at all.  I think other binary distros have this same patch to enable rfcomm network manager.

Anyway, I'm using gnome + blueman + networkmanager + modemmanager.

I have my phone (in bluetooth mode) paired and attached to its dialup networking using blueman.  I can then use Networkmanager (nm-applet) to select my phone, and achieve network.  It works perfectly fine.

I can even disconnect my network connection through nm-applet, network goes down as desired.

However after I disconnect, if I detach dialup network on blueman, the X11 server and everything comes crashing down in an oops in KMS fbcon.  Not exactly the expected behavior for a userspace app.  Machine is subsequently frozen and I can't get a dump.  I'll see if I can get a usbserial attached and have the kernel panic dump to that, but with these newfangled equipment I don't know how well that works for oops dumps.  I'll have to see if I can replicate this on another machine that has a hardware serial port, then that would be better.)

I noticed that in the oops dump that btusb was recently rmmodded for some reason.  My guess is that some code had some hooks into btusb and not getting notified when it got removed.  When I tried removing it before I setup a DUN link, it removes without the crash.

Anyone seen this behavior?  Or if not, that's also useful information...

EDIT: Real bug in 3.8.x and newer (not resolved), but works in older kernels (I only tried 3.2.12 which does not crash)Last edited by eccerr0r on Thu Jun 20, 2013 4:26 am; edited 1 time in total

----------

## eccerr0r

I think someone stumbled upon the same bug:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1165433

----------

## Mr. M

I have also noticed some strange behavior after using rfcomm using kernel 3.7.10-gentoo-r1. It's not a kernel panic, but after using rfcomm I am no longer able to login to the system, e.g., the command "su" just hangs. I have to restart the system to get it to work normally again.

----------

## eccerr0r

It may very well be the same issue, some major corruption occurring due to a rfcomm bug perhaps?

Was there an oops at least?

Well, at least I hope it's been brought up to the kernel guys.  There seems to be some report that 3.10-RC fixes it so I'll have to see if it does or not.

BTW: are you using networkmanager and if so, did you patch it for bluetooth?

EDIT: 3.10-rc5 appears to ALSO CRASH! but not behave exactly the same! as the previous kernels...

----------

## eccerr0r

I got an oops dump from serial console.

Unfortunately it seems to be indicating some massive corruption of the kernel skb's - btusb rfcomm or maybe pppd is leaving "presents" behind for other applications to step on.  However I doubt it's pppd since because USB ttyACM0 works...

Apparently this breaks for x86 and x86_64.  Gentoo devs don't have to worry about blocking anything, since this is my own "patch" to enable bluetooth dialup networking, I guess I have to work with Ubuntu guys... and so far ubuntu is thinking about simply disabling this pathway until a kernel fix is found...

```
[  163.887089] BUG: unable to handle kernel paging request at 000000fffffffe00

[  163.928923] IP: [<ffffffff8112a72a>] __kmalloc_track_caller+0xba/0x1e0

[  163.968065] PGD 0

[  163.980141] Oops: 0000 [#1] SMP

[  163.999558] Modules linked in: ppp_deflate zlib_deflate bsd_comp ppp_async crc_ccitt ppp_generic slhc cpufreq_ondemand cpufreq_conservative cpufreq_stats cpufreq_userspace binfmt_misc rfcomm hwmon_vid bnep nfsd exportfs nfs_acl lockd sunrpc ipv6 snd_hda_codec_hdmi snd_hda_codec_realtek i915 snd_hda_intel fbcon snd_hda_codec bitblit snd_hwdep video softcursor coretemp snd_pcm cfbfillrect font btusb tileblit cfbimgblt kvm_intel cfbcopyarea bluetooth drm_kms_helper snd_page_alloc kvm rfkill snd_timer backlight fb ppdev fbdev snd r8169 parport_pc soundcore serio_raw parport pcspkr mii evdev

[  164.313997] CPU 3

[  164.324981] Pid: 2029, comm: metacity Tainted: G        W    3.9.2 #1 Gigabyte Technology Co., Ltd. Z68AP-D3/Z68AP-D3

[  164.389627] RIP: 0010:[<ffffffff8112a72a>]  [<ffffffff8112a72a>] __kmalloc_track_caller+0xba/0x1e0

[  164.443342] RSP: 0018:ffff8802074579f8  EFLAGS: 00010206

[  164.475146] RAX: 0000000000000000 RBX: ffff880207457aa7 RCX: 000000000000188a

[  164.517879] RDX: 0000000000001889 RSI: 00000000000106d0 RDI: 00000000000154c0

[  164.560613] RBP: ffff880207457a48 R08: ffff880207457c14 R09: ffff88020ab72b20

[  164.603348] R10: 0000000000000001 R11: 0000000000000000 R12: 000000fffffffe00

[  164.646081] R13: ffff880216801780 R14: 00000000000001c0 R15: 00000000000106d0

[  164.688816] FS:  00007fd321adb900(0000) GS:ffff88021fac0000(0000) knlGS:0000000000000000

[  164.737274] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033

[  164.771679] CR2: 000000fffffffe00 CR3: 00000002058d8000 CR4: 00000000000407e0

[  164.814413] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000

[  164.857147] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400

[  164.899882] Process metacity (pid: 2029, threadinfo ffff880207456000, task ffff880216b6dac0)

[  164.950422] Stack:

[  164.962446]  ffff880216895ac0 ffff880216b6dac0 ffff880207457a28 ffffffff814087b1

[  165.006949]  0000000000000000 ffff880207457aa7 00000000000004d0 00000000000001c0

[  165.051454]  ffff8802168016c0 0000000000000000 ffff880207457a88 ffffffff81408317

[  165.095957] Call Trace:

[  165.110587]  [<ffffffff814087b1>] ? __alloc_skb+0x81/0x2a0

[  165.143429]  [<ffffffff81408317>] __kmalloc_reserve.isra.51+0x37/0x90

[  165.181998]  [<ffffffff814087b1>] __alloc_skb+0x81/0x2a0

[  165.213800]  [<ffffffff81402e55>] sock_alloc_send_pskb+0x1d5/0x350

[  165.250811]  [<ffffffff81141bfb>] ? do_sys_poll+0x3db/0x4c0

[  165.284173]  [<ffffffff81402fe0>] sock_alloc_send_skb+0x10/0x20

[  165.319621]  [<ffffffff814a610c>] unix_stream_sendmsg+0x32c/0x450

[  165.356109]  [<ffffffff813feac6>] sock_aio_write+0x126/0x150

[  165.389994]  [<ffffffff813fe9a0>] ? __sock_recv_ts_and_drops+0x150/0x150

[  165.430126]  [<ffffffff8112ec0b>] do_sync_readv_writev+0x9b/0xe0

[  165.466092]  [<ffffffff8112eec8>] do_readv_writev+0xc8/0x1c0

[  165.499977]  [<ffffffff81008ff9>] ? read_tsc+0x9/0x20

[  165.530219]  [<ffffffff810841c7>] ? ktime_get_ts+0x47/0xe0

[  165.563064]  [<ffffffff8112eff7>] vfs_writev+0x37/0x50

[  165.593824]  [<ffffffff8112f16d>] sys_writev+0x4d/0xc0

[  165.624587]  [<ffffffff81141da6>] ? sys_poll+0x66/0x100

[  165.655872]  [<ffffffff814d62a9>] system_call_fastpath+0x16/0x1b

[  165.691836] Code: 00 00 49 8b 4d 00 65 48 03 0c 25 28 cc 00 00 48 8b 51 08 4c 8b 21 4d 85 e4 0f 84 8c 00 00 00 49 63 45 20 48 8d 4a 01 49 8b 7d 00 <49> 8b 1c 04 4c 89 e0 65 48 0f c7 0f 0f 94 c0 84 c0 74 c4 49 63

[  165.808222] RIP  [<ffffffff8112a72a>] __kmalloc_track_caller+0xba/0x1e0

[  165.847884]  RSP <ffff8802074579f8>

[  165.868757] CR2: 000000fffffffe00

[  165.890664] ---[ end trace b87d4fcd88f07280 ]---

```

----------

## mrsaccess

I don't think this problem has to do with networkmanager, only with the kernel's bluetooth stack/rfcomm subsystem.

I use a bluetooth enabled Arduino to get some data. If I poweroff the Arduino without first disconnecting it from Gentoo, I get a kernel panic. Sometimes it is a proper one, with caps lock flashing, some other times it just blanks the screens, fans turn up and the computer stops responding to anything.

It is really easy to trigger the bug here. Just start a rfcomm connection with a bluetooth device:

```
# rfcomm connect 0 xx:xx:xx:xx:xx:xx
```

Then turn off the bluetooth device without hanging up the rfcomm from the Linux terminal.

----------

## Logicien

It is possible that the chipset of the bluetooth device used on Gentoo side cause de Oops. With some external Usb bluetooth devices I had a Oops with an Acer desktop trying to transfert data with obexftp after the connexion was established between any Linux distribution and my cellular.

I tried 3 external bluetooth Usb devices and only an Asus one with an Atheros chipset using ath3k module and firmware was working properly with no Oops. Now, I have two internal Usb devices, a Ralink in a HP netbook and an Atheros in a HP laptop and they both work fine.

Curiously, those externals Usb Bluetooth giving Oops on the desktop where working properly with Debian with my netbook. Now, Funtoo do not give me an Oops using the Ralink Usb on my netbook.

So, my experience suggest that some Bluetooth devices are better supported than others with Linux in relation with the hardware environment.

----------

## eccerr0r

I can see this behavior on my Intel bluetooth USB (internal), a Targus branded external USB, and another unknown brand USB.  All three exhibit this issue...

Something strange here...

BTW, I've been cheating and posting on the Launchpad bug tracker, as there seems to be some debuggers there, but I found this LKML posting that may be related:

http://marc.info/?l=linux-bluetooth&m=136868678418771&w=2

I saw some of the functions being flagged in a WARNING bug so it might be related (see the oops dumps I posted on Launchpad).

Hopefully there's a fix to come out of here...

Groking the thread, it looks like Peter Hurley wrote this workaround (this is NOT a fix):

```
 diff --git a/drivers/tty/tty_port.c b/drivers/tty/tty_port.c

index 6d9e0b2..a4f4fa9 100644

--- a/drivers/tty/tty_port.c

+++ b/drivers/tty/tty_port.c

@@ -140,6 +140,10 @@ EXPORT_SYMBOL(tty_port_destroy);

static void tty_port_destructor(struct kref *kref)

{

struct tty_port *port = container_of(kref, struct tty_port, kref);

+

+ /* check if last port ref was dropped before tty release */

+ if (WARN_ON(port->itty))

+ return;

if (port->xmit_buf)

free_page((unsigned long)port->xmit_buf);

tty_port_destroy(port);

```

Trying this, bluetooth gets completely hosed but the machine does not go down in flames (still can sort of do a somewhat graceful shutdown).  It still oops and it can clearly be seen that there's some rfcomm badness going on, in the oops reports.

I edited the heading as this appears to be a 3.8.x and newer bug, it was introduced in a big bluetooth patch in 3.8.

----------

## TomWij

Please file bugs at https://bugs.gentoo.org as we can't keep track of them nor be able to fix them on the forums; for your convenience, you can link to this forum thread from the URL field and give a summary such that you do not need to repeat yourself. Thank you in advance.

----------

## eccerr0r

Filed https://bugs.gentoo.org/show_bug.cgi?id=474432 but I suspect this will have to wait out until the Bluetooth stack kernel devs get a hold of it.

This is cross-distribution and cross-platform.  I don't know if something should be masked until they fix it but based on the low volume of complaints I suspect not many people use bluetooth rfcomm...

----------

## eccerr0r

Linux 3.12-rc1 from kernel.org has the proposed fixes, and 3.12-rc2 is out right now.

The crash is gone when I muck with /dev/rfcomm*, but networkmanager does NOT like the new rfcomm as far as I can tell.

Anyone give it a go and see what it does?

----------

## eccerr0r

Has anyone tried Gnome3 and Bluetooth RFCOMM?  It appears that Bluetooth dialup networking (DUN) is now part of Gentoo!  (BTW this is "wireless tethering" without the wifi in case people don't know why I'd like it to work.)

However, it looks like Gnome3 with any kernel between >=Linux 3.8 and < Linux 3.12 should be able to trigger the kernel crash.

Anyway I now have a different issue.  With a patched 3.12.8 bluetooth rfcomm DUN worked once again with Gnome2 with Networkmanager Bluetooth patch.  But once I got Gnome3 installed, it stops working if I try to connect to it after using the machine a bit.  On a fresh reboot I can get bluetooth rfcomm DUN to work however, but it's a bit disruptive to require a reboot each time I want to use BT RFCOMM DUN.

----------

