Re: CVS commit: src/sys/dev/acpi

[Taylor R Campbell]

> Module Name:src
> Committed By:   christos
> Date:   Fri Apr 26 18:19:18 UTC 2024
> 
> Modified Files:
> src/sys/dev/acpi: acpi_bat.c
> 
> Log Message:
> PR/58201: Malte Dehling: re-order sysmon initialization before acpi
> registration, to avoid needing to call to acpi_deregister_notify on sysmon
> failure.

This isn't really a bug: the detach function calls
acpi_deregister_notify.  Now, with this change, it will call
acpi_deregister_notify even if acpi_register_notify was never called.

Fortunately, that's mostly harmless in the current implementation --
just as it was harmless to leave the notifier there; it doesn't use
any memory that would be leaked.

(Really, if there's any bug here, it's that sysmon_envsys_register can
fail at all.  This creates vast swaths of never-tested error branches
that waste maintainer and auditor time.)

re: CVS commit: src/sys/dev/acpi

[matthew green]

"Jason R Thorpe" writes:
> Module Name:  src
> Committed By: thorpej
> Date: Sat Jan 16 01:23:04 UTC 2021
>
> Modified Files:
>   src/sys/dev/acpi: tpm_acpi.c
>
> Log Message:
> Match PNP0C31 as a TPM 1.2 device.  Works on my ThinkPad X260, and
> eliminates the last of the devices that attach to "isa".

cool.

now try to remove all the "at isa" devices in your config :-)

(it explodes last i tried.)

Re: CVS commit: src/sys/dev/acpi

[Jukka Ruohonen]

On Mon, Jun 22, 2020 at 04:14:18PM +, Maxime Villard wrote:
> Module Name:  src
> Committed By: maxv
> Date: Mon Jun 22 16:14:18 UTC 2020
> 
> Modified Files:
>   src/sys/dev/acpi: acpi.c
> 
> Log Message:

> Fix memory leak. Found by kLSan.
> +
> + default:
> + ACPI_FREE(devinfo);
> + break;
>   }
>  
>   return AE_OK;

I think it leaks more, i.e. AcpiGetObjectInfo() always allocates a buffer.

- Jukka

Re: CVS commit: src/sys/dev/acpi

[Nick Hudson]

On 10/08/2018 18:11, Taylor R Campbell wrote:

Module Name:src
Committed By:   riastradh
Date:   Fri Aug 10 17:11:56 UTC 2018

Modified Files:
src/sys/dev/acpi: acpi_bat.c

Log Message:
Don't hold up boot: defer acpibat(4) inquiry until threads are running.

ok jmcneill@


This makes an old hp510 laptop reset without warning around about dhcpcd
time.

I don't if it matters but the battery doesn't charge anymore.

Nick

Re: CVS commit: src/sys/dev/acpi

[Masanobu SAITOH]

On 2019/08/05 23:06, Joerg Sonnenberger wrote:
> On Mon, Aug 05, 2019 at 10:12:04AM +, SAITOH Masanobu wrote:
>> Module Name: src
>> Committed By:msaitoh
>> Date:Mon Aug  5 10:12:04 UTC 2019
>>
>> Modified Files:
>>  src/sys/dev/acpi: acpi_ec.c
>>
>> Log Message:
>> - Fix a bug that acpiec_space_handler() doesn't access more than 64bit
>>   correctly. Found by kUBSan on Thinkpad X220. acpiec0 accessed 128bits from
>>   address 0xa0. The error message was:
>>
>>  UBSan: Undefined Behavior in ../../../../dev/acpi/acpi_ec.c:672:32, 
>> shift exponent 64 is too large for 64-bit type 'long unsigned int'
> 
> Ignore all the gracious changes that make the diff harder to read than
> necessary, doesn't this break the case of width == 0?

Oh, you're correct. When I noticed our code didn't increment the address,
I read FreeBSD's acpi_ec.c and did the same way. It seems old NetBSD,
OpenBSD and linux do the same way but FreeBSD doesn't.

 I committed the change to keep the old behavior.

Thanks.

> Joerg
> 


-- 
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

Re: CVS commit: src/sys/dev/acpi

[Joerg Sonnenberger]

On Mon, Aug 05, 2019 at 10:12:04AM +, SAITOH Masanobu wrote:
> Module Name:  src
> Committed By: msaitoh
> Date: Mon Aug  5 10:12:04 UTC 2019
> 
> Modified Files:
>   src/sys/dev/acpi: acpi_ec.c
> 
> Log Message:
> - Fix a bug that acpiec_space_handler() doesn't access more than 64bit
>   correctly. Found by kUBSan on Thinkpad X220. acpiec0 accessed 128bits from
>   address 0xa0. The error message was:
> 
>   UBSan: Undefined Behavior in ../../../../dev/acpi/acpi_ec.c:672:32, 
> shift exponent 64 is too large for 64-bit type 'long unsigned int'

Ignore all the gracious changes that make the diff harder to read than
necessary, doesn't this break the case of width == 0?

Joerg

Re: CVS commit: src/sys/dev/acpi

[SAITOH Masanobu]

On 2019/08/05 19:12, SAITOH Masanobu wrote:
> Module Name:  src
> Committed By: msaitoh
> Date: Mon Aug  5 10:12:04 UTC 2019
> 
> Modified Files:
>   src/sys/dev/acpi: acpi_ec.c
> 
> Log Message:
> - Fix a bug that acpiec_space_handler() doesn't access more than 64bit
>   correctly. Found by kUBSan on Thinkpad X220. acpiec0 accessed 128bits from

s/acpi0/acpiecdt0/

>   address 0xa0. The error message was:
> 
>   UBSan: Undefined Behavior in ../../../../dev/acpi/acpi_ec.c:672:32, 
> shift exponent 64 is too large for 64-bit type 'long unsigned int'
> 
> - KNF.
> The error message was:
> 
> 
> To generate a diff of this commit:
> cvs rdiff -u -r1.75 -r1.76 src/sys/dev/acpi/acpi_ec.c
> 
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.
> 


-- 
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

Re: CVS commit: src/sys/dev/acpi

[Jared McNeill]

Hi Jaromir --

This change breaks the build of the one kernel that includes this code 
(evbarm GENERIC64) as intr_establish_xname is not an MI API.


Cheers,
Jared


On Mon, 15 Oct 2018, Jaromir Dolecek wrote:


Module Name:src
Committed By:   jdolecek
Date:   Mon Oct 15 06:58:08 UTC 2018

Modified Files:
src/sys/dev/acpi: ahcisata_acpi.c

Log Message:
use intr_establish_xname()


To generate a diff of this commit:
cvs rdiff -u -r1.1 -r1.2 src/sys/dev/acpi/ahcisata_acpi.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

Re: CVS commit: src/sys/dev/acpi

[Manuel Bouyer]

On Mon, Dec 11, 2017 at 12:22:56AM +0100, Jaromír Dole?ek wrote:
[in response to acpi_intr_establish() introduction]
> Can we have acpi_intr_establish() accept the xname? It's very useful to
> have the driver name registered for "intrctl list".

