Bug 13065 (fenomeno) - FSC Amilo Pi 1505 reboots after pressing "silent mode" special key
Summary: FSC Amilo Pi 1505 reboots after pressing "silent mode" special key
Status: REJECTED INVALID
Alias: fenomeno
Product: Drivers
Classification: Unclassified
Component: Platform (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Zhang Rui
URL:
Keywords:
Depends on:
Blocks: 56331
  Show dependency tree
 
Reported: 2009-04-11 19:27 UTC by Rafael Varela Pet
Modified: 2013-04-09 06:23 UTC (History)
3 users (show)

See Also:
Kernel Version: 2.6.26-1-amd64
Subsystem:
Regression: No
Bisected commit-id:


Attachments
Output of acpidump command (96.68 KB, text/plain)
2009-04-11 19:27 UTC, Rafael Varela Pet
Details
patch: show query method (696 bytes, patch)
2009-04-23 08:26 UTC, Zhang Rui
Details | Diff
dmesg output after turning on and off "silent mode" (76.31 KB, text/x-log)
2009-05-18 17:32 UTC, Rafael Varela Pet
Details
customized DSDT (168.34 KB, application/octet-stream)
2009-05-19 03:49 UTC, Zhang Rui
Details
dmesg output with custom DSDT (27.82 KB, application/zip)
2009-05-26 19:44 UTC, Rafael Varela Pet
Details
customized DSDT (168.26 KB, application/octet-stream)
2009-05-27 06:42 UTC, Zhang Rui
Details
dmesg output with the second custom DSDT (79.56 KB, text/plain)
2009-06-04 21:03 UTC, Rafael Varela Pet
Details
dmesg output. kernel 2.6.29 with custom DSDT (123.31 KB, text/x-log)
2009-06-06 20:57 UTC, Rafael Varela Pet
Details
demsg output with kernel config and dsdt from the running kernel (62.48 KB, application/zip)
2009-07-08 15:31 UTC, Rafael Varela Pet
Details
dmesg output with kernel 2.6.31 (37.17 KB, text/plain)
2009-09-27 08:35 UTC, Rafael Varela Pet
Details

Description Rafael Varela Pet 2009-04-11 19:27:01 UTC
Created attachment 20940 [details]
Output of acpidump command

One or two seconds after pressing "silent mode" special key, and after one of the LEDs confirms mode switching, system reboots inmediately.

In single user mode, the same happens. It seems to appear a message, probably from the kernel, but lasts for a very long time so it's impossible to read it.


Software platforms tested:

Debian Etch  / Kernel 2.6.18 (not sure about this)
Debian Etch  / Kernel 2.6.24-etchnhalf

Debian Lenny / Kernel 2.6.26-1
Debian Lenny / Kenel 2.6.29 (sid)


Hardware platform:

BIOS Information
        Vendor: FUJITSU SIEMENS
        Version: 1.08C

Base Board Information
        Manufacturer: FUJITSU SIEMENS
        Product Name: AMILO Pi 1505

00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub (rev 03)
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03)
00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02)
00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 02)
00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 02)
00:1c.2 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 3 (rev 02)
00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 (rev 02)
00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 (rev 02)
00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 (rev 02)
00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 (rev 02)
00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2)
00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 02)
00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller (rev 02)
00:1f.2 SATA controller: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA AHCI Controller (rev 02)
00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 02)
05:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection (rev 02)
06:04.0 FireWire (IEEE 1394): O2 Micro, Inc. Firewire (IEEE 1394) (rev 02)
06:04.2 SD Host controller: O2 Micro, Inc. Integrated MMC/SD Controller (rev 01)
06:04.3 Mass storage controller: O2 Micro, Inc. Integrated MS/xD Controller (rev 01)
06:05.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
Comment 1 ykzhao 2009-04-12 12:27:35 UTC
Will you please kill the process that is using /proc/acpi/event and see whether the issue still exits?(Use the command of "lsof /proc/acpi/events" to get the process using /proc/acpi/event).
   Thanks.
