ACPI for 2.6.12-rc1

Hi Linus, please do a

bk pull bk://linux-acpi.bkbits.net/to-linus

This includes the ACPI part of memory hotplug, plus various fixes, BIOS workarounds and a fix for an interpreter regressions we had in 2.6.11 vs 2.6.10.

All changes here have been through Andrew's mm tree.

thanks,
-Len

ps. a plain patch is also available here:
ftp://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/release/2.6.11/acpi-20050309-2.6.11.diff.gz

This will update the following files:

 arch/i386/kernel/acpi/sleep.c       |    3 
 arch/ia64/kernel/acpi.c             |    2 
 drivers/acpi/Kconfig                |   20 
 drivers/acpi/Makefile               |    1 
 drivers/acpi/ac.c                   |   18 
 drivers/acpi/acpi_memhotplug.c      |  542 ++++++++++++++++++++++++
 drivers/acpi/battery.c              |    2 
 drivers/acpi/button.c               |    4 
 drivers/acpi/container.c            |   15 
 drivers/acpi/debug.c                |    4 
 drivers/acpi/dispatcher/dsmethod.c  |   11 
 drivers/acpi/dispatcher/dsopcode.c  |    8 
 drivers/acpi/dispatcher/dsutils.c   |  166 +++++--
 drivers/acpi/dispatcher/dswexec.c   |   61 ++
 drivers/acpi/ec.c                   |    2 
 drivers/acpi/events/evxface.c       |    4 
 drivers/acpi/executer/exmisc.c      |    5 
 drivers/acpi/executer/exoparg2.c    |    6 
 drivers/acpi/executer/exresolv.c    |    6 
 drivers/acpi/executer/exstoren.c    |    7 
 drivers/acpi/executer/exstorob.c    |   27 -
 drivers/acpi/fan.c                  |   33 -
 drivers/acpi/ibm_acpi.c             |    4 
 drivers/acpi/numa.c                 |    2 
 drivers/acpi/osl.c                  |   10 
 drivers/acpi/parser/psopcode.c      |    2 
 drivers/acpi/parser/psparse.c       |   42 +
 drivers/acpi/parser/pswalk.c        |  254 +----------
 drivers/acpi/pci_irq.c              |   38 +
 drivers/acpi/pci_link.c             |   14 
 drivers/acpi/pci_root.c             |    4 
 drivers/acpi/power.c                |   10 
 drivers/acpi/processor_core.c       |    6 
 drivers/acpi/processor_thermal.c    |    2 
 drivers/acpi/processor_throttling.c |    2 
 drivers/acpi/resources/rsaddr.c     |  146 +++---
 drivers/acpi/resources/rscalc.c     |   14 
 drivers/acpi/resources/rsdump.c     |   23 -
 drivers/acpi/resources/rslist.c     |    1 
 drivers/acpi/scan.c                 |   47 +-
 drivers/acpi/thermal.c              |    2 
 drivers/acpi/toshiba_acpi.c         |    2 
 drivers/acpi/utilities/utcopy.c     |   19 
 drivers/acpi/utilities/utdelete.c   |   18 
 drivers/acpi/utilities/utglobal.c   |   10 
 drivers/acpi/utilities/utmisc.c     |   44 +
 drivers/acpi/video.c                |    2 
 drivers/pnp/pnpacpi/rsparser.c      |    9 
 include/acpi/acconfig.h             |    4 
 include/acpi/acdisasm.h             |    5 
 include/acpi/acdispat.h             |   10 
 include/acpi/acinterp.h             |    1 
 include/acpi/aclocal.h              |    4 
 include/acpi/acpi_bus.h             |    1 
 include/acpi/acpi_drivers.h         |    3 
 include/acpi/acstruct.h             |    1 
 include/acpi/actbl.h                |    4 
 include/acpi/actbl2.h               |   79 +++
 include/acpi/actypes.h              |   33 -
 include/acpi/platform/acenv.h       |    2 
 include/acpi/processor.h            |    2 
 include/linux/acpi.h                |    2 
 62 files changed, 1301 insertions(+), 524 deletions(-)

through these ChangeSets:

<[email protected]> (05/03/17 1.2213)
[ACPI] build fix in acpi_pci_irq_disable()