The attached patch does it.
AcpiOsInstallInterruptHandler(), part of ACPICA API, doesn't allow passing
the xname. I extend the API with AcpiOsInstallInterruptHandler_xname()
for this purpose, and change acpi_md_OsInstallInterruptHandler() to
accept and use the xname (ia64 doens't use it).
The xname was hardcoded to "acpi SCI" in the
x86 acpi_md_OsInstallInterruptHandler(), so I make
AcpiOsInstallInterruptHandler() call
AcpiOsInstallInterruptHandler_xname with xname = "acpi SCI".

On my laptop I had before the change:
>intrctl list
interrupt idCPU0  CPU1  CPU2  CPU3  device name(s)
ioapic0 pin 9  29928*0 0 0  acpi SCI
msi0 vec 0  3388*0 0 0  xhci0
ioapic0 pin 16 0*0 0 0  unknown, ahcisata0, ichsmb0
ioapic0 pin 17 0*0 0 0  unknown
ioapic0 pin 51 0*0 0 0  acpi SCI
msi1 vec 0   394*0 0 0  iwm0
msix2 vec 00*0 0 0  nvme0 adminq
msix2 vec 1 1652*0 0 0  nvme0 ioq1
msix2 vec 20  1915*0 0  nvme0 ioq2
msix2 vec 30 0   104*0  nvme0 ioq3
msix2 vec 40 0 0   426* nvme0 ioq4
msi3 vec 0 0*0 0 0  hdaudio0
ioapic0 pin 1  0*0 0 0  unknown
ioapic0 pin 12 0*0 0 0  unknown

and after:
>intrctl list
interrupt id   CPU0  CPU1  CPU2  CPU3  device name(s)
ioapic0 pin 9  7130*0 0 0  acpi SCI
msi0 vec 0  920*0 0 0  xhci0
ioapic0 pin 160*0 0 0  unknown, ahcisata0, ichsmb0
ioapic0 pin 170*0 0 0  unknown
ioapic0 pin 510*0 0 0  ihidev0
msi1 vec 0  617*0 0 0  iwm0
msix2 vec 0   0*0 0 0  nvme0 adminq
msix2 vec 12531*0 0 0  nvme0 ioq1
msix2 vec 2   0   911*0 0  nvme0 ioq2
msix2 vec 3   0 095*0  nvme0 ioq3
msix2 vec 4   0 0 0   407* nvme0 ioq4
msi3 vec 00*0 0 0  hdaudio0
ioapic0 pin 1 0*0 0 0  unknown
ioapic0 pin 120*0 0 0  unknown

any objection to this change ?

-- 
Manuel Bouyer 
 NetBSD: 26 ans d'experience feront toujours la difference
--
Index: sys/arch/ia64/acpi/acpi_machdep.c
===
RCS file: /cvsroot/src/sys/arch/ia64/acpi/acpi_machdep.c,v
retrieving revision 1.6
diff -u -p -u -r1.6 acpi_machdep.c
--- sys/arch/ia64/acpi/acpi_machdep.c   23 Sep 2012 00:31:05 -  1.6
+++ sys/arch/ia64/acpi/acpi_machdep.c   28 Dec 2017 14:32:18 -
@@ -77,7 +77,8 @@ acpi_md_OsGetRootPointer(void)
 ACPI_STATUS
 acpi_md_OsInstallInterruptHandler(UINT32 InterruptNumber,
  ACPI_OSD_HANDLER ServiceRoutine,
- void *Context, void **cookiep)
+ void *Context, void **cookiep,
+ const char *xname)
 {
static int isa_irq_to_vector_map[16] = {
/* i8259 IRQ translation, first 16 entries */
Index: sys/arch/ia64/include/acpi_machdep.h
===
RCS file: /cvsroot/src/sys/arch/ia64/include/acpi_machdep.h,v
retrieving revision 1.6
diff -u -p -u -r1.6 acpi_machdep.h
--- sys/arch/ia64/include/acpi_machdep.h23 Sep 2012 00:31:05 -  
1.6
+++ sys/arch/ia64/include/acpi_machdep.h28 Dec 2017 14:32:18 -
@@ -12,7 +12,7 @@ ACPI_PHYSICAL_ADDRESS acpi_md_OsGetRootP
 #define acpi_md_OsOut32(x, v)  outl((x), (v))
 
 ACPI_STATUS acpi_md_OsInstallInterruptHandler(UINT32, ACPI_OSD_HANDLER,
- void *, void **);
+ void *, void **, const char *);
 void acpi_md_OsRemoveInterruptHandler(void *);
 
 ACPI_STATUS acpi_md_OsMapMemory(ACPI_PHYSICAL_ADDRESS, UINT32, void **);
Index: sys/arch/x86/acpi/acpi_machdep.c
===
RCS file: /cvsroot/src/sys/arch/x86/acpi/acpi_machdep.c,v
retrieving revision 1.18
diff -u -p -u -r1.18 acpi_machdep.c
--- sys/arch/x86/acpi/acpi_machdep.c14 Feb 2017 13:29:09 -  1.18
+++ sys/arch/x86/acpi/acpi_machdep.c28 Dec 2017 14:32:19 -
@@ -147,7 +147,8 @@ acpi_md_findoverride(ACPI_SUBTABLE_HEADE
 
 ACPI_STATUS
 acpi_md_OsInstallInterruptHandler(uint32_t InterruptNumber,
-ACPI_OSD_HANDLER ServiceRoutine, void *Context, void **cookiep)
+ACPI_OSD_HANDLER ServiceRoutine, void *Context, void **cookiep,
+const char *xname)
 {
void *ih;
struct pic *pic;
@@ -242,7 +243,7 @@ acpi_md_OsInstallInterruptHandler(uint32
 * XXX probably, IPL_BIO is enough.
 */
ih 

Re: CVS commit: src/sys/dev/acpi

[Jaromír Doleček]

Can we have acpi_intr_establish() accept the xname? It's very useful to
have the driver name registered for "intrctl list".

Jaromir

2017-12-10 17:51 GMT+01:00 Manuel Bouyer :

> Module Name:src
> Committed By:   bouyer
> Date:   Sun Dec 10 16:51:30 UTC 2017
>
> Modified Files:
> src/sys/dev/acpi: acpi_util.c files.acpi
> Added Files:
> src/sys/dev/acpi: acpi_i2c.c acpi_i2c.h acpi_intr.h
>
> Log Message:
> Implement a ACPI helper to fill the property array expected from our I2C
> framework from the ACPI tables.
> Also implement acpi_intr_establish(), acpi_intr_disestablish() and
> acpi_intr_string().
> Needed for the upcoming HID over I2C support, proposed on tech-kern@
> on Dec, 1.
>
>
> To generate a diff of this commit:
> cvs rdiff -u -r0 -r1.1 src/sys/dev/acpi/acpi_i2c.c \
> src/sys/dev/acpi/acpi_i2c.h src/sys/dev/acpi/acpi_intr.h
> cvs rdiff -u -r1.8 -r1.9 src/sys/dev/acpi/acpi_util.c
> cvs rdiff -u -r1.99 -r1.100 src/sys/dev/acpi/files.acpi
>
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.
>
>

Re: CVS commit: src/sys/dev/acpi/wmi

[David Holland]

On Sun, Dec 03, 2017 at 11:53:37PM +0100, Manuel Bouyer wrote:
 > On Sun, Dec 03, 2017 at 11:06:47AM -0800, bch wrote:
 > > ...
 > > /usr/src/sys/dev/acpi/wmi/wmi_dell.c: In function 'wmi_dell_action':
 > > /usr/src/sys/dev/acpi/wmi/wmi_dell.c:234:16: error: comparison between
 > > signed and unsigned integer expressions [-Werror=sign-compare]
 > >   for (i = 0; i < __arraycount(wmi_dell_actions); i++) {
 > > ^
 > > cc1: all warnings being treated as errors
 > 
 > that's strange, I don't get it on my sources tree.

Odd that you wouldn't, but maybe it depends on whether you're building
a kernel or something rumpity.

 > Would changing i to unsigned int fix the warning ?

Yes. Provided of course that it doesn't break elsewhere that way :-)

-- 
David A. Holland
dholl...@netbsd.org

Re: CVS commit: src/sys/dev/acpi/wmi

[Manuel Bouyer]

On Sun, Dec 03, 2017 at 11:06:47AM -0800, bch wrote:
> ...
> /usr/src/sys/dev/acpi/wmi/wmi_dell.c: In function 'wmi_dell_action':
> /usr/src/sys/dev/acpi/wmi/wmi_dell.c:234:16: error: comparison between
> signed and unsigned integer expressions [-Werror=sign-compare]
>   for (i = 0; i < __arraycount(wmi_dell_actions); i++) {
> ^
> cc1: all warnings being treated as errors

that's strange, I don't get it on my sources tree.
Would changing i to unsigned int fix the warning ?

-- 
Manuel Bouyer 
 NetBSD: 26 ans d'experience feront toujours la difference
--

Re: CVS commit: src/sys/dev/acpi/wmi

[bch]

...
/usr/src/sys/dev/acpi/wmi/wmi_dell.c: In function 'wmi_dell_action':
/usr/src/sys/dev/acpi/wmi/wmi_dell.c:234:16: error: comparison between
signed and unsigned integer expressions [-Werror=sign-compare]
  for (i = 0; i < __arraycount(wmi_dell_actions); i++) {
^
cc1: all warnings being treated as errors




On 12/3/17, Manuel Bouyer  wrote:
> Module Name:  src
> Committed By: bouyer
> Date: Sun Dec  3 17:40:48 UTC 2017
>
> Modified Files:
>   src/sys/dev/acpi/wmi: wmi_dell.c
>
> Log Message:
> Fix dell WMI mappings:
> - query the descriptor to get the interface version, needed to workaround
>   a bug in the BIOS/ACPI
> - properly decode the event buffer in type/subtype, and handle multiple
> events
>   per handler call
> - record some known type/subtype in a table, with associated actions.
>
> Informations mostly from linux. Tested on a Dell 5480 laptop.
>
>
> To generate a diff of this commit:
> cvs rdiff -u -r1.9 -r1.10 src/sys/dev/acpi/wmi/wmi_dell.c
>
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.
>
>

Re: CVS commit: src/sys/dev/acpi

[Jukka Ruohonen]

On Fri, Aug 05, 2011 at 06:27:48PM +, Jonathan A. Kollasch wrote:
 Module Name:  src
 Committed By: jakllsch
 Date: Fri Aug  5 18:27:48 UTC 2011
 
 Modified Files:
   src/sys/dev/acpi: acpi.c
 
 Log Message:
 As we add a handler for the ACPI fixed feature button events,
 ensure they aren't going to trigger as soon as we enable interrupts,
 furthermore ensure that the event is unmasked.

What is the purpose of this? All fixed events should be disabled by default;

AcpiEnableSubsystem() -
AcpiEvInitializeEvents() -
AcpiEvFixedEventInitialize().

- Jukka.

Re: CVS commit: src/sys/dev/acpi

[Jonathan A. Kollasch]

On Sat, Aug 06, 2011 at 02:55:15PM +0300, Jukka Ruohonen wrote:
 On Fri, Aug 05, 2011 at 06:27:48PM +, Jonathan A. Kollasch wrote:
  Module Name:src
  Committed By:   jakllsch
  Date:   Fri Aug  5 18:27:48 UTC 2011
  
  Modified Files:
  src/sys/dev/acpi: acpi.c
  
  Log Message:
  As we add a handler for the ACPI fixed feature button events,
  ensure they aren't going to trigger as soon as we enable interrupts,
  furthermore ensure that the event is unmasked.
 
 What is the purpose of this? All fixed events should be disabled by default;
 
   AcpiEnableSubsystem() -
   AcpiEvInitializeEvents() -
   AcpiEvFixedEventInitialize().
 
 - Jukka.

That commit was mostly reverted already.

The current version does what I needed.

Jonathan Kollasch

Re: CVS commit: src/sys/dev/acpi

[Jukka Ruohonen]

On Sat, Aug 06, 2011 at 12:02:52PM +, Jonathan A. Kollasch wrote:
 The current version does what I needed.

But what is that?

- Jukka.

Re: CVS commit: src/sys/dev/acpi

[Jonathan A. Kollasch]

On Sat, Aug 06, 2011 at 03:04:27PM +0300, Jukka Ruohonen wrote:
 On Sat, Aug 06, 2011 at 12:02:52PM +, Jonathan A. Kollasch wrote:
  The current version does what I needed.
 
 But what is that?

Prevent immediate shutdowns because the button was pressed at power
up.

Jonathan Kollasch

Re: CVS commit: src/sys/dev/acpi

[Iain Hibbert]

On Sun, 22 May 2011, Joerg Sonnenberger wrote:

 Modified Files:
   src/sys/dev/acpi: acpi_power.c

 Log Message:
 Let's not be silly. Use a fancy if else to decide behavior of a bool
 and hope cosmic radition doesn't create a third state.

I'll just say here, that I found a code generation bug in pcc (actually,
inexact emulation of a gcc feature which was a wtf itself) because of the
existence of this kind of code..

think of it as an assert(), which could for example catch calls to the
function using an int argument (yeah ok, -std=gnu99 would complain about
lack of prototypes)

iain

Re: CVS commit: src/sys/dev/acpi

[Christos Zoulas]

In article 20110425053021.afdbf17...@cvs.netbsd.org,
Jukka Ruohonen source-changes-d@NetBSD.org wrote:
-=-=-=-=-=-

Module Name:   src
Committed By:  jruoho
Date:  Mon Apr 25 05:30:21 UTC 2011

Modified Files:
   src/sys/dev/acpi: acpi_cpu.c

Log Message:
Add a missing case value in a switch statement.


Why go from a switch to a bunch of if statements? You could also use
an array here, since the values are contiguous.

christos

Re: CVS commit: src/sys/dev/acpi

[Mindaugas Rasiukevicius]

Jukka Ruohonen jruoho...@iki.fi wrote:
 
 Are there any plans for kernel equivalent to cpuset(3)?
 

Yes, there is kcpuset(9), see kcpuset_create() and friends.  I plan to
modify it so it could be used early in MD code (when memory allocation
is not yet available) and thus unify random MD cpuset implementations.

Obviously, there is a lack of kcpuset(9) man page.

-- 
Mindaugas

Re: CVS commit: src/sys/dev/acpi

[Jukka Ruohonen]

On Fri, Feb 25, 2011 at 07:55:07PM +, Jukka Ruohonen wrote:
 Log Message:
 Start to derive the percpu(9) (or per-domain) state coordination
 mechanisms by parsing the _CSD, _PSD, and _TSD objects by default.

This is quite interesting development affecting the whole x86; the sleep and
performance states are no longer necessarily shared by all CPUs in the system.

Currently we do a xcall(9) and write the MSRs to all CPUs. But new x86 CPUs
can do percpu(9) -- or rather per-core or per CPU domain -- coordination. 
Note that these are not software constructs or BIOS constructs; as
usual, ACPI just supplies the data for us. While I need to study this more,
the basic scenario is:

set 1 = { CPU0, CPU1 } and set 2 = { CPU2, CPU3 }.

Write the MSR for CPU0 - the whole set 1 transforms.

This is also important due to the recent TurboBoost and AMD's equivalent;

The set 1 enters C3 - the set 2 can enter high-performance P-state.

Are there any plans for kernel equivalent to cpuset(3)?

- Jukka.

Re: CVS commit: src/sys/dev/acpi

[Jukka Ruohonen]

On Tue, Feb 22, 2011 at 09:34:13AM +, Jukka Ruohonen wrote:
 in acpicpu_cstate_fadt(). Note that this violates the specification, given:
 
PBlockAddress provides the system I/O address for the processors
 register block.  Each processor can supply a different such address.
 PBlockLength is the length of the processor register block, in bytes and
 is either 0 (for no P_BLK) or 6.  With one exception, all processors are
 required to have the same PBlockLength.  The exception is that the boot
 processor can have a non-zero PBlockLength when all other processors
 have a zero PBlockLength.  It is valid for every processor to have a
 PBlockLength of 0. (ACPI 4.0, p. 626)

In case someone noticed, that should read: Note that this DOES NOT
violate [...]. Fixed with cvs admin.

- Jukka.

Re: CVS commit: src/sys/dev/acpi

[Jukka Ruohonen]

The so-called wakedev code might be broken for a short while.
The reasons are listed below.

- Jukka.

On Thu, Feb 17, 2011 at 10:49:30AM +, Jukka Ruohonen wrote:
 Module Name:  src
 Committed By: jruoho
 Date: Thu Feb 17 10:49:30 UTC 2011
 
 Modified Files:
   src/sys/dev/acpi: acpi_ec.c acpi_wakedev.c
 
 Log Message:
 ACPICA 20101209:
 
 Completed the major overhaul of the GPE support code that was begun in July
 2010. Major features include: removal of _PRW execution in ACPICA (host
 executes _PRWs anyway), cleanup of wake GPE interfaces and processing,
 changes to existing interfaces, simplification of GPE handler operation, and
 a handful of new interfaces:
 
 AcpiUpdateAllGpes
 AcpiFinishGpe
 AcpiSetupGpeForWake
 AcpiSetGpeWakeMask
 
 ACPICA 20100331:
 
 Completed a major update for the GPE support in order to improve support for
 shared GPEs and to simplify both host OS and ACPICA code. Added a reference
 count mechanism to support shared GPEs that require multiple device drivers.
 Several external interfaces have changed. One external interface has been
 removed. One new external interface was added. Most of the GPE external
 interfaces now use the GPE spinlock instead of the events mutex (and the
 Flags parameter for many GPE interfaces has been removed.) See the updated
 ACPICA Programmer Reference for details. Matthew Garrett, Bob Moore, Rafael
 Wysocki. ACPICA BZ 831.
 
 Changed:
 AcpiEnableGpe, AcpiDisableGpe, AcpiClearGpe, AcpiGetGpeStatus
 Removed:
 AcpiSetGpeType
 New:
 AcpiSetGpe
 
 ACPICA 20100702:
 
 Implemented several updates to the recently added GPE reference count
 support. The model for wake GPEs is changing to give the host OS complete
 control of these GPEs. Eventually, the ACPICA core will not execute any _PRW
 methods, since the host already must execute them. Also, additional changes
 were made to help ensure that the reference counts are kept in proper
 synchronization with reality. Rafael J. Wysocki.
 
 1) Ensure that GPEs are not enabled twice during initialization.
 2) Ensure that GPE enable masks stay in sync with the reference count.
 3) Do not inadvertently enable GPEs when writing GPE registers.
 4) Remove the internal wake reference counter and add new AcpiGpeWakeup
 interface. This interface will set or clear individual GPEs for wakeup.
 5) Remove GpeType argument from AcpiEnable and AcpiDisable. These interfaces
 are now used for runtime GPEs only.
 
 
 To generate a diff of this commit:
 cvs rdiff -u -r1.68 -r1.69 src/sys/dev/acpi/acpi_ec.c
 cvs rdiff -u -r1.20 -r1.21 src/sys/dev/acpi/acpi_wakedev.c
 
 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.
 