Comment 2 Rafael Varela Pet 2009-04-13 16:50:26 UTC
Thank you for yor support

As I said in my initial report, I've already tested it in single-user mode, so there's almost any process running.

Anyway, I've used the command "lsof /proc/acpi/events" to be sure that anybody was using /proc/acpi/event, and it didn't show anything, as expected.

While trying this, I tried a slight variation on the test:

After enabling silent mode, instead of pushing the "Enter" key several times, I waited for a while. Nothing happened, so it seemed that it wasn't going to crash. 

I entered the "sync" command and it crashed again, but this time it didn't reboot and i could see some kernel messages which said something like this:

  CPU0: Machine Check Exception

  RIP !INEXACT!  10: <ffffffff80429e0e> (_spin_lock ....

  TSC 1e6962ba7c
  This is not a software problem!
  Run through mcelog --ascii to decode and ....

  HARDWARE ERROR
  CPU1: Machine Check Exception:

  TSC 1e6962becc

  Kernel panic - not syncing: Machine check


As you can see it says that is not a software problem, but this is a dual-boot machine and it does not crash while running Windows XP.

Also, it does not crash while waiting in the GRUB bootloader menu (and I cannot activate silent mode either)

I'll install mcelog to give you the information suggested by the kernel messages
Comment 3 Len Brown 2009-04-14 02:02:44 UTC
unclear if the machine exception is related to the mute button issue --
it is possible that you were just "lucky":-)
can you reproduce the MCE?

Also, does the machine survive if it runs memtest overnight?
Comment 4 Rafael Varela Pet 2009-04-14 20:32:47 UTC
:-) maybe the MCE was a question of luck, I cannot reproduce it, but I can reproduce the reboot every time I want. It is just a question of enabling "silent mode" and run some commands.

In single user mode, sometimes I have to type more commands, sometime less, to reproduce the crash. While running GNOME, the failure occurs almost immediately. 

In single user mode, if I don't enter any commands, the system seems to survive for a long time. I can even disable "silent mode" and enter back in runlevel 2 and then into GNOME without problems.

I can try to run a memtest if you think it would be useful, but:

1. This machine *never* crashed since I bought (more than two years ago), it doesn't matter if I run Windows XP or Debian.

2. It crashes in "silent mode" only while running Linux, since the first version of Debian installed.

3. It is a long standing issue. I didn't reported it until now because it is not a critical issue and I wanted to see what happens with newer kernel versions.
Comment 5 Zhang Rui 2009-04-15 01:57:22 UTC
hmm, please run "grep . /sys/firmware/acpi/interrupts/*" both before and after pressing the mute key and attach the output.
Comment 6 Rafael Varela Pet 2009-04-15 15:45:34 UTC
Before pressing the mute key:

