Re: [PATCH] Allocate pnp resources dynamically via krealloc
On Sun, 2008-01-20 at 02:23 +0200, Pekka Enberg wrote:
Hi Thomas,
On Jan 19, 2008 10:00 PM, Thomas Renninger [EMAIL PROTECTED] wrote:
+static int pnp_alloc_port(struct pnp_resource_table *res)
+{
[snip]
+ res-port_resource = krealloc(res-port_resource,
+ (sizeof(struct resource) * res-allocated_ports)
+ + (sizeof(struct resource) * PNP_ALLOC_PORT), GFP_KERNEL);
+
+ if (!res-port_resource)
+ return -ENOMEM;
When krealloc() returns NULL, there wasn't enough memory to fit the
new size but the original memory region remains unchanged. Therefore
you must not unconditionally overwrite the res-port_resource with the
return value of krealloc(); otherwise you might leak memory.
Thanks.
While looking at this I found something else..., I think I sent an old
version.
Please hold off, I will double check and resend soon.
Thomas
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] ACPI: add DMI to enable OSI(Linux) on ThinkPad T61
Hi, On Sunday, 20 of January 2008, Len Brown wrote: Ted, Henrique, Matthew, Thank you for your wise words. Here is my plan. 1. notify Intel mobile BIOS group that Linux will STOP answering yes to OSI(Linux), that they should STOP using OSI(Linux) in their BIOS, and that Linux will complain about them when they do. I believe this team is the upstream cause of the majority of OSI(Linux) in the field today. I did this last year -- and they were not happy about it. The laptops vendors were not happy either. However, as it is unsupportable in the long run, I assert we have no choice. Yes, we need a mitigation plan, for Linux tries to be Windows compatible, but the reality is that we use the platform differently in many areas. Graphics and platform specific drivers top the list, and a long list of platform workarounds fill it out. I am okay with defining OSI strings for the benefit of BIOS vendors that need to know about Linux capabilities. But the string must identify that specific capability (or lack of a capability). The first on the list would be a way to tell the BIOS that it should restore video on S3 resume. This is off on Windows b/c it is faster for a native driver to do it. But Linux doesn't yet have native drivers that can do this. So we need to be able to ask the BIOS to do this for us until we do -- and then we need to be able to _stop_ asking the BIOS when we have native graphics driver support in place. (This is an example of why Linux is a poor choice for a capability string -- once you use it, when can you _stop_ using it?) 2. Transition Linux from OSI(Linux) to !OSI(Linux) Linux-2.6.21 was the last kernel with OSI(Linux) by default w/o complaint. Linux-2.6.22 was the last kernel with OSI(Linux) by default, but it complains. Linux-2.6.23 was the first kernel with !OSI(Linux) by default, and it still complains. 3. Clean up any wreckage That is where we are now. The goal is to identify the products that really do need OSI(Linux) and help them keep shipping. There are 3 types of OSI(Linux) users: 1) most laptops with OSI(Linux) inherited it from the refernece code and don't actually use it for anything. Linux will complain about these, until we get their DMI and tell Linux to stop complaining. But with or without DMI, OSI(Linux) is off for these systems. 2) laptops where OSI(Linux) causes a failure. This is the case I'm most worried about, because it is just like the _OS=Linux issue in the old days, which means it has unbounded risk of failure in the field. As the default in 2.6.23 and later is to disable OSI(Linux) these systems work by default going forward, and we just need their DMI to quiet them up, like we did for case #1. I do actually use an OSI-disable DMI hook for these rather than an OSI-ignore DMI, in case somebody wants to build the kernel with it enabled by default. 3) OSI(Linux) added by the vendor that actually makes a Linux SKU work. The good/bad news is that there are very few real laptop Linux SKUs, so indentifying them and dealing with them is finite. As OSI(Linux) is disabled by default today, any vendor that wants it to be enabled for their product will have to get a change into Linux, whether it be a bootparam or a white-list entry. I think having this barrier to entry is good, in that it is motivation to avoid doing the wrong thing. The plan sounds good to me, FWIW. Thanks, Rafael - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] ACPI: add DMI to enable OSI(Linux) on ThinkPad T61
Len Brown wrote: I am okay with defining OSI strings for the benefit of BIOS vendors that need to know about Linux capabilities. But the string must identify that specific capability (or lack of a capability). Is there a chance this will be added to future ACPI specs, or have it standardized in one way or another? I think that would be not only good for Linux, but all other UNIX-like operating systems as well (and maybe Windows as well). Not that I care, really, but for me as an outsider to the whole ACPI domain, it seems _OSI() isn't a well thought out interface. Checking for an OS name rather than individual capabilities may not matter as much under Windows, but for Linux, with its rather short release cycle, it certainly does. tom - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] ACPI: add DMI to enable OSI(Linux) on ThinkPad T61
On Sunday 20 January 2008 07:03, Tomas Carnecky wrote:
Len Brown wrote:
I am okay with defining OSI strings for the benefit of BIOS vendors that
need to know about Linux capabilities. But the string must
identify that specific capability (or lack of a capability).
Is there a chance this will be added to future ACPI specs, or have it
standardized in one way or another? I think that would be not only good
for Linux, but all other UNIX-like operating systems as well (and maybe
Windows as well).
Not that I care, really, but for me as an outsider to the whole ACPI
domain, it seems _OSI() isn't a well thought out interface. Checking for
an OS name rather than individual capabilities may not matter as much
under Windows, but for Linux, with its rather short release cycle, it
certainly does.
Originally, there was _OS=insert your OS name to identify the OS to the
BIOS.
We proudly answered _OS=Linux and broke every BIOS on Earth
that assumed that the only two choices for _OS
which corresponded to Win98 and WinNT.
That is why _OS=Microsoft Windows NT is hardwired
into Linux and any other OS that is concerned about
following what has proven to be the only tested
path through the BIOS.
So naming the OS turned out to be a failure (for everybody,
not just for Linux -- consider that XP and Vista claim they are NT
according to _OS or they hit the same BIOS bugs we do...)
_OSI is supposed to tell the BIOS what interfaces the OS supports,
for example Extended Address Space Descriptor.
However, it is being mis-used to identify the
version of the OS, which is why you see this:
static char *acpi_interfaces_supported[] = {
/* Operating System Vendor Strings */
Windows 2000, /* Windows 2000 */
Windows 2001, /* Windows XP */
Windows 2001 SP1, /* Windows XP SP1 */
Windows 2001 SP2, /* Windows XP SP2 */
Windows 2001.1, /* Windows Server 2003 */
Windows 2001.1 SP1, /* Windows Server 2003 SP1 - Added 03/2006 */
Windows 2006, /* Windows Vista - Added 03/2006 */
ie. basically the OS name is a proxy for all the interfaces
that OS supports. Taken another way, OS-version-specific quirks
and workarounds are included in the definition of that interface...
We could do the same with Linux, except that
1. the string Linux is even more poorly defined than those above,
as it has no version information.
2. the presence of the string Linux tends to break as many BIOS'
implementations as it fixes -- because it isn't universally tested.
So if new strings come up in the ACPI spec, we can use standard strings.
But I don't think the ACPI spec is necessary to address Linux'
problem-at-hand.
We as the Linux community can define Needs BIOS S3 video restore as a string
and ship it in our kernel, telling BIOS writers about it.
However, we'd reserve the right to _stop_ answering YES to a query on that
string
when we no longer need it.
cheers,
-Len
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dmidecode from Dell Vostro 1000
On Saturday 19 January 2008 10:45, Jaakan Shorter wrote:
I added acpi_osi=Linux to 2.6.24 and didn't see a change should I also
try acpi_osi=!Linux on 2.6.24
no need, acpi_osi=!Linux is the default for 2.6.23 and later.
[EMAIL PROTECTED]:~$ cat /var/log/dmesg | grep 0x37E80F06
[EMAIL PROTECTED]:~$ cat /var/log/dmesg | grep BIOS
[0.00] BIOS-provided physical RAM map:
[0.00] BIOS-e820: - 0009dc00 (usable)
[0.00] BIOS-e820: 0009dc00 - 000a (reserved)
[0.00] BIOS-e820: 000ce000 - 0010 (reserved)
[0.00] BIOS-e820: 0010 - 37e7 (usable)
[0.00] BIOS-e820: 37e7 - 37e8 (ACPI data)
OperationRegion (OSTY, SystemMemory, 0x37E80F06, 0x0001)
Field (OSTY, AnyAcc, NoLock, Preserve)
{
TPOS, 8
}
Curious, Op-region OSTY sits in the (reclaimable) ACPI tables region
in the e820 map. I guess it is a good thing that Linux never calls
the BIOS's bluff and reclaims that region after the tables are read
(we leave the tables in place and use them there) -- because otherwise
the OS could scribble on a region that is used by AML at run time.
thanks for testing. I think we're done here.
-Len
[0.00] BIOS-e820: 37e8 - 37f0 (ACPI NVS)
[0.00] BIOS-e820: 37f0 - 4000 (reserved)
[0.00] BIOS-e820: e000 - f000 (reserved)
[0.00] BIOS-e820: fec0 - fec1 (reserved)
[0.00] BIOS-e820: fee0 - fee01000 (reserved)
[0.00] BIOS-e820: fff8 - 0001 (reserved)
[ 15.634917] ..MP-BIOS bug: 8254 timer not connected to IO-APIC
[ 15.826827] ACPI: System BIOS is requesting _OSI(Linux)
[ 18.539020] ide0: BM-DMA at 0x8420-0x8427, BIOS settings:
hda:DMA, hdb:pio
[EMAIL PROTECTED]:~$
On Jan 19, 2008 1:38 AM, Len Brown [EMAIL PROTECTED] wrote:
On Friday 18 January 2008 19:08, Jaakan Shorter wrote:
I didn't see any kind of changes with acpi_osi=!Linux on 2.6.22
here is the current output from uname -a, I'm now using the current
Ubuntu beta
Linux jms1000 2.6.24-4-generic #1 SMP Mon Jan 14 18:19:11 UTC 2008
x86_64 GNU/Linux
I'll try adding acpi_osi=Linux in a few and look for any changes.
Like others, Dell Vostro 1000 sets LINX, but never checks it.
TPOS and OSTB are also affected, but in the ASL they're referened
only with comparisons 4, (NT or greater) so OSI(Linux) shouldn't
have any effect there either.
That leaves the return value of OSTP(), which I see invoked
in several places, but the return value is never used.
So I'll add this box to the OSI(Linux) NOP list.
BTW.
Where does 0x37E80F06 show up in the e820 map in dmesg?
I'm wondering why they put OSTY (TPOS) in a special place.
thanks,
-Len
Scope (\_SB)
{
Name (LINX, 0x00)
Name (OSTB, Ones)
OperationRegion (OSTY, SystemMemory, 0x37E80F06, 0x0001)
Field (OSTY, AnyAcc, NoLock, Preserve)
{
TPOS, 8
}
Method (OSTP, 0, NotSerialized)
{
If (LEqual (^OSTB, Ones))
{
If (CondRefOf (\_OSI, Local0))
{
Store (0x00, ^OSTB)
Store (0x00, ^TPOS)
If (\_OSI (Windows 2001))
{
Store (0x08, ^OSTB)
Store (0x08, ^TPOS)
}
If (\_OSI (Windows 2001.1))
{
Store (0x20, ^OSTB)
Store (0x20, ^TPOS)
}
If (\_OSI (Windows 2001 SP1))
{
Store (0x10, ^OSTB)
Store (0x10, ^TPOS)
}
If (\_OSI (Windows 2001 SP2))
{
Store (0x11, ^OSTB)
Store (0x11, ^TPOS)
}
If (\_OSI (Windows 2001 SP3))
{
Store (0x12, ^OSTB)
Store (0x12, ^TPOS)
}
If (\_OSI (Windows 2006))
{
Store (0x40, ^OSTB)
Store (0x40, ^TPOS)
}
If (\_OSI (Linux))
{
Store (0x01, LINX)
Store (0x80, ^OSTB)
Store (0x80, ^TPOS)
}
}
Else
{
If
Re: dmidecode output from Benq notebook
On Saturday 19 January 2008 02:54, Dmitry A. Marin wrote:
Hello! The output of acpidumop is attached. I working with
2.6.24-4 kernel now (Ubuntu Hardy (testing)), but if it
important I can try 2.6.23 as it exist in distribution.
It seems, that I worked with 2.6.18 5-6 month ago and tried
some options for booting with another acpi-table (?) and
don't seen any differnce. Hibirnate and sleep worked well.
On Fri, 18 Jan 2008 18:56:30 -0500
Len Brown [EMAIL PROTECTED] wrote:
On Sunday 15 July 2007 06:40, Dmitry A. Marin wrote:
System Information
Manufacturer: BenQ
Product Name: Joybook S31
Do you notice any functional difference when booting with
acpi_osi=Linux(default for 2.6.22 and earlier)
vs.
acpi_osi=!Linux (default for 2.6.23 and later)
Also, please send me the output from acpidump.
thanks for the acpidump.
OSI(Linux) has no effect on the AML of this machine,
as OSYS is over-written. So I'll just kill the warning
on this box by adding it to the NOP DMI list.
thanks,
-Len
Store (0x07D0, OSYS)
If (CondRefOf (_OSI, Local0))
{
If (_OSI (Linux))
{
Store (0x03E8, OSYS)
}
If (_OSI (Windows 2001))
{
Store (0x07D1, OSYS)
}
If (_OSI (Windows 2001 SP1))
{
Store (0x07D1, OSYS)
}
If (_OSI (Windows 2001 SP2))
{
Store (0x07D2, OSYS)
}
If (_OSI (Windows 2006))
{
Store (0x07D6, OSYS)
}
If (LAnd (MPEN, LEqual (OSYS, 0x07D1)))
{
TRAP (0x3D)
}
}
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dmidecode output - FSC AMILO Pi 1536
On Saturday 19 January 2008 03:02, Andrea Rizzolo wrote:
Len Brown wrote:
On Tuesday 17 July 2007 15:51, andrea wrote:
ystem Information
Manufacturer: FUJITSU SIEMENS
Product Name: AMILO Pi 1536
Version: Not Applicable
Serial Number: 5311F9B6
UUID: 00D5D495-CD63-0010-8C63-99E512DA426C
Wake-up Type: Power Switch
SKU Number: Not Specified
Family: Not Specified
Handle 0x0002, DMI type 2, 8 bytes
Base Board Information
Manufacturer: FUJITSU SIEMENS
Product Name: AMILO Pi 1536
Do you notice any functional difference when booting with
acpi_osi=Linux(default for 2.6.22 and earlier)
vs.
acpi_osi=!Linux (default for 2.6.23 and later)
Also, please send me the output from acpidump.
thanks,
-Len
ps
If you don't have acpidump, you can get it from pmtools here:
http://www.lesswatts.org/projects/acpi/utilities.php
Since kernel 2.6.23 my acpi works way better: fan is less noisy (really
a lot) Currently Im running zen-sources, a patchset which applies to git
kernel. so, running latest acpi code, dmesg still complains about
acpi_osi but it gives more output:
ACPI: _OSI(Linux) requested by unknown system BIOS
1. FUJITSU SIEMENS
3. 07/19/2007
4. FUJITSU SIEMENS
5. AMILO Pi 1536
6. Not Applicable
10. AMILO Pi 1536
ACPI: Please send DMI info above to linux-acpi@vger.kernel.org
ah, good. This message replaces the request for dmidecode output.
It will go away when I update the entry, because ...
the ASL for this box shows that OSI(Linux) is a NOP.
-Len
Store (0x07D0, OSYS)
If (CondRefOf (_OSI, Local0))
{
If (_OSI (Linux))
{
Store (0x03E8, OSYS)
}
If (_OSI (Windows 2001))
{
Store (0x07D1, OSYS)
}
If (_OSI (Windows 2001 SP1))
{
Store (0x07D1, OSYS)
}
If (_OSI (Windows 2001 SP2))
{
Store (0x07D2, OSYS)
}
If (_OSI (Windows 2006))
{
Store (0x07D6, OSYS)
}
If (LAnd (MPEN, LEqual (OSYS, 0x07D1)))
{
TRAP (0x3D)
}
}
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] ACPI: add DMI to enable OSI(Linux) on ThinkPad T61
Len Brown wrote:
On Sunday 20 January 2008 07:03, Tomas Carnecky wrote:
Len Brown wrote:
I am okay with defining OSI strings for the benefit of BIOS vendors that
need to know about Linux capabilities. But the string must
identify that specific capability (or lack of a capability).
Is there a chance this will be added to future ACPI specs, or have it
standardized in one way or another? I think that would be not only good
for Linux, but all other UNIX-like operating systems as well (and maybe
Windows as well).
Not that I care, really, but for me as an outsider to the whole ACPI
domain, it seems _OSI() isn't a well thought out interface. Checking for
an OS name rather than individual capabilities may not matter as much
under Windows, but for Linux, with its rather short release cycle, it
certainly does.
Originally, there was _OS=insert your OS name to identify the OS to the
BIOS.
We proudly answered _OS=Linux and broke every BIOS on Earth
that assumed that the only two choices for _OS
which corresponded to Win98 and WinNT.
That is why _OS=Microsoft Windows NT is hardwired
into Linux and any other OS that is concerned about
following what has proven to be the only tested
path through the BIOS.
So naming the OS turned out to be a failure (for everybody,
not just for Linux -- consider that XP and Vista claim they are NT
according to _OS or they hit the same BIOS bugs we do...)
_OSI is supposed to tell the BIOS what interfaces the OS supports,
for example Extended Address Space Descriptor.
However, it is being mis-used to identify the
version of the OS, which is why you see this:
static char *acpi_interfaces_supported[] = {
/* Operating System Vendor Strings */
Windows 2000, /* Windows 2000 */
Windows 2001, /* Windows XP */
Windows 2001 SP1, /* Windows XP SP1 */
Windows 2001 SP2, /* Windows XP SP2 */
Windows 2001.1, /* Windows Server 2003 */
Windows 2001.1 SP1, /* Windows Server 2003 SP1 - Added 03/2006 */
Windows 2006, /* Windows Vista - Added 03/2006 */
ie. basically the OS name is a proxy for all the interfaces
that OS supports. Taken another way, OS-version-specific quirks
and workarounds are included in the definition of that interface...
So _OSI _is_ a good interface, it's just being misused. Thanks for the
explanation.
We could do the same with Linux, except that
1. the string Linux is even more poorly defined than those above,
as it has no version information.
Who came up with the idea to use Linux? After what you described
above, this seems even worse choice then what Windows does - they at
least have some information about the version in it.
2. the presence of the string Linux tends to break as many BIOS'
implementations as it fixes -- because it isn't universally tested.
So if new strings come up in the ACPI spec, we can use standard strings.
But I don't think the ACPI spec is necessary to address Linux'
problem-at-hand.
After what you explained above, I don't think either, the ACPI spec is ok.
We as the Linux community can define Needs BIOS S3 video restore as a string
and ship it in our kernel, telling BIOS writers about it.
However, we'd reserve the right to _stop_ answering YES to a query on that
string
when we no longer need it.
Still, it would be nice to have these strings somehow standardized.
Maybe Intel and other vendors or BIOS developers come up with something
and document it properly, include some of the most important strings in
the ACPI spec? Because if Linux starts using some strings and Windows or
BSD different strings, there will surely be a mess - again.
tom
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dmidecode from Dell Vostro 1000
On Sun, 20 Jan 2008, Len Brown wrote:
[0.00] BIOS-provided physical RAM map:
[0.00] BIOS-e820: - 0009dc00 (usable)
[0.00] BIOS-e820: 0009dc00 - 000a (reserved)
[0.00] BIOS-e820: 000ce000 - 0010 (reserved)
[0.00] BIOS-e820: 0010 - 37e7 (usable)
[0.00] BIOS-e820: 37e7 - 37e8 (ACPI data)
OperationRegion (OSTY, SystemMemory, 0x37E80F06, 0x0001)
Field (OSTY, AnyAcc, NoLock, Preserve)
{
TPOS, 8
}
Curious, Op-region OSTY sits in the (reclaimable) ACPI tables region
in the e820 map. I guess it is a good thing that Linux never calls
the BIOS's bluff and reclaims that region after the tables are read
(we leave the tables in place and use them there) -- because otherwise
the OS could scribble on a region that is used by AML at run time.
Shouldn't such problems be added that as a test of firmware quality to the
linux firmware kit (if it doesn't catch such issues already), even if it
doesn't cause Linux breakage?
Anyone screwing up something so basic probably botched up other stuff as
well.
--
One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie. -- The Silicon Valley Tarot
Henrique Holschuh
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dmidecode - Apple MacPro
On Saturday 19 January 2008 05:16, René Rebe wrote: Hi Len, now that was some time between the mails :-) Unfortunately the 8-core box is sort of running in production and I can not randomly boot kernels. Passing acpi_os=whatever did not really changed anything back in the days when I tried that. Actually the box is running quite fine (normal server load, no suspend or so) though currently an older 2.6.18+openvz kernel as that was the only openvz patch- set that was stable, all the other openvz patchsets locked up sooner than later ... If you are still interested in the acpidump I can hunting for it. Yes, I'm still interseted in the acpidump. While I hear a lot from folks running Linux on Apple laptops, I hear less from folks running Linux on Apple servers -- so I don't have this acpidump yet. Hopefully the acpidump will tell all, and we'll have no need for testing. thanks, -Len On 19.01.2008, at 04:36, Len Brown wrote: On Wednesday 29 August 2007 07:49, René Rebe wrote: Hi all, I just post because my dmesg says so: ACPI: System BIOS is requesting _OSI(Linux) ACPI: Please test with acpi_osi=!Linux Please send dmidecode to linux-acpi@vger.kernel.org Handle 0x003A, DMI type 0, 24 bytes BIOS Information Vendor: Apple Computer, Inc. Version: MP21.88Z.007F.B02.0703191612 Release Date: 03/19/07 Handle 0x003B, DMI type 1, 27 bytes System Information Manufacturer: Apple Computer, Inc. Product Name: MacPro2,1 Version: 1.0 ... If you need more let me know. I mostly looked thru the dmesg because the box shuts down sometimes, randomly. Maybe too hot? But I still investigate. However, the box (2 Quad-Core CPUs) even awakes from echo mem /sys/power/state (without graphic though, maybe s2ram posting would fix that - but I do not really care about the graphic as it is indended to be used as server anyway). Thanks for the dmidecode output. Do you notice any functional difference when booting with acpi_osi=Linux(default for 2.6.22 and earlier) vs. acpi_osi=!Linux (default for 2.6.23 and later) Also, please send me the output from acpidump. thanks, -Len ps If you don't have acpidump, you can get it from pmtools here: http://www.lesswatts.org/projects/acpi/utilities.php - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dmidecode-HP-Pavilion-dv9560eg
On Saturday 19 January 2008 04:13, Hans-Joachim Klein wrote:
Am Freitag, den 18.01.2008, 23:23 -0500 schrieb Len Brown:
On Monday 08 October 2007 01:00, Hans-Joachim Klein wrote:
System Information
Manufacturer: Hewlett-Packard
Product Name: HP Pavilion dv9500 Notebook PC
Version: Rev 1
Serial Number: CNF7301PB5
UUID: 434E4637-3330-3150-4235-001B246D0EFF
Wake-up Type: Power Switch
SKU Number: GP650EA#ABD
Family: 103C_5335KV
Handle 0x0002, DMI type 2, 8 bytes.
Base Board Information
Manufacturer: Quanta
Product Name: 30CB
Thanks for the dmidecode output.
Do you notice any functional difference when booting with
acpi_osi=Linux(default for 2.6.22 and earlier)
vs.
acpi_osi=!Linux (default for 2.6.23 and later)
No, I didn't notice any changes in system behaviour, just the output of
dmesg told that the bios requests acpi_osi=Linux.
Fedora-kernel: Linux Pavilion.famklein.net 2.6.23.9-85.fc8 #1 SMP Fri
Dec 7 15:49:36 EST 2007 x86_64 x86_64 x86_64 GNU/Linux
kernel command line:
kernel /boot/vmlinuz-2.6.23.9-85.fc8 ro acpi_osi=Linux pci=routeirq
root=/dev/sdb8 rhgb quiet
thanks for the acpidump.
The ASL sets LINX, but never references it,
so OSI(Linux) is a NOP on this machine.
-Len
OperationRegion (GNVS, SystemMemory, 0x7FEDEDBC, 0x0100)
Field (GNVS, AnyAcc, Lock, Preserve)
{
OSYS, 16,
SMIF, 8,
PRM0, 8,
PRM1, 8,
SCIF, 8,
PRM2, 8,
PRM3, 8,
LCKF, 8,
PRM4, 8,
PRM5, 8,
P80D, 32,
LIDS, 8,
PWRS, 8,
DBGS, 8,
LINX, 8,
Offset (0x14),
...
Store (0x07D0, OSYS)
If (CondRefOf (_OSI, Local0))
{
If (_OSI (Linux))
{
Store (One, LINX)
}
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dmidecode for LG P1 PRO Express Dual 150B
On Saturday 19 January 2008 02:58, Miguel Gea Milvaques wrote:
Len Brown wrote:
On Saturday 04 August 2007 07:24, Miguel Gea Milvaques wrote:
System Information
Manufacturer: LG Electronics
Product Name: P1-J150B
Version: Not Applicable
Serial Number: 701KSWK002977
UUID: 80B450F8-B164-0010-94B0-E3E13E4B84D0
Wake-up Type: Power Switch
SKU Number: Not Specified
Family: Not Specified
Handle 0x0002, DMI type 2, 8 bytes
Base Board Information
Manufacturer: LG Electronics
Product Name: ROCKY
Thanks for the dmidecode output.
Do you notice any functional difference when booting with
acpi_osi=Linux(default for 2.6.22 and earlier)
vs.
acpi_osi=!Linux (default for 2.6.23 and later)
That message has dissapeared from my dmesg in 2.6.23 kernel.
Attached you yave the acpidump
thanks for the acpidump.
The ASL sets LINX but never references it,
so OSI(Linux) is a NOP on this machine.
thanks,
-Len
OperationRegion (GNVS, SystemMemory, 0x3FEEDDBC, 0x0100)
Field (GNVS, AnyAcc, Lock, Preserve)
{
OSYS, 16,
SMIF, 8,
PRM0, 8,
PRM1, 8,
SCIF, 8,
PRM2, 8,
PRM3, 8,
LCKF, 8,
PRM4, 8,
PRM5, 8,
P80D, 32,
LIDS, 8,
PWRS, 8,
DBGS, 8,
LINX, 8,
Offset (0x14),
Store (0x07D0, OSYS)
If (CondRefOf (_OSI, Local0))
{
If (_OSI (Linux))
{
Store (One, LINX)
}
If (_OSI (Windows 2001))
{
Store (0x07D1, OSYS)
}
If (_OSI (Windows 2001 SP1))
{
Store (0x07D1, OSYS)
}
If (_OSI (Windows 2001 SP2))
{
Store (0x07D2, OSYS)
}
If (_OSI (Windows 2006))
{
Store (0x07D6, OSYS)
}
}
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: IT SAID Please send dmidecode to linux-acpi@vger.kernel.org ... - Toshiba Satellite A210
On Saturday 19 January 2008 06:19, W. Conrad GP wrote:
Dear Len,
I remember sending this mail because an error message popped up and
asked me to do so but I am at loss what it was all about since so many
things happend since then and everything has been up to my satisfaction
with Ubuntu Gutsy Gibbon on this notebook.
In order to answer the question With 2.6.22, did you notice any
functional difference with acpi_osi=!Linux? you would have to tell me
where this parameter was set. Sorry.
The acpi dumps the following on a
Linux conport 2.6.23-coney #1 SMP Sat Nov 17 15:48:15 CET 2007 x86_64
GNU/Linux
( ... a lot of boring data following a hope it's of help,
if there is anything else I can do, instruct me.
I'm glad to hear that 2.6.23 is working well for you.
With kernel 2.6.23 or later, please append acpi_osi=Linux to the boot command
line
to see if that has any change with and without.
Others Toshiba models had sound issues with acpi_osi=Linux,
so you might confirm that works in both cases.
Your box may potentially have an issue with SATA power states --
which you might notice when you suspend or hibernate.
(below)
thanks,
-Len
On Saturday 17 November 2007 13:06, W. Conrad GP wrote:
Manufacturer: TOSHIBA
Product Name: Satellite A210
With 2.6.22, did you notice any functional difference with
acpi_osi=!Linux?
(or since the default changed at 2.6.23, with 2.6.23 or later
do you notice any difference with acpi_osi=Linux?)
thanks for the acpidump output.
Name (LINX, 0x00)
Name (OSTB, Ones)
OperationRegion (OSTY, SystemMemory, 0x37E83F04, 0x0001)
Field (OSTY, AnyAcc, NoLock, Preserve)
{
TPOS, 8
}
Method (OSTP, 0, NotSerialized)
{
If (LEqual (^OSTB, Ones))
{
If (CondRefOf (\_OSI, Local0))
{
Store (0x00, ^OSTB)
Store (0x00, ^TPOS)
...
If (\_OSI (Linux))
{
Store (0x01, LINX)
Store (0x80, ^OSTB)
Store (0x80, ^TPOS)
}
...
Return (^OSTB)
}
LINX is set, but not referenced.
OSTB is compared to 4 only, (win NT or later)
TPOS is compared to 0x40 later (Vista) in the SATA wakeup ASL
so OSI(Linux) will change that.
Method (_PS0, 0, NotSerialized)
{
If (LEqual (TPOS, 0x40))
{
Store (0x32, Local0)
While (LAnd (LEqual (\_SB.PCI0.SATA.PMBY, 0x01),
Local0))
{
Sleep (0xFA)
Decrement (Local0)
}
}
Store (0x00, PRIS)
}
OSTP() is invoked in various places, but its return value is never checked.
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dmidecode (HP pavilion dv5000)
On Saturday 19 January 2008 06:31, Martin Tamme wrote:
I didn't notice any difference between acpi_osi=Linux and
acpi_osi=!Linux.
Len Brown wrote:
On Wednesday 20 June 2007 18:04, Martin Tamme wrote:
Manufacturer: Hewlett-Packard
Product Name: HP Pavilion dv5000 (RG959EA#ABD)
Version: F.23
Serial Number: CND63436SJ
UUID: CAB23257-2998-11DB-BA5A-0016D43EC990
Wake-up Type: Power Switch
SKU Number: RG959EA#ABD
Family: 103C_5335KV
Handle 0x0002, DMI type 2, 8 bytes
Base Board Information
Manufacturer: Hewlett-Packard
Product Name: 30A7
thanks for the acpidump -- it shows that OSI(Linux) is a NOP
on this box, for LINX is never referenced.
-Len
Store (0x07D0, OSYS)
If (CondRefOf (_OSI, Local0))
{
If (_OSI (Linux))
{
Store (One, LINX)
}
OperationRegion (GNVS, SystemMemory, 0x7FE93E4C, 0x0100)
Field (GNVS, AnyAcc, Lock, Preserve)
{
OSYS, 16,
SMIF, 8,
PRM0, 8,
PRM1, 8,
SCIF, 8,
PRM2, 8,
PRM3, 8,
LCKF, 8,
PRM4, 8,
PRM5, 8,
P80D, 32,
LIDS, 8,
PWRS, 8,
DBGS, 8,
LINX, 8,
Offset (0x14),
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] ACPI: add DMI to enable OSI(Linux) on ThinkPad T61
On Sat, 19 Jan 2008, Theodore Tso wrote: Sure, and that means they have to *tell* *us* what they are doing so we can be compatible with Windows. The concern is that they may be doing stuff that isn't in the standard ACPI spec, but which needs to be a certain way in order to be compatible with their proprietary Windows drivers. Or to be compatible with both Windows XP and Vista ACPI subsystems, *and* the Windows XP and Vista versions of their proprietary drivers. This is probably where half the weirdness in Lenovo ThinkPads come from, IMHO. The real problem comes when they decide to do things in a rush. That is, Dell deciding they want to make their laptops compatible with an already existing Ubuntu kernel, or Lenovo deciding they want to make their laptops compatible with an already existing SUSE kernel. And, so they decide to do a quick and dirty firmware release rather than negotiating with the distribution to do an Errata kernel. If we don't agressive move to nip this in the bud, even if a particular Thinkpad kernel isn't in the whitelist, I can see them simply documenting a workaround of setting acpi_osi=Linux in the boot command line, because it's easier than getting a distro to release a new kernel with a patch needed to support some new laptop Well, in defense of Lenovo, at least they seem to be quite open to changing future BIOSes if we are really clear on what we request *and* we provide a solution that won't cause total breakage on the kernels already in the Wild. But asking any hardware vendor to do something that will work right with the next version of Linux but will break hideously what distros have been shipping already just won't fly. Anything we do has to work well on both past and current kernels, unfortunately. Now, the real test will be if we ask for something that would require changing their Windows drivers. I sure hope they would do it, but... -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dmidecode from HP Pavilion DV6373EA
On Saturday 19 January 2008 06:01, Mirco Miranda wrote:
Hi Len,
Len Brown ha scritto:
Thanks for the dmidecode output.
Do you notice any functional difference when booting with...
acpi_osi=Linux(default for 2.6.22 and earlier)
vs.
acpi_osi=!Linux (default for 2.6.23 and later)
...in particular, please check sound, wifi, and hibernate.
I'm using K2.6.23. Sound and wifi works fine like 2.6.22; i'm not using
hibernate, only suspend to ram (works fine).
The big difference that I see from k2.6.22 is the LCD backlight
setting: with K2.6.23 works! :)
Thanks for the acpidump, it shows that OSI(Linux)
is a NOP on this box, as LINX is set but never referenced.
-Len
If (CondRefOf (_OSI, Local0))
{
If (\_OSI (Linux))
{
Store (0x01, LINX)
}
...
OperationRegion (GNVS, SystemMemory, 0x3FE84DBC, 0x0100)
Field (GNVS, AnyAcc, Lock, Preserve)
{
OSYS, 16,
SMIF, 8,
PRM0, 8,
PRM1, 8,
SCIF, 8,
PRM2, 8,
PRM3, 8,
LCKF, 8,
PRM4, 8,
PRM5, 8,
P80D, 32,
LIDS, 8,
PWRS, 8,
DBGS, 8,
LINX, 8,
Offset (0x14),
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dmidecode - Samsung R10P/R41P
On Saturday 19 January 2008 06:39, Yurij Perepelytsia wrote:
Hello Len,
Thank for your answer. I've made as you said with acpi_osi=!Linux
and additional with
acpi_osi=Linux here is dmidecode and acpidump in attachment :
acpi_osi=Linux: acpidump0.txt
acpi_osi=!Linux: acpidump1.txt
Thanks.
Jan 19 16:32:14 yura kernel: ACPI: Please test with acpi_osi=!Linux
2008/1/18, Len Brown [EMAIL PROTECTED]:
On Thursday 17 January 2008 07:43, Yurij Perepelytsia wrote:
Hello,
in my log file I've found Please send dmidecode to
linux-acpi@vger.kernel.org my laptop is Samsung R40Plus R40XY0E.
Here is copy past of that.
Thank you Yurij.
Does your system behave any differently when booted with this?:
acpi_osi=Linux
please e-mail me the output from acpidump.
thanks,
-Len
yura:/home/yura# dmidecode
# dmidecode 2.9
Handle 0x0001, DMI type 1, 27 bytes
System Information
Manufacturer: SAMSUNG ELECTRONICS CO., LTD.
Product Name: R40P/R41P
Version: 06YE
Serial Number: 967Y93FP800126
UUID: 20B7E72E-D21D-B211-8000-9F20205EAF5B
Wake-up Type: Power Switch
SKU Number: Not Specified
Family: Not Specified
Handle 0x0002, DMI type 2, 8 bytes
Base Board Information
Manufacturer: SAMSUNG ELECTRONICS CO., LTD.
Product Name: R40P/R41P
Version:
Serial Number: 123490EN400015
Thanks for the acpidump
Looks a lot like that on the Quanta boards from HP...
We need to disable OSI(Linux) on this box if we want
the proposd PNP0C32 to work.
-Len
Scope (\_SB)
{
Name (LINX, 0x00)
Name (OSTB, Ones)
OperationRegion (OSTY, SystemMemory, 0x2FE9FF4C, 0x0001)
Field (OSTY, AnyAcc, NoLock, Preserve)
{
TPOS, 8
}
Method (OSTP, 0, NotSerialized)
{
If (LEqual (^OSTB, Ones))
{
If (CondRefOf (\_OSI, Local0))
{
Store (0x00, ^OSTB)
Store (0x00, ^TPOS)
If (\_OSI (Windows 2001))
{
Store (0x08, ^OSTB)
Store (0x08, ^TPOS)
}
...
If (\_OSI (Windows 2006))
{
Store (0x40, ^OSTB)
Store (0x40, ^TPOS)
}
If (\_OSI (Linux))
{
Store (0x01, LINX) // NOP -- never refereced after set
Store (0x80, ^OSTB)
Store (0x80, ^TPOS)
}
PHNP0C32 looks for OSTB == 0x40, which this code clobbers,
so OSI(Linux) will disable that:
Device (MBTN)
{
Name (_HID, EisaId (PNP0C32))
Name (_UID, 0x01)
Method (_STA, 0, NotSerialized)
{
If (LEqual (\_SB.OSTB, 0x40))
{
Return (0x0F)
}
Else
{
Return (0x00)
}
}
Method (GHID, 0, NotSerialized)
{
If (DMED)
{
Notify (MBTN, 0x02)
}
Return (Buffer (0x01)
{
0x01
})
}
}
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dmidecode output, as requested (MacBook1,1)
On Saturday 19 January 2008 09:55, Henk Koster wrote:
On Friday 18 January 2008 22:48:00 you wrote:
Manufacturer: Apple Computer, Inc.
Product Name: MacBook1,1
With 2.6.22, did you notice any functional difference with
acpi_osi=!Linux?
No difference
(or since the default changed at 2.6.23, with 2.6.23 or later
do you notice any difference with acpi_osi=Linux?)
No difference
Please send me the output from acpidump.
Attached, running 2.6.23 now.
OSI(Linux) changes teh value of OSYS:
OperationRegion (GNVS, SystemMemory, 0x7EED5C10, 0x0100)
Field (GNVS, AnyAcc, Lock, Preserve)
{
OSYS, 16,
...
Scope (\_SB)
{
Method (_INI, 0, NotSerialized)
{
If (CondRefOf (_OSI, Local0))
{
If (_OSI (Darwin))
{
Store (0x2710, OSYS)
}
Else
{
If (_OSI (Linux))
{
Store (0x03E8, OSYS)
}
Else
{
Store (0x07D1, OSYS)
}
}
}
Else
{
Store (0x07D0, OSYS)
}
OSYS 0x7D1 enables the UI bit in HPET _STA (Linux doen't care)
and is used by the OS=Darwin test method:
Method (OSDW, 0, NotSerialized)
{
If (LEqual (OSYS, 0x2710))
{
Return (0x01)
}
Else
{
Return (0x00)
}
}
which treats Linux and Windows the same,
so OSI(Linux) is a NOP on the MacBook1,1
thanks,
-Len
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dmidecode for Acer TM3012
On Saturday 19 January 2008 08:23, Norbert Preining wrote: Hi all, the kernel asks me to send the dmidecode to the list. I always forgot that, but after seeing Len's activitly I decided it might actually be of interest. Hardware: Acer TravelMate 3012 Kernel: 2.6.24-rc8 kernel cmd line: root=/dev/sda3 ro usbcore.autosuspend=1 resume=/dev/sda2 OS: Debian/sid I am quite content having s2r and s2d normally running (save some regression I haven't checked/found). Only one thing puzzled me namely that the computer was in s2r sleep and used all the battery within 12hours. hmmm, probably we're not disabling some device before we suspend. i wonder how long windows lasts in s2r on the same box... Ok, here it is # dmidecode 2.9 SMBIOS 2.4 present. 34 structures occupying 1079 bytes. Table at 0x000DF810. Handle 0x, DMI type 0, 24 bytes BIOS Information Vendor: Acer Version: v1.3125 Release Date: 08/14/06 Address: 0xE6720 Runtime Size: 104672 bytes ROM Size: 512 kB Characteristics: ... Handle 0x0001, DMI type 1, 27 bytes System Information Manufacturer: Acer, inc. Product Name: TravelMate 3010 Version: Not Applicable Serial Number: LXTAT0602260908070EM02 UUID: C07A79BF-CB90-D811-97A0-0016361E27AD Wake-up Type: Power Switch SKU Number: Not Specified Family: Not Specified Handle 0x0002, DMI type 2, 8 bytes Base Board Information Manufacturer: Acer, Inc. Product Name: Ness Version: Not Applicable Serial Number: LXTAT0602260908070EM02 thanks for the dmidecode (DMI entry added) can you send me the acpidump so I can figure out how to set the DMI entry? thanks, -Len - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dmidecode - HP dv6000 30B8 (dv6276eu)
System Information
Manufacturer: Hewlett-Packard
Product Name:
Version: Rev 1
Serial Number:
UUID: Not Settable
Wake-up Type: Power Switch
SKU Number:
Family: 103C_5335KV
Handle 0x0002, DMI type 2, 8 bytes
Base Board Information
Manufacturer: Quanta
Product Name: 30B8
Is this a production BIOS?
It is unusual to have no Product Name above.
What name is on the sticker on the box -- something
from the Pavilion dv6000 family?
Thanks for the dmidecode output.
Do you notice any functional difference when booting with...
acpi_osi=Linux(default for 2.6.22 and earlier)
vs.
acpi_osi=!Linux (default for 2.6.23 and later)
...in particular, please check sound, wifi, and hibernate.
Also, please send me the output from acpidump.
thanks,
-Len
ps
If you don't have acpidump, you can get it from pmtools here:
http://www.lesswatts.org/projects/acpi/utilities.php
On Saturday 19 January 2008 11:14, Dimitri Michaux wrote:
Hey,
I had a hardware failure with this laptop and they had to replace the
motherboard, luckily HP didn't complain about me running Linux on the
laptop, but now dmidecode give's a different output (see attachment).
Is this a production BIOS?
It is unusual to have no Product Name above.
What name is on the sticker on the box -- something
from the Pavilion dv6000 family?
It's a dv6276eu
Heh, the new dmidecode says this:
BIOS Information
Vendor: Hewlett-Packard
Version: F.3B
Release Date: 10/02/2007
Address: 0xE6A30
Runtime Size: 103888 bytes
ROM Size: 1024 kB
...
Handle 0x0001, DMI type 1, 27 bytes
System Information
Manufacturer: Hewlett-Packard
Product Name: HP Pqvilion dv6000 (RY606EQ#UUG)
Version: Rev 1
Serial Number: CNF7092FC7
UUID: 434E4637-3039-3246-4337-001B24E59B82
Wake-up Type: Power Switch
SKU Number: RY606EQ#UUG
Family: 103C_5335KV
Handle 0x0002, DMI type 2, 8 bytes
Base Board Information
Manufacturer: Quanta
Product Name: 30B8
---
so it is still a Quanta 30B8 board.
Humerous that they mis-spelled the product name -- but
no matter -- it became clear very quickly that I can't key off the
product names on HP boxes b/c they are semi-random strings.
so I'm keying off of the board name (30B8).
When I need to boot with acpi_osi, do I still need to use
acpi_os_name=Windows 2006?
No, you should never have to use acpi_os_name= under any conditions.
On this particular box, the BIOS doesn't check _OS contents anyway,
so any setting you use would be a NOP.
re: acpi_osi=Linux ...
It is a NOP also, for in the code below, OSYS
is over-written by the Windows values no matter
if the Linux value is set or not.
thanks,
-Len
Device (PCI0)
{
Name (_ADR, 0x00)
Name (_HID, EisaId (PNP0A03))
Name (_UID, 0x01)
Method (_INI, 0, NotSerialized)
{
Store (0x07D0, OSYS)
If (CondRefOf (_OSI, Local0))
{
If (\_OSI (Linux))
{
Store (0x03E8, OSYS)
}
If (\_OSI (Windows 2001))
{
Store (0x07D1, OSYS)
}
If (\_OSI (Windows 2001 SP1))
{
Store (0x07D1, OSYS)
}
If (\_OSI (Windows 2001 SP2))
{
Store (0x07D2, OSYS)
}
If (\_OSI (Windows 2006))
{
Store (0x07D6, OSYS)
}
}
}
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dmidecode for Sony Vaio VGN-SZ650NC
On Saturday 19 January 2008 09:25, Michael Doube wrote:
Len Brown wrote:
On Sunday 02 December 2007 10:03, Michael Doube wrote:
Manufacturer: Sony Corporation
Product Name: VGN-SZ650N
With 2.6.22, did you notice any functional difference with
acpi_osi=!Linux?
No - what sort of changes should I look for?
(or since the default changed at 2.6.23, with 2.6.23 or later
do you notice any difference with acpi_osi=Linux?)
Please send me the output from acpidump.
attached...
thanks for the acpidump output.
OSI(Linux) is a NOP on this box b/c LINX is never referenced after it is
written.
-Len
OperationRegion (GNVS, SystemMemory, 0xBF6CAA37, 0x0100)
Field (GNVS, AnyAcc, Lock, Preserve)
{
OSYS, 16,
SMIF, 8,
PRM0, 8,
PRM1, 8,
SCIF, 8,
PRM2, 8,
PRM3, 8,
LCKF, 8,
PRM4, 8,
PRM5, 8,
P80D, 32,
LIDS, 8,
PWRS, 8,
DBGS, 8,
LINX, 8,
Offset (0x14),
...
Scope (_SB)
{
Method (_INI, 0, NotSerialized)
{
If (DTSE)
{
TRAP (0x47)
}
Store (0x07D0, OSYS)
If (CondRefOf (_OSI, Local0))
{
If (_OSI (Linux))
{
Store (One, LINX)
}
If (_OSI (Windows 2001))
{
Store (0x07D1, OSYS)
}
...
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dmidecode for acer aspire 5052 laptop
On Saturday 19 January 2008 09:58, Artem Goncharov wrote: Hi. For my laptop using acpi_osi=Linux seems to be working better, but I'm not completely sure in that. What I don't like is the following cut from /var/log/messages Jan 19 14:19:09 blending kernel: PCI: MSI quirk detected. MSI deactivated. Jan 19 14:19:09 blending kernel: assign_interrupt_mode Found MSI capability Jan 19 14:19:10 blending kernel:last message repeated 3 times Jan 19 14:19:09 blending kernel: pci_hotplug: PCI Hot Plug PCI Core version: 0.5 Jan 19 14:19:09 blending kernel: ACPI Exception (processor_core-0819): AE_NOT_FOUND, Processor Device is not present [20070126] if this one happens with latest 2.6.24-rc, then please file a bug and attch your acpidump output here: http://bugzilla.kernel.org/enter_bug.cgi?product=ACPI That is true in both cases (with and without acpi_osi=Linux option. However I'm attaching dmidecode for my laptop. P.S. Jan 19 14:19:09 blending kernel: ACPI: System BIOS is requesting _OSI(Linux) # dmidecode 2.7 SMBIOS 2.4 present. 35 structures occupying 1106 bytes. Table at 0x000F1790. Handle 0x, DMI type 0, 24 bytes. BIOS Information Vendor: Acer Version: v1.3303 Release Date: 01/23/07 Address: 0xE5230 Runtime Size: 110032 bytes ROM Size: 1024 kB Characteristics: ... Handle 0x0001, DMI type 1, 27 bytes. System Information Manufacturer: Acer, inc. Product Name: Aspire 5050 Version: Not Applicable Serial Number: LXAV40Y0867120E60B2502 UUID: C09465D5-4F87-D811-BCCB-001B240E64F7 Wake-up Type: Power Switch SKU Number: Not Specified Family: Not Specified Handle 0x0002, DMI type 2, 8 bytes. Base Board Information Manufacturer: Acer, Inc. Product Name: Prespa M Please capture the output from acpidump and send that to me. thanks, -Len - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dmidecode for Compal HEL80 Notebook
On Saturday 19 January 2008 10:20, Jochen Kemnade wrote:
Hello,
Len Brown schrieb:
Do you notice any functional difference when booting with
acpi_osi=Linux(default for 2.6.22 and earlier)
vs.
acpi_osi=!Linux (default for 2.6.23 and later)
No, i didn't. I was running 2.6.22 for some time and at the moment, I'm
running 2.6.24-rc8, but I couldn't make out any functional change. Do
you have anything specific in mind that I could test and report about?
Also, please send me the output from acpidump.
Thanks for the acpidump.
Please verify that the battery and AC/CD switch evenst are working
properly in both cases above.
-Len
...
Name (ECDY, 0x05)
...
Method (_INI, 0, NotSerialized)
{
Store (0x, MARK)
If (DTSE)
{
TRAP (0x47)
^PCI0.LPCB.PHSS (0x10)
}
Store (0x07D0, OSYS)
If (CondRefOf (_OSI, Local0))
{
If (_OSI (Linux))
{
Store (0x03E8, OSYS)
Store (Zero, ECDY)
// ECDY is used all over the battery and AC code.
}
If (_OSI (Windows 2001))
{
// here OSYS gets over-written, so writing it for Linux above was a NOP
Store (0x07D1, OSYS)
}
If (_OSI (Windows 2001 SP1))
{
Store (0x07D1, OSYS)
}
If (_OSI (Windows 2001 SP2))
{
Store (0x07D2, OSYS)
}
If (_OSI (Windows 2006))
{
Store (0x07D6, OSYS)
}
If (LLessEqual (OSYS, 0x07D2))
{
TRAP (0x49)
}
If (LAnd (MPEN, LEqual (OSYS, 0x07D1)))
{
TRAP (0x3D)
}
}
}
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dmidecode Compaq Presario C500 (C552US)
On Saturday 19 January 2008 10:22, Jesse Burt wrote:
On Fri, 2008-01-18 at 16:36 -0500, Len Brown wrote:
i can double check this in your acpidump output too.
The duplicate may be identical, or Linux may be immune
to the differences (depends what they are)
Thanks for the acpidump output.
OSI(Linux) is indeed a NOP on this box, it sets LINX, but never checks it
OperationRegion (GNVS, SystemMemory, 0x1F694E4C, 0x0100)
Field (GNVS, AnyAcc, Lock, Preserve)
{
OSYS, 16,
SMIF, 8,
PRM0, 8,
PRM1, 8,
SCIF, 8,
PRM2, 8,
PRM3, 8,
LCKF, 8,
PRM4, 8,
PRM5, 8,
P80D, 32,
LIDS, 8,
PWRS, 8,
DBGS, 8,
LINX, 8,
Offset (0x14),
...
If (CondRefOf (_OSI, Local0))
{
If (_OSI (Linux))
{
Store (One, LINX)
}
If (_OSI (Windows 2001))
{
Store (0x07D1, OSYS)
}
...
Re: the duplicate APIC tables...
Linux uses the 1st one by default, and that seems to be the OEM modified
version (vs. the 2nd one which seems bo be left over from the reference code).
$ madt APIC1.dat
ACPI: APIC (v001 HP NISSAN 0x0604 LOHR 0x005a) @ 0x(nil)
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] disabled)
ACPI: IOAPIC (id[0x01] address[0xfec0] global_irq_base[0x0])
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
Length 104 OK
Checksum OK
$ madt APIC2.dat
ACPI: APIC (v001 PTLTD APIC 0x0604 LTP 0x) @ 0x(nil)
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
ACPI: IOAPIC (id[0x01] address[0xfec0] global_irq_base[0x0])
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
Length 90 OK
Checksum OK
The Compaq added APIC table gives a 2nd processor, but it is disabled:
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] disabled)
I don't really follow this, since the specs on this box
say it has a dual core processor. Perhaps the 2nd core is disabled?
The INT_SRC_OVR thing should be a NOP, because high/edge
is the default for legacy timer interrupts.
thanks,
-Len
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dmidecode to linux-acpi@vger.kernel.org - SANTA ROSA CRB
On Saturday 19 January 2008 12:38, Sur3 wrote: Len Brown schrieb: is this a production system? If yes, can you upgrade to a production BIOS? then... Do you notice any functional difference when booting with acpi_osi=Linux(default for 2.6.22 and earlier) vs. acpi_osi=!Linux (default for 2.6.23 and later) Also, please send me the output from acpidump. thanks, -Len ps If you don't have acpidump, you can get it from pmtools here: http://www.lesswatts.org/projects/acpi/utilities.php hi Len, the acpidump is in the attachment. what do you mean by production system? This system seems to be running the BIOS from an Intel example design, which is an example implementation for our customers, not intended really for retail systems. it's kind of a normal laptop. I'm curious what brand and what model it is. i'll check for differences with the different boot-params the next days... You don't have to, OSI(Linux) is a NOP in this BIOS. Like many others, it sets LINX, but never uses it. It does remind me to ping the BIOS group and verify that they've delted this from their latest BIOS. maybe I should update the dmesg to say: BIOS BUG: Please tell your BIOS vendor not to query _OSI(Linux) thanks, -Len - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] ACPI: add DMI to enable OSI(Linux) on ThinkPad T61
On Sun, Jan 20, 2008 at 01:31:59PM -0500, Len Brown wrote: We as the Linux community can define Needs BIOS S3 video restore as a string and ship it in our kernel, telling BIOS writers about it. Maybe we should define the S3 video strong right away, along with whatever else Lenovo was trying to use OSI(Linux) for, and then get the distro's to ship Errata kernels that answer yes for those questions ASAP. Then we can work with Laptop vendors to release new BIOS's that use the new OSI strings instead of Linux, since they can just tell people that they need to upgrade to the latest Ubuntu/SLES kernel. Hopefully, this would allow us to recover from this mess as quickly as possible. - Ted - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dmidecode (Samsung R40plus)
On Saturday 19 January 2008 12:43, Ulrich Ivens wrote:
Am Freitag 18 Januar 2008 22:18:50 schrieben Sie:
Handle 0x0001, DMI type 1, 27 bytes
System Information
Manufacturer: SAMSUNG ELECTRONICS CO., LTD.
Product Name: R40P/R41P
Version: 01YE
Serial Number: 987V93CP300020
UUID: 609A7519-D21D-B211-8000-C10FFE3A9BBA
Wake-up Type: Power Switch
SKU Number: Not Specified
Family: Not Specified
With 2.6.22, did you notice any functional difference with
acpi_osi=!Linux?
No, no significant changes happened.
(or since the default changed at 2.6.23, with 2.6.23 or later
do you notice any difference with acpi_osi=Linux?)
It's still the Kernel 2.6.22 with ubuntu linux.
Please send me the output from acpidump.
If you don't have acpidump, you can get it from pmtools here:
http://www.lesswatts.org/projects/acpi/utilities.php
thanks,
-Len
I tried three things for you:
I set the menu.lst Parameters in kernel line explicit to
1. acpi_osi=!Linux,
2. acpi_osi=Linux
3. nothing
Each time I made an acpidump like you told me. I attached them to the mail. I
also added one output from dmesg.
thanks for the acpidump.
I wouldn't expect it to change for each case, though curiously,
some bits inside the HPET table did change.
Venki, should I be concerned about the Hardware Block ID?
* Disassembly of HPET.dat, Sun Jan 20 19:41:11 2008
---
* Disassembly of HPET.dat, Sun Jan 20 19:40:40 2008
15c15
[009h 009 1] Checksum : 8B
---
[009h 009 1] Checksum : 9A
22c22
[024h 036 4]Hardware Block ID : 43538310
---
[024h 036 4]Hardware Block ID : 43538301
39c39
: 48 50 45 54 38 00 00 00 01 8B 50 54 4C 54 44 20 HPET8.PTLTD
---
: 48 50 45 54 38 00 00 00 01 9A 50 54 4C 54 44 20 HPET8.PTLTD
41c41
0020: 01 00 00 00 10 83 53 43 00 08 00 00 00 00 D0 FE ..SC
---
0020: 01 00 00 00 01 83 53 43 00 08 00 00 00 00 D0 FE ..SC
Greetings from Heinsberg, Germany
Ulli
Re: OSI(Linux)
Method (OSTP, 0, NotSerialized)
# OSTP return value is never checked
{
If (LEqual (^OSTB, Ones))
{
If (CondRefOf (\_OSI, Local0))
{
Store (0x00, ^OSTB)
Store (0x00, ^TPOS)
If (\_OSI (Windows 2001))
{
Store (0x08, ^OSTB)
Store (0x08, ^TPOS)
}
If (\_OSI (Linux))
{
Store (0x01, LINX)
# LINX is a NOP here, since it is never referenced
Store (0x80, ^OSTB)
# there are quite a few references to OSTB == x40 (Vista)
# which will be disabled by OSI(Linux),
# including code under the RTC, PNP0100 timer, PNP0C32 button
# PNP0103 HPET
Store (0x80, ^TPOS)
# TPOS is only compared against 4 (NT)
}
So I I think it is not a good idea to enable OSI(Linux) on this box.
For it enables nothing, and disables hooks for Vista and newer.
It would be interesting if you notice any difference in the dmesg
with and without acpi_osi=Linux in 2.6.24-rc -- particularly any
messages about the timers.
-Len
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Dmidecode of the Clevo M720R
On Saturday 19 January 2008 13:07, Erik Andrén wrote:
Hi,
2008/1/19, Len Brown [EMAIL PROTECTED]:
On Saturday 13 October 2007 12:49, Erik Andrén wrote:
System Information
Manufacturer: Intel Corporation
Product Name: Crestline ICH8M Chipset
Version: Not Applicable
Serial Number: Not Applicable
UUID: ----
Wake-up Type: Power Switch
SKU Number: Not Specified
Family: Not Specified
Handle 0x0002, DMI type 2, 8 bytes
Base Board Information
Manufacturer: Intel Corporation
Product Name: SANTA ROSA CRB
Thanks for the dmidecode output
Looks like a pre-production BIOS,
can you update and
There are no updates available on the clevo homepage...
then do you notice any functional difference when booting with
acpi_osi=Linux(default for 2.6.22 and earlier)
vs.
acpi_osi=!Linux (default for 2.6.23 and later)
Also, please send me the output from acpidump.
So far I haven't noticed any difference when with or without the Linux
string.
I'm attaching the acpidump with this message.
Regards,
Erik
thanks,
-Len
ps
If you don't have acpidump, you can get it from pmtools here:
http://www.lesswatts.org/projects/acpi/utilities.php
acpi_osi=Linux is a NOP on this box b/c it simply sets LINX
and never referes to it after that.
thanks,
-Len
OperationRegion (GNVS, SystemMemory, 0xBF6DEDBC, 0x0100)
Field (GNVS, AnyAcc, Lock, Preserve)
{
OSYS, 16,
SMIF, 8,
PRM0, 8,
PRM1, 8,
SCIF, 8,
PRM2, 8,
PRM3, 8,
LCKF, 8,
PRM4, 8,
PRM5, 8,
P80D, 32,
LIDS, 8,
PWRS, 8,
DBGS, 8,
LINX, 8,
Offset (0x14),
Scope (_SB)
{
Method (_INI, 0, NotSerialized)
{
Store (0x07D0, OSYS)
If (CondRefOf (_OSI, Local0))
{
If (_OSI (Linux))
{
Store (One, LINX)
}
If (_OSI (Windows 2001))
{
Store (0x07D1, OSYS)
}
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dmidecode - dv9500
On Sunday 20 January 2008 04:14, Siegfried Lösch wrote:
Hi Len!
Please find attached the output of acpidump (file acpidump_out.txt).
Up to now I observed the following differences between 2.6.22 and 2.6.23
kernel:
Power-Management:
2.6.22: ok
2.6.23: after some time, during which starting different processes, the
CPU's are working with 2GHz all the time (ondemand is not present). I
work around by restarting gnome-power-management.
Shutdown:
2.6.22: ok
2.6.23: gdm crashes
Network:
2.6.22: LAN and Wlan ok.
2.6.23: LAN and Wlan shut down after some time (aprox. 2 to 4 hours -
but that differs much) and I have to reinitialize networking.
I'll further check the different boot options this week and come back to
you till the end of next week.
Thank's very much for your work and efforts!
Siegfried
Am Freitag, den 18.01.2008, 23:30 -0500 schrieb Len Brown:
On Saturday 13 October 2007 03:31, Siegfried Lösch wrote:
System Information
Manufacturer: Hewlett-Packard
Product Name: HP Pavilion dv9500 Notebook PC
Version: Rev 1
Serial Number: CNF7364LT9
UUID: 434E4637-3336-344C-5439-001B2496B6BB
Wake-up Type: Power Switch
SKU Number: GU135EA#ABD
Family: 103C_5335KV
Handle 0x0002, DMI type 2, 8 bytes
Base Board Information
Manufacturer: Quanta
Product Name: 30CB
Thanks for the dmidecode output.
Do you notice any functional difference when booting with
acpi_osi=Linux(default for 2.6.22 and earlier)
vs.
acpi_osi=!Linux (default for 2.6.23 and later)
Also, please send me the output from acpidump.
thanks,
-Len
ps
If you don't have acpidump, you can get it from pmtools here:
http://www.lesswatts.org/projects/acpi/utilities.php
The 2.6.22 vs 2.6.23 differences must be caused by something else,
for the AML on this box sets but never consults LINX, making
acpi_osi=Linux a NOP for this system.
thanks,
-Len
OperationRegion (GNVS, SystemMemory, 0x7FEDEDBC, 0x0100)
Field (GNVS, AnyAcc, Lock, Preserve)
{
OSYS, 16,
SMIF, 8,
PRM0, 8,
PRM1, 8,
SCIF, 8,
PRM2, 8,
PRM3, 8,
LCKF, 8,
PRM4, 8,
PRM5, 8,
P80D, 32,
LIDS, 8,
PWRS, 8,
DBGS, 8,
LINX, 8,
Offset (0x14),
...
If (CondRefOf (_OSI, Local0))
{
If (_OSI (Linux))
{
Store (One, LINX)
}
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 9/10] introduce intel_menlow platform specific driver
+static int __init intel_menlow_module_init(void)
+{
+ int result = -ENODEV;
+ acpi_status status;
+ unsigned long enable;
+
+ if (acpi_disabled)
+ return result;
+
+ /* Looking for the \_TZ.GSTS method */
+ status = acpi_evaluate_integer(NULL, BIOS_ENABLED, NULL, enable);
+ if (ACPI_FAILURE(status) || !enable)
+ return -ENODEV;
+
+ /* Looking for ACPI device MEM0 with hardware id INT0002 */
+ result = acpi_bus_register_driver(intel_menlow_memory_driver);
+ if (result)
+ return result;
+
+ /* Looking for sensors in each ACPI thermal zone */
+ status = acpi_walk_namespace(ACPI_TYPE_THERMAL, ACPI_ROOT_OBJECT,
+ACPI_UINT32_MAX,
+intel_menlow_register_sensor, NULL, NULL);
+ if (ACPI_FAILURE(status))
+ result = -ENODEV;
+
It seems to me this should be 'return -ENODEV;'
You can just eliminate variable result, because result will be
-ENODEV only.
I disagree. result is required to store the return value from
acpi_bus_register_driver which may be different from ENODEV. Otherwise it's
all -ENODEV.
:-Sujith
Indead, I overlooked it.
But the above 'result = -ENODEV;' should be 'return -ENODEV;', right?
+ return 0;
+}
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dmidecode - FSC AMILO Pi 1556
On Saturday 19 January 2008 15:26, Virus Q wrote:
Hi, Len!
19.01.08, 07:33, Len Brown ([EMAIL PROTECTED]):
On Saturday 13 October 2007 13:29, Virus Q wrote:
System Information
Manufacturer: FUJITSU SIEMENS
Product Name: AMILO Pi 1556
Version: Not Applicable
Serial Number: 5311A8AF
UUID: 00278868-CD63-0010-9AC8-B203A3B3CC32
Wake-up Type: Power Switch
SKU Number: Not Specified
Family: Not Specified
Handle 0x0002, DMI type 2, 8 bytes.
Base Board Information
Manufacturer: FUJITSU SIEMENS
Product Name: AMILO Pi 1556
Thanks for the dmidecode output.
...
Also, please send me the output from acpidump.
Send you a file with the output from acpidump.
Thanks for the acpidump -- it shows that OSI(Linux)
is a NOP on this box b/c the results of the test for
it are immediately over-written anyway.
-Len
--
Scope (_SB)
{
Method (_INI, 0, NotSerialized)
{
If (DTSE)
{
TRAP (0x47)
}
Store (0x07D0, OSYS)
If (CondRefOf (_OSI, Local0))
{
If (_OSI (Linux))
{
Store (0x03E8, OSYS)
}
If (_OSI (Windows 2001))
{
Store (0x07D1, OSYS)
}
...
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Dell Inspiron 1501 - dmidecode
On Saturday 19 January 2008 21:42, Dario Castellarin wrote:
Len Brown ha scritto:
On Tuesday 17 July 2007 08:05, Dario Castellarin wrote:
BIOS Information
Vendor: Dell Inc.
Version: 2.4.1
Release Date: 05/30/2006
System Information
Manufacturer: Dell Inc.
Product Name: Inspiron 1501
Version: Not Specified
Serial Number: 5NYFM2J
UUID: 44454C4C-4E00-1059-8046-B5C04F4D324A
Wake-up Type: Power Switch
SKU Number: Not Specified
Family: Not Specified
Handle 0x0003, DMI type 2, 8 bytes.
Base Board Information
Manufacturer: Dell Inc.
Product Name: 0UW744??
heh, after your BIOS upgrade Dell fixed the issue above
by clearing the Board Product Name field:-)
BIOS Information
Vendor: Dell Inc.
Version: 2.6.3
Release Date: 12/07/2007
Address: 0xE5860
Runtime Size: 108448 bytes
ROM Size: 1024 kB
...
Handle 0x0002, DMI type 1, 27 bytes.
System Information
Manufacturer: Dell Inc.
Product Name: Inspiron 1501
Version: Not Specified
Serial Number:
UUID: 44454C4C-2000-1020-8020-A0C04F202020
Wake-up Type: Power Switch
SKU Number: Not Specified
Family: Not Specified
Handle 0x0003, DMI type 2, 8 bytes.
Base Board Information
Manufacturer: Dell Inc.
Product Name:
(curious if you added the '?'s above, or did Dell?,
they are not there on earlier versions of this BIOS)
Thanks for confirming that
acpi_osi=Linux(default for 2.6.22 and earlier)
vs.
acpi_osi=!Linux (default for 2.6.23 and later)
had no functional difference on the 1501.
please send me the output from acpidump.
thanks,
-Len
ps
If you don't have acpidump, you can get it from pmtools here:
http://www.lesswatts.org/projects/acpi/utilities.php
No, I didn't add anything to that dmidecode dump.
Sorry but in the meanwhile I upgraded the BIOS to the latest offered by
Dell (version 2.6.3), many things changed, anyway I attached a new
dmidecode dump, and also an acpidump.
I wish this can be useful...
acpi_osi=Linux is a NOP on this box.
thanks,
-Len
Scope (\_SB)
{
Name (LINX, 0x00)
Name (OSTB, Ones)
OperationRegion (OSTY, SystemMemory, 0x37E80F06, 0x0001)
Field (OSTY, AnyAcc, NoLock, Preserve)
# return value of OSTY is never checked
{
TPOS, 8
}
Method (OSTP, 0, NotSerialized)
{
If (LEqual (^OSTB, Ones))
{
If (CondRefOf (\_OSI, Local0))
{
Store (0x00, ^OSTB)
Store (0x00, ^TPOS)
If (\_OSI (Windows 2001))
{
Store (0x08, ^OSTB)
Store (0x08, ^TPOS)
}
...
If (\_OSI (Windows 2006))
{
Store (0x40, ^OSTB)
Store (0x40, ^TPOS)
}
If (\_OSI (Linux))
{
Store (0x01, LINX)
# setting LINX is a NOP, as it is never referenced
Store (0x80, ^OSTB)
# OSTB is only compard to 4 (NT), so OSI(Linux) doen't affect that
Store (0x80, ^TPOS)
# TPOS is only compared to 4 (NT), so we have no effect on that either
n
}
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 9/10] introduce intel_menlow platform specific driver
-Original Message-
From: Li Zefan [mailto:[EMAIL PROTECTED]
Sent: Friday, January 18, 2008 9:25 AM
To: Zhang, Rui
Cc: Randy Dunlap; [EMAIL PROTECTED]; [EMAIL PROTECTED]; linux-
[EMAIL PROTECTED]; [EMAIL PROTECTED]; linux-
[EMAIL PROTECTED]; Thomas, Sujith
Subject: Re: [PATCH 9/10] introduce intel_menlow platform specific driver
Zhang Rui 写道:
Hi, Randy and Sam,
+ if (result)
+ goto end;acpi_bus_get_private_data
+ }
+
+ end:
Hah, Lindent always does this for me,
Labels should begin in column 0 or 1. Only.
yes, and checkpatch.pl begins to complain about this
after using Lindent...
I think we should change one of them, :)
+ return result;
+}
+
+
+const static struct acpi_device_id intel_menlow_memory_ids[] = {
+ {INT0002, 0},
+ {, 0},
or just {} for the terminating entry, right?
Yes, I use this just to be consistent with other ACPI device drivers.
Thanks for your comments, please review the patch below,
From: Thomas Sujith [EMAIL PROTECTED]
Intel menlow platform specific driver for thermal management extension.
Signed-off-by: Thomas Sujith [EMAIL PROTECTED]
Signed-off-by: Zhang Rui [EMAIL PROTECTED]
---
drivers/misc/Kconfig|9
drivers/misc/Makefile |1
drivers/misc/intel_menlow.c | 520
3 files changed, 530 insertions(+)
Index: linux-2.6/drivers/misc/intel_menlow.c
===
--- /dev/null
+++ linux-2.6/drivers/misc/intel_menlow.c
@@ -0,0 +1,520 @@
+/*
+* intel_menlow.c - Intel menlow Driver for thermal management
extension
+*
+* Copyright (C) 2008 Intel Corp
+* Copyright (C) 2008 Sujith Thomas [EMAIL PROTECTED]
+* Copyright (C) 2008 Zhang Rui [EMAIL PROTECTED]
+*
~~
+*
+* This program is free software; you can redistribute it and/or modify
+* it under the terms of the GNU General Public License as published by
+* the Free Software Foundation; version 2 of the License.
+*
+* This program is distributed in the hope that it will be useful, but
+* WITHOUT ANY WARRANTY; without even the implied warranty of
+* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+* General Public License for more details.
+*
+* You should have received a copy of the GNU General Public License
along
+* with this program; if not, write to the Free Software Foundation,
Inc.,
+* 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
+*
+*
~~
+*
+* This driver creates the sys I/F for programming the sensors.
+* It also implements the driver for intel menlow memory controller
(hardware
+* id is INT0002) which makes use of the platform specific ACPI methods
+* to get/set bandwidth.
+*/
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/init.h
+#include linux/types.h
+#include linux/pci.h
+#include linux/pm.h
+
+#include linux/thermal.h
+#include acpi/acpi_bus.h
+#include acpi/acpi_drivers.h
+
+MODULE_AUTHOR(Thomas Sujith);
+MODULE_AUTHOR(Zhang Rui);
+MODULE_DESCRIPTION(Intel Menlow platform specific driver);
+MODULE_LICENSE(GPL);
+
+/*
+ * Memory controller device control
+ */
+
+#define MEMORY_GET_BANDWIDTH GTHS
+#define MEMORY_SET_BANDWIDTH STHS
+#define MEMORY_ARG_CUR_BANDWIDTH 1
+#define MEMORY_ARG_MAX_BANDWIDTH 0
+
+static int memory_get_int_max_bandwidth(struct thermal_cooling_device
*cdev,
+ unsigned long *max_state)
+{
+ struct acpi_device *device = cdev-devdata;
+ acpi_handle handle = device-handle;
+ unsigned long value;
+ struct acpi_object_list arg_list;
+ union acpi_object arg;
+ acpi_status status = AE_OK;
+
+ arg_list.count = 1;
+ arg_list.pointer = arg;
+ arg.type = ACPI_TYPE_INTEGER;
+ arg.integer.value = MEMORY_ARG_MAX_BANDWIDTH;
+ status = acpi_evaluate_integer(handle, MEMORY_GET_BANDWIDTH,
+ arg_list, value);
+ if (ACPI_FAILURE(status))
+ return -EFAULT;
+
+ *max_state = value - 1;
+ return 0;
+}
+
+static int memory_get_max_bandwidth(struct thermal_cooling_device
*cdev,
+ char *buf)
+{
+ unsigned long value;
+ if (memory_get_int_max_bandwidth(cdev, value))
+ return -EINVAL;
+
+ return sprintf(buf, %ld\n, value);
+}
+
...
+static int memory_get_cur_bandwidth(struct thermal_cooling_device
*cdev,
+ char *buf)
+{
+ struct acpi_device *device = cdev-devdata;
+ acpi_handle handle = device-handle;
+ unsigned long value;
+ struct acpi_object_list arg_list;
+ union
Re: Please send dmidecode to linux-acpi@vger.kernel.org - Compal HEL8X
On Saturday 19 January 2008 16:42, Josue Resende wrote:
2008/1/19, Len Brown [EMAIL PROTECTED]:
On Sunday 04 November 2007 08:21, Josue Resende wrote:
System Information
Manufacturer: COMPAL
Product Name: HEL81I
Version: *
Serial Number: 2057336701224
UUID: 5D703279-5869-11DB-9D7E-0016D457FA87
Wake-up Type: Power Switch
SKU Number: Not Specified
Family: Not Specified
Handle 0x0002, DMI type 2, 8 bytes
Base Board Information
Manufacturer: COMPAL
Product Name: HEL8X
thanks for the acpidump
Please verify that your battery information and AC/DC
transitions are properly reported in /proc/acpi/
both with and without acpi_osi=Linux
-Len
-
Name (ECDY, 0x05)
...
If (CondRefOf (_OSI, Local0))
{
If (_OSI (Linux))
{
Store (0x03E8, OSYS)
## setting OSYS is a NOP, since it gets overwritten
Store (Zero, ECDY)
## clearing ECDY may have implications in wakeup,
## battery, and some ACPI general purpose events
}
If (_OSI (Windows 2001))
{
Store (0x07D1, OSYS)
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dmidecode - Acer Aspire 5580
On Saturday 19 January 2008 23:42, Anne-Simone wrote:
Attached is the acpidump file.
I haven't noticed any functional difference when setting acpi_osi=!Linux.
My current kernel version is Gentoo 2.6.22-suspend2-r2 and in both cases
(acpi_osi=Linux and acpi_osi=!Linux), I can suspend, but after resuming, the
network connection fails after about 10 - 15 minutes. I get no route to
host to my router...
Also attached is a diff of dmesg for the different acpi_osi settings.
acpidump output was the same for the different acpi_osi settings.
Cheers,
Anne-Simone
On Jan 18, 2008 7:40 PM, Len Brown [EMAIL PROTECTED] wrote:
On Sunday 02 September 2007 18:41, Anne-Simone wrote:
System Information
Manufacturer: Acer, inc.
Product Name: Aspire 5580
Version: Not Applicable
Serial Number: LXAXW0X01471503FA42505
UUID: 404E6C55-1803-D911-8BE3-001B242367DD
Wake-up Type: Power Switch
SKU Number: Not Specified
Family: Not Specified
Handle 0x0002, DMI type 2, 8 bytes
Base Board Information
Manufacturer: Acer, Inc.
Product Name: Prespa1
thanks for the acpidump.
It shows lots of dependencies on OSYS, which is set differently for Linux.
The dependencies show up in places like battery, AC, wakup support and docking.
Basically, it sets the DSDT to run in unknown OS mode, since there
is not a single test for OSYS = the value set for Linux.
I will blacklist OSI(Linux) on this box (which for 2.6.23 and later
is no change, since OSI(Linux) is off by default. If we find incompatibilities
with how Windows exercises the box, we'll fix those -- which is a better
course than running the DSDT in other mode that the vendor surely
has never tested.
thanks,
-Len
Scope (\_SB)
{
Method (_INI, 0, NotSerialized)
{
Store (0x07D0, OSYS)
If (CondRefOf (_OSI, Local0))
{
If (_OSI (Linux))
{
Store (0x03E8, OSYS)
}
Else
{
Store (0x07D1, OSYS)
If (_OSI (Windows 2001 SP2))
{
Store (0x07D2, OSYS)
}
If (_OSI (Windows 2006))
{
Store (0x07D6, OSYS)
}
If (LAnd (MPEN, LEqual (OSYS, 0x07D1)))
{
TRAP (0x3D)
}
}
}
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dmidecode - MacBook2,1
On Sunday 20 January 2008 13:24, eeva wrote:
Len Brown a écrit :
On Saturday 06 October 2007 12:05, Samae wrote:
System Information
Manufacturer: Apple Inc.
Product Name: MacBook2,1
Version: 1.0
Serial Number: W87311YWZ5X
UUID: 61F9E18A-38B2-B440-A87E-7457DF18863C
Wake-up Type: Power Switch
SKU Number: System SKUNumber
Family: MacBook
Handle 0x0002, DMI type 2, 16 bytes
Base Board Information
Manufacturer: Apple Inc.
Product Name: Mac-F4208CAA
Thanks for the dmidecode output.
Do you notice any functional difference when booting with
acpi_osi=Linux(default for 2.6.22 and earlier)
vs.
acpi_osi=!Linux (default for 2.6.23 and later)
Also, please send me the output from acpidump.
thanks,
-Len
ps
If you don't have acpidump, you can get it from pmtools here:
http://www.lesswatts.org/projects/acpi/utilities.php
I haven't notice any difference when booting with one or the other
kernel. I send you the output of acpidump.
pmtools wasn't reachable so I built it with an archlinux PKGBUILD. it
worked nicely.
acpi_osi=Linux is a NOP on the MacBook2,1 because it only
compares OSYS to Darwin. Everything else is treated the same.
thanks,
-Len
If (CondRefOf (_OSI, Local0))
{
If (_OSI (Darwin))
{
Store (0x2710, OSYS)
}
Else
{
If (_OSI (Linux))
{
Store (0x03E8, OSYS)
}
Else
{
Store (0x07D1, OSYS)
}
}
}
Else
{
Store (0x07D0, OSYS)
}
.
Method (OSDW, 0, NotSerialized)
{
If (LEqual (OSYS, 0x2710))
{
Return (0x01)
}
Else
{
Return (0x00)
}
}
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dmidecode output (MacBook2,1)
On Saturday 19 January 2008 15:24, Christer Edwards wrote:
On Jan 18, 2008 7:25 PM, Len Brown [EMAIL PROTECTED] wrote:
Thanks for the dmidecode output.
Do you notice any functional difference when booting with
acpi_osi=Linux(default for 2.6.22 and earlier)
vs.
acpi_osi=!Linux (default for 2.6.23 and later)
I have not yet had a chance to try these values at boot, but I've
attached acpidump.
No testing necessary, the acpudump shows that this box
is like other Apples -- it basically tells the difference
between Darwin and other - and treats Linux and Windows the same.
So if we set OSI(Linux) or not doesn't make any difference.
thanks,
-Len
---
Method (_INI, 0, NotSerialized)
{
If (CondRefOf (_OSI, Local0))
{
If (_OSI (Darwin))
{
Store (0x2710, OSYS)
}
Else
{
If (_OSI (Linux))
{
Store (0x03E8, OSYS)
}
Else
{
Store (0x07D1, OSYS)
}
}
}
Else
{
Store (0x07D0, OSYS)
}
...
Method (OSDW, 0, NotSerialized)
{
If (LEqual (OSYS, 0x2710))
{
Return (0x01)
}
Else
{
Return (0x00)
}
}
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
a problem about the EC driver
Hi, Alexey I know that you are very familiar with the EC driver and you submit a lot patches for EC. Now I have a problem about the EC and want to get help from you. a. In the March of 2007 the patch of 33c7a0738c5f753a7d94fd3b2ec7d84e79a141a8 was submitted by you. In this patch the Fake ECDT workaround is no longer used, which means that OSPM won't parse EC in DSDT when there is no ECDT table. b. In the August of 2007 the patch of cd8c93a4e04dce8f00d1ef3a476aac8bd65ae40b was submitted. In this patch OSPM will parse EC in DSDT when there is no ECDT table. It seems that many laptops without ECDT table will be affected. Is there a potential problem for the laptops without ECDT table? c. In the November of 2007 the patch of 5870a8cd23181703cc76f88f630372f8602c7648 was submitted. In this patch _INI check is added for EC device in DSDT table, which means that in the function of acpi_ec_ecdt_probe OSPM won't install EC handler when no _INI method is found under the scope of EC in DSDT. It seems that a regression is caused by this patch. Please refer to the bug 9730. In the bug of 9730 there is no _INI method for EC device in DSDT table and OSPM won't install EC handler. But the _CRS method of EC device will set the EC flag. So some devices can't access the Operation Region defined in EC device in the course of Linux ACPI device scan and the error messages are reported. According to the description of this patch it seems that the _EC device is related to the _INI method. But according to ACPI spec whether the operation region can be accessed is related to the _REG method. d. In the Jan of 2008 the patch of c04209a7948b95e8c52084e8595e74e9428653d3 was submitted. In this patch the function of boot_ec_enable is added , which means that OSPM will install EC handler for boot_ec device before acpi_bus_scan. I don't understand why the flowchart of boot EC is changed very frequently. Will you please give me detailed info about the four patches? Maybe it is helpful for us to understand the EC driver. Thanks. - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
