With a -pae kernel, freeze during boot when wistron_btns loaded

[Jani Uusitalo]

With my Amilo M7400 and the recent Precise kernels (at least 3.2.0-[10-12] I think), the system freezes during boot with the Ubuntu logo and colored dots on screen (the dots stop progressing), when I have wistron_btns enabled in /etc/modules. I need wistron_btns on this laptop for the wireless to work, which is why I'd like to have it enabled.

This is unrelated to Bug #926007 which I also just filed: the wistron_btns freeze happens even when I'm using fbdev. (With -intel, the #926007 panic and this freeze take turns in who gets to mess with me.)

From what I've gathered so far, it seems that wistron_btns works fine if I manually modprobe it from my desktop, after booting without it. So that's a workaround at least.

I can kill the freeze with Alt+PrtSc+REISUB. I'll provide any additional info needed, though I don't know how to produce logs when the system is frozen.

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: linux-image-3.2.0-12-generic-pae 3.2.0-12.21
ProcVersionSignature: Ubuntu 3.2.0-12.21-generic-pae 3.2.2
Uname: Linux 3.2.0-12-generic-pae i686
AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.24.
ApportVersion: 1.91-0ubuntu1
Architecture: i386
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: jani 1782 F.... pulseaudio
Card0.Amixer.info:
 Card hw:0 'I82801DBICH4'/'Intel 82801DB-ICH4 with CS4299 at irq 10'
   Mixer name : 'Cirrus Logic CS4299 rev 4'
   Components : 'AC97a:43525934'
   Controls : 36
   Simple ctrls : 22
CurrentDmesg:
 [ 35.672075] intel8x0: clocking to 48000
 [ 36.816209] b44 ssb0:0: eth0: Link is up at 100 Mbps, full duplex
 [ 36.816216] b44 ssb0:0: eth0: Flow control is off for TX and off for RX
 [ 36.816551] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
 [ 46.880038] eth0: no IPv6 routers present
Date: Fri Feb 3 13:58:44 2012
EcryptfsInUse: Yes
HibernationDevice: RESUME=UUID=80b87005-5f3a-4290-bba9-d30ef32f8151
InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Release i386 (20111012)
Lsusb:
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
 Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
 Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
 Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
MachineType: FUJITSU SIEMENS AMILO M
PccardctlIdent:
 Socket 0:
   no product info available
PccardctlStatus:
 Socket 0:
   no card
ProcEnviron:
 LANGUAGE=fi:en_US:en
 PATH=(custom, user)
 LANG=fi_FI.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.2.0-12-generic-pae root=UUID=f5b168d7-b4d0-40d8-b76a-8bda4fb90be5 ro quiet splash vt.handoff=7
RelatedPackageVersions:
 linux-restricted-modules-3.2.0-12-generic-pae N/A
 linux-backports-modules-3.2.0-12-generic-pae N/A
 linux-firmware 1.68
RfKill:
 0: phy0: Wireless LAN
  Soft blocked: no
  Hard blocked: yes
SourcePackage: linux
UpgradeStatus: Upgraded to precise on 2011-12-09 (55 days ago)
dmi.bios.date: 06/15/04
dmi.bios.vendor: Phoenix Technologies LTD
dmi.bios.version: R01-S0U
dmi.board.name: AMILO M
dmi.board.vendor: FUJITSU SIEMENS
dmi.board.version: Rev.A
dmi.chassis.type: 1
dmi.chassis.vendor: FUJITSU SIEMENS
dmi.chassis.version: N/A
dmi.modalias: dmi:bvnPhoenixTechnologiesLTD:bvrR01-S0U:bd06/15/04:svnFUJITSUSIEMENS:pnAMILOM:pvr-1:rvnFUJITSUSIEMENS:rnAMILOM:rvrRev.A:cvnFUJITSUSIEMENS:ct1:cvrN/A:
dmi.product.name: AMILO M
dmi.product.version: -1
dmi.sys.vendor: FUJITSU SIEMENS

[Brad Figg (brad-figg)]

Thank you for taking the time to file a bug report on this issue.