/sys/firmware/acpi/interrupts/error:0
/sys/firmware/acpi/interrupts/ff_gbl_lock:0
/sys/firmware/acpi/interrupts/ff_pmtimer:0
/sys/firmware/acpi/interrupts/ff_pwr_btn:0
/sys/firmware/acpi/interrupts/ff_rt_clk:0
/sys/firmware/acpi/interrupts/ff_slp_btn:0
/sys/firmware/acpi/interrupts/gpe00:0
/sys/firmware/acpi/interrupts/gpe01:0
/sys/firmware/acpi/interrupts/gpe02:0
/sys/firmware/acpi/interrupts/gpe03:0
/sys/firmware/acpi/interrupts/gpe04:0
/sys/firmware/acpi/interrupts/gpe05:0
/sys/firmware/acpi/interrupts/gpe06:0
/sys/firmware/acpi/interrupts/gpe07:0
/sys/firmware/acpi/interrupts/gpe08:0
/sys/firmware/acpi/interrupts/gpe09:0
/sys/firmware/acpi/interrupts/gpe0A:0
/sys/firmware/acpi/interrupts/gpe0B:0
/sys/firmware/acpi/interrupts/gpe0C:0
/sys/firmware/acpi/interrupts/gpe0D:0
/sys/firmware/acpi/interrupts/gpe0E:0
/sys/firmware/acpi/interrupts/gpe0F:0
/sys/firmware/acpi/interrupts/gpe10:0
/sys/firmware/acpi/interrupts/gpe11:0
/sys/firmware/acpi/interrupts/gpe12:0
/sys/firmware/acpi/interrupts/gpe13:0
/sys/firmware/acpi/interrupts/gpe14:0
/sys/firmware/acpi/interrupts/gpe15:0
/sys/firmware/acpi/interrupts/gpe16:0
/sys/firmware/acpi/interrupts/gpe17:0
/sys/firmware/acpi/interrupts/gpe18:0
/sys/firmware/acpi/interrupts/gpe19:151
/sys/firmware/acpi/interrupts/gpe1A:0
/sys/firmware/acpi/interrupts/gpe1B:0
/sys/firmware/acpi/interrupts/gpe1C:0
/sys/firmware/acpi/interrupts/gpe1D:0
/sys/firmware/acpi/interrupts/gpe1E:0
/sys/firmware/acpi/interrupts/gpe1F:0
/sys/firmware/acpi/interrupts/gpe_all:151
/sys/firmware/acpi/interrupts/sci:151


I was unable to read the file while in "silent mode" because the system reboots immediately alfter running the 'grep' command.

