Created attachment 596750 [details] Log Description of problem: After having updated system and after each and every system start up, NetworkManager is in flight mode which can be switched off. Then only ethernet can be switched on and off. Wifi can never be switched on. The wifi button stays in off position. Version-Release number of selected component (if applicable): NetworkManager.x86_64 1:0.9.4-6.git20120521.fc16 3.4.2-1.fc16.x86_64 GNOME 3.2.1 How reproducible: Start up system, switch off flight mode and try wifi button Steps to Reproduce: 1. 2. 3. Actual results: No wifi Expected results: Wifi to start up Additional info:
it might be worth taking a look at the dbus package tests from https://bugzilla.redhat.com/show_bug.cgi?id=817851#c8 that seemed to help me if same bug.
Dirk, can you provide the following information (all commands to be run in a terminal)? rfkill list lsmod lspci Sounds like there's something wrong with rfkill handling in the kernel with your machine.
Created attachment 598506 [details] Log
Created attachment 598510 [details] Log Log for latest kernel giving wifi error.
Ok, so the logs indicate that 3.3.8 works, but 3.4.2 does not, correct? Based on the output of the 'rfkill list' command. When you do "rfkill unblock wifi" that should make the wifi device usable again via NM. Also whenever "rfkill list" shows that all wifi switches are "no" for hardblock and softblock, the device should be usable with NM. Is that the case? What kind of laptop is this?
(In reply to comment #5) > Ok, so the logs indicate that 3.3.8 works, but 3.4.2 does not, correct? > Based on the output of the 'rfkill list' command. When you do "rfkill > unblock wifi" that should make the wifi device usable again via NM. Also > whenever "rfkill list" shows that all wifi switches are "no" for hardblock > and softblock, the device should be usable with NM. Is that the case? > > What kind of laptop is this? 1)Yes, correct. 2)No, that does not work. 3)Fujitsu Siemens Amilo A 1630
Are you ever able to get this laptop into a situation where the WiFi switch is *not* hardblocked, as reported by "rfkill list", using the 3.4.x kernels? The two things you can try are flipping the hardware switches (which might be touch-sensitive button near the keyboard too) and by running "sudo rfkill unblock wifi". Basically, we need to get the WiFi rfkill state to be softblocked or completely unblocked, then it's something NetworkManager can deal with. Otherwise it's a kernel driver issue.
(In reply to comment #7) > Are you ever able to get this laptop into a situation where the WiFi switch > is *not* hardblocked, as reported by "rfkill list", using the 3.4.x kernels? > The two things you can try are flipping the hardware switches (which might > be touch-sensitive button near the keyboard too) and by running "sudo rfkill > unblock wifi". > > Basically, we need to get the WiFi rfkill state to be softblocked or > completely unblocked, then it's something NetworkManager can deal with. > Otherwise it's a kernel driver issue. 1) No doesn't work. Upgraded to 3.4.4 kernel. 2) Hardware switch always WiFi on. 3) I'm not using sudo. Do all commands as #. Does that make any difference? Still won't work. WiFi only works with 3.3.8.
Upgraded to 3.4.9-1.fc16.x86_64. Problem persists.
Upgraded to 3.4.9-2.fc16.x86_64. Problem persists.
This might be a regression in the rt2500pci driver. I don't see anything relevant at all in rfkill itself, and the amilo-rfkill driver isn't loaded in either the 3.3.8 or 3.4.X cases. Stanislaw, any idea on this one?
There is upstream rt2500 rfkill related fix: http://marc.info/?l=linux-wireless&m=134643374922507&w=2 Kernel build with above patch and some other rt2x00 fixes is here: http://koji.fedoraproject.org/koji/taskinfo?taskID=4472276 Dirk, does it fix problem for you?
(In reply to comment #12) > There is upstream rt2500 rfkill related fix: > http://marc.info/?l=linux-wireless&m=134643374922507&w=2 > > Kernel build with above patch and some other rt2x00 fixes is here: > http://koji.fedoraproject.org/koji/taskinfo?taskID=4472276 > > Dirk, does it fix problem for you? Upgraded to 3.4.10-1.bz838218.fc16.x86_64. Problem persists.
Newly installed Fedora 17. Without any updates WiFi went well with kernel 3.3.4-5fc17.x86_64. After having updated on new kernel 3.6.1-1.fc17.x86_64., WiFi does not work any more and the same problem persists.
Using kernel 3.6.2-4.fc17.x86_64 problem persists.
Upgraded to kernel 3.6.3-1.fc17.x86_64. Problem persists.
Same computer model, same problem. Wifi was fine from live CD install with 3.3.4-5, yum update to 3.6.9-2 hardware blocked it. Solution for people with other laptops seems to be changing BIOS settings to enable wireless by default. I couldn't find any BIOS setting related to wifi on mine (BIOS 1.03c), and the only BIOS update available from Fujitsu (1.04c) deals only with sound/battery related issues. http://support.ts.fujitsu.com/Download/Showfiles.asp?OSOpenedTree=&IsOSSelected=YES&RHRead=&OS%20Independent%20%20(BIOS,%20Firmware,%20etc.)-Childs=0&OSText=FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF_OS%20Independent%20%20(BIOS,%20Firmware,%20etc.)_True
Is possible that some of you could bisect this problem between v3.3 and v3.4 kernel versions, to find commit which cause breakage. Unfortunately otherwise I do not see chance to fix this. I described how to perform bisection on Fedora here: https://bugzilla.redhat.com/show_bug.cgi?id=637647#c1
(In reply to comment #18) > Is possible that some of you could bisect this problem between v3.3 and v3.4 > kernel versions, to find commit which cause breakage. Unfortunately > otherwise I do not see chance to fix this. I described how to perform > bisection on Fedora here: > https://bugzilla.redhat.com/show_bug.cgi?id=637647#c1 Will try to get on it this weekend, I'm quite willing to learn but I'm at the bottom of the learning curve so it may have to wait till January.
(In reply to comment #18) > Is possible that some of you could bisect this problem between v3.3 and v3.4 > kernel versions, to find commit which cause breakage. Unfortunately > otherwise I do not see chance to fix this. I described how to perform > bisection on Fedora here: > https://bugzilla.redhat.com/show_bug.cgi?id=637647#c1 On my machine there are these kernels: 3.6.3-1.fc17.x86_64 3.6.2-4.fc17.x86_64 3.3.4-5.fc17.x86_64 (last working one) Do you want me to bisect the last good one 3.3.4-5.fc17.x86_64 with the latest bad one 3.6.3-1.fc17.x86_64 or version before that 3.6.2-4.fc17.x86_64? It would be most helpful if you could advise on what kernel to boot and what to do on $. The quoted guide is not all clear to me. Would that be right booting 3.3.4-5.fc17.x86_64? $ git bisect start 3.6.3-1.fc17.x86_64 3.3.4-5.fc17.x86_64 -- $ git bisect run make test
According to comment 0 first bad is 3.4, so you have to bisect between v3.3 and v3.4, but perhaps this have to be confirmed - if 3.4 is bad. $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git $ git checkout -b b3.4 v3.4 compile and boot kernel -test then if v3.4 is really bad and v3.3 is last know good: $ git bisect start $ git bisect bad # HEAD is v3.4 $ git bisect good v3.3 then compile and install and test, continue that until find bad commit. Note some revisions could not compile, so use "git bisect skip" then. See for more details: http://www.kernel.org/pub/software/scm/git/docs/git-bisect.html
(In reply to comment #21) > According to comment 0 first bad is 3.4, so you have to bisect between v3.3 > and v3.4, but perhaps this have to be confirmed - if 3.4 is bad. > > $ git clone > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git > $ git checkout -b b3.4 v3.4 > > compile and boot kernel -test > > then if v3.4 is really bad and v3.3 is last know good: > > $ git bisect start > $ git bisect bad # HEAD is v3.4 > $ git bisect good v3.3 > > then compile and install and test, continue that until find bad commit. Note > some revisions could not compile, so use "git bisect skip" then. See for > more details: > http://www.kernel.org/pub/software/scm/git/docs/git-bisect.html Please see below. Booted 3.6.3-1.fc17.x86_64. $ git checkout -b b3.4 v3.4 gave fatal error. [root@localhost usuario1]# git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Cloning into 'linux-2.6'... remote: Counting objects: 2828846, done. remote: Compressing objects: 100% (427959/427959), done. remote: Total 2828846 (delta 2375121), reused 2827220 (delta 2373510) Receiving objects: 100% (2828846/2828846), 579.77 MiB | 55 KiB/s, done. Resolving deltas: 100% (2375121/2375121), done. Checking out files: 100% (41507/41507), done. [root@localhost usuario1]# git checkout -b b3.4 v3.4 fatal: Not a git repository (or any parent up to mount point /home) Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
You should change directory $ cd linux-2.6
(In reply to comment #23) > You should change directory > > $ cd linux-2.6 Going through first bisect as I write. Would you know of "compile-heavy" sections I can just deselect safely in menuconfig to speed it up ? Thanks
You should compile out as much things that you don't need as possible. But be careful, to do not remove things that are needed to boot (root fs, disk controller driver). Possible remove list include : infiniband, bluetooth, v4l (media), network drivers and options, filesystems ...
Well... Done with the bisecting! Was long and bloody but a great learning experience (never compiled a kernel before). The culprit per git-bisect : http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=ded81f6ba934e792e441f20178683608cbc0b5cb Will attach bisect log. Observations : - Bug was not present up to at least 3.4.0-rc2 although bad commit is in 3.3.0. Maybe that will make sense to you. - On the 3 or 4 last bad kernels, boot and shutdown would freeze/hang on the fedora logo (not white fill-in progression, logo after that), sometimes after user login. Often I'd lose patience after 10+ minutes, cut power, reboot, and the hanging would be almost non existent. Hope this helps, I'm available for more bug hunting if needed. Thanks
Created attachment 676587 [details] git-bisect log
> Observations : - Also, I noticed in the kernel config under "Device drivers -> X86 Platform specific device drivers" (in menuconfig), there is an option call 'Fujitsu-Siemens Amilo rfkill support'. But it seems to be only for two other Amilo models, not the A1630.
(In reply to comment #26) > The culprit per git-bisect : > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit; > h=ded81f6ba934e792e441f20178683608cbc0b5cb [snip] > - Bug was not present up to at least 3.4.0-rc2 although bad commit is in 3.3.0. Maybe that will make sense to you. No really, perhaps we have more issues. So does it mean the problem do not exist also on released 3.4 or it was introduced somewhere between 3.4-rc2 and 3.4 ? > - On the 3 or 4 last bad kernels, boot and shutdown would freeze/hang on the > fedora logo (not white fill-in progression, logo after that), sometimes > after user login. Often I'd lose patience after 10+ minutes, cut power, > reboot, and the hanging would be almost non existent. Unfortunately, this is because you hit another issue. This crash introduced in 81f6ba934e792e441f20178683608cbc0b5cb (3.5-rc1) was then fixed in a6f38ac3cc853189705006cc1e0f17ce8467a1df (3.6-rc1). So on last 4 or 3 steps you bisected another problem, not the original one, so incorrectly mark compiled kernel as bad. You can continue bisection based on history. First prepare fix for crash: git show a6f38ac3cc853189705006cc1e0f17ce8467a1df > fix.patch Then restart bisection based of history - perform the same commands on git directory, you remember you hit actual rfkill bug, but not the crash. For example: git bisect start # good: [c16fa4f2ad19908a47c63d8fa436a1178438c7e7] Linux 3.3 git bisect good c16fa4f2ad19908a47c63d8fa436a1178438c7e7 # bad: [a0d271cbfed1dd50278c6b06bead3d00ba0a88f9] Linux 3.6 git bisect bad a0d271cbfed1dd50278c6b06bead3d00ba0a88f9 # bad: [0b87da68a0f0a7bf7f7446cf64f92e672bd68ef8] Merge git://www.linux-watchdog.org/linux-watchdog git bisect bad 0b87da68a0f0a7bf7f7446cf64f92e672bd68ef8 # bad: [0b87da68a0f0a7bf7f7446cf64f92e672bd68ef8] Merge git://www.linux-watchdog.org/linux-watchdog git bisect bad 0b87da68a0f0a7bf7f7446cf64f92e672bd68ef8 # good: [0c9aac08261512d70d7d4817bd222abca8b6bdd6] Merge branch 'slab/for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/penberg/linux Then when you unsure if you hit crash, check if crash commit is there, for example: git log net/mac80211/iface.c | grep ded81f6ba934e792e441f20178683608cbc0b5cb If it is present apply the fix: patch -p1 < fix.patch and build and test kernel as usual. However I think, it will be probably better to just start bisect again, between two consecutive major releases, i.e. between 3.3 and 3.4, instead of 3.3 and 3.6 . Such way you make probability smaller of hitting different issues and abuse bisection of actual problem.
Oh, one more thing. Next time you will hit different issue than you bisect, for example compiled kernel will not boot, or it could not be build, just use "git bisect skip", so git will choose different commit to test.
(In reply to comment #23) > You should change directory > > $ cd linux-2.6 Did that. [root@localhost usuario1]# cd linux-2.6 [root@localhost linux-2.6]# git checkout -b b3.4 v3.4 Checking out files: 100% (27109/27109), done. Switched to a new branch 'b3.4' Not sure--anything more needed or do you have the answer to fix the problem? If you need me to continue, I need more guidance what to do step by step. Also, shall I run yum update since with each new kernel the oldest gets deleted?
I need true bad commit of this problem, see previous comments.
> I need true bad commit of this problem, see previous comments. It will be a couple weeks before I can get on it again. Dirk, starting from beginning is going to take you 10+ hours, as it seems like me you'll need to learn how to use git, compile kernels and such. Though feel free to do so if you want to learn all this stuff. If so you can also start from comment #29.
I do not see possibility to fix this bug :-(