RE: new pmtools available for testing
On Mon, 2006-11-27 at 10:13 -0800, Moore, Robert wrote: I don't know what's going on here. I wrote acpixtract in C in order to get away from Perl and Perl issues. I certainly hope that we don't have yet another version of acpixtract. Second. Better remove this one soon. People are packing Len's pmtools. As soon as it's spread confusion and maintenance work will grow. 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: new pmtools available for testing
Thomas Renninger wrote: On Mon, 2006-11-27 at 10:13 -0800, Moore, Robert wrote: I don't know what's going on here. I wrote acpixtract in C in order to get away from Perl and Perl issues. I certainly hope that we don't have yet another version of acpixtract. Second. Better remove this one soon. People are packing Len's pmtools. As soon as it's spread confusion and maintenance work will grow. There was no confusion between two utilities with the same name, and now you claim to have lost between two with different names, how so? pmtools used to be complete in sense it was able to decode that was it has produced, and it will remain complete. Thanks, Alex. - 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: Broken DSDT (ASUS A6Km, Sempron 3300+)
On Mon, 2006-11-27 at 19:19 +0100, Mirosław Majka wrote: Hi, I've been sent to You by Ling Yu. don't know how to repair my broken DSDT. I've tried some of those sent to the ACPI for linux page but none of them works perfectly. I don't know where to send my decompiled code to search for some anwsers. Can I send my DSDT to You to have it examined and for some tips on how to fix it? If this is about that your asus model specific stuff like hotkeys or whatever is not supported well you may want to try: linux-acpi@vger.kernel.org If you have the possibility to upload the acpidump or DSDT and point to it it's best, if not just give it a try, I just saw some tables attached there. If you have a general ACPI problem you are right here. Best is you describe your problem a bit first. What function does not work? Do you see kernel errors/warnings (pls CP them)? In general you should not override the DSDT table at all! Hmm, asus could be a smart battery machine? If yes throw away all DSDT tables you downloaded and try the new sbs module. Maybe these SBS workaround DSDT tables should get marked somehow that there is support for this feature since kernel xy, if this is possible? So, before sending anything, pls describe your problem. Thanks, 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: new pmtools available for testing
On Tue, 2006-11-28 at 13:24 +0300, Alexey Starikovskiy wrote: Thomas Renninger wrote: On Mon, 2006-11-27 at 10:13 -0800, Moore, Robert wrote: I don't know what's going on here. I wrote acpixtract in C in order to get away from Perl and Perl issues. I certainly hope that we don't have yet another version of acpixtract. Second. Better remove this one soon. People are packing Len's pmtools. As soon as it's spread confusion and maintenance work will grow. There was no confusion between two utilities with the same name, and now you claim to have lost between two with different names, how so? It's not the two names, it simply makes no sense to provide two utilities which do the same. Why do you want to do that? You have other params, other output, double amount of bug fixing or feature enhancements work. I only see cons not one single pro argument to do so. pmtools used to be complete in sense it was able to decode that was it has produced, and it will remain complete. But why not just move/copy Robert's acpixtract, it's already well tested? It does not include any APCICA stuff and changing the license shouldn't be a problem for you... 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: How ACPI is actually implemented?
Hi All,
On 11/28/06, Wu, Cody [EMAIL PROTECTED] wrote:
Hi Kein,
The SCI handler, which will run a GPE handler as you said here, Who is
belongs to? I mean, is it part of OS? Or BIOS? ACPI spec seems says if
the OS is ACPI compatible and ACPI was enabled, EC will trigger SCI,
then handled by OS otherwise it will trigger SMI which handled by BIOS,
is this true?
GPE handler is provided by Bios originally in the form of AML. Os's AcPI
driver will parse it and link it to SCI interrupt processing. Whether EC
will trigger SCI or SMI depends on how you want it to be done as well as
what OS you are working with. For OS supporting ACPI it will enable ACPI
controller on the chipset and SCI will take precedence over SMI.
If we will go back again to the GPEs, In my DSDT (Lenovo Laptop),
under the _GPE scope, there is a method that assigns itself to the 3rd
bit of the GPE register block. It's code is the following:
Method (_L03, 0, NotSerialized)
{
Notify (\_SB.PCI0.USB1, 0x02)
}
Now, it tells the OSPM to notify the native device driver of the USB1
device to Wake (0x02). But, the thing is, I didn't see in any place
that the actual USB1 device is being associated with the 3rd bit of
this GPE register block. Is it defined in some other ACPI table or is
it dectated by the system platform?
Thanks,
Eric.
-
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: acpi nic card flapping
On Fri, 2006-11-24 at 23:34 -0800, Yong Lee wrote: Hi all, I’m hoping that someone out there can lend me a hand with a problem that we were seeing. I’m not very familiar with the acpi tool so please bear with me. We had an outage where we could not ssh into our web server and we had to do a reboot from our console to get things running again. It looks like an acpi problem and I’m trying to figure out what was going on. Was ACPI going crazy or was it trying to report a problem condition that we were not aware of. What we saw in the dmesg log was this : shpchp: Address64 Resource unparsed shpchp: acpi_pciehprm:\_SB_.PCI0.PBLO OSHP fails=0x5 shpchp: acpi_shpchprm: Slot sun(0) at s:b:d:f=0x00:04:1f:00 shpchp: acpi_pciehprm:\_SB_.PCI0.PBLO OSHP fails=0x5 shpchp: acpi_pciehprm:\_SB_.PCI0.PBLO OSHP fails=0x5 shpchp: acpi_pciehprm:\_SB_.PCI0.PBLO OSHP fails=0x5 shpchp: acpi_pciehprm:\_SB_.PCI0.PBLO OSHP fails=0x5 shpchp: acpi_pciehprm:\_SB_.PCI0.PBLO OSHP fails=0x5 shpchp: acpi_pciehprm:\_SB_.PCI0.PBLO OSHP fails=0x5 shpchp: acpi_pciehprm:\_SB_.PCI0.PBLO OSHP fails=0x5 shpchp: acpi_pciehprm:\_SB_.PCI0.VPR0 OSHP fails=0x5 shpchp: acpi_pciehprm:\_SB_.PCI0.VPR0 OSHP fails=0x5 shpchp: acpi_pciehprm:\_SB_.PCI0.VPR0 OSHP fails=0x5 shpchp: acpi_pciehprm:\_SB_.PCI0.VPR0 OSHP fails=0x5 shpchp: acpi_pciehprm:\_SB_.PCI0.VPR0 OSHP fails=0x5 shpchp: acpi_pciehprm:\_SB_.PCI0.VPR0 OSHP fails=0x5 shpchp: acpi_pciehprm:\_SB_.PCI0.VPR0 OSHP fails=0x5 shpchp: acpi_pciehprm:\_SB_.PCI0.VPR0 OSHP fails=0x5 shpchp: shpc_init : shpc_cap_offset == 0 shpchp: shpc_init : shpc_cap_offset == 0 shpchp: shpc_init : shpc_cap_offset == 0 shpchp: shpc_init : shpc_cap_offset == 0 shpchp: shpc_init : shpc_cap_offset == 0 shpchp: shpc_init : shpc_cap_offset == 0 shpchp: shpc_init : shpc_cap_offset == 0 shpchp: shpc_init : shpc_cap_offset == 0 shpchp: shpc_init : shpc_cap_offset == 0 shpchp: Standard Hot Plug PCI Controller Driver version: 0.4 During the time of the outage we saw from our router logs that the connection to the server was going up and down. There was a lot of other messages on the console but our sysadmin guy didn’t capture this. Hmm, so that may not be the root cause of your problems? We’re running redhat linux 2.6.9-34.0.2.ELsmp on intel xeon processors. We have 2 intel nic cards : Intel Corporation 82541GI/PI Gigabit Ethernet Controller (rev 05) Any light you can shed on this problem would be great. Note that while the kacpid kernel thread is running the acpid daemon was shut off during this incident. If the pci hotplug module (shpchp, difficult to spell...) really causes this it might be kernel or a BIOS bug. If this is a production machine that is already running for a while, I would not risk a BIOS update or waste time with kernel compilations. Best/simplest would be to remove the module out of /lib/modules/xy/kernel/drivers/pci/hotplug/shpchp.ko directory if you do not need PCI hotplug urgently. Hope that works... 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: new pmtools available for testing
Thomas Renninger wrote: On Tue, 2006-11-28 at 13:24 +0300, Alexey Starikovskiy wrote: Thomas Renninger wrote: On Mon, 2006-11-27 at 10:13 -0800, Moore, Robert wrote: I don't know what's going on here. I wrote acpixtract in C in order to get away from Perl and Perl issues. I certainly hope that we don't have yet another version of acpixtract. Second. Better remove this one soon. People are packing Len's pmtools. As soon as it's spread confusion and maintenance work will grow. There was no confusion between two utilities with the same name, and now you claim to have lost between two with different names, how so? It's not the two names, it simply makes no sense to provide two utilities which do the same. So blaim Bob for making second utility and distributing it in ACPICA. Why do you want to do that? You have other params, other output, double amount of bug fixing or feature enhancements work. I only see cons not one single pro argument to do so. Params are compatible with acpidump. What do you mean by other output? pmtools used to be complete in sense it was able to decode that was it has produced, and it will remain complete. But why not just move/copy Robert's acpixtract, it's already well tested? It does not include any APCICA stuff and changing the license shouldn't be a problem for you... Writing new utility from scratch took half a day, while porting ACPICA acpidump with change in license would take weeks. It does include ACPICA types, so it will require ACPICA headers at least. Also it relies on ACPICA subset of libc, so it will be pain to both maintain it and make any improvements. We already tried to have acpidump utility in both ACPICA and pmtools and ended with two completely different programs. Regards, Alex. - 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: How ACPI is actually implemented?
Hi Eric,
But, the thing is, I didn't see in any place
that the actual USB1 device is being associated with the 3rd bit of
this GPE register block. Is it defined in some other ACPI table or is
it dectated by the system platform?
This is made stiff in the board hardware layout especially how it
connects onboard USB controller to the ACPI Chipset. You can find the
details illustrations such as which USB port is for which bit in the ICH
spec.
Best regards,
Cody
-Original Message-
From: Eric Benton [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 28, 2006 7:37 PM
To: Wu, Cody
Cc: Yuan, Kein; Len Brown; linux-acpi@vger.kernel.org
Subject: Re: How ACPI is actually implemented?
Hi All,
On 11/28/06, Wu, Cody [EMAIL PROTECTED] wrote:
Hi Kein,
The SCI handler, which will run a GPE handler as you said here, Who
is
belongs to? I mean, is it part of OS? Or BIOS? ACPI spec seems says
if
the OS is ACPI compatible and ACPI was enabled, EC will trigger SCI,
then handled by OS otherwise it will trigger SMI which handled by
BIOS,
is this true?
GPE handler is provided by Bios originally in the form of AML. Os's
AcPI
driver will parse it and link it to SCI interrupt processing. Whether
EC
will trigger SCI or SMI depends on how you want it to be done as well
as
what OS you are working with. For OS supporting ACPI it will enable
ACPI
controller on the chipset and SCI will take precedence over SMI.
If we will go back again to the GPEs, In my DSDT (Lenovo Laptop),
under the _GPE scope, there is a method that assigns itself to the 3rd
bit of the GPE register block. It's code is the following:
Method (_L03, 0, NotSerialized)
{
Notify (\_SB.PCI0.USB1, 0x02)
}
Now, it tells the OSPM to notify the native device driver of the USB1
device to Wake (0x02). But, the thing is, I didn't see in any place
that the actual USB1 device is being associated with the 3rd bit of
this GPE register block. Is it defined in some other ACPI table or is
it dectated by the system platform?
Thanks,
Eric.
-
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: How ACPI is actually implemented?
Thanks Cody for your replay!
Thank you all guys!
Eric.
On 11/29/06, Wu, Cody [EMAIL PROTECTED] wrote:
Hi Eric,
But, the thing is, I didn't see in any place
that the actual USB1 device is being associated with the 3rd bit of
this GPE register block. Is it defined in some other ACPI table or is
it dectated by the system platform?
This is made stiff in the board hardware layout especially how it
connects onboard USB controller to the ACPI Chipset. You can find the
details illustrations such as which USB port is for which bit in the ICH
spec.
So does that means that the OSPM needs to
Best regards,
Cody
-Original Message-
From: Eric Benton [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 28, 2006 7:37 PM
To: Wu, Cody
Cc: Yuan, Kein; Len Brown; linux-acpi@vger.kernel.org
Subject: Re: How ACPI is actually implemented?
Hi All,
On 11/28/06, Wu, Cody [EMAIL PROTECTED] wrote:
Hi Kein,
The SCI handler, which will run a GPE handler as you said here, Who
is
belongs to? I mean, is it part of OS? Or BIOS? ACPI spec seems says
if
the OS is ACPI compatible and ACPI was enabled, EC will trigger SCI,
then handled by OS otherwise it will trigger SMI which handled by
BIOS,
is this true?
GPE handler is provided by Bios originally in the form of AML. Os's
AcPI
driver will parse it and link it to SCI interrupt processing. Whether
EC
will trigger SCI or SMI depends on how you want it to be done as well
as
what OS you are working with. For OS supporting ACPI it will enable
ACPI
controller on the chipset and SCI will take precedence over SMI.
If we will go back again to the GPEs, In my DSDT (Lenovo Laptop),
under the _GPE scope, there is a method that assigns itself to the 3rd
bit of the GPE register block. It's code is the following:
Method (_L03, 0, NotSerialized)
{
Notify (\_SB.PCI0.USB1, 0x02)
}
Now, it tells the OSPM to notify the native device driver of the USB1
device to Wake (0x02). But, the thing is, I didn't see in any place
that the actual USB1 device is being associated with the 3rd bit of
this GPE register block. Is it defined in some other ACPI table or is
it dectated by the system platform?
Thanks,
Eric.
-
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: acpi nic card flapping
Hi Yong Lee, shpchp: acpi_pciehprm:\_SB_.PCI0.PBLO OSHP fails=0x5 This message means OSHP method is not found under _SB.PCI0.PBLO. This message itself is harmless, I think. But, IIRC, old shpchp driver had a problem that loading shpchp driver may cause a master-abort on some ongoing PCI cards. The root cause is old shpchp driver writes 0x to BARs of some ongoing PCI cards to know the size of resources assigned to the cards at modprobe time. I don't know this is related to your problem. But I hope this info is helpful for you. Thanks, Kenji Kaneshige Yong Lee wrote: Hi all, I’m hoping that someone out there can lend me a hand with a problem that we were seeing. I’m not very familiar with the acpi tool so please bear with me. We had an outage where we could not ssh into our web server and we had to do a reboot from our console to get things running again. It looks like an acpi problem and I’m trying to figure out what was going on. Was ACPI going crazy or was it trying to report a problem condition that we were not aware of. What we saw in the dmesg log was this : shpchp: Address64 Resource unparsed shpchp: acpi_pciehprm:\_SB_.PCI0.PBLO OSHP fails=0x5 shpchp: acpi_shpchprm: Slot sun(0) at s:b:d:f=0x00:04:1f:00 shpchp: acpi_pciehprm:\_SB_.PCI0.PBLO OSHP fails=0x5 shpchp: acpi_pciehprm:\_SB_.PCI0.PBLO OSHP fails=0x5 shpchp: acpi_pciehprm:\_SB_.PCI0.PBLO OSHP fails=0x5 shpchp: acpi_pciehprm:\_SB_.PCI0.PBLO OSHP fails=0x5 shpchp: acpi_pciehprm:\_SB_.PCI0.PBLO OSHP fails=0x5 shpchp: acpi_pciehprm:\_SB_.PCI0.PBLO OSHP fails=0x5 shpchp: acpi_pciehprm:\_SB_.PCI0.PBLO OSHP fails=0x5 shpchp: acpi_pciehprm:\_SB_.PCI0.VPR0 OSHP fails=0x5 shpchp: acpi_pciehprm:\_SB_.PCI0.VPR0 OSHP fails=0x5 shpchp: acpi_pciehprm:\_SB_.PCI0.VPR0 OSHP fails=0x5 shpchp: acpi_pciehprm:\_SB_.PCI0.VPR0 OSHP fails=0x5 shpchp: acpi_pciehprm:\_SB_.PCI0.VPR0 OSHP fails=0x5 shpchp: acpi_pciehprm:\_SB_.PCI0.VPR0 OSHP fails=0x5 shpchp: acpi_pciehprm:\_SB_.PCI0.VPR0 OSHP fails=0x5 shpchp: acpi_pciehprm:\_SB_.PCI0.VPR0 OSHP fails=0x5 shpchp: shpc_init : shpc_cap_offset == 0 shpchp: shpc_init : shpc_cap_offset == 0 shpchp: shpc_init : shpc_cap_offset == 0 shpchp: shpc_init : shpc_cap_offset == 0 shpchp: shpc_init : shpc_cap_offset == 0 shpchp: shpc_init : shpc_cap_offset == 0 shpchp: shpc_init : shpc_cap_offset == 0 shpchp: shpc_init : shpc_cap_offset == 0 shpchp: shpc_init : shpc_cap_offset == 0 shpchp: Standard Hot Plug PCI Controller Driver version: 0.4 During the time of the outage we saw from our router logs that the connection to the server was going up and down. There was a lot of other messages on the console but our sysadmin guy didn’t capture this. We’re running redhat linux 2.6.9-34.0.2.ELsmp on intel xeon processors. We have 2 intel nic cards : Intel Corporation 82541GI/PI Gigabit Ethernet Controller (rev 05) Any light you can shed on this problem would be great. Note that while the kacpid kernel thread is running the acpid daemon was shut off during this incident. Many thanks, Yong. - 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 - 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] allow the highest frequency if bios think so.
Peter Clifton napisał(a): I don't know about the HP NX 6125, but on my nc 6320, you have to rmmod psmouse before you shutdown or reboot the computer, otherwise something upsets the BIOS and it won't run at full speed on next boot up. Can't hurt to give it a try. The other method to get it working again is to remove the AC adaptor and the battery for a few seconds, then re-insert and power up. Bootup time is also much faster if the psmouse was rmmod'd before shutdown, or the power was completely removed as above. Weired indeed! Peter Clifton The same problem in NX 6310 and - probably - other NX models. When I forgot remove psmouse sometimes I saw psmouse CRC32 error (or something similar) after ACPI called power off (at the last moment when power off). Sorry, it's to fast, so I can't check what is happen. -- Maciej Rutecki [EMAIL PROTECTED] http://www.unixy.pl LTG - Linux Testers Group (http://www.stardust.webpages.pl/ltg/wiki/) smime.p7s Description: S/MIME Cryptographic Signature
