Launchpad has imported 4 comments from the remote bug at https://bugs.gentoo.org/show_bug.cgi?id=474432.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2013-06-22T23:55:54+00:00 Blc+gentoo wrote: Created attachment 351696 WARN/stack dump/oops in the bluetooth rfcomm code introduced in raw kernel 3.8.x This is an *UPSTREAM* bug and also some collation of known information of the nature of this bug. A bug that was introduced upstream by the bluetooth developers in 3.8.x which remains in 3.9.x will cause the machine to crash with an oops when rfcomm is disconnected while a tty is connected. This is unexpected behavior. While in 3.10-rc5 the behavior changed, the bug still exists. The initial method to trigger this bug was listed in http://forums.gentoo.org/viewtopic-t-961421-highlight-.html In brief, set up any bluetooth rfcomm connection and then rip up the bluetooth connection (/etc/init.d/bluetooth stop, rfcomm release, use blueman to disconnect Dial Up Networking/Serial). (I believe that pulling the bluetooth USB device from the plug also will trigger this issue, but I'd call that nonnatural behavior.) The kernel will then stomp over another kernel structure and cause the kernel to get corrupted, making other subsystem oops. As Gentoo appears to not have bluetooth setup for networkmanager, it should not be affected unless someone is using rfcomm directly to communicate with a bluetooth serial device, say over minicom for a bluetooth device or using pppd directly to access a bluetooth modem. I hit the bug because I have a /etc/portage/patches/net- misc/networkmanager patch file to allow bluetooth rfcomm links. As far as I can tell and from reports/tests upstream, this is probably due to bluetooth rfcomm not following standard tty procedures ripping up connected applications if the bluetooth link is torn down without cleaning up the tty. A patch to expose the bad rfcomm behavior was posted on LKML on 2013 May 15, which also prevents the machine from hanging/crashing by stopping the memory corruption. It does not fix the problem, merely instruments it (and also prevents other subsystems from dying, causing potential data loss). The patch that Peter Hurley wrote was: 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); Attached is the warnings and errors generated when I disable rfcomm from blueman with the above patch showing the correct trace. Without the above patch, corruption will tend to make other functions show incorrect information and tends to completely crash/hang the machine shortly after disconnection. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1144322/comments/35 ------------------------------------------------------------------------ On 2013-07-01T17:10:04+00:00 Tomwij-1 wrote: Seems the upstream patch has been rejected; and on Launchpad, people wait too. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1144322/comments/36 ------------------------------------------------------------------------ On 2013-07-01T17:52:03+00:00 Blc+gentoo wrote: There seems to have been a flame war on this on LKML on what to do when the illegal situation arises. Alex's original patch was to BUG() when the problem occurs, got rejected, but Peter suggested to WARN() on the issue. Either should be fine to notify in syslog/console trace when the improper procedure to tear down the tty occurs. Either way, it's still just instrumenting the bug. There still appears to be no true fixes are in sight. On June 25 LKML there was a message reply to the subject "BUG: tty: memory corruption through tty_release/tty_ldisc_release" that indicates the bug can also be triggered by having the link open and suspend/resume the machine (ouch). I suppose it's just because not many people use BT else this would be a fairly serious bug... Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1144322/comments/37 ------------------------------------------------------------------------ On 2013-07-09T07:19:52+00:00 Blc+gentoo wrote: Saw a message come by on linux-bluetooth/linux-serial mail lists, dated Jul 6 2013 from Gianluka Anzolin who submitted a patch versus 3.10 which may fix this issue, but the same doubts exist - people aren't sure how this piece of software really works :( Though it was suggested that it stopped the crash from happening. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1144322/comments/40 ** Changed in: gentoo Status: Unknown => New ** Changed in: gentoo Importance: Unknown => Medium -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1144322 Title: Kernel Panic in 3.8.0, 3.8.1 & 3.8.2 when diconnecting from network manager, using ppp0 to connect to net To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1144322/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
