Bug 448618

Summary: Unable to use wireless Intel 4965 if Thinkpad T61 booted with rf switch off
Product: [Fedora] Fedora Reporter: Alain Lafontaine <alafontaine>
Component: kernelAssignee: John W. Linville <linville>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 9CC: kernel-maint, nhorman
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-06-12 17:44:50 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
lspci result
none
lsusb result
none
dmesg output with rf killswitch off
none
dmesg output with rf killswitch on
none
dmesg output when switching rf killswitch on to off none

Description Alain Lafontaine 2008-05-27 21:08:08 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b5) Gecko/2008043010 Fedora/3.0-0.60.beta5.fc9 Firefox/3.0b5

Description of problem:
Power up thinkpad with rf switch ON:  network manager detects all wireless networks and works correctly

Power up thinkpad with rf switch OFF: network manager does not detect any wireless network, only shows wired network adapter.  Change switch position to ON: only bluethoot activates, network manager never detects card or wireless networks

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


How reproducible:
Always


Steps to Reproduce:
1.Power up laptop with rf switch off
2.
3.

Actual Results:
No wireless networks or wireless cards in network manager

Expected Results:
Wireless cards and networks appear in Network Manager.  Connect to wireless network.

Additional info:
dmesg output when switch rf switch on and off:

RF Switch ON:

hub 1-0:1.0: unable to enumerate USB device on port 1
usb 3-1: new full speed USB device using uhci_hcd and address 6
usb 3-1: configuration #1 chosen from 1 choice
usb 3-1: New USB device found, idVendor=0a5c, idProduct=2110
usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 3-1: Product: BCM2045B
usb 3-1: Manufacturer: Broadcom Corp


RF Switch OFF:

usb 3-1: USB disconnect, address 6

Comment 1 Nicolas Chauvet (kwizart) 2008-05-27 21:35:15 UTC
This bug has been assigned to the wrong component.

Can you provide an output of theses command. 
(or the smolt profile for your laptop)
/sbin/lspci
/sbin/lsusb

This also seems useful, a "full" dmesg output. (once with RFKS on, and the other
off) and also dmesg |tail when switch goes from ON to OFF.
 (Pick "Create a New Attachment" to upload each file )

Note that we usually say that RF kill switch (Radio Frequency Kill switch) is
OFF when you can use your wireless, whereas is it is ON when wireless is disabled.



Comment 2 Alain Lafontaine 2008-05-27 23:08:18 UTC
Created attachment 306852 [details]
lspci result

Comment 3 Alain Lafontaine 2008-05-27 23:08:40 UTC
Created attachment 306853 [details]
lsusb result

Comment 4 Alain Lafontaine 2008-05-27 23:09:15 UTC
Created attachment 306854 [details]
dmesg output with rf killswitch off

Comment 5 Alain Lafontaine 2008-05-27 23:09:44 UTC
Created attachment 306855 [details]
dmesg output with rf killswitch on

Comment 6 Alain Lafontaine 2008-05-27 23:10:32 UTC
Created attachment 306856 [details]
dmesg output when switching rf killswitch on to off

Comment 7 John W. Linville 2008-05-28 12:55:51 UTC
Can you replicate this issue with the kernels here?

   http://koji.fedoraproject.org/koji/buildinfo?buildID=50669

Comment 8 Alain Lafontaine 2008-05-28 14:00:06 UTC
Booted the new kernel with the rf killswitch off, logged in then system hung
with caps lock led flashing.

Booted the new kernel with rf killswitch on, system working fine, no wireless,
switch rf kill switch off still no wireless but system did not hang. 

Comment 9 John W. Linville 2008-06-12 17:44:50 UTC

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