However, given the number of bugs that the Kernel Team receives during any development cycle it is impossible for us to review them all. Therefore, we occasionally resort to using automated bots to request further testing. This is such a request.

We have noted that there is a newer version of the development kernel than the one you last tested when this issue was found. Please test again with the newer kernel and indicate in the bug if this issue still exists or not.

You can update to the latest development kernel by simply running the following commands in a terminal window:

    sudo apt-get update
    sudo apt-get upgrade

If the bug still exists, change the bug status from Incomplete to Confirmed. If the bug no longer exists, change the bug status from Incomplete to Fix Released.

If you want this bot to quit automatically requesting kernel tests, add a tag named: bot-stop-nagging.

 Thank you for your help, we really do appreciate it.

[Jani Uusitalo (uusijani)]

3.2.0-13.22 fixed this! Just did three consequtive reboots and a cold boot with wistron_btns. Each booted just fine and the wireless was there, working. To be sure, I also tried 3.2.0-12 again and it still hung during boot. Back to 3.2.0-13 and again no problems. Excellent!

[Jani Uusitalo (uusijani)]

Reopening, there's more to this than I thought.

I thought 3.2.0-14 brought with it a regression, but it turns out it's now the -pae kernels that freeze during boot as I initially described. The thing is, I could've sworn I already ruled this out and also that I did most of yesterday's successful boots with 3.2.0-13-pae, since that was the topmost and default in the Grub menu. So I'm not yet ruling out some funky hardware fault, but for now I'll update the title to reflect how it presently seems: the wistron_btns problem lies with -pae. Non-pae kernels all the way back to 3.2.0-12 now boot fine.

I'm currently running memtest on the laptop just to be sure, although I've done it multiple times before with no issues.

[Brad Figg (brad-figg)]

Thank you for taking the time to file a bug report on this issue.

However, given the number of bugs that the Kernel Team receives during any development cycle it is impossible for us to review them all. Therefore, we occasionally resort to using automated bots to request further testing. This is such a request.

We have noted that there is a newer version of the development kernel than the one you last tested when this issue was found. Please test again with the newer kernel and indicate in the bug if this issue still exists or not.

You can update to the latest development kernel by simply running the following commands in a terminal window:

    sudo apt-get update
    sudo apt-get upgrade

If the bug still exists, change the bug status from Incomplete to Confirmed. If the bug no longer exists, change the bug status from Incomplete to Fix Released.

If you want this bot to quit automatically requesting kernel tests, add a tag named: bot-stop-nagging.

 Thank you for your help, we really do appreciate it.

[Jani Uusitalo (uusijani)]

(My previous comment was after trying 3.2.0-14.)

[Brad Figg (brad-figg)]

Thank you for taking the time to file a bug report on this issue.

However, given the number of bugs that the Kernel Team receives during any development cycle it is impossible for us to review them all. Therefore, we occasionally resort to using automated bots to request further testing. This is such a request.

We have noted that there is a newer version of the development kernel than the one you last tested when this issue was found. Please test again with the newer kernel and indicate in the bug if this issue still exists or not.

You can update to the latest development kernel by simply running the following commands in a terminal window:

    sudo apt-get update
    sudo apt-get upgrade

If the bug still exists, change the bug status from Incomplete to Confirmed. If the bug no longer exists, change the bug status from Incomplete to Fix Released.

If you want this bot to quit automatically requesting kernel tests, add a tag named: bot-stop-nagging.

 Thank you for your help, we really do appreciate it.

[Jani Uusitalo (uusijani)]

After dozens and dozens of boots with the 3.2.0-14 and 3.2.0-15 kernels, here's what I know.