bk-acpi-acpi_pci_irq_disable-build-fix.patch

<[email protected]> (05/03/09 1.1938.505.27)
[ACPI] ACPICA 20050309 from Bob Moore

The string-to-buffer implicit conversion code has been modified again after a change to the ACPI specification. In order to match the behavior of the other major ACPI implementation, the target buffer is no longer truncated if the source string is smaller than an existing target buffer. This change requires an update to the ACPI spec, and should eliminate the recent AE_AML_BUFFER_LIMIT issues.

The "implicit return" support was rewritten to a new algorithm that solves the general case. Rather than attempt to determine when a method is about to exit, the result of every ASL operator is saved momentarily until the very next ASL operator is executed. Therefore, no matter how the method exits, there will always be a saved implicit return value. This feature is only enabled with the acpi_gbl_enable_interpreter_slack flag which Linux enables unless "acpi=strict". This should eliminate AE_AML_NO_RETURN_VALUE errors.

Implemented implicit conversion support for the predicate (operand) of the If, Else, and While operators. String and Buffer arguments are automatically converted to Integers.

Changed the string-to-integer conversion behavior to match the new ACPI errata: "If no integer object exists, a new integer is created. The ASCII string is interpreted as a hexadecimal constant. Each string character is interpreted as a hexadecimal value ('0'-'9', 'A'-'F', 'a', 'f'), starting with the first character as the most significant digit, and ending with the first non-hexadecimal character or end-of-string." This means that the first non-hex character terminates the conversion and this is the code that was changed.

Fixed a problem where the ObjectType operator would fail (fault) when used on an Index of a Package which pointed to a null package element. The operator now properly returns zero (Uninitialized) in this case.

Fixed a problem where the While operator used excessive memory by not properly popping the result stack during execution. There was no memory leak after execution, however. (Code provided by Valery Podrezov.)

Fixed a problem where references to control methods within Package objects caused the method to be invoked, instead of producing a reference object pointing to the method.

Restructured and simplified the pswalk.c module (acpi_ps_delete_parse_tree) to improve performance and reduce code size. (Code provided by Alexey Starikovskiy.)

<[email protected]> (05/03/09 1.1994.11.5)
[ACPI] limit scope of various globals to static

<[email protected]> (05/03/09 1.1938.505.26)
[ACPI] fix acpi_numa_init() build warning

<[email protected]> (05/03/09 1.1938.505.25)
[ACPI] Allow 4 digits when printing PCI segments
to be consistent with the rest of the kernel.

<[email protected]> (05/03/08 1.1938.505.24)
[ACPI] Make PCI device -> interrupt link associations explicit,

ACPI: PCI Interrupt 0000:00:0f.2[A] -> Link [IUSB] -> GSI 10 (level,
low) -> IRQ 10

Previously, you could sometimes infer an association based on the
output
when an interrupt link is enabled, but when interrupt links are
shared
among several PCI devices, you could only make the inference for the
first
device to be enabled.

<[email protected]> (05/03/08 1.1938.505.23)
[ACPI] PNPACPI should ignore vendor-defined resources

<[email protected]> (05/03/03 1.1938.505.22)
[ACPI] fix [ACPI_MTX_Hardware] AE_TIME warning
which resulted from enabling the wake-on-RTC feature

http://bugme.osdl.org/show_bug.cgi?id=3967

<[email protected]> (05/03/03 1.1938.505.21)
[ACPI] ACPICA 20050303 from Bob Moore for AE_AML_BUFFER_LIMIT issue.

It turns out that tightening up the interpreter to truncate buffers per the ACPI spec was a bad idea -- BIOS' in the field depended on old behaviour. Instead, we'll endeavor to update the ACPI spec to reflect industry practice in this area.

http://bugme.osdl.org/show_bug.cgi?id=4263

<[email protected]> (05/03/02 1.1938.505.20)
[ACPI] fix sysfs "eject" file

This fixes a if-statement in setup_sys_fs_device_files(). It seems
to
assume that 'struct acpi_device_flags.ejectable' indicates whether a
device
has _EJ0 or not. But this is not a right assumption. It indicates
whether
a device has _EJ0|_EJD (See acpi_bus_get_flags() function).