Re: CVS commit: src/sys/dev/acpi

[Jukka Ruohonen]

On Thu, Feb 17, 2011 at 07:36:49PM +, Jukka Ruohonen wrote:
 Log Message:
 As explained in the new ACPICA documentation, as of ACPICA 20101207, the
 _PRW methods are no longer automatically executed as part of the ACPICA
 initialization. Refactor and rewrite the wake-device code to account this.

Despite of testing before the import, a regression still slipped through.
The following change that affects acpiec(4) is the most plausible culprit:

Re-introduced the support to enable multi-byte transfers for Embedded
Controller (EC) operation regions. A reported problem was found to be a bug
in the host OS, not in the multi-byte support. Previously, the maximum data 
size passed to the EC operation region handler was a single byte. There are
often EC Fields larger than one byte that need to be transferred, and it is 
useful for the EC driver to lock these as a single transaction. This change
enables single transfers larger than 8 bits. This effectively changes the
access to the EC space from ByteAcc to AnyAcc, and will probably require   
changes to the host OS Embedded Controller driver to enable 16/32/64/256-bit
transfers in addition to 8-bit transfers. Alexey Starikovskiy, Lin Ming.

(ACPICA 20100806.)

I don't have cycles to debug this any more today, but I will continue
tomorrow. In the meanwhile, if someone has an idea about this, please feel
free to join.

- Jukka.

Re: CVS commit: src/sys/dev/acpi

[Mindaugas Rasiukevicius]

