Bug 11895

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.