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)
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.
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
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?
:-) 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.
hmm, please run "grep . /sys/firmware/acpi/interrupts/*" both before and after pressing the mute key and attach the output.
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
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.
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.
ping Rafael Varela Pet.
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.
ping Rafael Varela Pet again...
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
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.
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
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.
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.
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.
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
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?
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"
> > 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
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
ping ...
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.
please try the patch at http://patchwork.kernel.org/patch/38246/ and see if it helps.
ping Rafael Varela Pet :)
no response from the bug reporter for more than a month. close it.
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
using the original DSDT is okay, thanks.
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".
Created attachment 23188 [details] dmesg output with kernel 2.6.31 I forgot to attach the dmesg output with kernel 2.6.31
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.
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.
Confirmed. After upgrading to BIOS version 1.14C problem is gone. Thanks to Jean-Louis Biasini for providing the necessary feedback.