Bug 34272 - Kernel panic when issuing "echo disabled > /proc/acpi/ibm/bluetooth" during startup
Summary: Kernel panic when issuing "echo disabled > /proc/acpi/ibm/bluetooth" during s...
Status: CLOSED UNREPRODUCIBLE
Alias: None
Product: Drivers
Classification: Unclassified
Component: Bluetooth (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: drivers_bluetooth@kernel-bugs.osdl.org
URL:
Keywords:
Depends on:
Blocks: 32012
  Show dependency tree
 
Reported: 2011-05-03 05:29 UTC by Stefan Bauer
Modified: 2011-05-09 09:33 UTC (History)
3 users (show)

See Also:
Kernel Version: 2.6.39-rc5
Subsystem:
Regression: Yes
Bisected commit-id:

Attachments
lsusb -v (23.56 KB, text/plain)
2011-05-03 05:29 UTC, Stefan Bauer 		Details
The promised photo showing the panic message (687.61 KB, image/jpeg)
2011-05-03 05:31 UTC, Stefan Bauer 		Details
Kernel .config (67.56 KB, text/plain)
2011-05-03 05:33 UTC, Stefan Bauer 		Details
Add an attachment (proposed patch, testcase, etc.)

Description Stefan Bauer 2011-05-03 05:29:55 UTC 
Created attachment 56292 [details]
lsusb -v

I've configured acpid to issue the above given command when I press Fn+F6 to disable the BT module built into my laptop. Running 2.6.39-rc5, the kernel panics when I press Fn+F6 during startup, preferably when X/gdm is starting. I wasn't able to reproduce the problem once the system was "settled".

I never faced this problem in 2.6.38 or any prior version.

Attached you find a photo (sorry for the bad quality, but it should be readable) of the messages and the lsusb output.

Steps to reproduce:
- Turn on the laptop. The bluetooth module is activated by default.
- Press Fn+F6 after acpid is started, i.e. while gdm is starting
- watch the kernel panic

Hardware:
- Thinkpad Z60m

Software:
- Gentoo Linux
- if you need version numbers of some particular userspace programs, let me know
Comment 1 Stefan Bauer 2011-05-03 05:31:00 UTC 
Created attachment 56302 [details]
The promised photo showing the panic message
Comment 2 Stefan Bauer 2011-05-03 05:33:40 UTC 
Created attachment 56312 [details]
Kernel .config
Comment 3 Stefan Bauer 2011-05-03 05:58:10 UTC 
OK, now I was able to trigger the bug during a running KDE session. So I withdraw my statement that the problem isn't reproducible once the boot process is finished.

I also suspect this bug being the reason that entering Suspend to RAM fails with a flashing Caps Lock LED since 2.6.39-rc5. Suspend to RAM worked flawlessly with .38.
Comment 4 Rafael J. Wysocki 2011-05-04 16:38:47 UTC 
Does 2.6.39-rc6 fix it?
Comment 5 Stefan Bauer 2011-05-05 01:26:02 UTC 
(In reply to comment #4)
> Does 2.6.39-rc6 fix it?

Apparently, yes. I can't reproduce the panic with 2.6.39-rc6, and suspend works again. Thank you!
Comment 6 Florian Mickler 2011-05-09 09:32:55 UTC 
Thanks for the update.
Note You need to log in before you can comment on or make changes to this bug.