Description of problem: Sometimes when I try to send some files to my PC from my phone via bluetooth kernel hangs. Everything freezes, so i reboot with power button. My dongle is SerteC bluetooth dongle. Version-Release number of selected component (if applicable): kernel 3.6.8-2.fc17.x86_64 How reproducible: Send some files to PC with my dongle. Steps to Reproduce: 1. Get files to send on phone 2. Send them to PC 3. Some files are sent others are 0 sized and then kernel panics Actual results: Sending sometimes goes OK, but with crashing at next sending attempt. Expected results: Smooth file transfer. Additional info: I did setup kdump and i have vmcore file. I will add it as an attachment. Backtrace that i got through crash utility: PID: 1038 TASK: ffff880134964530 CPU: 0 COMMAND: "X" #0 [ffff88013fc03570] machine_kexec at ffffffff8103e985 #1 [ffff88013fc035e0] crash_kexec at ffffffff810c39c8 #2 [ffff88013fc036b0] oops_end at ffffffff8161ffa8 #3 [ffff88013fc036e0] no_context at ffffffff8161468d #4 [ffff88013fc03740] __bad_area_nosemaphore at ffffffff81614877 #5 [ffff88013fc03790] bad_area_nosemaphore at ffffffff816148a9 #6 [ffff88013fc037a0] do_page_fault at ffffffff81622b2f #7 [ffff88013fc038b0] page_fault at ffffffff8161f3e5 [exception RIP: ksize+51] RIP: ffffffff81178683 RSP: ffff88013fc03960 RFLAGS: 00010016 RAX: 000001880009e200 RBX: ffffeb880009e200 RCX: 0000000000000800 RDX: ffffea0000000000 RSI: 0000000000000000 RDI: ffffea0002788f80 RBP: ffff88013fc03970 R8: ffff88013fc16ac0 R9: 0000000000016ac0 R10: 0000000000000000 R11: ffff88013b402c00 R12: ffffea0002788f80 R13: 00000000ffffffff R14: ffff88013b402900 R15: 0000000000000580 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #8 [ffff88013fc03978] __alloc_skb at ffffffff815057bf #9 [ffff88013fc039d8] hci_reassembly at ffffffffa03ea593 [bluetooth] #10 [ffff88013fc03a38] hci_recv_fragment at ffffffffa03ea6f1 [bluetooth] #11 [ffff88013fc03a78] btusb_bulk_complete at ffffffffa02ba79d [btusb] #12 [ffff88013fc03aa8] usb_hcd_giveback_urb at ffffffff81439505 #13 [ffff88013fc03ad8] ehci_urb_done at ffffffff814513c5 #14 [ffff88013fc03b18] qh_completions at ffffffff8145178d #15 [ffff88013fc03bb8] ehci_work at ffffffff814536d2 #16 [ffff88013fc03c58] ehci_irq at ffffffff81454136 #17 [ffff88013fc03d28] usb_hcd_irq at ffffffff8143852c #18 [ffff88013fc03d48] handle_irq_event_percpu at ffffffff810e8874 #19 [ffff88013fc03d98] handle_irq_event at ffffffff810e8a51 #20 [ffff88013fc03dc8] handle_fasteoi_irq at ffffffff810ebb99 #21 [ffff88013fc03de8] handle_irq at ffffffff810160ff #22 [ffff88013fc03e28] do_IRQ at ffffffff8162884a #23 [ffff88013fc03ec8] __do_softirq at ffffffff81065470 #24 [ffff88013fc03f48] call_softirq at ffffffff81627ffc #25 [ffff88013fc03f60] do_softirq at ffffffff81016205 #26 [ffff88013fc03f80] irq_exit at ffffffff810658b5 #27 [ffff88013fc03f90] smp_apic_timer_interrupt at ffffffff8162893e #28 [ffff88013fc03fb0] apic_timer_interrupt at ffffffff8162790a --- <IRQ stack> --- #29 [ffff880135f853c8] apic_timer_interrupt at ffffffff8162790a [exception RIP: __schedule+1895] RIP: ffffffff8161da17 RSP: ffff880135f85478 RFLAGS: 00000282 RAX: ffff880135f84000 RBX: ffff880133fe5c00 RCX: 000000820c60b830 RDX: ffff88013fc13cc0 RSI: ffff880134964530 RDI: ffff880134964530 RBP: ffff880135f854d8 R8: 0000000000000001 R9: 0000000000000001 R10: 0000000000000001 R11: 0000000000000001 R12: ffffffff81094edf R13: ffff880135f853f8 R14: ffff880133fe5c00 R15: ffff880134964588 ORIG_RAX: ffffffffffffff10 CS: 0010 SS: 0018 #30 [ffff880135f85470] __schedule at ffffffff8161d3fb #31 [ffff880135f854e0] __cond_resched at ffffffff8108f0ea #32 [ffff880135f85500] _cond_resched at ffffffff8161dad0 #33 [ffff880135f85510] mutex_lock at ffffffff8161c74d #34 [ffff880135f85530] drm_fb_helper_pan_display at ffffffffa00a56e6 [drm_kms_helper] #35 [ffff880135f85580] fb_pan_display at ffffffff8131ca51 #36 [ffff880135f855a0] bit_update_start at ffffffff8132e199 #37 [ffff880135f855c0] fbcon_switch at ffffffff8132dc0c #38 [ffff880135f856b0] redraw_screen at ffffffff81399f89 #39 [ffff880135f856e0] fbcon_blank at ffffffff8132c38a #40 [ffff880135f857e0] do_unblank_screen at ffffffff8139b406 #41 [ffff880135f85800] unblank_screen at ffffffff8139b550 #42 [ffff880135f85810] bust_spinlocks at ffffffff812e83e9 #43 [ffff880135f85820] oops_end at ffffffff8161ff3f #44 [ffff880135f85850] die at ffffffff810177a8 #45 [ffff880135f85880] do_trap at ffffffff8161f890 #46 [ffff880135f858e0] do_invalid_op at ffffffff81014e6b #47 [ffff880135f85980] invalid_op at ffffffff81627d7b [exception RIP: intel_gtt_map_memory+339] RIP: ffffffff813b9313 RSP: ffff880135f85a38 RFLAGS: 00010202 RAX: 0000000000000000 RBX: ffff8800af3eb020 RCX: 0000000000000002 RDX: 0000000000000000 RSI: ffff8800af3eb400 RDI: ffff8800af3eb000 RBP: ffff880135f85a88 R8: ffff88013fc16ac0 R9: ffff8800af3eb000 R10: 00000000000040b3 R11: 0000000000000000 R12: 00000000000000a0 R13: ffff8800af3eb000 R14: ffff8800af1cbf00 R15: 0000000000000080 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #48 [ffff880135f85a90] i915_gem_gtt_prepare_object at ffffffffa00cd032 [i915] #49 [ffff880135f85aa0] i915_gem_object_bind_to_gtt at ffffffffa00c3950 [i915] #50 [ffff880135f85b20] i915_gem_object_pin at ffffffffa00c6b1f [i915] #51 [ffff880135f85b60] pin_and_fence_object.isra.6 at ffffffffa00ca730 [i915] #52 [ffff880135f85ba0] i915_gem_execbuffer_reserve.isra.7 at ffffffffa00caad1 [i915] #53 [ffff880135f85c00] i915_gem_do_execbuffer.isra.12 at ffffffffa00cb279 [i915] #54 [ffff880135f85d30] i915_gem_execbuffer2 at ffffffffa00cc4e1 [i915] #55 [ffff880135f85d80] drm_ioctl at ffffffffa00693c3 [drm] #56 [ffff880135f85ea0] do_vfs_ioctl at ffffffff811a20e9 #57 [ffff880135f85f30] sys_ioctl at ffffffff811a2669 #58 [ffff880135f85f80] system_call_fastpath at ffffffff81626e69 RIP: 000000351f4ea307 RSP: 00007fff41e0cf18 RFLAGS: 00013202 RAX: 0000000000000010 RBX: ffffffff81626e69 RCX: 0000000000000000 RDX: 00007fff41e0d1d0 RSI: 0000000040406469 RDI: 0000000000000008 RBP: 00007fff41e0d1d0 R8: 0000000002f95140 R9: 000000000000040e R10: 0000000000b38090 R11: 0000000000003246 R12: 00000000ffffffff R13: 0000000000000008 R14: 0000000040406469 R15: 0000000000000000 ORIG_RAX: 0000000000000010 CS: 0033 SS: 002b
Created attachment 656040 [details] Crash details Archive: CrashDetails.zip Length Date Time Name --------- ---------- ----- ---- 1488 12-02-2012 16:56 cpuinfo.txt 4322 12-02-2012 16:56 dmidecore.txt 18968 12-02-2012 16:57 lshw.txt 2760 12-02-2012 16:57 lsmod.txt 46204651 12-02-2012 16:58 vmcore --------- ------- 46232189 5 files
Also my machine is Toshiba Satellite L300
I'm seeing this too, on 3.6.9-2.fc17.x86_64. I never had any problems with Fedora 16 kernels. The panics seem to happen in unrelated kernel functions (tcp, graphics, etc), so I think there could be some funky memory access going on. Kernel driver btusb. The Bluetooth dongle is a generic one.
Still seeing this after upgrading to Fedora 18(kernel 3.7.4-204.fc18.x86_64)
Are you still seeing this with the 3.8.2 update?
Yes, I still see this with 3.8.2. In my case, I am trying to use bluetooth audio, and I usually get panics if I remove the btusb dongle or suspend and resume after having used the dongle at some point.
(In reply to comment #6) > Yes, I still see this with 3.8.2. In my case, I am trying to use bluetooth > audio, and I usually get panics if I remove the btusb dongle or suspend and > resume after having used the dongle at some point. Please attach the backtrace you're seeing.
(In reply to comment #7) > > Please attach the backtrace you're seeing. I would if I knew how -- my screen goes black and fills with white text and the whole thing locks up. My laptop doesn't have a serial port, so I'm not sure how else to get the backtrace.
(In reply to comment #8) > (In reply to comment #7) > > > > Please attach the backtrace you're seeing. > > I would if I knew how -- my screen goes black and fills with white text and > the whole thing locks up. My laptop doesn't have a serial port, so I'm not > sure how else to get the backtrace. Take a picture of the white text and attach it here. If it scrolls off the top of the screen, try adding "pause_on_oops=60" to your kernel command line.
(In reply to comment #9) > Take a picture of the white text and attach it here. If it scrolls off the > top of the screen, try adding "pause_on_oops=60" to your kernel command line. Okay -- to save time, I've just uploaded them to a web album, I hope that is okay (let me know if you'd rather me upload them individually here): http://www.smugmug.com/gallery/28412486_fsDzfQ The one with the white text was first, before I put the pause_on_oops. I then triggered it again (use bluetooth dongle, then suspend & resume) and got the ones with the orange text. It seems to have locked up before reaching the bottom of the trace though. You can see that alsa-source is calling some snd ioctls, which may be because I was using bluetooth audio before suspending.
None of those seem to show an oops related to bluetooth. Pictures 1 and 4 seem to show oopses stemming from sunrpc code. Picture 5 seems to be related to wireless internet (ath5k). All of them seem to be because your memory is corrupted. So this only happens when you use your bluetooth dongle? What device is it (lsusb -v)? Do you get any sort of corruption like this if you suspend/resume without ever plugging the device in? When you say "remove btusb dongle" do you mean you just pull it out of the machine, or do you close any programs using it and remove the btusb module?
Yes, this only happens when I use the bluetooth dongle (both plug in and then use bluetooth functionality). If I pull it out of the machine, probably 30% of the time it will panic immediately (no suspend required). Usually though, I leave it plugged in while I suspend & resume, but that is still enough to trigger a panic 90% of the time (within 60 seconds of resuming). I think it is related to this kernel bug, but the patches attached there didn't fix the problem when I built a kernel with them: https://bugzilla.kernel.org/show_bug.cgi?id=50541 That bug documents a null pointer dereference within btusb code, but as you can see, I am getting corruption in other kernel memory. Perhaps there's some kind of double free, or btusb is trying to free memory that never belonged to it.
Created attachment 709836 [details] lsusb -v output
Still not fixed, im on 3.8.3-201.fc18.x86_64
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 18 kernel bugs. Fedora 18 has now been rebased to 3.11.4-101.fc18. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 19, and are still experiencing this issue, please change the version to Fedora 19. If you experience different issues, please open a new bug report for those.
I don't get kernel panic on Fedora 19 kernel 3.11.1-200.fc19.x86_64. I can use hcitool and hciconfig with the dongle, but KDE doesn't see it. When I insert it bluetooth device hci0 is down when i run hciconfig. Then i just hciconfig hci0 up. All commands work only as root so I think that there is permission issue. I can't test any further because of bug above, so if there is any hci commands i will be glad to test them.
Closing this out because the kernel issue is resolved. For the KDE issue, I would suggest opening a bug against one of the KDE components.