This is the result after enabling "silent mode" for more than a minute (I didn't run any command during this period of time) and then disabling it:

/sys/firmware/acpi/interrupts/error:0
/sys/firmware/acpi/interrupts/ff_gbl_lock:0
/sys/firmware/acpi/interrupts/ff_pmtimer:0
/sys/firmware/acpi/interrupts/ff_pwr_btn:0
/sys/firmware/acpi/interrupts/ff_rt_clk:0
/sys/firmware/acpi/interrupts/ff_slp_btn:0
/sys/firmware/acpi/interrupts/gpe00:0
/sys/firmware/acpi/interrupts/gpe01:0
/sys/firmware/acpi/interrupts/gpe02:0
/sys/firmware/acpi/interrupts/gpe03:0
/sys/firmware/acpi/interrupts/gpe04:0
/sys/firmware/acpi/interrupts/gpe05:0
/sys/firmware/acpi/interrupts/gpe06:0
/sys/firmware/acpi/interrupts/gpe07:0
/sys/firmware/acpi/interrupts/gpe08:0
/sys/firmware/acpi/interrupts/gpe09:0
/sys/firmware/acpi/interrupts/gpe0A:0
/sys/firmware/acpi/interrupts/gpe0B:0
/sys/firmware/acpi/interrupts/gpe0C:0
/sys/firmware/acpi/interrupts/gpe0D:0
/sys/firmware/acpi/interrupts/gpe0E:0
/sys/firmware/acpi/interrupts/gpe0F:0
/sys/firmware/acpi/interrupts/gpe10:0
/sys/firmware/acpi/interrupts/gpe11:0
/sys/firmware/acpi/interrupts/gpe12:0
/sys/firmware/acpi/interrupts/gpe13:0
/sys/firmware/acpi/interrupts/gpe14:0
/sys/firmware/acpi/interrupts/gpe15:0
/sys/firmware/acpi/interrupts/gpe16:0
/sys/firmware/acpi/interrupts/gpe17:0
/sys/firmware/acpi/interrupts/gpe18:0
/sys/firmware/acpi/interrupts/gpe19:159
/sys/firmware/acpi/interrupts/gpe1A:0
/sys/firmware/acpi/interrupts/gpe1B:0
/sys/firmware/acpi/interrupts/gpe1C:0
/sys/firmware/acpi/interrupts/gpe1D:0
/sys/firmware/acpi/interrupts/gpe1E:0
/sys/firmware/acpi/interrupts/gpe1F:0
/sys/firmware/acpi/interrupts/gpe_all:159
/sys/firmware/acpi/interrupts/sci:159
Comment 7 Rafael Varela Pet 2009-04-17 15:44:18 UTC
One additional comment:

Booting with "acpi=off" prevents the system from entering in "silent mode" (i.e. the corresponding LED doesn't lit after pressing the "mute" key).

In this mode the system didn't crashed so far, but I'll keep trying.
Comment 8 Zhang Rui 2009-04-23 08:26:04 UTC
Created attachment 21090 [details]
patch: show query method

please apply this patch, uncomment the line /* #define DEBUG */
 in drivers/acpi/ec.c and rebuild your kernel.
and attach the dmesg output after pressing the query method.
Comment 9 Zhang Rui 2009-05-05 02:16:33 UTC
ping Rafael Varela Pet.
Comment 10 Rafael Varela Pet 2009-05-05 17:52:09 UTC
I'm, still here. Sorry for the delay. I've been a bit busy last days.

I hope I will be able to give you the requested information this week.
Comment 11 Zhang Rui 2009-05-18 09:22:57 UTC
ping Rafael Varela Pet again...
Comment 12 Rafael Varela Pet 2009-05-18 17:32:13 UTC
Created attachment 21413 [details]
dmesg output after turning on and off "silent mode"

	
Thank you for your interest in this issue and sorry (again) for the delay.

I'm not sure I understand what "after pressing the query method" means. The attachment contains "dmesg" output in single-user mode, running the patched 2.6.26-2-amd64 Debian kernel after turning on and off "silent mode".

I hope this is the information you requested. Let me know if I'm wrong.

Regards
Comment 13 Zhang Rui 2009-05-19 03:49:45 UTC
Created attachment 21421 [details]
customized DSDT

please
apply this customized DSDT,
set CONFIG_ACPI_DEBUG,
rebuild your kernel
reboot with "acpi.debug_layer=0xffffffff acpi.debug_level=0x07"
and then attach the dmesg output after press the "silent mode" key on and off.
note that you should get no reboot this time.
Comment 14 Rafael Varela Pet 2009-05-26 19:44:06 UTC
Created attachment 21563 [details]
dmesg output with custom DSDT

This is the dmesg output before and after activating silent mode.

In silent mode, the systems still reboots. I think I have followed your instructions correctly. The boot log confirms that the DSDT it's being overrided:

[    0.087236] ACPI: Override [DSDT-F36_____], this is unsafe: tainting kernel
[    0.087306] ACPI: Table DSDT replaced by host OS

The boot options seem to be correct too:

[    0.000000] Command line: root=/dev/mapper/rigel-root acpi.debug_layer=0xffffffff acpi.debug_level=0x07 ro single
Comment 15 Zhang Rui 2009-05-27 06:42:34 UTC
Created attachment 21579 [details]
customized DSDT

so the laptop reboots after you press the silent key for the first time, right?
please try this one and re-do the test.
Comment 16 Rafael Varela Pet 2009-06-04 21:03:14 UTC
Created attachment 21755 [details]
dmesg output with the second custom DSDT

Until now, the laptop rebooted after pressing silent key for the first time *and* after trying to run any command.

With the latest DSDT the system reboots right after pressing the key (this happened two times, but in one of the three attempts the system survived, so I could get the dmesg output.
Comment 17 Zhang Rui 2009-06-05 01:34:18 UTC
please redo the test on a newer kernel, say 2.6.29.
2.6.26 is a little bit old to get the debug info I want.
Comment 18 Rafael Varela Pet 2009-06-06 20:57:54 UTC
Created attachment 21780 [details]
dmesg output. kernel 2.6.29 with custom DSDT

Sure. Here's the dmesg output with an stock kernel verswion 2.6.29.4
Comment 19 Zhang Rui 2009-06-08 02:13:01 UTC
In the test mentioned in comment #18, the laptop reboots soon after you press the "silent mode" key for the second time, right?
If yes, please build in the processor module and boot with boot option "processor.ignore_ppc=1", does the problem still exist like before?
Comment 20 Rafael Varela Pet 2009-06-08 21:27:50 UTC
No, in the test in comment #18 the system didn't reboot, it survived. I've repeated it. This time the system crashed (no reboot) the first time I pressed the key.

After that, I booted with option "processor.ignore_ppc=1". This time the system got frozen after showing the debug info (no reboot, no kernel panic or similar messages). I had to press the key three times (i.e:silent mode on, silent mode off and silent mode on again)

I'm sorry but I don't understand what you mean with "build in the processor module"
Comment 21 Zhang Rui 2009-06-18 09:10:34 UTC
> 
> I'm sorry but I don't understand what you mean with "build in the processor
> module"

in the kernel config file, CONFIG_ACPI_PROCESSOR=y
Comment 22 Rafael Varela Pet 2009-06-22 17:11:47 UTC
Ok. I understand now. 

The test was made with CONFIG_ACPI_PROCESSOR=m and "processor.ko" loaded into memory

I will test it again with CONFIG_ACPI_PROCESSOR=y
Comment 23 Zhang Rui 2009-07-06 03:40:49 UTC
ping ...
Comment 24 Rafael Varela Pet 2009-07-08 15:31:26 UTC
Created attachment 22257 [details]
demsg output with kernel config and dsdt from the running kernel 

I've repeated the test with the processor module compiled into the kernel

Zip contents are:

-Output of dmesg before entering silent mode
-Output of dmesg before turning silent mode on and off
-Running kernel configuration
-Running kernel dsdt contents
-Kernel command line parameters

The last three items are supplied just to avoid misunderstandings.

Just for the record, the kernel crashed again after trying to run a "ls" command while in silent mode.
Comment 25 Zhang Rui 2009-07-30 01:00:27 UTC
please try the patch at http://patchwork.kernel.org/patch/38246/ and see if it helps.
Comment 26 Zhang Rui 2009-08-12 06:20:26 UTC
ping Rafael Varela Pet :)
Comment 27 Zhang Rui 2009-09-03 06:52:38 UTC
no response from the bug reporter for more than a month.
close it.
Comment 28 Rafael Varela Pet 2009-09-13 10:30:55 UTC
Sorry for that. I was on vacation with no easy access to my computer

The patch at http://patchwork.kernel.org/patch/38246/ does noy apply cleanly to kernel 2.6.29.4, but I adapted the patch to give it a try... with no luck.

I'm downloading kernel 2,6.31 to repeat the test. Please, tell if you want me to test it with the custom DSDT or with the DSDT that came with the laptop
Comment 29 Zhang Rui 2009-09-14 05:21:14 UTC
using the original DSDT is okay, thanks.
Comment 30 Rafael Varela Pet 2009-09-14 16:49:35 UTC
Tested with kernel 2.6.31 and the original DSDT. I didn't apply the patch at http://patchwork.kernel.org/patch/38246/ because it is already incorporated in kernel version 2.6.31

Similar result as in previous kernels: in single-user mode, system reboots inmediately after trying to run any command while in "silent mode".
Comment 31 Rafael Varela Pet 2009-09-27 08:35:29 UTC
Created attachment 23188 [details]
dmesg output with kernel 2.6.31

I forgot to attach the dmesg output with kernel 2.6.31
Comment 32 Rafael Varela Pet 2011-02-13 17:45:16 UTC
This problem still persists with Debian Kernel 2.6.32-5-amd64

Would you consider reopening this bug? I can provide you with information of the latest stable official kernel.
Comment 33 Rafael Varela Pet 2011-02-15 07:36:11 UTC
I've contacted with another FSC Pi1505 owner that doesn't suffer this bug. It seems that a BIOS upgrade will solve the problem.

I will upgrade my BIOS and post the result here.
Comment 34 Rafael Varela Pet 2011-02-15 17:16:17 UTC
Confirmed. After upgrading to BIOS version 1.14C problem is gone.

Thanks to Jean-Louis Biasini for providing the necessary feedback.

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