Bug 877545

Summary:	Dell Latitude E6420 - Radio kill switch causes lockup during boot - Maybe bluetooth related?
Product:	[Fedora] Fedora	Reporter:	Nick Lamb <redhat>
Component:	kernel	Assignee:	Kernel Maintainer List <kernel-maint>
Status:	CLOSED DUPLICATE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	17	CC:	gansalmon, itamar, jonathan, kernel-maint, madhu.chinakonda
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-01-08 20:37:20 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Nick Lamb 2012-11-16 20:30:51 UTC

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 21:05:11 UTC

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 11:12:35 UTC

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 13:26:37 UTC

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 19:47:31 UTC

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 20:37:20 UTC


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