Jukka Ruohonen jruoho...@iki.fi wrote:
 +/*
 + * sysmon_task_queue_cancel:
 + *
 + *   Cancel a scheduled task.
 + */
 +int
 +sysmon_task_queue_cancel(void (*func)(void *))
 +{
 + struct sysmon_task *st;
 +
 + if (func == NULL)
 + return EINVAL;
 +
 + mutex_enter(sysmon_task_queue_mtx);
 + TAILQ_FOREACH(st, sysmon_task_queue, st_list) {
 + if (st-st_func == func) {
 + TAILQ_REMOVE(sysmon_task_queue, st, st_list);
 + mutex_exit(sysmon_task_queue_mtx);
 + free(st, M_TEMP);
 + mutex_enter(sysmon_task_queue_mtx);
 + }
 + }
 + mutex_exit(sysmon_task_queue_mtx);

1) There is a use-after-free.  Hint: TAILQ_FOREACH_SAFE().

2) It is not safe; while lock is dropped, the 'next' entry may also
be removed and freed.  Hint: have a local list and avoid relocking.

-- 
Mindaugas

Re: CVS commit: src/sys/dev/acpi

[Jukka Ruohonen]

On Tue, Jan 04, 2011 at 12:52:57PM +, Mindaugas Rasiukevicius wrote:
 1) There is a use-after-free.  Hint: TAILQ_FOREACH_SAFE().
 
 2) It is not safe; while lock is dropped, the 'next' entry may also
 be removed and freed.  Hint: have a local list and avoid relocking.

Hmm. 2) implies that the whole sysmon_taskq(9) is not safe?

- Jukka.

PS. It is crazy to have safe and unsafe variants of these macros.

Re: CVS commit: src/sys/dev/acpi

[Jukka Ruohonen]

On Tue, Jan 04, 2011 at 05:48:49AM +, Jukka Ruohonen wrote:
   Do not queue functions via sysmon_taskq(9) in the pmf(9) resume hooks.
There is a small and unlikely race when the drivers are loaded as modules;
suspend, resume, queue a function, and immediately unload the module.

Anything against adding for instance the following to sysmon_taskq(9)? Or
better ideas how this should be handled?

- Jukka.

Index: sysmon_taskq.c
===
RCS file: /cvsroot/src/sys/dev/sysmon/sysmon_taskq.c,v
retrieving revision 1.14
diff -u -p -r1.14 sysmon_taskq.c
--- sysmon_taskq.c  5 Sep 2008 22:06:52 -   1.14
+++ sysmon_taskq.c  4 Jan 2011 06:17:45 -
@@ -209,3 +209,30 @@ sysmon_task_queue_sched(u_int pri, void 
 
return 0;
 }
+
+/*
+ * sysmon_task_queue_cancel:
+ *
+ * Cancel a scheduled task.
+ */
+int
+sysmon_task_queue_cancel(void (*func)(void *))
+{
+   struct sysmon_task *st;
+
+   if (func == NULL)
+   return EINVAL;
+
+   mutex_enter(sysmon_task_queue_mtx);
+   TAILQ_FOREACH(st, sysmon_task_queue, st_list) {
+   if (st-st_func == func) {
+   TAILQ_REMOVE(sysmon_task_queue, st, st_list);
+   mutex_exit(sysmon_task_queue_mtx);
+   free(st, M_TEMP);
+   mutex_enter(sysmon_task_queue_mtx);
+   }
+   }
+   mutex_exit(sysmon_task_queue_mtx);
+
+   return 0;
+}
Index: sysmon_taskq.h
===
RCS file: /cvsroot/src/sys/dev/sysmon/sysmon_taskq.h,v
retrieving revision 1.2
diff -u -p -r1.2 sysmon_taskq.h
--- sysmon_taskq.h  21 Jul 2007 23:15:17 -  1.2
+++ sysmon_taskq.h  4 Jan 2011 06:17:45 -
@@ -42,5 +42,6 @@ void  sysmon_task_queue_preinit(void);
 void   sysmon_task_queue_init(void);
 void   sysmon_task_queue_fini(void);
 intsysmon_task_queue_sched(u_int, void (*)(void *), void *);
+intsysmon_task_queue_cancel(void (*func)(void *));
 
 #endif /* _DEV_SYSMON_SYSMON_TASKQ_H_ */
Index: sysmon_taskq.9
===
RCS file: /cvsroot/src/share/man/man9/sysmon_taskq.9,v
retrieving revision 1.6
diff -u -p -r1.6 sysmon_taskq.9
--- sysmon_taskq.9  26 Jan 2010 08:48:39 -  1.6
+++ sysmon_taskq.9  4 Jan 2011 06:18:23 -
@@ -43,6 +43,8 @@
 .Fn sysmon_task_queue_fini void
 .Ft int
 .Fn sysmon_task_queue_sched u_int pri void (*func)(void *) void *arg
+.Ft int
+.Fn sysmon_task_queue_cancel void (*func)(void *)
 .Sh DESCRIPTION
 The machine-independent
 .Nm
@@ -78,10 +80,15 @@ The single argument passed to
 .Fa func
 is specified by
 .Fa arg .
+The
+.Fn sysmon_task_queue_cancel
+function can be used to cancel the execution of already scheduled function.
 .Sh RETURN VALUES
-Upon successful completion,
+Both
 .Fn sysmon_task_queue_sched
-returns 0.
+and
+.Fn sysmon_task_queue_cancel
+return 0 upon successful completion,
 Otherwise, the following error values are returned:
 .Bl -tag -width [EINVAL]
 .It Bq Er EINVAL

Re: CVS commit: src/sys/dev/acpi

[Christoph Egger]

On 09.08.10 07:00, Jukka Ruohonen wrote:
 Module Name:  src
 Committed By: jruoho
 Date: Mon Aug  9 05:00:24 UTC 2010
 
 Modified Files:
   src/sys/dev/acpi: acpi_cpu_cstate.c
 
 Log Message:
 Downgrade the currently supported maximum C-state to C1. There appears to be
 timer-related interrupt issues also in C2. With C1 it is guaranteed that
 acpicpu(4) will not cause any slowdowns due stalled local APIC timer.

Before you switch into C3-state you need to move away from using
the local APIC timer. You can use any external timer such as HPET or
PIT. You use local APIC timer after wakeup again.

Christoph

Re: CVS commit: src/sys/dev/acpi

[Jukka Ruohonen]

On Mon, Aug 09, 2010 at 07:30:52AM +0200, Christoph Egger wrote:
  Log Message:
  Downgrade the currently supported maximum C-state to C1. There appears to be
  timer-related interrupt issues also in C2. With C1 it is guaranteed that
  acpicpu(4) will not cause any slowdowns due stalled local APIC timer.
 
 Before you switch into C3-state you need to move away from using
 the local APIC timer. You can use any external timer such as HPET or
 PIT. You use local APIC timer after wakeup again.

Yes, I am well aware of that. But it is evident that the local APIC timer is
stopped also in C2 on some systems. Thus, for now the only entirely safe
option is to use C1, i.e. operate identically with or without acpicpu(4).

OpenSolaris is considering to use HPET as a proxy for the stalled timers.[1]
But I think there are many other available options as well.

- Jukka.

[1] http://hub.opensolaris.org/bin/view/Project+tesla/CPUPM

Re: CVS commit: src/sys/dev/acpi

[Jukka Ruohonen]

On Sun, Jul 18, 2010 at 08:59:33PM -0400, Christos Zoulas wrote:
 1. ACPI seems to define cpuids 1..n; we define 0..n-1. Adjust for that
 2. My laptop is dual core, but ACPI reports 4 cpu nodes. Instead of
attaching the unmatched ones, make the match fail. Do we want to
attach and do nothing instead?
 3. Create a flag, and only set it after we are completely initialized,
so the sysmon thread does not try to access unitialized state.

Can you (and others who might have the same problem) test the attached diff?

There might be a more elegant way to do this, but including the MADT ID in
x86/cpu.h is probably the least invasive one.  There is still the case
where the MADT IDs and ACPI processor object IDs do not match, and the case
where a BIOS writer was unable to enumerate numbers in ascending order.

- Jukka.


