Hi Matthew,
GIT commit 660e34cebf0a11d54f2d5dd8838607452355f321 x86: reorder
reboot method preferences causes my Acer Aspire One to hang on
shutdown/reboot.
I'm running the original Aspire One A110, BIOS version 3310.
Booting with reboot=k or reboot=b both work; so it looks like an
ACPI firmware bug.
I printed out the FADT bits that were relevant---it claims revision 4
in the header, and the ACPI_FADT_RESET_REGISTER bit is set in the
flags. The values of the reset register's address and width look
reasonable (address 3321 in IO space, width 8 offset 0)
I'm not sure of the best fix: one could I suppose add the Aspire
One to the list of machines that need BIOS reboot. Is there a
cleaner fix?
Peter C
--
Dr Peter Chubb peter DOT chubb AT nicta.com.au
http://www.ertos.nicta.com.au ERTOS within National ICT Australia
All things shall perish from under the sky/Music alone shall live, never to die
On Wed, Jun 22, 2011 at 08:38:08PM +1000, Peter Chubb wrote:
> I printed out the FADT bits that were relevant---it claims revision 4
> in the header, and the ACPI_FADT_RESET_REGISTER bit is set in the
> flags. The values of the reset register's address and width look
> reasonable (address 3321 in IO space, width 8 offset 0)
Irritating. Ok, let's see if we can figure this out. Can you put the
system's acpidump output somewhere? Also, if you boot with
init=/bin/bash, what does writing the FADT reset value to 3321 do?
--
Matthew Garrett | [email protected]
On Wed, Jun 22, 2011 at 08:38:08PM +1000, Peter Chubb wrote:
>
> Hi Matthew,
> GIT commit 660e34cebf0a11d54f2d5dd8838607452355f321 x86: reorder
> reboot method preferences causes my Acer Aspire One to hang on
> shutdown/reboot.
Also, shutdown? Really?
--
Matthew Garrett | [email protected]
>>>>> "Matthew" == Matthew Garrett <[email protected]> writes:
Matthew> On Wed, Jun 22, 2011 at 08:38:08PM +1000, Peter Chubb wrote:
>>
>> Hi Matthew, GIT commit 660e34cebf0a11d54f2d5dd8838607452355f321
>> x86: reorder reboot method preferences causes my Acer Aspire One to
>> hang on shutdown/reboot.
Matthew> Also, shutdown? Really?
Sorry, shutdown -r (which is reboot really).
Writing the reset value `6' to the reset port 3321 in single user mode
makes the screen go blank, and the machine to become totally
unresponsive. The power light remains on. But the machine does *not*
reboot.
I've put up the ACPI tables at
http://www.cse.unsw.edu.au/~peterc/AspireOneACPI
The relevant part of the FADT is:
[074h 0116 12] Reset Register : <Generic Address Structure>
[074h 0116 1] Space ID : 01 (SystemIO)
[075h 0117 1] Bit Width : 08
[076h 0118 1] Bit Offset : 00
[077h 0119 1] Access Width : 01
[078h 0120 8] Address : 0000000000000CF9
[080h 0128 1] Value to cause reset : 06
--
Dr Peter Chubb http://www.gelato.unsw.edu.au peterc AT gelato.unsw.edu.au
http://www.ertos.nicta.com.au ERTOS within National ICT Australia
On 06/22/2011 04:50 PM, Peter Chubb wrote:
>>>>>> "Matthew" == Matthew Garrett <[email protected]> writes:
>
> Matthew> On Wed, Jun 22, 2011 at 08:38:08PM +1000, Peter Chubb wrote:
>>>
>>> Hi Matthew, GIT commit 660e34cebf0a11d54f2d5dd8838607452355f321
>>> x86: reorder reboot method preferences causes my Acer Aspire One to
>>> hang on shutdown/reboot.
>
> Matthew> Also, shutdown? Really?
>
> Sorry, shutdown -r (which is reboot really).
>
>
> Writing the reset value `6' to the reset port 3321 in single user mode
> makes the screen go blank, and the machine to become totally
> unresponsive. The power light remains on. But the machine does *not*
> reboot.
>
> I've put up the ACPI tables at
> http://www.cse.unsw.edu.au/~peterc/AspireOneACPI
>
> The relevant part of the FADT is:
> [074h 0116 12] Reset Register : <Generic Address Structure>
> [074h 0116 1] Space ID : 01 (SystemIO)
> [075h 0117 1] Bit Width : 08
> [076h 0118 1] Bit Offset : 00
> [077h 0119 1] Access Width : 01
> [078h 0120 8] Address : 0000000000000CF9
>
> [080h 0128 1] Value to cause reset : 06
>
OK, so this machine is actively broken and needs a quirk.
Which "reboot=" options work on this machine?
-hpa
>>>>> "H" == H Peter Anvin <[email protected]> writes:
H> On 06/22/2011 04:50 PM, Peter Chubb wrote:
>>>>>>> "Matthew" == Matthew Garrett <[email protected]> writes:
>>
Matthew> On Wed, Jun 22, 2011 at 08:38:08PM +1000, Peter Chubb wrote:
>>>>
>>>> Hi Matthew, GIT commit 660e34cebf0a11d54f2d5dd8838607452355f321
>>>> x86: reorder reboot method preferences causes my Acer Aspire One
>>>> to hang on shutdown/reboot.
>>
Matthew> Also, shutdown? Really?
>>
>> Sorry, shutdown -r (which is reboot really).
>>
>>
>> Writing the reset value `6' to the reset port 3321 in single user
>> mode makes the screen go blank, and the machine to become totally
>> unresponsive. The power light remains on. But the machine does
>> *not* reboot.
>>
>> I've put up the ACPI tables at
>> http://www.cse.unsw.edu.au/~peterc/AspireOneACPI
>>
>> The relevant part of the FADT is: [074h 0116 12] Reset Register :
>> <Generic Address Structure> [074h 0116 1] Space ID : 01 (SystemIO)
>> [075h 0117 1] Bit Width : 08 [076h 0118 1] Bit Offset : 00 [077h
>> 0119 1] Access Width : 01 [078h 0120 8] Address : 0000000000000CF9
>>
>> [080h 0128 1] Value to cause reset : 06
>>
H> OK, so this machine is actively broken and needs a quirk.
H> Which "reboot=" options work on this machine?
b and k
t, p and a all result in a machine hang with the power light on, the
backlight off, and no apparent activity anywhere.
H> -hpa
H> --
Dr Peter Chubb peter DOT chubb AT nicta.com.au
http://www.ertos.nicta.com.au ERTOS within National ICT Australia
All things shall perish from under the sky/Music alone shall live, never to die
On Fri, Jul 01, 2011 at 09:10:33AM +1000, Peter Chubb wrote:
> t, p and a all result in a machine hang with the power light on, the
> backlight off, and no apparent activity anywhere.
Having PCI reboot be broken does make me wonder whether there's
something about the hardware state that confuses it.
--
Matthew Garrett | [email protected]
On 06/30/2011 04:58 PM, Matthew Garrett wrote:
> On Fri, Jul 01, 2011 at 09:10:33AM +1000, Peter Chubb wrote:
>
>> t, p and a all result in a machine hang with the power light on, the
>> backlight off, and no apparent activity anywhere.
>
> Having PCI reboot be broken does make me wonder whether there's
> something about the hardware state that confuses it.
>
It might be a RESET versus INIT difference... if the "PCI reboot" (which
is what "ACPI reboot") points to, it might end up pulling INIT, whereas
the keyboard controller pulls RESET.
RESET would forcibly initialize the hardware state of the machine,
obviously...
-hpa
On Thu, Jun 30, 2011 at 05:18:01PM -0700, H. Peter Anvin wrote:
> It might be a RESET versus INIT difference... if the "PCI reboot" (which
> is what "ACPI reboot") points to, it might end up pulling INIT, whereas
> the keyboard controller pulls RESET.
>
> RESET would forcibly initialize the hardware state of the machine,
> obviously...
I guess I'm going to have to go back and retest the XP behaviour. I'd
expect this machine to be using the ACPI vector there too.
--
Matthew Garrett | [email protected]
>>>>> "Matthew" == Matthew Garrett <[email protected]> writes:
Matthew> On Thu, Jun 30, 2011 at 05:18:01PM -0700, H. Peter Anvin
Matthew> wrote:
>> It might be a RESET versus INIT difference... if the "PCI reboot"
>> (which is what "ACPI reboot") points to, it might end up pulling
>> INIT, whereas the keyboard controller pulls RESET.
>>
>> RESET would forcibly initialize the hardware state of the machine,
>> obviously...
Matthew> I guess I'm going to have to go back and retest the XP
Matthew> behaviour. I'd expect this machine to be using the ACPI
Matthew> vector there too.
This machine was only ever shipped with Linux (Linpus) on it, AFAIK.
Peter C
--
Dr Peter Chubb http://www.gelato.unsw.edu.au peterc AT gelato.unsw.edu.au
http://www.ertos.nicta.com.au ERTOS within National ICT Australia
On 06/30/2011 05:31 PM, Peter Chubb wrote:
>
> Matthew> I guess I'm going to have to go back and retest the XP
> Matthew> behaviour. I'd expect this machine to be using the ACPI
> Matthew> vector there too.
>
> This machine was only ever shipped with Linux (Linpus) on it, AFAIK.
>
OK, so the old Linux behavior was the only that ever got exercised.
That makes sense.
-hpa
On Fri, Jul 01, 2011 at 10:31:53AM +1000, Peter Chubb wrote:
> Matthew> I guess I'm going to have to go back and retest the XP
> Matthew> behaviour. I'd expect this machine to be using the ACPI
> Matthew> vector there too.
>
> This machine was only ever shipped with Linux (Linpus) on it, AFAIK.
Ha! Ok, let me look into this some more.
--
Matthew Garrett | [email protected]
On Fri, Jul 01, 2011 at 10:31:53AM +1000, Peter Chubb wrote:
> This machine was only ever shipped with Linux (Linpus) on it, AFAIK.
Bother. Your ACPI tables still make an _OSI query for Windows, even if
it only ever booted Linux - but only if there's no _OSI Linux. So we
could theoretically quirk it based on an OSI call for Linux followed by
one for Windows (rather than the other way around), but I suspect that
this is a specific enough case that a static quirk may be the easiest
thing to do here.
--
Matthew Garrett | [email protected]