Created attachment 10395 [details]
minimal kernel config where this bug happens

Created attachment 10396 [details]
dmesg from booting current kernel where bug happens too

Created attachment 10397 [details]
DSDT from affected system

Created attachment 10398 [details]
lspci from affected system

Created attachment 10399 [details]
files under /proc/acpi

What will be the AC state in 10 minutes after resume?
Please perform the same action with the battery - remove the battery instead 
of power cord.

Is it a stable bug?

Created attachment 10406 [details]
acpidump output

Re. comment #7 - yes, it is stable; it has been this way for quite some time.
Rafael also confirmed it.

And what about comment #6 ?

Re comment #6.

Yes, it persists also 10 minutes after resume. Moreover, both with power cord 
*or* battery removed it shows exactly the same information:

{pts/0}% cat /proc/acpi/ac_adapter/ADP1/state
state:                   on-line
{pts/0}% cat /proc/acpi/battery/BAT1/state
present:                 yes
capacity state:          ok
charging state:          charging
present rate:            11124 mW
remaining capacity:      34678 mWh
present voltage:         11340 mV

(well, with battery present the remaining capacity really changes down when I 
check several times)

The same question is about thermal devices; does the tempethure change during 
various loadings of CPU?

yes, it does.

Please try the latest linux-2.6.20-git*, we will start the bug investigation 
with the latest kernel.
Please post acpidump output, .config file, and boot options

Fails the same (with minimal config I posted) as of commit 
7de970e11fb832a56c897276967fb0e49f59b313

Created attachment 10439 [details]
acpidump from 2.6.20-git boot

Created attachment 10440 [details]
.config for 2.6.20-git

And I boot using grub with this entry (no extra options):

title str
kernel (hd0,1)/home/bor/build/str-bisect/arch/i386/boot/bzImage BOOT_IMAGE=str 
root=/dev/hda2 init=/bin/sh vga=791

Then

mount -t proc none /proc
mount -t sysfs none /sys
/sbin/swapon -a
echo disk > /sys/power/state

unplug power cord
boot into the same entry again

mount -t sysfs none /sys
echo 3:1 > /sys/power/resume

check AC state ...

What is the ac/battery behavior if you reboot or boot the system?
What is the ac/battery behavior if you remove/insert ac cable/battery after 
resume or boot?

Also, there are some principal changes in mm tree, can you try the latest mm?

Please look at bug #7689 and verify the problem without psmouse loaded.

Please test rc1 w w/o psmouse loaded.

No change without psmouse
No change with 2.6.20-mm2
No change with current git as of b5bf28cde894b3bb3bd25c13a7647020562f9ea0

Oh, missed earlier questions.

AC state is correctly detected during boot. Replugging power cord after resume 
also works correctly (i.e. unplugging after that shows AC as unplugged). I 
guess I already mentioned this.

Frankly speaking (not knowing internals) the most probable reason seems to be 
that part of system memory gets restored on resume. AC status simply returns a 
value from memory (which apparently gets updated only on actual status 
change):

            Method (_PSR, 0, NotSerialized)
            {
                Return (\_SB.MEM.ACST)
            }

where ACST should be located somewhere in lower memory:

            OperationRegion (SRAM, SystemMemory, 0x000EE800, 0x1800)
                     ...
            Field (SRAM, AnyAcc, NoLock, Preserve)
                     ...
                Offset (0xFF),
                ACST,   1,
                     ...

this perfectly explains what happens. This part is marked as reserved

 BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
 BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000e0000 - 00000000000eee00 (reserved)
 BIOS-e820: 00000000000eee00 - 00000000000ef000 (ACPI NVS)
 BIOS-e820: 00000000000ef000 - 0000000000100000 (reserved)

While I could not find where to check (and display) physical page addresses, 
here is indirect proof. Suspend to disk, remove AC plug, boot into kernel 
(before initiating resume), display memory state:

sh-3.1# /display_ac_state
0000000: 02                                       .

*now* initiate resume and *immediately* display memory state again:

sh-3.1# /display_ac_state
0000000: 03                                       .

where script does 

{pts/0}% cat /display_ac_state
#!/bin/sh

/bin/dd if=/dev/mem skip=$[0xee800+0xff] bs=1c count=1 
2> /dev/null | /usr/bin/xxd

well, this seems to prove that this part of memory is indeed (incorrectly) 
restored during resume from STD.

Well, this might be the reason, but I have exactly the same problem on x86_64, 
where this region is not restored during the resume.

There are set of emails with patches/etc ... for your problem.
So the problem is solved or not?

The reason for misbehavior is identified. I think ATM there is no patch that 
is included upstream (but all of them work for me). In any case it does not 
look like ACPI issue and should probably be reassigned to more appropriate 
component. To me bug is fixed when patch is in some tree that has chance to 
appear upstream.

Thanks, so I suggest to close the bug, OK?

There doesn't seem to be a bugzilla category for
suspend-to-disk failures that are unrelated to ACPI,
so I'll drop this in Power-management/Other
and assign it to Pavel, who maintains suspend-to-disk.

I'll try to prepare a patch to fix this against the current mainline.

Created attachment 11624 [details]
Proposed fix patch, against 2.6.22-rc3

Andrey, can you please confirm that this patch fixes the problem?

Patch from Comment #31 is present in 2.6.23-rc2.  Closing.