Tested 3.10.2 from the mainline ppa (in spite of the bad experience with
3.9.8 that is broken).
The linux bluetooth screen of death is still there, 127 days since first
notification on the LKML for a fully reproducible regression that
completely impairs a subsystem and causes a hard kernel crash with a
disastrous memory corruption, sigh.
Specifically, the RFCOMM session disconnection fixes that got applied to
Linux 3.10 commits (8 off) 24fd642ccb24c8b5732d7d7b5e98277507860b2a to
fea7b02fbf73adb2e746f00ed279a782de7e74e4 do not help.
All LKML activity on this stopped on 2013-06-25. From it it looks like
kernel developers seem to believe that to reproduce the bug a hard power
down of the remote is necessary ('Yes. With power down I meant a hard
power down, such that the remote doesn't has the chance to close the
session cleanly.'). Looks like this is not the case. A simple bluetooth
DUN activation / deactivation cycle from network manager (targeting a
Galaxy S mobile phone that is never switched off) seems to trigger the
bug and the kernel crash here. They may also thik that the bug is fixed
with the latest RFCOMM session disconnection fixes or that at least it
is reduced in scope (so that only a process is killed and a TTY not
released, without the disastrous memory corruption in the kernel).
Either here we are discussing a completely different bug from that in
the LKML thread http://news.gmane.org/find-
root.php?message_id=%3c519480A1.6030909%40ahsoftware.de%3e or the kernel
developers miss some relevant information.
Can someone from the ubuntu kernel team forward this info to Alexander
Holler and others on the LKML list revitalizing the thread?
In the meantime, may I again suggest unconfiguring RFCOMM TTY support
from ubuntu production kernels as a SRU until this is fixed, so DUN
still remains unfunctional, but at least the kernel crashes that may
lead to data loss are prevented? The thread on LKML does not exclude
data loss '[crash reports] don't make much sense because they happen
because of a disastreous memory corruption, which means the BUGs can
include almost everything (hopefully nothing which eats your disk
contents).'
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1165433
Title:
Kernel 3.8.x panics on bluetooth DUN disconnect
Status in “linux” package in Ubuntu:
Confirmed
Bug description:
Issue is obviously in the kernel that should not panic in any circumnstances.
This bug is seen on quantal using the kernel from PPA mainline. Tested with
3.8.0 to 3.8.6.
Since 3.8.x is going to be the raring kernel I believe that this should
definitely be fixed before raring is shipped.
Seen on:
DELL E6500 with kubuntu quantal 12.10 64 bit and as said, kernel 3.8.6 from
the mainline ppa.
The machine has a Dell Computer Corp. Wireless 370 Bluetooth Mini-card
(connected via an internal usb connection).
The issue is shown when connecting to the internet via a Samsung Galaxy S
plus phone, using a bluetooth DUN connection.
It is reproducible every time.
How to reproduce:
1) Use the bluetooth applet to discover the phone and associate to it.
2) Use network manager to setup a DUN connection with the phone through your
APN
3) Connect to the internet via bluetooth DUN (connection works perfectly)
4) Disconnect from the network manager.
At the same time you disconnect, the GUI session is terminated and the
kernel panics, briefly showing a panic log on the screen.
Note that:
a) The issue is not present using the standard ubuntu quantal kernel
b) The issue is not present using kernels from the mainline ppa before 3.8
(e.g., 3.7.x is fine for all x)
c) The issue is not present when connecting to the internet using a USB
mobile dongle (e.g. Huawei usb key)
This looks pretty serious to me: kernel does not sync when panicing
and there is a serious risk of data loss; connecting to the internet
via a smart phone using bluetooth DUN seems to be something that one
should take for granted on any modern OS. Furthermore, points a) and
b) above show that this is a *regression* over previous kernels.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1165433/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
