Red Hat Bugzilla – Full Text Bug Listing
|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>|
|Version:||17||CC:||gansalmon, itamar, jonathan, kernel-maint, madhu.chinakonda|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2013-01-08 15:37:20 EST||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
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.