I realise the question regarding acpi=copy_dsdt is rather lazy of me,
so I tried it with the stock 2.6.36-rc2.
I can confirm it works as expected. So, even if later kernels ship
without the Toshiba Satellite detection, copy_dsdt can be used.
The only significant difference in the 2 dmesg outputs (Toshiba patch
versus acpi=copy_dsdt) is the absence of the 1st line below for
acpi-copy_dsdt. Both dmesg contain the second line.
TOSHIBA Satellite detected - force copy of DSDT to local memory
ACPI: Forced DSDT copy: length 0x094DE copied locally, original unmapped
Cheers, al.
On 2 October 2010 21:46, Allan Kelly <allankelly@xxxxxxxxx> wrote:
> Glad to help Len.
>
> BTW, what is going on here? Is there a thread where this is explained?
> Seems the BIOS deliberately alters the DSDT after initialisation. Do
> we know why? Does it do it for Win OSs?
>
> Also, I see that for kernels >= 2.6.35 the boot argument
> acpi=copy_dsdt is available which it sounds like it should cause the
> same behaviour as this patch. Is that right? In which case I can start
> to use that with standard distros once the appropriate kernel level is
> distributed for Ubuntu.
>
> Many thanks, al.
>
> On 2 October 2010 03:45, Len Brown <lenb@xxxxxxxxxx> wrote:
>> Thanks for confirming the patch works, Allan,
>>
>> It shipped upstream in 2.6.36-rc6-git2
>> and I just sent a note for Greg to consider it for .stable
>>
>> cheers,
>> Len Brown, Intel Open Source Technology Center
>>
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