setup_sys_fs_device_files() creates 'eject' file for devices that
have _EJ0
control method under a corresponding directory in /sys/firmware/acpi/namespace/ACPI/. 'eject' file is used to trigger hot-removal function from userland.

<Note that we expect this file location to change in the future.>

<[email protected]> (05/03/02 1.1938.505.19)
[ACPI] fix ACPI container driver's notify handler.

Previously, the handler tried to make a container device be offline
if an
ACPI_NOTIFY_BUS/DEVICE_CHECK notification is performed on the device
was
present and has its acpi_device. But, the condition is weird.
Whenever
the notification is performed, there should be only the following two conditions:

1. the device is present, but does not have its acpi_device.
2. the device is not present, but has its acpi_device.

#1 is a hot-addition case, which was handled properly also in
previous
handler. #2 is a surprising hot-removal case, which was not handled
in
previous handler.

<[email protected]> (05/03/02 1.1938.505.18)
[ACPI] fix kobject_hotplug() use by ACPI processor and container
drivers

A while ago, the drivers used their own function 'processor_run_sbin_hotplug() and container_run_sbin_hotplug()' to
notify
the agent script using /sbin/hotplug mechanism. But, they were
changed to
use kobject_hotplug() instead and this has caused a side effect.

The container driver was supposed to invoke a container.agent (user
mode
agent script) using /sbin/hotplug mechanism, but after the changes,
it is
not able to call the agent any more and kobject_hotplug() in the container.c became to invoke a namespace.agent instead if exists.
So, I
would like to use the namespace.agent to handle container hotplug
event (or
something else) and let the agent to call proper agent (e.g. container.agent). But, there is an issue we need to solve. When the namespace.agent is called, a path name of associated kobject is
passed as a
DEVPATH (e.g./sys/firmware/ acpi/namespace/ACPI/_SB/DEV0). However,
the
agent would not know what device is associated with the DEVPATH nor
which
agents to call since the DEVPATH name depends on platform. The
attached
patch is to add .hotplug_ops member to acpi_namespace_kset structure
and
let it to set a driver name attached to the target kobject into the
envp[]
variable as a DRV_NAME element. With this, the namespace.agent can
call
proper agents (e.g. container.agent) by refering the DRV_NAME.

<[email protected]> (05/03/02 1.1938.505.17)
[ACPI] flush TLB in init_low_mappings()

From: Li Shaohua <[email protected]>

<[email protected]> (05/03/02 1.1938.505.16)
[ACPI] enhance fan output in error path

Currently, fan.c ignores errors from acpi_bus_get_power. On compaq
evo
notebook that leads to very confusing empty output.

From: Pavel Machek <[email protected]>

<[email protected]> (05/03/02 1.1938.505.15)
[ACPI] CONFIG_ACPI_NUMA build fix

<[email protected]> (05/03/01 1.1938.505.14)
[ACPI] ACPICA 20050228 from Bob Moore

Fixed a problem where the result of an Index() operator (an object reference) must increment the reference count on the target object for the life of the object reference.

Implemented AML Interpreter and Debugger support for the new ACPI 3.0 Extended Address (IO, Memory, Space), QwordSpace, DwordSpace, and WordSpace resource descriptors.

Implemented support in the _OSI method for the ACPI 3.0 "Extended Address Space Descriptor" string, indicating interpreter support for the descriptors above.

Implemented header support for the new ACPI 3.0 FADT flag bits.

Implemented header support for the new ACPI 3.0 PCI Express bits for the PM1 status/enable registers.

Updated header support for the MADT processor local Apic struct and MADT platform interrupt source struct for new ACPI 3.0 fields.

Implemented header support for the SRAT and SLIT ACPI tables.

<[email protected]> (05/02/17 1.1982.92.2)
[ACPI] Add ACPI-based memory hot plug driver.

The ACPI based memory hot plug driver patch supports physical hotplug operations on memory. This driver fields notifications for memory add and remove operations from firmware and notifies the VM of the
affected
memory ranges. Accordingly, this driver also maintains and updates
the
states of all the memory ranges. This driver is useful on hardware
which
helps firmware generating ACPI events for every physical hotplug operation of memory boards on the system during runtime.

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Thank you for the grat work. Could I humble advocating pushing the patch
http://bugme.osdl.org/attachment.cgi?id=4516&action=view ,please? It fixed a very bad regression in hotkey event from 2.6.9...

