Subject : regression: keyboard dead after reboot on Toshiba Portege 4000 Submitter : Andrey Borzenkov <arvidjaar@mail.ru> Date : 2008-10-28 19:05 References : http://marc.info/?l=linux-acpi&m=122522085418555&w=4 This entry is being used for tracking a regression from 2.6.27. Please don't close it until the problem is fixed in the mainline.
Handled-By : Andrey Borzenkov <arvidjaar@mail.ru> Patch : http://marc.info/?l=linux-kernel&m=122547719810921&w=4
Created attachment 18737 [details] dmesg output
Created attachment 18738 [details] acpidump from Toshiba Portege 4000
Created attachment 18739 [details] dmidecode from Toshiba Portege 4000
Notify-Also : Ingo Molnar <mingo@elte.hu> Notify-Also : Avi Kivity <avi@redhat.com>
On Monday, 10 of November 2008, Andrey Borzenkov wrote: > On Sunday 09 November 2008, Rafael J. Wysocki wrote: > > This message has been generated automatically as a part of a report > > of recent regressions. > > > > The following bug entry is on the current list of known regressions > > from 2.6.27. Please verify if it still should be listed and let me know > > (either way). > > > > it is fixed in rc4 > > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11895
this bug was closed not because the workaround in comment #1 was applied, nor because the root cause of the keyboard issue was found, but because ACPI reset as default was reverted: commit 8d00450d296dedec9ada38d43b83e79cca6fd5a3 Author: Eduardo Habkost <ehabkost@redhat.com> Date: Tue Nov 4 12:52:44 2008 -0200 Revert "x86: default to reboot via ACPI" This reverts commit c7ffa6c26277b403920e2255d10df849bd613380.
decoding the FADT in the acpidump... [070h 112 4] Flags (decoded below) : 000006A5 bit 10 is set, which is the RESET_REG_SUP bit. So according the the ACPI spec, we should indeed be using the ACPI reset register for this box. re: cutoff dates to not use ACPI reset... the DSDT asks the OS if it is XP \_OSI ("Windows 2001") even though the sticker on the box is for Win2k. So you'd think this box is new enough... dmidecode shows the box is 5 years old BIOS Information Vendor: TOSHIBA Version: Version 2.10 Release Date: 12/15/2003 According to the Toshiba web site, 2.10 is indeed, the latest BIOS. I suspect the issue on this particular box is indeed an input issue. ie. Linux is doing something with the keyboard that the BIOS does not expect, and thus it fails to come back after ACPI reset.
Further Decoding of the FADT shows that ACPI reset on the Toshiba Portege 4000 will write the value FE to IO address B1 [070h 112 4] Flags (decoded below) : 000006A5 WBINVD is operational : 1 WBINVD does not invalidate : 0 All CPUs support C1 : 1 C2 works on MP system : 0 Power button is generic : 0 Sleep button is generic : 1 RTC wakeup not fixed : 0 RTC wakeup/S4 not possible : 1 32-bit PM Timer : 0 Docking Supported : 1 Reset Register Supported : 1 [074h 116 12] Reset Register : <Generic Address Structure> [074h 116 1] Space ID : 01 (SystemIO) [075h 117 1] Bit Width : 08 [076h 118 1] Bit Offset : 00 [077h 119 1] Access Width : 00 [078h 120 8] Address : 00000000000000B1 [080h 128 1] Value to cause reset : FE [081h 129 3] Reserved : 000000 Andrey, Perhaps you can boot from livecd or single-user and scribble on this IO port to see if it resets then? # outb 0xFE 0xB1 Also, please attach the lspci -v output for the toshiba.
Hi, Andrey What Len said in comment #9 is right. On your laptop the RESET_REG_SUP bit of FADT flag is set and the RESET_REG is also definied. It indicates that the acpi reboot mechanism is supported. But unfortunately the keyboard can't work after acpi reboot. Will you please have an opportunity to try the box can work well after reboot on windows? From the acpidump it seems that the revision of FADT is 2, which indicates that it follows the ACPI 1.0 spec. Maybe we should bypass the acpi reboot mechanism if the BIOS follows the ACPI 1.0 spec. Thanks.