Bug 877545 - Dell Latitude E6420 - Radio kill switch causes lockup during boot - Maybe bluetooth related?
Dell Latitude E6420 - Radio kill switch causes lockup during boot - Maybe blu...
Status: CLOSED DUPLICATE of bug 854069
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
17
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-11-16 15:30 EST by Nick Lamb
Modified: 2013-01-08 15:37 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-01-08 15:37:20 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Nick Lamb 2012-11-16 15:30:51 EST
Description of problem:

Hardware is a laptop, Dell Latitude E6420. The release F17 kernel boots (installing wasn't entirely trivial but it worked). Subsequent update kernels (e.g. 3.6.6) lock up during late startup, e.g. commonly while the Fedora logo is appearing just before the login screen.

BUT I found out just now it turns out this doesn't happen if I switch the hardware Radio kill switch to its enable (ie radios are working) mode, rather than where I usually leave it set (radios disabled) because I have GigE in my house and rarely use WiFi elsewhere.

Version-Release number of selected component (if applicable):

No problem in: kernel-3.3.4-5.fc17.x86_64

Problem in all more recent F17 kernels e.g.: kernel-3.6.6-1.fc17.x86_64


How reproducible:

Always locks up if radios are disabled. Exactly when varies (just as progress bar fills, just after that when logo appears, or during the "flash" of the logo)

Steps to Reproduce:
1. From a perfectly working Fedora 17 on this exact hardware, set radio kill switch to disable radios, boot affected kernel
  
Actual results:

It locks up before you reach the login screen.

Expected results:

It should work just the same as with radios enabled, (but of course, minus WiFi, bluetooth and any other radios affected)

Additional info:

This seems like it _could_ be a bluetooth defect. With 'verbose debug' as my boot parameters obviously I get no graphical logos etc. but I do see Bluetooth related messages shortly before it locks up. There are no ERRORs from the bluetooth subsystem, nor from any other plausibly relevant subsystem. It is, of course, difficult to paste text of the crashed system, but I can try to take a digital camera photo & upload that if someone is sure it will help?
Comment 1 Josh Boyer 2013-01-07 16:05:11 EST
Are you still seeing this with the 3.6.10 or newer kernel updates?  There was a fix for a few Dell machines that went into 3.6.8 kernel that may help.

If this is still happening with 3.6.10 or newer, please remove 'rhgb' and 'quiet' from the kernel parameter list and attach a picture of any error messages or kernel panics that occur.
Comment 2 Nick Lamb 2013-01-08 06:12:35 EST
Still happening with 3.6.10-2.fc17.x86-64

Removing 'rhgb' and 'quiet' gets me the expected scrolling messages, followed swiftly by an entirely blank screen (perhaps, crashing more or less simultaneously with X starting?). I will spare you from the useless JPEG photo of a blank screen.
Comment 3 Josh Boyer 2013-01-08 08:26:37 EST
After reviewing a number of other bugs, this looks like it might be a duplicate of 854069.  Does your machine have a BCM4313 wlan adapter?
Comment 4 Nick Lamb 2013-01-08 14:47:31 EST
Yes, there's a BCM4313 (PCI ID 14e4:4727) fitted to this laptop,

I have installed the recent upgrade to 3.6.11-1.fc17.x86-64 and the problem still exists with this kernel out of the box.

However based on your hint about the BCM4313 I removed the module bcma.ko which, so far as I can tell, is one element of the BCM4313 driver and the part which is loaded based on the PCI ID match, and I confirmed that with this module removed the system boots regardless of the position of the radio kill switch, although obviously (since there is no longer a driver) WiFi does not work once this drastic step is taken.

This is clearly not a fix, but it's indicative. So I agree that this is very similar to, and thus perhaps identical with, the BCM4313 symptoms in bug 854069 and I'm content to see this closed as a DUP on that basis if you prefer.

I also agree that commit 82d8eba358badb466a4e988ecabf0668a8d92e9c sounds, in principle relevant to my scenario.

Unfortunately my employer intends to take away my Linux laptop and require me to use Linux from a VM on a Windows laptop, if that happens I will not be able to contribute to this bug, so I may never see this resolved, best of luck fixing it even if I never get to enjoy the fix.
Comment 5 Josh Boyer 2013-01-08 15:37:20 EST

*** This bug has been marked as a duplicate of bug 854069 ***

Note You need to log in before you can comment on or make changes to this bug.