When going into suspend irqs must be disabled for a long time.
There is already a acpi_in_resume variable in osl.c
to not make use of sleeping functions (mem allocs/mutexes).
This one just makes a bit more intensive use of it.
The acpi_in_resume seem to vanish later (pci_link.c):
/*
* FIXME:
On Wednesday 08 March 2006 09:04, Thomas Renninger wrote:
When going into suspend irqs must be disabled for a long time.
Mine is very similar to recently posted:
[patch 16/22] acpi_os_acquire_object (GFP_KERNEL) called with IRQs disabled
through suspend-resume
Hmm, but on my machine
On 3/8/06, Yu, Luming [EMAIL PROTECTED] wrote:
I know this user-defined region needs address space handler, but your
address space handler below is so weird that make me doubt
the correctness. The example of address space handler is:
ec.c : acpi_ec_space_handler
As you suggested, I looked
Thomas Renninger wrote:
On Wednesday 08 March 2006 09:04, Thomas Renninger wrote:
When going into suspend irqs must be disabled for a long time.
Mine is very similar to recently posted:
[patch 16/22] acpi_os_acquire_object (GFP_KERNEL) called with IRQs
disabled through suspend-resume
Hmm,
FYI, ACPI slab usage on Viro's box.
1344 * 96 bytes = 129KB, which is significant.
[02:40] viro acpi_operand: 801d90af acpi_os_acquire_object+b/3e 1344
[02:40] viro size-2048: 802180fc acpi_thermal_add+6b/223 1
[02:40] viro size-1024: 80213331 acpi_processor_add+65/10a 1
Should this work or is this really not supported via ACPI?
I expect this is the relevant output:
ACPI: PCI Root Bridge [PCI1] (0001:40)
PCI: Multiple domains not supported
ACPI Error (pci_root-0279): Bus 0001:40 not present in PCI namespace7Losing
some ticks... checking if CPU frequency
To find if an acpi_device is a child of a PCI bus, it seems
that you need to look at its parent, and parents of parents...
to see if any are a PCI bus, eg have HID PNP0A03.
Alternatively, you could go top-down,
acpi_get_devices( PCI_ROOT_HID_STRING,
and provide a callback to walk below
On Wed, 8 Mar 2006, Brown, Len wrote:
To find if an acpi_device is a child of a PCI bus, it seems
that you need to look at its parent, and parents of parents...
to see if any are a PCI bus, eg have HID PNP0A03.
Alternatively, you could go top-down,
acpi_get_devices( PCI_ROOT_HID_STRING,
To find if an acpi_device is a child of a PCI bus, it seems
that you need to look at its parent, and parents of parents...
to see if any are a PCI bus, eg have HID PNP0A03.
Alternatively, you could go top-down,
acpi_get_devices( PCI_ROOT_HID_STRING,
and provide a callback to walk
Re: debug printouts
We should come up with a best-known way to get and print
full pathnames, b/c they're done in several ways in
several places
The AcpiGetName interface will take a namespace node and return a full
pathname, it should be used whenever this is needed.
-Original
On Wed, 8 Mar 2006, Brown, Len wrote:
To find if an acpi_device is a child of a PCI bus, it seems
that you need to look at its parent, and parents of parents...
to see if any are a PCI bus, eg have HID PNP0A03.
Alternatively, you could go top-down,
acpi_get_devices(
Thomas Renninger wrote:
Should this work or is this really not supported via ACPI?
I expect this is the relevant output:
ACPI: PCI Root Bridge [PCI1] (0001:40)
PCI: Multiple domains not supported
ACPI Error (pci_root-0279): Bus 0001:40 not present in PCI
namespace7Losing some ticks...
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Posting of your message titled System completely hangs using
acpi_cpufreq
has been rejected by the list moderator. The moderator gave the
following reason for rejecting your request:
[EMAIL PROTECTED] is defunct, replaced by
[EMAIL PROTECTED]
Bob,
Is ACPI_DBG_TRACK_ALLOCATIONS of any use in kernel builds?
I notice that it is getting enabled with ACPI_DEBUG_OUTPUT
which is getting enabled with CONFIG_ACPI_DEBUG=y
thanks,
-Len
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[I resend this now with correct ACPI ML address]
For some time I have been experiencing mysterious lockups on my notebook. They
happened usually shortly after system has been booted (probably 95% of
power-ups), 5-10 minutes. I normally switch
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I get this when resuming from swsup STR. I wonder if this may possibly account
for hard lockups I have been experiencing with acpi_cpufreq (see System
completely hangs using acpi_cpufreq).
This is vanilla 2.6.15.6 (except WiFi driver - *not* binary
-L:[EMAIL PROTECTED]
+L:linux-acpi@vger.kernel.org
Andrey,
I think you've got a down-rev kernel source tree,
we fixed this in top-of-tree a while ago.
thanks,
-Len
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More
Please open a bugzilla here
http://bugzilla.kernel.org/enter_bug.cgi?product=ACPI
Attach the output from acpidump, available in pmtools here:
http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/
paste the contents of /proc/cpuinfo attach the dmesg.
Please verify if speedstep_centrino
These three jump out as worth thinking about:
[02:40] viro acpi_operand: 801d90af
acpi_os_acquire_object+b/3e 1344
/proc/slabinfo on my 64-bit box shows these are 96 bytes each
with CONFIG_DEBUG_SLAB=y, and 72 bytes each for CONFIG_DEBUG_SLAB=n.
1344*72 = 96KB
sizeof(union
Hi,
Currently, I'm testing memory hot add on a big machine which supports
acpi memory hotplug.
I found there is the case which Memory Device's _CRS contains plural
resources. This is because of requirements of Windows.
Current code cannot manage plural _CRS. This patch fixes it.
-- Kame
==
This
20 matches
Mail list logo