1. This *is* tied to wistron_btns as I reported. Without it, boot never fails (the way I initially reported, though I'll redefine what "fails" means further below).
2. With non-pae kernels, boot never fails.
3. With 3.2.0-14-pae, the boot always fails.
4. A cold boot with 3.2.0-15-pae never fails.
5. A re-boot with 3.2.0-15-pae after a *non-failing* boot never fails.
6. A re-boot of 3.2.0-15-pae, after a *failing* boot (of 3.2.0-14-pae for instance), is *almost* sure to fail. I'd give it a 10% chance of not failing.

If you put it another way, this appears is pretty interesting:
1. You can "break" 3.2.0-15-pae by booting 3.2.0-14-pae first.
2. You "fix" a thus "broken" 3.2.0-15-pae by booting a non-pae kernel.

I suspect this brokenness is actually hidden in the hardware, in something (the wifi key perhaps?) controlled by wistron_btns. Booting 3.2.0-14-pae puts the controller(?) in a "broken" state from which 3.2.0-15-pae can't recover, but a non-pae kernel can. And though 3.2.0-15-pae can't recover a "broken" controller, it also cannot put it into that "broken" state (which is a good turn of development).

So now, about that "fails" part.

I discovered by accident that although the system appears to freeze in boots I referred to as "fails", it has in fact been brought down to *almost* complete halt, but *just* almost. If I'm patient enough to wait, it does actually boot into LDM, from where I can switch to another VT and log in... slooooooowly.

Thus I was able to find out what's going on that makes it so slow:

jani@amilo:~$ head dmesg.fail
stron_btns: Unknown key code 10
[ 1011.554522] wistron_btns: Unknown key code 10
[ 1011.554722] wistron_btns: Unknown key code 10
[ 1011.554921] wistron_btns: Unknown key code 10
[ 1011.555120] wistron_btns: Unknown key code 10
[ 1011.555320] wistron_btns: Unknown key code 10
[ 1011.555518] wistron_btns: Unknown key code 10
[ 1011.555717] wistron_btns: Unknown key code 10
[ 1011.555916] wistron_btns: Unknown key code 10
[ 1011.556134] wistron_btns: Unknown key code 10
jani@amilo:~$ grep wistron dmesg.fail | wc -l
2520

Note that this is unrelated to pressing any actual physical buttons. It' wistron_btns misbehaving under the conditions I described above.

[Brad Figg (brad-figg)]

Thank you for taking the time to file a bug report on this issue.

However, given the number of bugs that the Kernel Team receives during any development cycle it is impossible for us to review them all. Therefore, we occasionally resort to using automated bots to request further testing. This is such a request.

We have noted that there is a newer version of the development kernel than the one you last tested when this issue was found. Please test again with the newer kernel and indicate in the bug if this issue still exists or not.

You can update to the latest development kernel by simply running the following commands in a terminal window:

    sudo apt-get update
    sudo apt-get upgrade

If the bug still exists, change the bug status from Incomplete to Confirmed. If the bug no longer exists, change the bug status from Incomplete to Fix Released.

If you want this bot to quit automatically requesting kernel tests, add a tag named: bot-stop-nagging.

 Thank you for your help, we really do appreciate it.

[Jani Uusitalo (uusijani)]

With both 3.2.0-16 and 3.2.0-17, what I said in #8 still holds, with -16 and -17 behaving just as -15 did. 3.2.0-17 added something interesting though: booting 3.2.0-17-pae in recovery mode "breaks" the -pae's like (non-recovery booting) 3.2.0-14-pae does. To be sure, I tried recovery booting other kernels going back to 3.2.0-14, and couldn't reproduce this with them (not even with 3.2.0-14-pae!) . Recovery booting 3.2.0-17 non-pae also doesn't bring it on, it's just recovery booting 3.2.0-17-pae.

The steps to reproducing this freeze with 3.2.0-17 are:
1. Boot 3.2.0-17-pae in recovery mode.
2. In the recovery menu, select "root".
3. From the root prompt, just reboot.
4. Boot 3.2.0-17-pae (normally).

The "fix" also still holds: just boot a non-pae kernel once, and the pae's again work.

[Brad Figg (brad-figg)]

Thank you for taking the time to file a bug report on this issue.

However, given the number of bugs that the Kernel Team receives during any development cycle it is impossible for us to review them all. Therefore, we occasionally resort to using automated bots to request further testing. This is such a request.

We have noted that there is a newer version of the development kernel than the one you last tested when this issue was found. Please test again with the newer kernel and indicate in the bug if this issue still exists or not.

You can update to the latest development kernel by simply running the following commands in a terminal window:

    sudo apt-get update
    sudo apt-get upgrade

If the bug still exists, change the bug status from Incomplete to Confirmed. If the bug no longer exists, change the bug status from Incomplete to Fix Released.

If you want this bot to quit automatically requesting kernel tests, add a tag named: bot-stop-nagging.

 Thank you for your help, we really do appreciate it.

[Brad Figg (brad-figg)]

Thank you for taking the time to file a bug report on this issue.

However, given the number of bugs that the Kernel Team receives during any development cycle it is impossible for us to review them all. Therefore, we occasionally resort to using automated bots to request further testing. This is such a request.

We have noted that there is a newer version of the development kernel than the one you last tested when this issue was found. Please test again with the newer kernel and indicate in the bug if this issue still exists or not.

You can update to the latest development kernel by simply running the following commands in a terminal window:

    sudo apt-get update
    sudo apt-get upgrade

If the bug still exists, change the bug status from Incomplete to Confirmed. If the bug no longer exists, change the bug status from Incomplete to Fix Released.

If you want this bot to quit automatically requesting kernel tests, add a tag named: bot-stop-nagging.

 Thank you for your help, we really do appreciate it.

[Jani Uusitalo (uusijani)]

3.2.0-17.27 seems to be interchangeable with 3.2.0-17.26 in what I described above, i.e. no change wrt. this bug.

[Joseph Salisbury (jsalisbury)]

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v3.3 kernel[1] (Not a kernel in the daily directory). Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag(Only that one tag, please leave the other tags). This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text.

If this bug is fixed by the mainline kernel, please add the following tag 'kernel-fixed-upstream-KERNEL-VERSION'. For example, if kernel version 3.3-rc5 fixed the issue, the tag would be: 'kernel-fixed-upstream-v3.3-rc5'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream'.
Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[1] http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.3-rc5-precise/

[Jani Uusitalo (uusijani)]

Still present in upstream 3.3.0-030300rc4 as it was in 3.2.0-17.27.

[Joseph Salisbury (jsalisbury)]

This issue appears to be an upstream bug, since you tested the latest upstream kernel. Would it be possible for you to open an upstream bug report at bugzilla.kernel.org [1]? That will allow the upstream Developers to examine the issue, and may provide a quicker resolution to the bug.

If you are comfortable with opening a bug upstream, It would be great if you can report back the upstream bug number in this bug report. That will allow us to link this bug to the upstream report.

[1] https://wiki.ubuntu.com/Bugs/Upstream/kernel

[Luis Henriques (henrix)]

This bug could actually be a duplicate of bug #979253, which uses a different driver (fsam7400) but with a similar problem on -pae kernels. To verify this, could you please try the same workaround described there: to add 'noexec=off' parameter (without the quotes) to your kernel. You can test it by editing your boot parameters directly on grub while booting (see the "Temporarily Add a Kernel Boot Parameter for Testing" section in https://wiki.ubuntu.com/Kernel/KernelBootParameters).

[Jani Uusitalo (uusijani)]

Thanks for commenting, Luis. I booted with noexec=off a couple of times with 3.2.0-24-pae, but it didn't seem to change anything, i.e. the boot still (seemingly) froze when wistron_btns was enabled.

I was unaware of fsam7400 prior to this, so I tried that too, instead of wistron_btns. With fsam7400, the -pae kernel boots fine here even without noexec=off, apart from a "Waiting for network" , and the wireless network never coming up (can't bring it up from the desktop either). So here, at least, the noexec=off workaround isn't needed with fsam7400, though it isn't much good wrt the wireless either.

To reiterate: the only way currently to have this system boot with the wireless working is to have wistron_btns enabled and to use a non-pae kernel.

I should mention that I've upgraded the laptop to Quantal.

I should also mention that Precise's mainstream installation media refused to boot on the laptop. I believe the message was "This kernel requires the following features not present on the CPU: pae". This despite the fact that the -pae kernels, once a system has been installed, *do* boot and work just fine, albeit not with wistron_btns loaded. So currently I'm unsure whether the CPU actually supports pae or not.

[Luis Henriques (henrix)]

So, I've re-read all the comments above (in particular #8) and the only thing at this moment I can really think of (and that you somehow already hint in your comments) is a BIOS issue. The state of your hardware is left in an unclean state and the device driver isn't able to recover from that. And the wistron_btns device driver pretty much invokes some BIOS code in order to do its job, which further corroborates this theory.

Is there a chance that you're not running the latest BIOS for your hardware? Could you check if there is a BIOS upgrade for you laptop?

[Jani Uusitalo (uusijani)]

Ahem. It now looks like non-pae + wistron doesn't work either. But this looks more like a configuration issue on my part, I'll have to investigate it further. It still doesn't freeze or anything, it's just that the wireless doesn't go online.

Luis, there actually was a BIOS upgrade available from Fujitsu [1], thanks for prompting me to look! I flashed the latest revision S0Z in (it was S0U until now), but unfortunately this didn't change the behavior at issue here. (There was no mention of the wireless in manufacturer's changelog either, but those are often incomplete anyway.)

*[1] http://download.ts.fujitsu.com/download/ShowDescription.asp?SoftwareGUID=1968BB6F-7819-4C8C-A488-BAA44C111F7C

[penalvch (penalvch)]

Jani Uusitalo, could you please confirm this issue exists with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ . If the issue remains, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p linux <replace-with-bug-number>

Also, could you please test the latest upstream kernel available following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue. Please do not test the daily folder, but the one all the way at the bottom. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags:
kernel-fixed-upstream
kernel-fixed-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested. For example:
kernel-fixed-upstream-v3.11-rc5

This can be done by clicking on the yellow circle with a black pencil icon next to the word Tags located at the bottom of the bug description. As well, please remove the tag:
needs-upstream-testing

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-VERSION-NUMBER

As well, please remove the tag:
needs-upstream-testing

Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results. Thank you for your understanding.

[Jani Uusitalo (uusijani)]

Hi Christopher.

I was unable to test the Saucy images and the latest mainline kernel, as they refuse to boot/install on the Amilo due to lack of PAE support.

jani@kingugidora:~$ LC_ALL=C sudo dpkg --install linux-image-3.11.0-031100rc6-generic_3.11.0-031100rc6.201308181835_i386.deb
(Reading database ... 818498 files and directories currently installed.)
Unpacking linux-image-3.11.0-031100rc6-generic (from linux-image-3.11.0-031100rc6-generic_3.11.0-031100rc6.201308181835_i386.deb) ...
This kernel does not support a non-PAE CPU.
dpkg: error processing linux-image-3.11.0-031100rc6-generic_3.11.0-031100rc6.201308181835_i386.deb (--install):
subprocess new pre-installation script returned error exit status 1
Examining /etc/kernel/postrm.d .
run-parts: executing /etc/kernel/postrm.d/initramfs-tools 3.11.0-031100rc6-generic /boot/vmlinuz-3.11.0-031100rc6-generic
run-parts: executing /etc/kernel/postrm.d/zz-update-grub 3.11.0-031100rc6-generic /boot/vmlinuz-3.11.0-031100rc6-generic
Errors were encountered while processing:
linux-image-3.11.0-031100rc6-generic_3.11.0-031100rc6.201308181835_i386.deb

I guess the only (unimportant) question remaining is how come I was able to boot -pae kernels on this very same device back in the pre-release times (3.2.0-[<23]) - perhaps those earlier kernels didn't properly detect the lack of PAE?

The wireless now (with the current 3.2.0-52-generic #78-Ubuntu) seems to somehow work without wistron_btns.

I'm not sure how to deal with the tags & bug status in this case, so I'll leave it to your discretion. If you have further ideas to test, I'll be happy to provide, but closing this report (perhaps as 'Invalid') is also fine by me.

[penalvch (penalvch)]

Jani Uusitalo, this bug report is being closed due to your last comment https://bugs.launchpad.net/ubuntu/+source/linux/+bug/926012/comments/22 regarding this being fixed with an update. For future reference you can manage the status of your own bugs by clicking on the current status in the yellow line and then choosing a new status in the revealed drop down box. You can learn more about bug statuses at https://wiki.ubuntu.com/Bugs/Status. Thank you again for taking the time to report this bug and helping to make Ubuntu better. Please submit any future bugs you may find.