lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sat, 12 Jan 2008 04:16:08 -0500
From:	Len Brown <lenb@...nel.org>
To:	Henrique de Moraes Holschuh <hmh@....eng.br>
Cc:	linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: Lenovo ThinkPads need acpi_osi="Linux"

On Friday 11 January 2008 21:23, Henrique de Moraes Holschuh wrote:
> While helping a user find out what happened to his mute key, I found out
> that the Lenovo BIOSes need the OSI string Linux defined to behave properly
> in Linux.
> 
> Lenovo has been attempting to make things a bit easier for Linux on their
> ThinkPads, by disabling the more obnoxious behaviours of the firmware (used
> by their Windows drivers) when in Linux.  It looks like they used the OSI
> string for that.
> 
> It is probably worthwhile to give a head's up: regressions involving
> thinkpads and 2.6.23+ should probably have a 'please test with
> acpi_osi="Linux"' step added if there is any chance ACPI AML code, BIOS or
> SMBIOS code, or EC behaviour could be involved.
> 
> The most concrete example I have right now of changed behaviour is the Mute
> key on the T61, which just plain disappears if acpi_osi="!Linux" (2.6.23
> default).
> 
> I have also seen some hacked DSDTs around (mostly for older T4x models)
> which used the Linux OSI string to fix or work around AML weirdness.  Those
> would break in 2.6.23 (and 2.6.24?) as well.
> 
> Now, what should we do about it?  Add a quirk to always define the Linux OSI
> string on ThinkPads (based on DMI information)?  All IBM ones (which won't
> have BIOS revisions anymore, anyway) deal well with it, and Lenovo ones
> seem to benefit from it.
> 
> We could also ask Lenovo to change the BIOS to stop paying attention to that
> OSI string, but they will likely want/need a trigger for the AML code to
> know it should change behaviour anyway, and the OSI string *does* look like
> the proper thing to use IMHO.  I don't know if we could get them to arrive
> to a behaviour that is acceptable both to us, and also to their Windows
> drivers...
> 

I discussed this with Lenovo a few months ago
and made it clear that Linux will unlikely
default to answer yes to OSI(Linux) in the future --
for all the reasons I stated when I disabled it.

However, they told me they wanted to use OSI(Linux)
to enable the backlight (via video re-post) on S3 resume,
and the problem at hand was a distro kernel which still
had OSI(Linux), so that is what they did.

I was unaware that they're using it for anything else,
and the fact that they are lends further support to
the case that as an OS interface string "Linux"
is too vague to be meaningful.

They seemed open to looking for another string, say
"Needs S3 video re-post".  However, we didn't
agree on such a string, and so it isn't in Linux
or the Lenovo BIOS.

I think until we have native Linux graphics driver for (fast)
backlight restore, we need to add a DMI to enable OSI(Linux)
for the offending Lenovo models.   We'll need to have
some coordination with the graphics guys so that they
can turn this off from user-space when they don't need it.

The reason it shoudl be turned off is that backlight enabling
backlight from a native graphics driver is much faster than running
through the video BIOS POST.  So if we keep the OSI(Linux)
video BIOS POST workaround in place permanently, it would
put Linux at a permanent performance disadvantage to Windows.

cheers,
-Len
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists