Bug 838218 - Fujitsu Amilo A1630 WiFi rfkill cannot be unblocked with 3.4.x
Fujitsu Amilo A1630 WiFi rfkill cannot be unblocked with 3.4.x
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
17
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: Stanislaw Gruszka
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-07-07 07:26 EDT by Dirk Foerster
Modified: 2013-06-12 05:25 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-06-12 05:25:16 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Log (3.43 KB, text/plain)
2012-07-07 07:26 EDT, Dirk Foerster
no flags Details
Log (4.93 KB, text/plain)
2012-07-16 13:29 EDT, Dirk Foerster
no flags Details
Log (4.92 KB, text/plain)
2012-07-16 13:46 EDT, Dirk Foerster
no flags Details
git-bisect log (3.91 KB, text/plain)
2013-01-10 18:25 EST, Holdem Cowfield
no flags Details

  None (edit)
Description Dirk Foerster 2012-07-07 07:26:36 EDT
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:
Comment 1 collura 2012-07-14 01:35:52 EDT
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.
Comment 2 Dan Williams 2012-07-16 11:21:52 EDT
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.
Comment 3 Dirk Foerster 2012-07-16 13:29:07 EDT
Created attachment 598506 [details]
Log
Comment 4 Dirk Foerster 2012-07-16 13:46:54 EDT
Created attachment 598510 [details]
Log

Log for latest kernel giving wifi error.
Comment 5 Dan Williams 2012-07-16 18:32:42 EDT
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?
Comment 6 Dirk Foerster 2012-07-17 17:37:49 EDT
(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
Comment 7 Dan Williams 2012-07-20 16:04:44 EDT
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.
Comment 8 Dirk Foerster 2012-07-24 06:56:56 EDT
(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.
Comment 9 Dirk Foerster 2012-08-21 04:07:56 EDT
Upgraded to 3.4.9-1.fc16.x86_64. Problem persists.
Comment 10 Dirk Foerster 2012-09-02 07:43:42 EDT
Upgraded to 3.4.9-2.fc16.x86_64. Problem persists.
Comment 11 Josh Boyer 2012-09-05 10:15:04 EDT
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?
Comment 12 Stanislaw Gruszka 2012-09-11 03:48:53 EDT
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?
Comment 13 Dirk Foerster 2012-09-13 03:48:18 EDT
(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.
Comment 14 Dirk Foerster 2012-10-14 16:33:44 EDT
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.
Comment 15 Dirk Foerster 2012-10-26 15:05:23 EDT
Using kernel 3.6.2-4.fc17.x86_64 problem persists.
Comment 16 Dirk Foerster 2012-10-28 10:03:18 EDT
Upgraded to kernel 3.6.3-1.fc17.x86_64. Problem persists.
Comment 17 Holdem Cowfield 2012-12-08 09:07:26 EST
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
Comment 18 Stanislaw Gruszka 2012-12-12 07:36:59 EST
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
Comment 19 Holdem Cowfield 2012-12-13 13:03:40 EST
(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.
Comment 20 Dirk Foerster 2012-12-16 08:52:10 EST
(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
Comment 21 Stanislaw Gruszka 2012-12-17 03:23:10 EST
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
Comment 22 Dirk Foerster 2012-12-23 15:00:10 EST
(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).
Comment 23 Stanislaw Gruszka 2013-01-07 03:44:39 EST
You should change directory

$ cd linux-2.6
Comment 24 Holdem Cowfield 2013-01-07 04:50:04 EST
(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
Comment 25 Stanislaw Gruszka 2013-01-07 05:48:55 EST
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 ...
Comment 26 Holdem Cowfield 2013-01-10 18:16:28 EST
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
Comment 27 Holdem Cowfield 2013-01-10 18:25:10 EST
Created attachment 676587 [details]
git-bisect log
Comment 28 Holdem Cowfield 2013-01-10 18:32:02 EST
> 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.
Comment 29 Stanislaw Gruszka 2013-01-14 06:12:51 EST
(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.
Comment 30 Stanislaw Gruszka 2013-01-14 06:16:32 EST
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.
Comment 31 Dirk Foerster 2013-01-22 05:04:09 EST
(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?
Comment 32 Stanislaw Gruszka 2013-01-22 05:29:44 EST
I need true bad commit of this problem, see previous comments.
Comment 33 Holdem Cowfield 2013-01-22 08:04:03 EST
> 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.
Comment 34 Stanislaw Gruszka 2013-06-12 05:25:16 EDT
I do not see possibility to fix this bug :-(

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