Index: include/cpu.h
===
RCS file: /cvsroot/src/sys/arch/x86/include/cpu.h,v
retrieving revision 1.23
diff -u -p -r1.23 cpu.h
--- include/cpu.h   24 Jul 2010 00:45:56 -  1.23
+++ include/cpu.h   30 Jul 2010 07:06:50 -
@@ -95,6 +95,7 @@ struct cpu_info {
int ci_fpused;  /* XEN: FPU was used by curlwp */
cpuid_t ci_cpuid;   /* our CPU ID */
int ci_cpumask; /* (1  CPU ID) */
+   uint32_t ci_acpiid; /* our ACPI/MADT ID */
uint32_t ci_initapicid; /* our intitial APIC ID */
struct cpu_data ci_data;/* MI per-cpu data */
 
Index: include/cpuvar.h
===
RCS file: /cvsroot/src/sys/arch/x86/include/cpuvar.h,v
retrieving revision 1.33
diff -u -p -r1.33 cpuvar.h
--- include/cpuvar.h6 Jul 2010 20:50:35 -   1.33
+++ include/cpuvar.h30 Jul 2010 07:06:50 -
@@ -79,6 +79,7 @@ extern const struct cpu_functions mp_cpu
 #define CPU_ROLE_AP2
 
 struct cpu_attach_args {
+   int cpu_id;
int cpu_number;
int cpu_role;
const struct cpu_functions *cpu_func;
Index: x86/cpu.c
===
RCS file: /cvsroot/src/sys/arch/x86/x86/cpu.c,v
retrieving revision 1.73
diff -u -p -r1.73 cpu.c
--- x86/cpu.c   24 Jul 2010 00:45:56 -  1.73
+++ x86/cpu.c   30 Jul 2010 07:06:50 -
@@ -330,6 +330,7 @@ cpu_attach(device_t parent, device_t sel
ci-ci_self = ci;
sc-sc_info = ci;
ci-ci_dev = self;
+   ci-ci_acpiid = caa-cpu_id;
ci-ci_cpuid = caa-cpu_number;
ci-ci_func = caa-cpu_func;
 
Index: x86/mpacpi.c
===
RCS file: /cvsroot/src/sys/arch/x86/x86/mpacpi.c,v
retrieving revision 1.87
diff -u -p -r1.87 mpacpi.c
--- x86/mpacpi.c27 Apr 2010 05:34:14 -  1.87
+++ x86/mpacpi.c30 Jul 2010 07:06:51 -
@@ -383,6 +383,7 @@ mpacpi_config_cpu(ACPI_SUBTABLE_HEADER *
caa.cpu_role = CPU_ROLE_AP;
else
caa.cpu_role = CPU_ROLE_BP;
+   caa.cpu_id = lapic-ProcessorId;
caa.cpu_number = lapic-Id;
caa.cpu_func = mp_cpu_funcs;
locs[CPUBUSCF_APID] = caa.cpu_number;
@@ -409,6 +410,7 @@ mpacpi_config_cpu(ACPI_SUBTABLE_HEADER *
caa.cpu_role = CPU_ROLE_AP;
else
caa.cpu_role = CPU_ROLE_BP;
+   caa.cpu_id = x2apic-Uid;
caa.cpu_number = x2apic-LocalApicId;
caa.cpu_func = mp_cpu_funcs;
locs[CPUBUSCF_APID] = caa.cpu_number;
Index: x86/mpbios.c
===
RCS file: /cvsroot/src/sys/arch/x86/x86/mpbios.c,v
retrieving revision 1.57
diff -u -p -r1.57 mpbios.c
--- x86/mpbios.c18 Apr 2010 23:47:51 -  1.57
+++ x86/mpbios.c30 Jul 2010 07:06:51 -
@@ -717,6 +717,7 @@ mpbios_cpu(const uint8_t *ent, device_t 
else
caa.cpu_role = CPU_ROLE_AP;
 
+   caa.cpu_id = entry-apic_id;
caa.cpu_number = entry-apic_id;
caa.cpu_func = mp_cpu_funcs;
locs[CPUBUSCF_APID] = caa.cpu_number;
Index: acpi_cpu.c
===
RCS file: /cvsroot/src/sys/dev/acpi/acpi_cpu.c,v
retrieving revision 1.10
diff -u -p -r1.10 acpi_cpu.c
--- acpi_cpu.c  30 Jul 2010 06:11:14 -  1.10
+++ acpi_cpu.c  30 Jul 2010 07:08:02 -
@@ -270,8 +270,12 @@ acpicpu_id(uint32_t id)
 
for (CPU_INFO_FOREACH(cii, ci)) {
 
-   if (id == ci-ci_cpuid)
+   if (id == ci-ci_acpiid) {
+   printf(ACPI CPU: 
+   ACPI ID %u, MADT ID %u, LAPIC ID %u\n,
+   id, ci-ci_acpiid, 

Re: CVS commit: src/sys/dev/acpi

[Christos Zoulas]

In article 20100730072156.ga20...@marx.bitnet,
Jukka Ruohonen  jruoho...@iki.fi wrote:
-=-=-=-=-=-

On Sun, Jul 18, 2010 at 08:59:33PM -0400, Christos Zoulas wrote:
 1. ACPI seems to define cpuids 1..n; we define 0..n-1. Adjust for that
 2. My laptop is dual core, but ACPI reports 4 cpu nodes. Instead of
attaching the unmatched ones, make the match fail. Do we want to
attach and do nothing instead?
 3. Create a flag, and only set it after we are completely initialized,
so the sysmon thread does not try to access unitialized state.

Can you (and others who might have the same problem) test the attached diff?

There might be a more elegant way to do this, but including the MADT ID in
x86/cpu.h is probably the least invasive one.  There is still the case
where the MADT IDs and ACPI processor object IDs do not match, and the case
where a BIOS writer was unable to enumerate numbers in ascending order.


Works just fine for me :-) Commit!

cpu0 at mainbus0 apid 0: Intel 686-class, 2527MHz, id 0x10676
cpu1 at mainbus0 apid 1: Intel 686-class, 2527MHz, id 0x10676
ioapic0 at mainbus0 apid 4: pa 0xfec0, version 20, 24 pins
acpi0 at mainbus0: Intel ACPICA 20100528
acpi0: X/RSDT: OemId   Sony,VAIO,20090717, AslId ,0113
acpi0: SCI interrupting at int 9
timecounter: Timecounter ACPI-Fast frequency 3579545 Hz quality 1000
acpi0: SNY6001 activated, STA 0x000D - STA 0x000F
ACPI CPU: ACPI ID 1, MADT ID 1, LAPIC ID 0
acpicpu0 at acpi0 (CPU0)ACPI CPU: ACPI ID 1, MADT ID 1, LAPIC ID 0
ACPI: Dynamic OEM Table Load:
: ACPI CPU, cap 0x318, addr 0x000410, len 0x06
ACPI CPU: ACPI ID 2, MADT ID 2, LAPIC ID 1
acpicpu1 at acpi0 (CPU1)ACPI CPU: ACPI ID 2, MADT ID 2, LAPIC ID 1
ACPI: Dynamic OEM Table Load:
: ACPI CPU, cap 0x318, addr 0x000410, len 0x06
CPU2 (ACPI Object Type 'Processor' [0x0c]) at acpi0 not configured
CPU3 (ACPI Object Type 'Processor' [0x0c]) at acpi0 not configured

christos

Re: CVS commit: src/sys/dev/acpi

[Jukka Ruohonen]

On Mon, Jul 19, 2010 at 12:39:08PM +, Quentin Garnier wrote:
 When the platform uses the APIC interrupt model, OSPM associates
 processors declared in the namespace with entries in the MADT.  Prior to
 ACPI 3.0, this was accomplished using the processor object's ProcessorID
 and the ACPI Processor ID fields in MADT entries.  UID fields were added
 to MADT entries in ACPI 3.0.  By expanding processor declaration using
 Device definitions, UID object values under a processor device are used to
 associate processor devices with entries in the MADT.  This removes the
 previous 256 processor declaration limit.

Yes, you are quite right. What I meant that the Processor opcode (section
18.5.93) just says that the ID should be unique.

We can of course match against cpu_info::ci_cpuid or cpu_info::ci_initapicid,
or anything that is derived from MADT, which we should always prefer. But it
does not really matter what the base is.  Nor does it matter how and where
the ACPI CPUs are attached.

We have at least the case where the MADT values are right (e.g. are
derived from 0) and the processor object's values are bogus (e.g.
enumerated from 1 by the BIOS writer). Arguably these are BIOS bugs,
but unfortunately such flaws are not uncommon.

If you have any good ideas, I am all ears. Please feel free to commit as well.
It may be enlightening to go see how for instance FreeBSD struggled with this.

- Jukka.

Re: CVS commit: src/sys/dev/acpi

[Christoph Egger]

On 19.07.10 02:59, Christos Zoulas wrote:
 Module Name:  src
 Committed By: christos
 Date: Mon Jul 19 00:59:32 UTC 2010
 
 Modified Files:
   src/sys/dev/acpi: acpi_cpu.c acpi_cpu.h acpi_cpu_cstate.c
 
 Log Message:
 XXX: If this is not correct, revert or fix.
 This makes my laptop boot instead of panic:
 
 panic: kernel diagnostic assertion native_idle != NULL failed: file 
 ../../../../arch/x86/acpi/acpi_cpu_md.c, line 155
 fatal breakpoint trap in supervisor mode
 type 1 code 0 rip 8022e4ad cs 8 rflags 246 cr2  0 cpl 0 rsp 
 80004c37db10
 
 trace
 breakpoint() at netbsd:breakpoint+0x5
 panic() at netbsd:panic+0x2ba
 kern_assert() at netbsd:kern_assert+0x2d
 acpicpu_md_idle_stop() at netbsd:acpicpu_md_idle_stop+0x62
 acpicpu_cstate_callback() at netbsd:acpicpu_cstate_callback+0x34
 sysmon_task_queue_thread() at netbsd:sysmon_task_queue_thread+0x41
 
 1. ACPI seems to define cpuids 1..n; we define 0..n-1. Adjust for that
 2. My laptop is dual core, but ACPI reports 4 cpu nodes. Instead of
attaching the unmatched ones, make the match fail. Do we want to
attach and do nothing instead?
 3. Create a flag, and only set it after we are completely initialized,
so the sysmon thread does not try to access unitialized state.

This change let's my laptop panic:

panic: kernel diagnostic assertion id != 0 failed: file
sys/dev/acpi/acpi_cpu.c, line 274
db{0} bt
breakpoint+0x5
panic+0x2ba
kern_assert+0x2d
acpicpu_id+0x69
acpicpu_match+0x5a
mapply+0x41

Re: CVS commit: src/sys/dev/acpi

[Jukka Ruohonen]

On Mon, Jul 19, 2010 at 09:32:58AM +0300, Jukka Ruohonen wrote:
 This is a known issue. No clean solution exist in any implementation I am
 aware of.  The IDs may also vary between the processor object and MADT.

As I noted to Christos in private mail, the right solution is likely to
include the ACPI processor object ID in (x86) cpu_info and operate with that
value only.  The specification imposes no restrictions on these IDs; some
BIOSes may start counting the ACPI CPUs from zero and others from one.

 Due to the reasons with the identification, I think we might want to
 attach them all nevertheless.

I also checked the ACPI tables of some servers; these may define even up to
0xFF processor objects by default, possibly in order to use the same tables
with different models, etc.  Another case is virtualized environments. So,
yes, we should only attach those ACPI CPUs that have a real counterpart.

- Jukka.

Re: CVS commit: src/sys/dev/acpi

[Christoph Egger]

 Module Name:  src
 Committed By: christos
 Date: Mon Jul 19 00:59:32 UTC 2010
 
 Modified Files:
   src/sys/dev/acpi: acpi_cpu.c acpi_cpu.h acpi_cpu_cstate.c
 
 Log Message:
 XXX: If this is not correct, revert or fix.
 This makes my laptop boot instead of panic:
 
 panic: kernel diagnostic assertion native_idle != NULL failed: file
 ../../../../arch/x86/acpi/acpi_cpu_md.c, line 155
 fatal breakpoint trap in supervisor mode
 type 1 code 0 rip 8022e4ad cs 8 rflags 246 cr2  0 cpl 0 rsp
 80004c37db10
 
 trace
 breakpoint() at netbsd:breakpoint+0x5
 panic() at netbsd:panic+0x2ba
 kern_assert() at netbsd:kern_assert+0x2d
 acpicpu_md_idle_stop() at netbsd:acpicpu_md_idle_stop+0x62
 acpicpu_cstate_callback() at netbsd:acpicpu_cstate_callback+0x34
 sysmon_task_queue_thread() at netbsd:sysmon_task_queue_thread+0x41
 
 1. ACPI seems to define cpuids 1..n; we define 0..n-1. Adjust for that

No, ACPI enumerates cpus 0..n-1 by specification.

 2. My laptop is dual core, but ACPI reports 4 cpu nodes. Instead of
attaching the unmatched ones, make the match fail. Do we want to
attach and do nothing instead?

Uh, do your two cores attach on id 1 and 2 and ids 0 and 3
are unused?

That sounds like your laptop vendor prepared the BIOS to
deliver laptop models with a quad-core cpu.

 3. Create a flag, and only set it after we are completely initialized,
so the sysmon thread does not try to access unitialized state.

Re: CVS commit: src/sys/dev/acpi

[Quentin Garnier]

On Mon, Jul 19, 2010 at 09:32:58AM +0300, Jukka Ruohonen wrote:
 On Sun, Jul 18, 2010 at 08:59:33PM -0400, Christos Zoulas wrote:
  1. ACPI seems to define cpuids 1..n; we define 0..n-1. Adjust for that
 
 ACPI is silent about the CPU IDs in the processor object. In all three

Huh?

8.4 Declaring Processors

[...]

When the platform uses the APIC interrupt model, OSPM associates processors 
declared in the namespace
with entries in the MADT. Prior to ACPI 3.0, this was accomplished using the 
processor object's
ProcessorID and the ACPI Processor ID fields in MADT entries. UID fields were 
added to MADT entries
in ACPI 3.0. By expanding processor declaration using Device definitions, UID 
object values under a
processor device are used to associate processor devices with entries in the 
MADT. This removes the
previous 256 processor declaration limit.

-- 
Quentin Garnier - c...@cubidou.net - c...@netbsd.org
See the look on my face from staying too long in one place
[...] every time the morning breaks I know I'm closer to falling
KT Tunstall, Saving My Face, Drastic Fantastic, 2007.


pgpiWiBqs23aC.pgp
Description: PGP signature

Re: CVS commit: src/sys/dev/acpi

[Christoph Egger]

On 03.04.10 18:29, Jukka Ruohonen wrote:
 Module Name:  src
 Committed By: jruoho
 Date: Sat Apr  3 16:29:22 UTC 2010
 
 Modified Files:
   src/sys/dev/acpi: acpi_bat.c
 
 Log Message:
 Update the limits when a change from absent to present is detected.
 

Does acpi_bat also detect the other way around ?

I.e. when you have multiple batteries you can unplug a full charged
battery and then re-plug an empty one for charging.

Christoph

Re: CVS commit: src/sys/dev/acpi

[Jukka Ruohonen]

On Sat, Apr 03, 2010 at 06:39:54PM +0200, Christoph Egger wrote:
 Does acpi_bat also detect the other way around ?
 
 I.e. when you have multiple batteries you can unplug a full charged
 battery and then re-plug an empty one for charging.

Yes, this should be possible.

(This change only fixed an issue where the limits were not visible in a
situation where the driver is attached with no battery present and a battery
is later inserted.)

- Jukka.

Re: CVS commit: src/sys/dev/acpi

[Paul Goyette]

On Sat, 3 Apr 2010, Christoph Egger wrote:


On 03.04.10 18:29, Jukka Ruohonen wrote:

Module Name:src
Committed By:   jruoho
Date:   Sat Apr  3 16:29:22 UTC 2010

Modified Files:
src/sys/dev/acpi: acpi_bat.c

Log Message:
Update the limits when a change from absent to present is detected.



Does acpi_bat also detect the other way around ?

I.e. when you have multiple batteries you can unplug a full charged
battery and then re-plug an empty one for charging.


When the battery is absent, the limit values don't make much difference!

But yes, the scenario you propose will work - nothing happens when the 
old (full) battery is removed, but when you insert a new (empty) one, 
the limits will get set based on the new battery, and its state will be 
monitored.




Christoph



-
|   Paul Goyette   | PGP DSS Key fingerprint: |  E-mail addresses:  |
| Customer Service | FA29 0E3B 35AF E8AE 6651 |  paul at whooppee.com   |
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
| Kernel Developer |  | pgoyette at netbsd.org  |
-

Re: CVS commit: src/sys/dev/acpi

[Constantine Aleksandrovich Murenin]

This doesn't sound right:  if sysmon_envsys(9) functions are
specifically used in these drivers, then depending on header pollution
for the prototypes of these functions instead of explicitly including
dev/sysmon/sysmonvar.h sounds like a definite bug, not at all a
feature.

C.

On 05/03/2010, Jukka Ruohonen jru...@netbsd.org wrote:
 Module Name:src
  Committed By:   jruoho

 Date:   Fri Mar  5 14:00:17 UTC 2010

  Modified Files:
 src/sys/dev/acpi: acpi.c acpi_acad.c acpi_apm.c acpi_bat.c
 acpi_button.c acpi_ec.c acpi_lid.c acpi_madt.c acpi_pci.c
 acpi_pci_link.c acpi_powerres.c acpi_quirks.c acpi_resource.c
 acpi_slit.c acpi_srat.c acpi_timer.c acpi_tz.c acpi_wakedev.c
 aiboost.c asus_acpi.c atk0110.c atppc_acpi.c attimer_acpi.c
 com_acpi.c dalb_acpi.c fdc_acpi.c hpet_acpi.c hpqlb_acpi.c
 joy_acpi.c lpt_acpi.c mpu_acpi.c pckbc_acpi.c pcppi_acpi.c
 smbus_acpi.c sony_acpi.c spic_acpi.c thinkpad_acpi.c ug_acpi.c
 wb_acpi.c wmi_acpi.c wss_acpi.c ym_acpi.c

  Log Message:
  Remove dev/acpi/acpica.h from all files. It is included from
  dev/acpi/acpivar.h. Ditto for dev/sysmon/sysmonvar.h, sys/bus.h,
  dev/pci/pcivar.h, and dev/isa/isavar.h.

  Also nuke a lot of unused and invalid headers. Some of these are audibly
  provided by standard headers (namely sys/param.h and sys/device.h), some
  have nothing to do with ACPI devices (e.g. sys/syslog.h), and some are
  nonexistent local includes (e.g. mpu_ym.h). Moreoever, try to group the
  includes into their respective blocks.

  Tested with GENERIC and ALL (i386). No functional change.



  To generate a diff of this commit:

 cvs rdiff -u -r1.154 -r1.155 src/sys/dev/acpi/acpi.c
  cvs rdiff -u -r1.41 -r1.42 src/sys/dev/acpi/acpi_acad.c
  cvs rdiff -u -r1.14 -r1.15 src/sys/dev/acpi/acpi_apm.c \
 src/sys/dev/acpi/acpi_timer.c src/sys/dev/acpi/sony_acpi.c \
 src/sys/dev/acpi/wmi_acpi.c
  cvs rdiff -u -r1.83 -r1.84 src/sys/dev/acpi/acpi_bat.c
  cvs rdiff -u -r1.33 -r1.34 src/sys/dev/acpi/acpi_button.c
  cvs rdiff -u -r1.61 -r1.62 src/sys/dev/acpi/acpi_ec.c
  cvs rdiff -u -r1.35 -r1.36 src/sys/dev/acpi/acpi_lid.c
  cvs rdiff -u -r1.20 -r1.21 src/sys/dev/acpi/acpi_madt.c
  cvs rdiff -u -r1.2 -r1.3 src/sys/dev/acpi/acpi_pci.c \
 src/sys/dev/acpi/acpi_slit.c src/sys/dev/acpi/acpi_srat.c \
 src/sys/dev/acpi/acpi_wakedev.c
  cvs rdiff -u -r1.15 -r1.16 src/sys/dev/acpi/acpi_pci_link.c
  cvs rdiff -u -r1.10 -r1.11 src/sys/dev/acpi/acpi_powerres.c \
 src/sys/dev/acpi/acpi_quirks.c src/sys/dev/acpi/ym_acpi.c
  cvs rdiff -u -r1.31 -r1.32 src/sys/dev/acpi/acpi_resource.c
  cvs rdiff -u -r1.60 -r1.61 src/sys/dev/acpi/acpi_tz.c
  cvs rdiff -u -r1.29 -r1.30 src/sys/dev/acpi/aiboost.c
  cvs rdiff -u -r1.17 -r1.18 src/sys/dev/acpi/asus_acpi.c
  cvs rdiff -u -r1.8 -r1.9 src/sys/dev/acpi/atk0110.c \
 src/sys/dev/acpi/dalb_acpi.c src/sys/dev/acpi/smbus_acpi.c
  cvs rdiff -u -r1.16 -r1.17 src/sys/dev/acpi/atppc_acpi.c
  cvs rdiff -u -r1.13 -r1.14 src/sys/dev/acpi/attimer_acpi.c
  cvs rdiff -u -r1.30 -r1.31 src/sys/dev/acpi/com_acpi.c
  cvs rdiff -u -r1.37 -r1.38 src/sys/dev/acpi/fdc_acpi.c
  cvs rdiff -u -r1.4 -r1.5 src/sys/dev/acpi/hpet_acpi.c
  cvs rdiff -u -r1.6 -r1.7 src/sys/dev/acpi/hpqlb_acpi.c
  cvs rdiff -u -r1.9 -r1.10 src/sys/dev/acpi/joy_acpi.c \
 src/sys/dev/acpi/mpu_acpi.c
  cvs rdiff -u -r1.18 -r1.19 src/sys/dev/acpi/lpt_acpi.c
  cvs rdiff -u -r1.32 -r1.33 src/sys/dev/acpi/pckbc_acpi.c
  cvs rdiff -u -r1.11 -r1.12 src/sys/dev/acpi/pcppi_acpi.c
  cvs rdiff -u -r1.5 -r1.6 src/sys/dev/acpi/spic_acpi.c \
 src/sys/dev/acpi/ug_acpi.c
  cvs rdiff -u -r1.27 -r1.28 src/sys/dev/acpi/thinkpad_acpi.c
  cvs rdiff -u -r1.1 -r1.2 src/sys/dev/acpi/wb_acpi.c
  cvs rdiff -u -r1.25 -r1.26 src/sys/dev/acpi/wss_acpi.c


  Please note that diffs are not public domain; they are subject to the
  copyright notices on the relevant files.

Re: CVS commit: src/sys/dev/acpi

[Paul Goyette]

On Thu, 4 Mar 2010, Jukka Ruohonen wrote:


Well, this is wrong in the sense that the _COMPONENT definition was
incorrect to begin with, and in the sense that we have explicitly tried to
recently add the _COMPONENT definitions.

Also: now it does BadThings(tm) if the memory tracking of ACPICA is enabled.

The right solution is to e.g. #define _COMPONENT ACPI_BUS_COMPONENT.
The components that can be used are defined in dev/acpi/acpireg.h.


Yes - I've just fixed this.  I wan't sure if BUS or RESOURCE was the 
correct component to use...


Thanks.


-
|   Paul Goyette   | PGP DSS Key fingerprint: |  E-mail addresses:  |
| Customer Service | FA29 0E3B 35AF E8AE 6651 |  paul at whooppee.com   |
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
| Kernel Developer |  | pgoyette at netbsd.org  |
-

Re: CVS commit: src/sys/dev/acpi

[Jukka Ruohonen]

On Thu, Mar 04, 2010 at 05:12:43AM -0800, Paul Goyette wrote:
 On Thu, 4 Mar 2010, Jukka Ruohonen wrote:
 
 Well, this is wrong in the sense that the _COMPONENT definition was
 incorrect to begin with, and in the sense that we have explicitly tried to
 recently add the _COMPONENT definitions.
 
 Also: now it does BadThings(tm) if the memory tracking of ACPICA is 
 enabled.
 
 The right solution is to e.g. #define _COMPONENT ACPI_BUS_COMPONENT.
 The components that can be used are defined in dev/acpi/acpireg.h.
 
 Yes - I've just fixed this.  I wan't sure if BUS or RESOURCE was the 
 correct component to use...

It doesn't really matter whether it is RESOURCE or BUS. These are only
heuristics for debugging.

- Jukka.

Re: CVS commit: src/sys/dev/acpi

[Jukka Ruohonen]

On Thu, Mar 04, 2010 at 03:10:18AM +, Paul Goyette wrote:
 Module Name:  src
 Committed By: pgoyette
 Date: Thu Mar  4 03:10:18 UTC 2010
 
 Modified Files:
   src/sys/dev/acpi: smbus_acpi.c
 
 Log Message:
 Replace ACPI_FREE() with AcpiOsFree() so we no longer need to define
 _COMPONENT (we don't have a bit defined for SMBUS anyway).  This was
 uncovered by turning on ACPI_DEBUG for the i386 ALL kernel config.
 
 Reported by Greg Woods on current-users@

Well, this is wrong in the sense that the _COMPONENT definition was
incorrect to begin with, and in the sense that we have explicitly tried to
recently add the _COMPONENT definitions.

Also: now it does BadThings(tm) if the memory tracking of ACPICA is enabled.

The right solution is to e.g. #define _COMPONENT ACPI_BUS_COMPONENT. 
The components that can be used are defined in dev/acpi/acpireg.h.

But a bigger question I'd like to ask from all: do we really need to play
these games with the ACPICA; why not just convert everything to use native
allocators?

- Jukka.

re: CVS commit: src/sys/dev/acpi

[matthew green]

   Module Name: src
   Committed By:jruoho
   Date:Sun Feb 28 09:23:30 UTC 2010
   
   Modified Files:
src/sys/dev/acpi: acpi_lid.c
   
   Log Message:
   Cleanup:
   
 * Semantics.
 * Remove ACPI_LID_DEBUG.
 * Reduce the amount of error reporting.
 * As the status of the lid (open/closed) is known upon suspend, move the
   state variable to the softc, and avoid one object evaluation this way.


i'm curious why ignoring the various errors is a good thing.  in
particular, sysmon_pswitch_register() and pmf_device_register()
failure mean the device won't work properly, yet there is nothing
to indicate such...


.mrg.

Re: CVS commit: src/sys/dev/acpi

[Jukka Ruohonen]

On Sun, Feb 28, 2010 at 09:16:38PM +1100, matthew green wrote:
 i'm curious why ignoring the various errors is a good thing.  in
 particular, sysmon_pswitch_register() and pmf_device_register()
 failure mean the device won't work properly, yet there is nothing
 to indicate such...

Well, generally I've tried to reduce the verbosity in the acpi(4) subtree,
as it is quite chatty compared to many other subsystems. The acpi(4) device
drivers are also believed to be robust, having been in production since
NetBSD 1.6.

The sysmon_pswitch_register() is currently a dummy function. If
pmf_device_register() fails, the failure should noticeable without an error
message in the event of e.g. suspend... As for things like AcpiOsExecute(),
the failures typically involve invalid parameters (can be verified not to be
the case by manual code inspection) or lack of memory (in which case there
sure are bigger problems than ACPI drivers).

- Jukka.

Re: CVS commit: src/sys/dev/acpi

[David Young]

On Sat, Feb 06, 2010 at 08:10:18PM +, Paul Goyette wrote:
 Module Name:  src
 Committed By: pgoyette
 Date: Sat Feb  6 20:10:18 UTC 2010
 
 Modified Files:
   src/sys/dev/acpi: files.acpi
 Added Files:
   src/sys/dev/acpi: smbus_acpi.c
 
 Log Message:
 Import my experimental ACPI SMBus Control Method Interface driver
 
 XXX Should not be enabled in any configuration file until you have
 XXX disabled corresponding native i2c driver!  Read the acpismbus(4)
 XXX man page!

Is there any possibility/plan to integrate ACPI SMBus CMI with Martin's
direct configuration?

In my experience, disagreement between bus  ACPI device attachments
causes a lot of confusion for operators and kernel bugs.

Dave

-- 
David Young OJC Technologies
dyo...@ojctech.com  Urbana, IL * (217) 278-3933

Re: CVS commit: src/sys/dev/acpi

[Jason Thorpe]

On Dec 3, 2009, at 1:04 PM, Christoph Egger wrote:

 Module Name:  src
 Committed By: cegger
 Date: Thu Dec  3 21:04:29 UTC 2009
 
 Modified Files:
   src/sys/dev/acpi: acpi.c files.acpi
 Added Files:
   src/sys/dev/acpi: acpi_pci.c acpi_pci.h
 
 Log Message:
 Enumerate ACPI PCI devices. Allows to link PCI with ACPI devices.
 Patch presented on tech-kern@
 http://mail-index.netbsd.org/tech-kern/2009/11/28/msg006552.html
 

Shouldn't we just attach PCI busses @ ACPI instead of mainbus?

 'nice work' Jukka Ruohonen
 
 
 To generate a diff of this commit:
 cvs rdiff -u -r1.136 -r1.137 src/sys/dev/acpi/acpi.c
 cvs rdiff -u -r0 -r1.1 src/sys/dev/acpi/acpi_pci.c \
src/sys/dev/acpi/acpi_pci.h
 cvs rdiff -u -r1.62 -r1.63 src/sys/dev/acpi/files.acpi
 
 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

-- thorpej

Re: CVS commit: src/sys/dev/acpi

[David Young]

On Thu, Dec 03, 2009 at 01:54:19PM -0800, Jason Thorpe wrote:
 
 On Dec 3, 2009, at 1:04 PM, Christoph Egger wrote:
 
  Module Name:src
  Committed By:   cegger
  Date:   Thu Dec  3 21:04:29 UTC 2009
  
  Modified Files:
  src/sys/dev/acpi: acpi.c files.acpi
  Added Files:
  src/sys/dev/acpi: acpi_pci.c acpi_pci.h
  
  Log Message:
  Enumerate ACPI PCI devices. Allows to link PCI with ACPI devices.
  Patch presented on tech-kern@
  http://mail-index.netbsd.org/tech-kern/2009/11/28/msg006552.html
  
 
 Shouldn't we just attach PCI busses @ ACPI instead of mainbus?

ISTM that ACPI is a lot of things, but in this instance, it is hardware
metadata.  Existing practice notwithstanding, acpi is not a proper
parent for any ISA/PCI device/bus driver.  (The same goes for isapnp.)

IMO, very few devices should attach at acpi, but autoconfiguration
should use ACPI data, when it is available, for the direct
configuration of devices that we would otherwise have to probe for.

Dave

-- 
David Young OJC Technologies
dyo...@ojctech.com  Urbana, IL * (217) 278-3933

Re: CVS commit: src/sys/dev/acpi

[Quentin Garnier]

On Thu, Dec 03, 2009 at 04:18:52PM -0600, David Young wrote:
 On Thu, Dec 03, 2009 at 01:54:19PM -0800, Jason Thorpe wrote:
  
  On Dec 3, 2009, at 1:04 PM, Christoph Egger wrote:
  
   Module Name:  src
   Committed By: cegger
   Date: Thu Dec  3 21:04:29 UTC 2009
   
   Modified Files:
 src/sys/dev/acpi: acpi.c files.acpi
   Added Files:
 src/sys/dev/acpi: acpi_pci.c acpi_pci.h
   
   Log Message:
   Enumerate ACPI PCI devices. Allows to link PCI with ACPI devices.
   Patch presented on tech-kern@
   http://mail-index.netbsd.org/tech-kern/2009/11/28/msg006552.html
   
  
  Shouldn't we just attach PCI busses @ ACPI instead of mainbus?
 
 ISTM that ACPI is a lot of things, but in this instance, it is hardware
 metadata.  Existing practice notwithstanding, acpi is not a proper
 parent for any ISA/PCI device/bus driver.  (The same goes for isapnp.)
 
 IMO, very few devices should attach at acpi, but autoconfiguration
 should use ACPI data, when it is available, for the direct
 configuration of devices that we would otherwise have to probe for.

Was there ever a disagreement on that?

I fail to see how the API that was just committed will not result in a
#if NACPI  0 block every time it is used.

-- 
Quentin Garnier - c...@cubidou.net - c...@netbsd.org
See the look on my face from staying too long in one place
[...] every time the morning breaks I know I'm closer to falling
KT Tunstall, Saving My Face, Drastic Fantastic, 2007.


pgp2Botmh6Lmg.pgp
Description: PGP signature

Re: CVS commit: src/sys/dev/acpi

[Christoph Egger]

Paul Goyette wrote:
 On Fri, 4 Dec 2009, Quentin Garnier wrote:
 
 IMO, very few devices should attach at acpi, but autoconfiguration
 should use ACPI data, when it is available, for the direct
 configuration of devices that we would otherwise have to probe for.

 Was there ever a disagreement on that?
 
 Well, one place where this might not work is for ACPI-accessible i2c
 busses!  The acpi code might well be manipulating the bus without
 obeying any i2c_acquire_bus() locking mechanism implemented in the
 native pci-based drivers, with unpredictable results.  (Consider the
 case where an acpitz might be using an i2c-connected sensor...)

For this case, the ACPI driver gives the BIOS a chance to handle mutex
access SMBus in OS runtime. The purpose of ACPI CMI is to coordinate
access to the SMBus controller between OSPM and SMI. Bad things will
happen if the EC tries to read the fan speed at the same time that you
do, for example.

Further, the ACPI PCI driver has to be linked with the native PCI driver
to coordinate this i2c bus locking between the drivers.

This is a point where I am not sure if the ACPI PCI devices should be
attached before or after the native PCI drivers attached.


 I fail to see how the API that was just committed will not result in a
 #if NACPI  0 block every time it is used.
 
 Yeah, and that would be, ahem, ugly.

Side-note: This has been changed to #if NACPICA  0

If the whole file depends on 'acpi' in files.acpi it already
belongs to the acpi context and #if NACPICA  0 blocks make no sense to me.

Files outside of sys/dev/acpi using ACPI code should generally have
#if NACPICA  0 blocks.

Further, jmcneill@ stated earlier he does not want to see any acpi code
in sys/dev/pci/


Christoph - who wonder's why this discussion started after commit
instead of after presenting the patch on tech-kern.

re: CVS commit: src/sys/dev/acpi

[matthew green]

   
   
   Christoph - who wonder's why this discussion started after commit
   instead of after presenting the patch on tech-kern.
   

partly, because you did not wait very long for comments.  again.


.mrg.

Re: CVS commit: src/sys/dev/acpi

[David Brownlee]

On Sun, 30 Aug 2009, David Brownlee wrote:


From: Jared D. McNeill jmcne...@netbsd.org

Log Message:
PR# port-i386/39671: panic while booting with an acpi kernel on a 790GX 
board


If the firmware describes duplicate keyboard controller nodes, don't panic
when the driver fails to map registers.


Is tis suitable for a pullup to netbsd-5?


Just a (very limited) testing report, have tested the patch on
two netbsd-5 boxes, one which paniced and one which did not and
they both boot fine with it :)

--
David/absolute   -- www.NetBSD.org: No hype required --

Re: CVS commit: src/sys/dev/acpi

[David Brownlee]

From: Jared D. McNeill jmcne...@netbsd.org

Modified Files:
 src/sys/dev/acpi: pckbc_acpi.c

Log Message:
PR# port-i386/39671: panic while booting with an acpi kernel on a 790GX 
board


If the firmware describes duplicate keyboard controller nodes, don't 
panic

when the driver fails to map registers.


Is tis suitable for a pullup to netbsd-5?
Thanks :) 

Re: CVS commit: src/sys/dev/acpi

[Andrew Doran]

On Wed, Apr 08, 2009 at 12:15:45AM +, David Young wrote:

 Modified Files:
   src/sys/dev/acpi: acpi_timer.c acpi_timer.h
 
 Log Message:
 Add acpitimer_detach() to eventually support acpi(4) detachment.

tc_detach() does not work correctly on a running system. It can race with
binuptime(), so the timecounter may still be in use when it is destroyed.

One solution would be to use the passive serialization patch that I posted
to tech-k...@. I believe rmind@ is working on it.

Re: CVS commit: src/sys/dev/acpi

[Jared D. McNeill]

-
From: David Young dyo...@netbsd.org
Sent: Tuesday, April 07, 2009 8:23 PM
To: source-changes-f...@netbsd.org
Subject: CVS commit: src/sys/dev/acpi


Module Name: src
Committed By: dyoung
Date: Wed Apr  8 00:23:30 UTC 2009

Modified Files:
src/sys/dev/acpi: acpi.c acpivar.h

Log Message:
Refactor slightly to create acpi_rescan(), a hook for rescanning the
devices that attach at acpi(4).

Begin deriving an acpi(4) device-detachment hook, acpi_detach(), from
acpi_attach().  The code between #if 0 and #endif still needs to be
turned to the opposite calls (enables to disables, maps to unmaps,
attaches to detaches), which should be run in the opposite order.
Somebody with deep ACPI knowledge can probably finish this off without
too much trouble.


Detaching ACPI is more complicated than this because it is actually used for 
much more than just device attachment; think about IRQ routing, PCI bus 
discovery, PCI bus/addr/intr fixups, and CPU attachment as some examples. 
It's probably not worth the effort.


Cheers,
Jared 

Re: CVS commit: src/sys/dev/acpi/acpica

[Andrew Doran]

On Tue, Mar 31, 2009 at 05:17:47PM +, Matthias Drochner wrote:

 Module Name:  src
 Committed By: drochner
 Date: Tue Mar 31 17:17:47 UTC 2009
 
 Modified Files:
   src/sys/dev/acpi/acpica: OsdSchedule.c OsdSynch.c
 
 Log Message:
 avoid tsleep also during shutdown (and in particular ACPI poweroff),
 should fix PR kern/39141 by Takahiro Kambe and PR port-i386/41110
 by Reinoud Zandijk

Thank you for fixing an annoying panic. However it's one of many hacks to be
applied to this. There's no good reason for interrupts to be off while the
shutdown hooks are being processed.