Thanks!

Romano Giannetti             -  Univ. Pontificia Comillas (Madrid, Spain)
Electronic Engineer - phone +34 915 422 800 ext 2416  fax +34 915 596 569

It seems to not be in ACPI bk yet. What bug number is that actually attached to? There seems to be no way to go backwards from the URL.

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Yes, this is an important fix, and I'll be pushing it up to-akpm tonight along with a bucket-full of other important fixes. The push to Linus yesterday was to clear the pipeline for this next batch, which should hopefully also make 2.6.12.

cheers,
-Len

ps. You can query bugzilla for comments containing string "id=4516" and you find this is Luming's burst-mode EC patch:
http://bugzilla.kernel.org/show_bug.cgi?id=3851

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

http://bugme.osdl.org/show_bug.cgi?id=3851

search for id=4516 on Description/Comment:
on ACPI with all componenets and all status .

thanks,

Sorry to resume an old thread, but...

During Easter I had time to test a bit more the patch and I found a very bad issue between acpi keys, preempt and suspend. It's a lot of data; I have filed the same data on the above bug.

Hi!

This is to report an issue with 2.6.11 and ACPI battery/ac. The resume is:
acpi battery with preemptive kernel do not work, while the same kernel with no preempt works ok. I have tried to collect all the possible info; tell me if you need something more.

The details:

The working kernel is 2.6.11 with the patch from the acpi-devel list to fix acpi keys (not working otherwise). See for a description
http://bugme.osdl.org/show_bug.cgi?id=4124

The data on the non-preemptive kernel (boot messages, config, etc) is here:
http://www.dea.icai.upco.es/romano/linux/br/config-nop/laptop-config.html
This works, apart for the little glitch that doing two "acpi -V" at the same time, one of them give "0" for battery charge, while the other works ok. Suspend/resume works perfectly with this script:
http://www.dea.icai.upco.es/romano/linux/br/config-nop/rg_suspend_script_nowait

The complete configuration for the preemptive kernel is here:
http://www.dea.icai.upco.es/romano/linux/br/config-p2/laptop-config.html

The problem with the preemptive kernel is that after a while the ac/battery ACPI reading stop working. The errors do occur at seemely random times. First time it happened at boot, but I do not have a log of it. Second time it happened at resume time, and I have captured "oops" (really, scheduling while atomic) from this (in the following lines). After that, battery/ac status does not work anymore. If you look at the following dmesg, battery module will load but it will not detect any battery in the slots.

The same information as above, after resume, is here:
http://www.dea.icai.upco.es/romano/linux/br/after-res2/laptop-config.html

