[Bug 571977] Re: [Lucid] Possible race condition involving rtc wakealarm when hibernating a system
Jeff Lane
jeffrey.lane at canonical.com
Mon May 3 18:58:53 UTC 2010
Recreated with the daily mainline for today...
root at rogue:/home/bladernr# uname -a
Linux rogue 2.6.34-999-generic #201005011008 SMP Sat May 1 10:09:28 UTC 2010 i686 GNU/Linux
root at rogue:/home/bladernr# cat /proc/driver/rtc
rtc_time : 18:56:51
rtc_date : 2010-05-03
alrm_time : 18:45:30
alrm_date : 2010-05-04
alarm_IRQ : yes
alrm_pending : no
24hr : yes
periodic_IRQ : no
update_IRQ : no
HPET_emulated : no
DST_enable : no
periodic_freq : 1024
batt_status : okay
root at rogue:/home/bladernr# cat /sys/class/rtc/rtc0/since_epoch
1272913021
root at rogue:/home/bladernr# cat /sys/class/rtc/rtc0/wakealarm
1272998730
As you can see, the alarm_IRQ entry was not reset, nor was wakealarm,
even though my test box DID wake itself at the correct time after being
hibernated...
I tried doing an apport-collect for this bug, but apport refuses to
allow me to file anything when running a mainline kernel (even though
you asked me to do so)...
So if you need logs or other info of whatever sort, ask here and be
detailed in what you want.
** Tags added: apport-collected
** Description changed:
I'm working on a test script that sets a time in the future in
/sys/class/rtc/rtc0/wakealarm and then uses pm-suspend to hibernate a
system. I believe I've found a race condition that's causing my tests
to fail.
First, the steps to recreate:
0: cat /proc/driver/rtc and verify that alarm_IRQ says 'no'
1: echo '+180' > /sys/class/rtc/rtc0/wakealarm
1.5: cat /proc/driver/rtc and verify that alarm_IRQ says 'yes' and the correct alarm time is set
2: sudo pm-suspend
3: wait 3 minutes
4: system wakes itself
5: wait for system to fully wake (disk activity to stop, or at the very least, keyboard and mouse function to resume on desktop)
6: cat /proc/driver/rtc and verify that current time is > alarm time and alarm_IRQ still says 'yes'
The test, when putting the system into an S3 state, does not suffer from
this issue. It DOES when I'm using S4. I think the reason is that S3
wakes quickly enough that the kernel can register that the alarm fired
and reset /proc/driver/rtc accordingly, however, when waking from
suspend, the kernel takes far longer to wake, causing it to think that
even though the rtc's alarm_IRQ fired the IRQ didn't fire, so the kernel
does not reset /proc/driver/rtc.
For example, this is the output from (my comments highlighted with ##
# watch -n 5 'cat /proc/driver/rtc |head -5'
## First observation, note alarm_date is empty, this is after echoing '0' to /sys/class/rtc/rtc0/wakealarm
rtc_time : 20:35:11
rtc_date : 2010-04-29
alrm_time : 20:38:03
alrm_date : ****-**-29
alarm_IRQ : no
## wakealarm set
rtc_time : 20:35:16
rtc_date : 2010-04-29
alrm_time : 20:37:11
alrm_date : 2010-04-29
alarm_IRQ : yes
## executing pm-hibernate now
rtc_time : 20:35:21
rtc_date : 2010-04-29
alrm_time : 20:37:11
alrm_date : 2010-04-29
alarm_IRQ : yes
rtc_time : 20:35:26
rtc_date : 2010-04-29
alrm_time : 20:37:11
alrm_date : 2010-04-29
alarm_IRQ : yes
## System is now asleep.
## IRQ must be firing, because system wakes itself at this point after sleeping for the proscribed number of seconds (180)
rtc_time : 20:38:16
rtc_date : 2010-04-29
alrm_time : 20:37:11
alrm_date : 2010-04-30
alarm_IRQ : yes
## first report after system is fully awake. Note that rtc_time is now a full 60 seconds ahead of alarm time.
I'm not sure what's actually causing this behaviour, but what it seems
as though the kernel isn't actually registering that the IRQ actually
fired during a hibernate (or the rtc is broken, but it works fine during
S3 tests and I can verify that the IRQ fires and alarm_IRQ resets to
'no' in S3 tests).
In any case, a race is created that isn't met in S3 testing due to the
nearly instantaneous kernel resumption from that sleep state, where it
is created (or at least the race is lost) when resuming from S4 due to
the length of time it takes to resume from that state.)
because of this, subsequent setting of /sys/class/rtc/rtc0/wakealarm
will fail without first clearing it with a '0' and if a piece of
software is actually looking to see if the RTC fired it's alarm_IRQ,
that software will believe that the IRQ has not been fired due to
/driver/proc/rtc incorrectly reporting the event.
ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: linux-image-2.6.32-21-generic 2.6.32-21.32
Regression: No
Reproducible: Yes
ProcVersionSignature: Ubuntu 2.6.32-21.32-generic 2.6.32.11+drm33.2
Uname: Linux 2.6.32-21-generic x86_64
NonfreeKernelModules: nvidia
AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.21.
AplayDevices:
**** List of PLAYBACK Hardware Devices ****
card 0: Intel [HDA Intel], device 0: STAC92xx Analog [STAC92xx Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
Architecture: amd64
ArecordDevices:
**** List of CAPTURE Hardware Devices ****
card 0: Intel [HDA Intel], device 0: STAC92xx Analog [STAC92xx Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
AudioDevicesInUse:
USER PID ACCESS COMMAND
/dev/snd/controlC0: bladernr 2029 F.... pulseaudio
CRDA: Error: [Errno 2] No such file or directory
Card0.Amixer.info:
Card hw:0 'Intel'/'HDA Intel at 0xf0f20000 irq 22'
Mixer name : 'IDT 92HD83C1X5'
Components : 'HDA:111d7604,102802a2,00100104'
Controls : 16
Simple ctrls : 10
Card1.Amixer.info:
Card hw:1 'NVidia'/'HDA NVidia at 0xcdefc000 irq 16'
Mixer name : 'Nvidia ID a'
Components : 'HDA:10de000a,10de0101,00100100'
Controls : 0
Simple ctrls : 0
Card1.Amixer.values:
Date: Thu Apr 29 20:55:42 2010
HibernationDevice: RESUME=UUID=f4e6db09-5257-40b2-ba2a-0718fc0b3f0d
InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Release amd64 (20091027)
MachineType: Alienware M15x
ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.32-21-generic root=UUID=acc23352-13ab-4854-b1d7-a1099a5bf3a5 ro quiet splash
ProcEnviron:
LANG=en_US.UTF-8
SHELL=/bin/bash
RelatedPackageVersions: linux-firmware 1.34
SourcePackage: linux
dmi.bios.date: 03/11/2010
dmi.bios.vendor: Alienware
dmi.bios.version: A05
dmi.board.vendor: Alienware
dmi.board.version: A05
dmi.chassis.type: 8
dmi.chassis.vendor: Alienware
dmi.chassis.version: A05
dmi.modalias: dmi:bvnAlienware:bvrA05:bd03/11/2010:svnAlienware:pnM15x:pvrA05:rvnAlienware:rn:rvrA05:cvnAlienware:ct8:cvrA05:
dmi.product.name: M15x
dmi.product.version: A05
dmi.sys.vendor: Alienware
+ ---
+ Architecture: i386
+ DistroRelease: Ubuntu 10.04
+ InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Release i386 (20091028.5)
+ Package: linux (not installed)
+ ProcEnviron:
+ LANG=en_US.UTF-8
+ SHELL=/bin/bash
+ Tags: lucid
+ Uname: Linux 2.6.34-999-generic i686
+ UnreportableReason: The running kernel is not an Ubuntu kernel
+ UserGroups:
** Changed in: linux (Ubuntu)
Status: Incomplete => New
** Tags removed: needs-upstream-testing
--
[Lucid] Possible race condition involving rtc wakealarm when hibernating a system
https://bugs.launchpad.net/bugs/571977
You received this bug notification because you are a member of Kernel
Bugs, which is subscribed to linux in ubuntu.
More information about the kernel-bugs
mailing list