Try:
cat /proc/acpi/battery/BAT0/alarm
and
cat /proc/acpi/battery/BAT0/info
and
cat /proc/acpi/battery/BAT0/state

and if you have two battrie:
cat /proc/acpi/battery/BAT1/alarm
and
cat /proc/acpi/battery/BAT1/info
and
cat /proc/acpi/battery/BAT1/state

(In reply to comment #1)
  Well, to observe in another way what was stated at the end of the
"Additional info:" section above, when rebooted into the more
dysfunctional state *without* the acpi=off kernel parameter:

[root]# cat /proc/acpi/battery/BAT0/alarm
cat: /proc/acpi/battery/BAT0/alarm: No such file or directory
[root]# cat /proc/acpi/battery/BAT0/info
cat: /proc/acpi/battery/BAT0/info: No such file or directory
[root]# cat /proc/acpi/battery/BAT0/state
cat: /proc/acpi/battery/BAT0/state: No such file or directory

While running in this mode, when one removes AC power, the hover text
from Battery Charge Monitor 2.18.0 is:

  System is running on battery power
  Battery status unknown

I also notice that its About screen reveals:
  Legacy (non-HAL) backend enabled.

The hover text from Power Manager 2.18.3 is:

  Computer is running on battery power

[but without the expected second line showing the state of charge].

Hello,

I'm reviewing this bug as part of the kernel bug triage project, an attempt to
isolate current bugs in the fedora kernel.

http://fedoraproject.org/wiki/KernelBugTriage

I am CC'ing myself to this bug and will try and assist you in resolving it if I can.

There hasn't been much activity on this bug for a while. Could you tell me if
you are still having problems with the latest kernel?

If the problem no longer exists then please close this bug or I'll do so in a
few days if there is no additional information lodged.

Cheers
Chris

Overview:  The score is 1 - 1 - 1. instead of the desired 2 - 0.  I have
updated the Summary line to reflect which bits remain outstanding.

Improvement:  With the 2.6.22.5-76.fc7 kernel, the battery information
appears normal with or without "acpi=off apm=on" kernel parameters. 

Regression:  With the 2.6.22.5-76.fc7 kernel, resume from hibernation
fails when using acpi.

No change:  With the 2.6.22.5-76.fc7 kernel, hibernate still requires 
manual intervention when using the "acpi=off apm=on" kernel parameters.

Details:
  I happen to be able to have access to this hardware system again.
No updates have appeared for acpi, it remains acpi,i386 0.09-2.fc6.
With the kernel updated to 2.6.22.5-76.fc7, when the previously failing
system is rebooted *without* the acpi=off kernel parameter, the
battery info appears normal to me:

[root]# cat /proc/acpi/battery/BAT0/alarm
alarm:                   2160 mWh
[root]# cat /proc/acpi/battery/BAT0/info
present:                 yes
design capacity:         43200 mWh
last full capacity:      26530 mWh
battery technology:      rechargeable
design voltage:          10800 mV
design capacity warning: 2160 mWh
design capacity low:     432 mWh
capacity granularity 1:  1 mWh
capacity granularity 2:  1 mWh
model number:            IBM-02K7028
serial number:            1841
battery type:            LION
OEM info:                SANYO
[root]# cat /proc/acpi/battery/BAT0/state
present:                 yes
capacity state:          ok
charging state:          charged
present rate:            0 mW
remaining capacity:      25990 mWh
present voltage:         12259 mV
[root]#

While running in this mode, when one removes AC power, the hover text
from Battery Charge Monitor 2.18.0 is now:

  System is running on battery power
  1 hour 43 minutes (100%) remaining

I also notice that its About screen now reveals:
  HAL backend enabled.
instead of the former:
  Legacy (non-HAL) backend enabled.

The hover text from Power Manager 2.18.3 is now:

  Computer is running on battery power
  Laptop battery 1 hour, 45 minutes remaining (98%)

instead of the previously missing second line (not) showing the state
of charge.

  The system appears to hibernate and self-power-down correctly, but
when it resumes it soon displays:

  swsusp: Basic memory bitmaps created
  Stopping tasks ... done.
  Shrinking memory... done (28184 pages freed)
  Freed 112736 kbytes in 0.94 seconds (119.93 MB/s)
  Suspending console(s)

and no more.  It DOES NOT progress to the expected:

 sd 0:0:0:0: [sda] Synchronizing SCSI cache

No hint of X, etc. The flashing cursor stays at the left end of the
top line of the output quoted above (i.e. "swsusp: Basic..." ).

  If one returns to including "acpi=off apm=on" in the kernel arguments,
then either battery monitor application behaves as expected.  But
when one hibernates, the eventual reward now ends with:
 sd 0:0:0:0: [sda] Synchronizing SCSI cache
 sd 0:0:0:0: [sda] Stopping disk
 Power down
 sd 0:0:0:0: [sda] Synchronizing SCSI cache
and still it just sits there forever.  If one then pushes the Power
button, the system turns off, and later one can Resume it without any
detected problem.

Okay, some things to try out:

# Find out if the system is locked up completely by hitting the caps lock key.

    * If the capslock light doesn't toggle, the system is completely dead. Try
again, but this time before suspending, activate the pm_trace functionality with
echo 1 > /sys/power/pm_trace. This reprograms the real time clock to contain a
few bytes of information which we can use to diagnose which driver failed to
resume. After the hang, reboot, boot up again, and save the output of dmesg.

    * If the capslock light does toggle, then the system did come back up, and
it's possible that we just failed to reinitialise the video.
http://people.freedesktop.org/~hughsient/quirk may contain further useful
information to diagnose this problem. It may also be useful to initiate the
suspend from a tty (ctrl-alt-f1) and run pm-suspend ; dmesg > dmesg.out ; sync
by hand. Upon resuming you'll now have some more debug info to sift through.
Additionally, this way when it resumes, you already have a console logged in
from which you can type commands 'blind'. Trying vbetool post for example may
bring things back to life. 

# Try rmmod'ing various modules before doing the suspend. If this makes things
work again, retry with a smaller set of modules unloaded. Keep retrying until
you narrow down which module is to blame.

# Another trick that sometimes works to force video to come back up is to enable
the BIOS password. This makes the system resume in a VGA text mode that the
kernel recovers from a lot easier. Not a real solution, but it can help to
diagnose other problems.

(In reply to comment #5)
  This comment focuses on:
> Regression:  With the 2.6.22.5-76.fc7 kernel, resume from hibernation
> fails when using acpi.

After Hibernate, power on to Resume, and printing lines similar to:

  swsusp: Basic memory bitmaps created
  Stopping tasks ... done.
  Shrinking memory... done (28184 pages freed)
  Freed 112736 kbytes in 0.94 seconds (119.93 MB/s)
  Suspending console(s)

the system is, as you phrase it, dead.  Pressing the caps lock key
does not toggle the state of the caps lock indicator LED. So for the
next try, after enabling the trace:

[root@localhost ~]# echo 1 > /sys/power/pm_trace 
[root@localhost ~]#

Save dmesg1.txt.  Hibernate#2, power on to attempt Resume#2, hang#2,
power off#2, power on, save dmesg2.txt.  The RTC info in dmesg2.txt
is (showing the value from 2 different attempts, having reset the
correct time and date in between): 

  Time: 12:24:12  Date: 01/06/00
  Time: 12:22:12  Date: 01/06/00

So it is mostly repeatable.  However, no lines containing "hash matches"
are present?  That seems to be the usual way to understand the output
of pm_trace, from what I find.

lsmod shows 78 lines of output, so I will pause before attempting a binary
search through rmmod'ing these in case the dmesg output offers some clues
via another set of eyes.

(In reply to comment #6)

> So it is mostly repeatable.  However, no lines containing "hash matches"
> are present?  That seems to be the usual way to understand the output
> of pm_trace, from what I find.

Yes, I think you need to make sure you boot up again almost immediately however
there should be some hash matches in dmesg.

Is there any chance suspending from console rather than X? I also read this today:

http://kerneltrap.org/Linux/2.6.23-rc8_Getting_Close

which might make testing a kernel >= 2.6.23-rc8 worthwhile if you can. One
landed in rawhide yesterday.

(In reply to comment #7)
> Yes, I think you need to make sure you boot up again almost immediately 

  All of the results reported above were gathered with no delays (beyond
pausing ~10 seconds between presses of the power button).

> Is there any chance suspending from console rather than X? 

  Tried Ctrl+Alt+F1, logged in, then used /usr/bin/pm-hibernate.
The RTC info from dmesg was the very similar:

Time: 12:21:44  Date: 01/06/00

Still, no lines containing "hash matches"

> which might make testing a kernel >= 2.6.23-rc8 worthwhile if you can.

  Except this system belongs to someone else, for whom running rawhide is
not appropriate.

(In reply to comment #8)

>   Except this system belongs to someone else, for whom running rawhide is
> not appropriate.

Understandable, though you would not be running rawhide per se, just a kernel
which, if it fails, can be removedd after booting back into the previous kernel.
The release of 2.6.23 is just around the corner however so if you can test that
when it arrives it might resolve the issue for you as indicated.

(In reply to comment #9)
  Now checking back in with some more broken results with testing
a newer kernel on this f7 system, as suggested.

  # uanme -r
  2.6.23-0.214.rc8.git2.fc8
  #

  Using the default ACPI configuration, hibernate automatically
powers down.  Sadly, an attempt to Resume chugs through a lot of
text-mode messages, reads the swsusp image, then displays:

  swsusp: Reading resume file was successful
  Suspending console(s)

and no more...  No X.  No LED lights in response to selecting the Caps
Lock key. Resume fails.  The RTC info from dmesg showed the time
travel went to:

  Time: 12:22:09  Date: 01/05/92

and the only line containing "hash matches" was:

  Magic number: 0:449:379
  hash matches drivers/base/power/resume.c:64

  With the "acpi=off apm=on" kernel parameters, upon Hibernation, the
text-mode messages progress until:

 md: stopping all md devices.
 sd 0:0:0:0: [sda] Synchronizing SCSI cache
 sd 0:0:0:0: [sda] Stopping disk
 Power down
 md: stopping all md devices.
 sd 0:0:0:0: [sda] Synchronizing SCSI cache

and then it just sits there without automatically powering off.
After a manual Power Off. then Power On, the system successfully
Resumes.

  Attempting a Shutdown is even more messed up, as no text-mode
messages are displayed as things wind down, but the system again does
not automatically Power Off as it should.  One is left staring at a
black screen (with the back-light still on) and a lit power LED.  So
one also has to manually Power Off even after Shutdown.  Another
Regression.  So the disease has spread, in that with kernel
2.6.23-0.214.rc8.git2.fc8 manual intervention is required "at the end
of" both Hibernate and Shutdown.

  So upon which kernel will someone assist with resolving these failures?

Can you attach the output of the following as text/plain to this bug:

# dmidecode (you may need to install this)
# lspci -vvxxx
dmesg

This will give a better idea of your system configuration for people reviewing
this bug.

Created attachment 215771 [details]
Output from dmidecode.

Created attachment 215781 [details]
Output from lspci -vvxxx

Created attachment 215791 [details]
Output from dmesg after failed resume, 2.6.23-0.214.rc8.git2.fc8

Before Hibernate, had issued:
  echo 1 > /sys/power/pm_trace
and with this kernel, finally have a "hash matches ..." line in dmesg.

(In reply to comment #14)
> Created an attachment (id=215791) [edit]
> Output from dmesg after failed resume, 2.6.23-0.214.rc8.git2.fc8
> 
> Before Hibernate, had issued:
>   echo 1 > /sys/power/pm_trace
> and with this kernel, finally have a "hash matches ..." line in dmesg.

I'll add that inline for brevity but it doesn't tell us any more than we already
know unfortunately:

<snip>
NET: Registered protocol family 1
NET: Registered protocol family 17
Using IPI No-Shortcut mode
  Magic number: 0:449:379
  hash matches drivers/base/power/resume.c:64
Freeing unused kernel memory: 568k freed
Write protecting the kernel read-only data: 864k
Marking TSC unstable due to: TSC halts in idle.
Time: hpet clocksource has been installed.
<snip>

BIOS info from dmidecode:

<snip>
Handle 0x0000, DMI type 0, 20 bytes.
BIOS Information
        Vendor: IBM
        Version: 1AET54WW (1.11 )
        Release Date: 05/08/2002
        Address: 0xDC000
        Runtime Size: 144 kB
        ROM Size: 1024 kB
<snip>

so the BIOS is certainly recent enough and capable of supporting sus/res as is
indicated later on in the output.

Other info from dmesg:

APIC is disabled by BIOS so dummy emulation used.

Clocksource is unstable, switches from tsc to hpet.

 Time: 12:22:09  Date: 01/05/92
 ...
 Marking TSC unstable due to: TSC halts in idle.
 Time: hpet clocksource has been installed.

Can you try booting with:

clocksource=acpi_pm

You might also want to try:

# rmmod orinoco_cs

before sus/res to see if this makes a difference.

Could you also attach an lsmod output.

Created attachment 217451 [details]
Output from lsmod.

(In reply to comment #15)
> Can you try booting with:
>
> clocksource=acpi_pm

  I did, with no observed change in behavior whether 
"acpi=off apm=on" was in use or not.

> You might also want to try:
>
> # rmmod orinoco_cs
>
> before sus/res to see if this makes a difference.

[root ~]# rmmod orinoco_cs
ERROR: Module orinoco_cs is in use
[root ~]# ifconfig eth1 down
[root ~]# rmmod orinoco_cs
ERROR: Module orinoco_cs is in use
[root ~]# ## physically remove card from PCMMCIA slot ...
[root ~]# rmmod orinoco_cs
[root ~]# 

Still with no observed change in behavior whether 
"acpi=off apm=on" was in use or not.

>Could you also attach an lsmod output.

  Done.

  With this 2.6.23... kernel I have noticed some text messages 
in a different format scrolling past when one attempts Hibernate, 
whether or not Hibernate self-powers down, whether or not the 
next Resume succeeds.  Once I caught the contents with a 
digital camera image (transcribed below), it appears to be an
interesting and maybe relevant difference:

[<c0406e4d>] show_trace+0x12/0x14
[<c0406e65>] dump_stack+0x16/0x18
[<c0448856>] print_usage_bug+0x141/0x14b
[<c04481be>] mark_lock+0x211/0x472
[<c0449f8f>] __lock_acquire+0x4de/0xc67
[<c044as92>] lock_acquire+0x7b/0x9e
[<c0633050>] _spin_lock+0x2e/0x58
[<c09a2050>] orinoco_cs_resume+0x50/0x9b [orinoco_cs]
[<c05803f5>] pcmcia_dev_resume+0x3f/0x4f
[<c05798cd>] resume_device+0x71/0xd8
[<c057997f>] dpm_resume+0x4b/0x78
[<c05799d2>] device_resume+0x26/0x34
[<c0454e8d>] hibernation_snapshot+0xa6/0xb3
[<c0454ffe>] hibernate+0xb1/0x17f
[<c0453cf9>] state_store+0x44/0xaa
[<c04c33e1>] subsys_attr_store+0x29/0x2e
[<c04c365e>] sysfs_write_file+0xc6/0xfe
[<c0489e87>] vfs_write+0xaf/0x169
[<c048a4e3>] sys_write+0x3d/0x61
[<c040522e>] syscall_call+0x7/0xb

  I wrote in comment #10:

>   Using the default ACPI configuration, hibernate automatically
> powers down.  Sadly, an attempt to Resume chugs through a lot of
> text-mode messages, reads the swsusp image, then displays:
> 
>   swsusp: Reading resume file was successful
>   Suspending console(s)
>
> and no more...  No X.  No LED lights in response to selecting the Caps
> Lock key. Resume fails. 

The way I achieved "the default ACPI configuration" was to edit the
kernel arguments via the grub menu and remove "acpi=off apm=on", which
were automatically copied there when this new test kernel was
installed (since that was the least broken (or last tested)
configuration used with the previous kernel).  I have not been in the
habit of trying to grab the grub menu in the shorter window of time it
is available when resuming from hibernation to edit kernel arguments.
So I realized upon resume there was a kernel booted with "acpi=off
apm=on" trying to make sense of an image stored by a kernel booted
with neither of these parameters.  That could be confusing.

  So I edited /boot/grub/grub.conf to remove "acpi=off apm=on" on the
entry for 2.6.23-0.214.rc8.git2.fc8.  Booted, Hibernate, Resume ... 
with a sample of size 1 that seems to work properly.

  Among the remaining open questions:

- I suspect there are many other kernel parameters whose presence
  or absence could make or break the ability to Resume a mismatched
  image.  Should there be widespread in-your-face documentation to
  never edit kernel arguments and then attempt to Hibernate that
  booted system?  Should the Hibernate - Resume sequence be
  redesigned to store the kernel parameters of the running system
  in the hibernated image, and upon resume check to see that the  
  kernel parameters of the resumed system match those in the
  hibernated image?  If the match verification fails, display an
  informative message.  (Is there a canonical representation already
  extant in the kernel that would match if one included e.g.
  "acpi=off apm=on" and the other included "apm=on acpi=off"?)

- Should I bugzilla the stack trace on component orinco_cs?

Apologies for delay. Are you still experiencing this issue or has it resolved
itself with the updated kernels? You might want to have a look at:

http://fedoraproject.org/wiki/KernelCommonProblems

which may be of some assistance. You mention that the rawhide kernel worked for
you - is that still the case. You can bugzilla the stack trace for orinoco_cs
separately if you wish though I'm not sure this driver is actively developed any
more...

Any update on this? Have you been able to test with F8 or F9 Alpha?

  Well, as was somewhat buried in Comment #17, using 
kernel 2.6.23-0.214.rc8.git2.fc8 with an otherwise f7 system,
with the default ACPI configuration (no kernel arguments on this topic),
I witnessed several Hibernate, Resume sequences to work properly.

  I no longer have convenient access to this set of hardware to
continue testing to see whether subsequent kernels or the full complement
of f8 or f9 software have preserved this desired behavior, or whether
more regressions have occurred.

  So in a narrow sense I do not have cause to resist closing the
report of the "Neither ACPI nor APM provide normal hibernate - resume"
bug.  But I have seen no response of any kind to my observations / 
questions about the robustness of the kernel for successfully Resuming
an image that was Hibernated by the kernel running with a different
set of arguments.  To repeat from the end of Comment #17, if one has:
 - kernel configuration A described by a set (or lack thereof) of
   kernel arguments in a stanza in /boot/grub/grub.conf,
then boots this kernel with:
 - kernel configuration B by using the Grub menu to edit the 
   kernel arguments for this one boot sequence
then Hibernates the system, then Resumes the system (which will
boot with kernel configuration A, then load an image or read a resume
file saved by kernel configuration B), is this not begging for trouble?
I witnessed failure of Resume when configuration A included 
"acpi=off apm=on" and configuration B did not include these arguments.

  So, I am open to your advice as to how to proceed most constructively:
- re-title this bug again, to something like
 "Resume should verify current kernel arguments match those of Hibernated image"
 and leave it open, or
- close this bug, and open a new bug (more busy work for me).
In either case, the kernel open bug count will remain the same.

(In reply to comment #20)
> To repeat from the end of Comment #17, if one has:
>  - kernel configuration A described by a set (or lack thereof) of
>    kernel arguments in a stanza in /boot/grub/grub.conf,
> then boots this kernel with:
>  - kernel configuration B by using the Grub menu to edit the 
>    kernel arguments for this one boot sequence
> then Hibernates the system, then Resumes the system (which will
> boot with kernel configuration A, then load an image or read a resume
> file saved by kernel configuration B), is this not begging for trouble?
> I witnessed failure of Resume when configuration A included 
> "acpi=off apm=on" and configuration B did not include these arguments.

The kernel should in no way (IMO) have to tolerate parameter alterations on
boot. If you are altering kernel boot parameters in the middle of hibernation
then you should expect things to break. This can only be considered a bug if a
kernel fails to hibernate and thaw/un-hibernate successfully with the same set
of parameters. Those parameters are what makes the kernel hibernate successfully
for you.
 
>   So, I am open to your advice as to how to proceed most constructively:
> - re-title this bug again, to something like
>  "Resume should verify current kernel arguments match those of Hibernated image"
>  and leave it open, or
> - close this bug, and open a new bug (more busy work for me).
> In either case, the kernel open bug count will remain the same.

I wont close but will wait for your comments in case I have somehow
misunderstood what you are saying however as the original issue is resolved (and
you can successfully hibernate and thaw) I cannot see any reason to leave this
bug open.

(In reply to comment #21)
> .... If you are altering kernel boot parameters in the middle of hibernation
> then you should expect things to break. 

  I happened to realize that after accidentally being in that situation.
But I have yet to see this risk documented nor guarded against anywhere.

- Should /boot/grub/stage2 emit a modified prompt such as:
    Press enter to boot the selected OS, 'e' to edit the
    commands before booting (do NOT use this technique if there is
    any chance of subsequently Hibernating and Resuming the booted system),
    'a' to modify the kernel arguments before booting (do NOT use this
    technique if there is any chance of subsequently Hibernating and Resuming
    the booted system), or 'c' for a command-line.

- Should we suggest that Richard update: 
    http://people.freedesktop.org/~hughsient/quirk/quirk-suspend-index.html
  or 
    http://people.freedesktop.org/~hughsient/quirk/quirk-suspend-debug.html
  to mention that one should always invest the extra time to edit e.g.
  /boot/grub/grub.conf instead of using the grub menu to edit the boot
  command or modify the kernel arguments on the chance that someone some
  days or weeks in the future may wish to Hibernate and then Resume the
  booted system?

- Should we suggest a similar warning be added in the appropriate
  locations within the GNOME desktop Help Brower, KDE Help system,
  the help system for other desktop environments, lilo, etc.?

But even if all of the appropriate documentation of this risk were in
place, would it not be better for the kernel to write an image containing
information so that such a mismatch could be detected, and thus be
able to emit a clue-full error message as it dies to inform the user?
To quote Comment #17:

>  .... Should the Hibernate - Resume sequence be
>  redesigned to store the kernel parameters of the running system
>  in the hibernated image, and upon resume check to see that the  
>  kernel parameters of the resumed system match those in the
>  hibernated image?  If the match verification fails, display an
>  informative message.  (Is there a canonical representation already
>  extant in the kernel that would match if one included e.g.
>  "acpi=off apm=on" and the other included "apm=on acpi=off"?)

This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'.

Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.

Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:
http://docs.fedoraproject.org/release-notes/

The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 7 changed to end-of-life (EOL) status on June 13, 2008. 
Fedora 7 is no longer maintained, which means that it will not 
receive any further security or bug fix updates. As a result we 
are closing this bug. 

If you can reproduce this bug against a currently maintained version 
of Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.