After that, I activated full ACPI debug (echo 0xFFFFFFFF > /proc/acpi/debug_level) and tried to load again the battery module. This time the loading suceeded. The full syslog output (it's enormous) is here:
http://www.dea.icai.upco.es/romano/linux/br/after-res2/syslog.txt.gz

Notice that a very similar thing happens with vanilla 2.6.11 with preemptive kernel (without the patch above). Notice, though, that the acpi key delay bug is resolved by simpl activate preempt, like Mr. Shaohua said in
http://bugme.osdl.org/show_bug.cgi?id=4124#c8

Here is the "oops" log at resume (log starts at suspend time)

usbcore: deregistering driver usbhid
uhci_hcd 0000:00:07.2: remove, state 1
usb usb1: USB disconnect, address 1
usb 1-2: USB disconnect, address 2
uhci_hcd 0000:00:07.2: USB bus 1 deregistered
uhci_hcd 0000:00:07.3: remove, state 1
usb usb2: USB disconnect, address 1
uhci_hcd 0000:00:07.3: USB bus 2 deregistered
usbcore: deregistering driver usbmouse
Stopping tasks: ================================= [...] Freeing memory... -\|/-\|/-\ [...]
PM: Attempting to suspend to disk.
PM: snapshotting memory.
swsusp: critical section:
[nosave pfn 0x484]<7>[nosave pfn 0x485]swsusp: Need to copy 8934 pages
suspend: (pages needed: 8934 + 512 free: 56600)
[nosave pfn 0x484]<7>[nosave pfn 0x485]<7>PM: Image restored successfully. scheduling while atomic: really_suspend/0x00000001/4624

 [<c0396007>] schedule+0x467/0x520
 [<c0121035>] __mod_timer+0x1c5/0x1f0
 [<c0396acd>] schedule_timeout+0x5d/0xb0
 [<c0121ac0>] process_timeout+0x0/0x10
 [<c0121eaf>] msleep+0x2f/0x40
 [<c024b080>] pci_set_power_state+0x190/0x1d0
 [<c024b1c8>] pci_enable_device_bars+0x18/0x40
 [<c024b20f>] pci_enable_device+0x1f/0x40
 [<d0ccf64c>] snd_via82xx_resume+0x1c/0x170 [snd_via82xx]
 [<c024b199>] pci_restore_state+0x39/0x50
 [<d0cacc79>] snd_card_pci_resume+0x49/0x76 [snd]
 [<c024d36c>] pci_device_resume+0x2c/0x40
 [<c02c79a8>] dpm_resume+0xa8/0xb0
 [<c02c79c1>] device_resume+0x11/0x20
 [<c0135268>] finish+0x8/0x40
 [<c01353c5>] pm_suspend_disk+0x75/0xc0
 [<c0133786>] enter_state+0x86/0x90
 [<c013379f>] software_suspend+0xf/0x20
 [<c0289d9a>] acpi_system_write_sleep+0x6a/0x84
 [<c015835c>] vfs_write+0x14c/0x160
 [<c0158441>] sys_write+0x51/0x80
 [<c01032b9>] sysenter_past_esp+0x52/0x75
ACPI: PCI interrupt 0000:00:07.5[C] -> GSI 5 (level, low) -> IRQ 5
scheduling while atomic: really_suspend/0x00000001/4624
 [<c0396007>] schedule+0x467/0x520
 [<c0120fb2>] __mod_timer+0x142/0x1f0
 [<c0396acd>] schedule_timeout+0x5d/0xb0
 [<c0121ac0>] process_timeout+0x0/0x10
 [<c0121eaf>] msleep+0x2f/0x40
 [<d0c338b6>] socket_shutdown+0x26/0x40 [pcmcia_core]
 [<d0c33dbf>] socket_resume+0xbf/0x130 [pcmcia_core]
 [<d0c6ec0e>] yenta_dev_resume+0xae/0xb0 [yenta_socket]
 [<d0c3310c>] pcmcia_socket_dev_resume+0x7c/0x90 [pcmcia_core]
 [<c024d36c>] pci_device_resume+0x2c/0x40
 [<c02c79a8>] dpm_resume+0xa8/0xb0
 [<c02c79c1>] device_resume+0x11/0x20
 [<c0135268>] finish+0x8/0x40
 [<c01353c5>] pm_suspend_disk+0x75/0xc0
 [<c0133786>] enter_state+0x86/0x90
 [<c013379f>] software_suspend+0xf/0x20
 [<c0289d9a>] acpi_system_write_sleep+0x6a/0x84
 [<c015835c>] vfs_write+0x14c/0x160
 [<c0158441>] sys_write+0x51/0x80
 [<c01032b9>] sysenter_past_esp+0x52/0x75
scheduling while atomic: really_suspend/0x00000001/4624
 [<c0396007>] schedule+0x467/0x520
 [<c0120fb2>] __mod_timer+0x142/0x1f0
 [<c0396acd>] schedule_timeout+0x5d/0xb0
 [<c0249088>] pci_bus_write_config_word+0x68/0xa0
 [<c0121ac0>] process_timeout+0x0/0x10
 [<c0121eaf>] msleep+0x2f/0x40
 [<d0c339ed>] socket_setup+0x3d/0x160 [pcmcia_core]
 [<d0c33d5f>] socket_resume+0x5f/0x130 [pcmcia_core]
 [<d0c6ec0e>] yenta_dev_resume+0xae/0xb0 [yenta_socket]
 [<d0c3310c>] pcmcia_socket_dev_resume+0x7c/0x90 [pcmcia_core]
 [<c024d36c>] pci_device_resume+0x2c/0x40
 [<c02c79a8>] dpm_resume+0xa8/0xb0
 [<c02c79c1>] device_resume+0x11/0x20
 [<c0135268>] finish+0x8/0x40
 [<c01353c5>] pm_suspend_disk+0x75/0xc0
 [<c0133786>] enter_state+0x86/0x90
 [<c013379f>] software_suspend+0xf/0x20
 [<c0289d9a>] acpi_system_write_sleep+0x6a/0x84
 [<c015835c>] vfs_write+0x14c/0x160
 [<c0158441>] sys_write+0x51/0x80
 [<c01032b9>] sysenter_past_esp+0x52/0x75
scheduling while atomic: really_suspend/0x00000001/4624
 [<c0396007>] schedule+0x467/0x520
 [<c0323b2e>] pci_write+0x3e/0x50
 [<c0120fb2>] __mod_timer+0x142/0x1f0
 [<c0396acd>] schedule_timeout+0x5d/0xb0
 [<c0121ac0>] process_timeout+0x0/0x10
 [<c0121eaf>] msleep+0x2f/0x40
 [<d0c33a83>] socket_setup+0xd3/0x160 [pcmcia_core]
 [<d0c33d5f>] socket_resume+0x5f/0x130 [pcmcia_core]
 [<d0c6ec0e>] yenta_dev_resume+0xae/0xb0 [yenta_socket]
 [<d0c3310c>] pcmcia_socket_dev_resume+0x7c/0x90 [pcmcia_core]
 [<c024d36c>] pci_device_resume+0x2c/0x40
 [<c02c79a8>] dpm_resume+0xa8/0xb0
 [<c02c79c1>] device_resume+0x11/0x20
 [<c0135268>] finish+0x8/0x40
 [<c01353c5>] pm_suspend_disk+0x75/0xc0
 [<c0133786>] enter_state+0x86/0x90
 [<c013379f>] software_suspend+0xf/0x20
 [<c0289d9a>] acpi_system_write_sleep+0x6a/0x84
 [<c015835c>] vfs_write+0x14c/0x160
 [<c0158441>] sys_write+0x51/0x80
 [<c01032b9>] sysenter_past_esp+0x52/0x75
scheduling while atomic: really_suspend/0x00000001/4624
 [<c0396007>] schedule+0x467/0x520
 [<c0323b2e>] pci_write+0x3e/0x50
 [<c0120fb2>] __mod_timer+0x142/0x1f0
 [<c0396acd>] schedule_timeout+0x5d/0xb0
 [<c0121ac0>] process_timeout+0x0/0x10
 [<c0121eaf>] msleep+0x2f/0x40
 [<d0c33929>] socket_reset+0x59/0xe0 [pcmcia_core]
 [<d0c33aa2>] socket_setup+0xf2/0x160 [pcmcia_core]
 [<d0c33d5f>] socket_resume+0x5f/0x130 [pcmcia_core]
 [<d0c6ec0e>] yenta_dev_resume+0xae/0xb0 [yenta_socket]
 [<d0c3310c>] pcmcia_socket_dev_resume+0x7c/0x90 [pcmcia_core]
 [<c024d36c>] pci_device_resume+0x2c/0x40
 [<c02c79a8>] dpm_resume+0xa8/0xb0
 [<c02c79c1>] device_resume+0x11/0x20
 [<c0135268>] finish+0x8/0x40
 [<c01353c5>] pm_suspend_disk+0x75/0xc0
 [<c0133786>] enter_state+0x86/0x90
 [<c013379f>] software_suspend+0xf/0x20
 [<c0289d9a>] acpi_system_write_sleep+0x6a/0x84
 [<c015835c>] vfs_write+0x14c/0x160
 [<c0158441>] sys_write+0x51/0x80
 [<c01032b9>] sysenter_past_esp+0x52/0x75
ACPI: PCI interrupt 0000:00:0e.0[A] -> GSI 9 (level, low) -> IRQ 9
scheduling while atomic: really_suspend/0x00000001/4624
 [<c0396007>] schedule+0x467/0x520
 [<c02f86a4>] do_rw_taskfile+0x254/0x2b0
 [<c02f8890>] task_no_data_intr+0x0/0xb0
 [<c0396206>] wait_for_completion+0x86/0xf0
 [<c0114460>] default_wake_function+0x0/0x20
 [<c0114460>] default_wake_function+0x0/0x20
 [<c02c8339>] __elv_add_request+0x99/0xe0
 [<c02f38cf>] ide_do_drive_cmd+0x11f/0x170
 [<c02f0623>] generic_ide_resume+0x93/0xc0
 [<c02f8890>] task_no_data_intr+0x0/0xb0
 [<c023cbc7>] kobject_get+0x17/0x20
 [<c02c79a8>] dpm_resume+0xa8/0xb0
 [<c02c79c1>] device_resume+0x11/0x20
 [<c0135268>] finish+0x8/0x40
 [<c01353c5>] pm_suspend_disk+0x75/0xc0
 [<c0133786>] enter_state+0x86/0x90
 [<c013379f>] software_suspend+0xf/0x20
 [<c0289d9a>] acpi_system_write_sleep+0x6a/0x84
 [<c015835c>] vfs_write+0x14c/0x160
 [<c0158441>] sys_write+0x51/0x80
 [<c01032b9>] sysenter_past_esp+0x52/0x75
Restarting tasks...<3>scheduling while atomic: really_suspend/0x00000001/4624
 [<c0396007>] schedule+0x467/0x520
 [<c011399e>] wake_up_process+0x1e/0x20
 [<c0133c78>] thaw_processes+0xe8/0x100
 [<c0135276>] finish+0x16/0x40
 [<c01353c5>] pm_suspend_disk+0x75/0xc0
 [<c0133786>] enter_state+0x86/0x90
 [<c013379f>] software_suspend+0xf/0x20
 [<c0289d9a>] acpi_system_write_sleep+0x6a/0x84
 [<c015835c>] vfs_write+0x14c/0x160
 [<c0158441>] sys_write+0x51/0x80
 [<c01032b9>] sysenter_past_esp+0x52/0x75
 done
scheduling while atomic: really_suspend/0x00000001/4624
 [<c0396007>] schedule+0x467/0x520
 [<c0158441>] sys_write+0x51/0x80
 [<c0103336>] work_resched+0x5/0x16
scheduling while atomic: really_suspend/0x00000001/4624
 [<c0396007>] schedule+0x467/0x520
 [<c011506a>] sys_sched_yield+0x5a/0x80
 [<c0164f02>] coredump_wait+0x32/0xa0
 [<c016505c>] do_coredump+0xec/0x22a
 [<c0113854>] activate_task+0x64/0x80
 [<c0113524>] task_rq_lock+0x14/0x20
 [<c0121fac>] free_uid+0x1c/0x80
 [<c01228d5>] __dequeue_signal+0x105/0x180
 [<c0122985>] dequeue_signal+0x35/0xd0
 [<c012491f>] get_signal_to_deliver+0x2df/0x350
 [<c01030dd>] do_signal+0x9d/0x170
 [<c012a4e8>] __kernel_text_address+0x28/0x40
 [<c0103755>] show_trace+0x35/0x90
 [<c0103755>] show_trace+0x35/0x90
 [<c0103336>] work_resched+0x5/0x16
 [<c0113c90>] finish_task_switch+0x30/0x90
 [<c0395e64>] schedule+0x2c4/0x520
 [<c01123f0>] do_page_fault+0x0/0x5de
 [<c01031e7>] do_notify_resume+0x37/0x3c
 [<c010335a>] work_notifysig+0x13/0x15

note: really_suspend[4624] exited with preempt_count 1
ALPS Touchpad (Glidepoint) detected
Disabling hardware tapping
input: AlpsPS/2 ALPS TouchPad on isa0060/serio1
ACPI: Battery Slot [BAT1] (battery absent)
ACPI: Battery Slot [BAT2] (battery absent)
ACPI: AC Adapter [ACAD] (off-line)
USB Universal Host Controller Interface driver v2.2
ACPI: PCI interrupt 0000:00:07.2[D] -> GSI 9 (level, low) -> IRQ 9 uhci_hcd 0000:00:07.2: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller uhci_hcd 0000:00:07.2: irq 9, io base 0x1c00
uhci_hcd 0000:00:07.2: new USB bus registered, assigned bus number 1 hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
ACPI: PCI interrupt 0000:00:07.3[D] -> GSI 9 (level, low) -> IRQ 9 uhci_hcd 0000:00:07.3: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (#2) uhci_hcd 0000:00:07.3: irq 9, io base 0x1c20
uhci_hcd 0000:00:07.3: new USB bus registered, assigned bus number 2 hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
usb 1-2: new low speed USB device using uhci_hcd and address 2
input: USB HID v1.10 Mouse [USB Mouse] on usb-0000:00:07.2-2
usbcore: registered new driver usbhid
drivers/usb/input/hid-core.c: v2.0:USB HID core driver
usbcore: registered new driver usbmouse
drivers/usb/input/usbmouse.c: v1.6:USB HID Boot Protocol mouse driver

Romano Giannetti             -  Univ. Pontificia Comillas (Madrid, Spain)
Electronic Engineer - phone +34 915 422 800 ext 2416  fax +34 915 596 569


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=click

If you can find AE_AML_BUFFER_LIMIT in your long, then, it should be interpreter bug. please see http://bugzilla.kernel.org/show_bug.cgi?id=4150
Otherwise, maybe it is related to EC driver.

Thanks,
Luming


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

I am not sure if I understood. If I do

(0)% grep AE_AML_BUFFER_LIMIT dmesg.txt
(1)%

I have nothing like that in syslog, either, so it should be another thing. Hmmm... I have "scheduling in atomic" errors, when resuming with preemptive kernel, so maybe it's related with
http://sourceforge.net/mailarchive/message.php?msg_id=11129317

The errors are:

scheduling while atomic: really_suspend/0x00000001/4624

 [<c0396007>] schedule+0x467/0x520
 [<c0121035>] __mod_timer+0x1c5/0x1f0
 [<c0396acd>] schedule_timeout+0x5d/0xb0
 [<c0121ac0>] process_timeout+0x0/0x10
 [<c0121eaf>] msleep+0x2f/0x40
 [<c024b080>] pci_set_power_state+0x190/0x1d0
 [<c024b1c8>] pci_enable_device_bars+0x18/0x40
 [<c024b20f>] pci_enable_device+0x1f/0x40
 [<d0ccf64c>] snd_via82xx_resume+0x1c/0x170 [snd_via82xx]
 [<c024b199>] pci_restore_state+0x39/0x50
 [<d0cacc79>] snd_card_pci_resume+0x49/0x76 [snd]
 [<c024d36c>] pci_device_resume+0x2c/0x40
 [<c02c79a8>] dpm_resume+0xa8/0xb0
 [<c02c79c1>] device_resume+0x11/0x20
 [<c0135268>] finish+0x8/0x40
 [<c01353c5>] pm_suspend_disk+0x75/0xc0
 [<c0133786>] enter_state+0x86/0x90
 [<c013379f>] software_suspend+0xf/0x20
 [<c0289d9a>] acpi_system_write_sleep+0x6a/0x84
 [<c015835c>] vfs_write+0x14c/0x160
 [<c0158441>] sys_write+0x51/0x80
 [<c01032b9>] sysenter_past_esp+0x52/0x75

...and more, you can find them all in
http://www.dea.icai.upco.es/romano/linux/br/acpi-preempt.txt

Could this be related to the fact that in 2.6.12-rc1 software suspend stopped to work? Maybe some bad interaction between acpi code and swsusp?

Moreover, if you can, can you point me to some documentation on how to use "debug_level" and "debug_layer" to help debugging?

Thanks!

Romano

Romano Giannetti             -  Univ. Pontificia Comillas (Madrid, Spain)
Electronic Engineer - phone +34 915 422 800 ext 2416  fax +34 915 596 569


-------------------------------------------------------
This SF.net email is sponsored by Demarc:
A global provider of Threat Management Solutions.
Download our HomeAdmin security software for free today!
http://www.demarc.com/Info/Sentarus/hamr30