> 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_deregi
"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
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
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
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:
>>
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 64b
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. Fou
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 2
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.
AcpiOsInstallInterruptHan
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:
>
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 unsig
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 < __arraycoun
...
/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
Hi,
From: "Christos Zoulas" , Date: Sat, 26 Sep 2015 09:04:10
-0400
> Module Name: src
> Committed By: christos
> Date: Sat Sep 26 13:04:10 UTC 2015
>
> Modified Files:
> src/sys/dev/acpi: valz_acpi.c
>
> Log Message:
> CID 1324963: Remove bogus NULL test
> CID 1324962: This is
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 Kol
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.
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
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,
> e
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 genera
In article <20110425053021.afdbf17...@cvs.netbsd.org>,
Jukka Ruohonen 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 statemen
Jukka Ruohonen 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
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
perfor
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.
> PB
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
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/
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
Jukka Ruohonen 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_
Looks reasonable to me.
In the man-page update, please refer to "an already scheduled function"
(insert the word "an").
On Tue, 4 Jan 2011, Jukka Ruohonen wrote:
On Tue, Jan 04, 2011 at 05:48:49AM +, Jukka Ruohonen wrote:
"Do not queue functions via sysmon_taskq(9) in the pmf(9) res
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."
An
On Mon, 6 Sep 2010, Jonathan A. Kollasch wrote:
If we want to avoid manually specifying RB_MD2 in boothowto on
pgoyette@'s board, we're going to have to find another way; perhaps
with the DMI strings available from pmf(9).
It really isn't necessary quirk my board, anyway. Despite the error
m
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 loc
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-
In article <20100730072156.ga20...@marx.bitnet>,
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
>> 2. My laptop is dual core, but ACPI reports 4 cpu nodes. Instead of
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 no
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 Pr
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
On Jul 19, 9:32am, jruoho...@iki.fi (Jukka Ruohonen) wrote:
-- Subject: Re: CVS commit: src/sys/dev/acpi
| 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
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 Declar
> 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:
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
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
systems where I tested this the range started from 0. So now these systems
hit the includ
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
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
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 d
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
sounds like a definite bug, not at all a
feature.
C.
On 05/03/2010, Jukka Ruohonen wrote:
> M
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 definition
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 e
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 defin
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, genera
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.
On Sat, 6 Feb 2010, David Young wrote:
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.
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 exper
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.
On Fri, Dec 04, 2009 at 07:40:10AM +0100, Christoph Egger wrote:
[..]
> Christoph - who wonder's why this discussion started after commit
> instead of after presenting the patch on tech-kern.
I would say because you used a link and didn't attach the actual
changes to that mail.
Bernd
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
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 plac
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 20
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.ac
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
Masao Uebayashi wrote:
> Module Name: src
> Committed By: uebayasi
> Date: Sun Nov 29 18:08:22 UTC 2009
>
> Modified Files:
> src/sys/dev/acpi: acpi_tz.c
>
> Log Message:
> Remove a debug printf().
Thanks.
Christoph
Thanks for testing David, I will request a pullup.
Cheers,
Jared
-Original Message-
From: David Brownlee [mailto:a...@netbsd.org]
Sent: August-31-09 7:20 AM
To: source-changes-d@NetBSD.org
Cc: Jared D. McNeill
Subject: Re: CVS commit: src/sys/dev/acpi
On Sun, 30 Aug 2009, David
On Sun, 30 Aug 2009, David Brownlee wrote:
From: Jared D. McNeill
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 f
On Sun, Aug 30, 2009 at 01:19:37PM +0100, David Brownlee wrote:
> >From: Jared D. McNeill
> >
> >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 ke
From: Jared D. McNeill
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 suit
On Wed, Apr 08, 2009 at 07:19:58PM +, Andrew Doran wrote:
> 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_
On Wed, Apr 08, 2009 at 02:58:58PM -0400, Perry E. Metzger wrote:
>
> "Jared D. McNeill" writes:
> > 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, an
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
binupti
"David Young" wrote in message
news:20090408164157.gd25...@ojctech.com...
On Tue, Apr 07, 2009 at 09:20:23PM -0400, Jared D. McNeill wrote:
-
From: "David Young"
Sent: Tuesday, April 07, 2009 8:23 PM
To:
Subject: CVS commit: src/sys/dev/acpi
"Jared D. McNeill" writes:
> 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.
If
On Wed, Apr 08, 2009 at 11:41:58AM -0500, David Young wrote:
[...]
> Do you think that in the long term, devices that attach today at the
> interface attribute "acpinodebus" will attach, instead, at "pci" or
> "isa" ?
I sure hope so!
--
Quentin Garnier - c...@cubidou.net - c...@netbsd.org
"See t
On Tue, Apr 07, 2009 at 09:20:23PM -0400, Jared D. McNeill wrote:
> -
> From: "David Young"
> Sent: Tuesday, April 07, 2009 8:23 PM
> To:
> Subject: CVS commit: src/sys/dev/acpi
>
>> Module Name: src
>> Committed By: dyoung
>> Date: Wed Apr 8 00:23
-
From: "David Young"
Sent: Tuesday, April 07, 2009 8:23 PM
To:
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:
Refac
m.droch...@fz-juelich.de said:
> with ACPI one doesn't know which parts of the systems have already
> been taken out of service
Actually, since ACPI does explicitely require that interrupts
are off at some point during state transitions, basically
all code reachable by the AML interpreter must b
a...@netbsd.org said:
> 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.
Maybe one can assume interrupts in some cases, but with
ACPI one doesn't know wh
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
75 matches
Mail list logo
