Red Hat Bugzilla – Bug 144415
kernel-2.6.9-1.724_FC3 breaks APM suspend on Thinkpad
Last modified: 2015-01-04 17:15:01 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Description of problem:
Thinkpad T41 hangs on resume from APM suspend-to-ram (with caps-lock
light flashing). Worked fine with kernel-2.6.9-1.681_FC3 and earlier.
Version-Release number of selected component (if applicable):
Always (At least always so far for me.)
Steps to Reproduce:
1. Install kernel-2.6.9-1.724_FC3 on Thinkpad. Set acpi=off kernel
2. Suspend to RAM
Actual Results: Machine locks hard, before display restores. The
caps-lock light flashes. Power-off is required to reset.
Expected Results: Machine resumes normally
Another report of this bug suggested that it was intermittent and that
disabling lm_sensors appeared to fix the problem. I have not found
either to be the case. It fails every time for me, and disabling
lm_sensors had no effect.
I've encountered this issue with kernel-2.6.10-1.1063_FC4 from rawhide
I'm seeing *exactly* the same problem (including the flashing
caps-lock) on my ThinkPad A22p (2629-Y1U). It happens frequently, but
not on every suspend-resume cycle. I suspect that the bug was
introduced between 2.6.9-1.681_FC3 and 2.6.9-1.724_FC3 because the
latter is the first kernel that triggered the problem.
I see the same effect on my workstation; .681 works fine, .724 hangs
on resume, and the lights on the keyboard just blink.
(HW: Athlon Thunderbird on an ABit KT7A motherboard.)
kernel-2.6.10-1.735_FC3 is still broken (on T40)
This bug is a major problem also for people using SWSUSP2. There ACPI
suspend to disk has the same problem on resume. This is with vanilla
2.6.10 and swsusp2 patch. Seems to be dominantly thinkpads, I have T42
but it is affecting others too.
Re: comment #5
Try 2.6.10 with the following two patches:
(or you can run 2.6.10-mm2 instead of 2.6.10 + the two patches)
I have no idea if these patches are compatible with swsusp2, so you
may need to test without swsusp2 if that's possible.
So far, things seem to be working with latest release
All my crashes happened with overnight suspend. I've had 736 crash on
me - and it doesn't look very different than 737 (+ debugging)
Will try 737 tonight and see what happens..
Ok - 737 also crashes.. Not sure how 'overnight' suspend is different
from 'short' suspend of minutes/1hour.
There is a note about the bios setting "Hibernate after suspend
expires -> Enabled" causing this problem - but I don't have this
enabled. So something else (which must be similar) is causing this
It's true, kernel-2.6.10-1.737_FC3 still hangs on resume (this time
after about 3 hours in suspension). Interestingly, the caps lock LED
doesn't flash now.
Probably to nobody's surprise, kernel-2.6.10-1.1076_FC4 also fails as
I tried using 2.6.10-ac8 - and it survived a 6 hour suspend.
I guess I'll have to wait and see if it can survive a few more long suspends
before assuming this version is free of this bug..
Basically I grabbed
and rebuilt it with 'ac-8' patch.
ok - 2.6.10-ac8 survived another 6hour suspend.
Just curious, is there anything in the comments for -ac8 that indicate they
fixed something related to this? Or any other differences between -ac* and the
-bk* series they seem to use for FC?
I just realized I was using ac7 not ac8. (error building kernel rpm on my part)
And kernel-2.6.10-1.737_FC3 is supporsed to be 2.6.10-ac8 + additional patches -
so I'm guessing the bug is in some of the fedora specific patches in 737. (I'm
assuming differences in ac7 vs ac8 doesn't affect this bug)
Created attachment 109680 [details]
Oops - init
Can confirm that kernel-2.6.10-1.737_FC3 with swsusp2 220.127.116.11 displays a
similar problem on my Thinkpad T40 - Oops on init, capslock flashing, system
still functional but init taking >90% cpu and unresponsive to telinit, reboot etc.
Have tried to apply the patches at comment #6, which I can get to apply cleanly
with some line number changes, but they make no difference - same symptoms.
I know swsusp2 isn't part of FC3 - but oops attached (above! oops indeed) if of
help to anyone.
Would you mind trying again without swsusp2, with just the kernel's built-in
swsusp1 + the comment #6 patches? I'm not suggesting this as a permanent change,
just as another test to gather more information about the problem.
OK, I've done so - complete recompile from SRPM, without and with the patches
above. Note that I haven't tried swsusp1 with 2.6.10, as I've been happily using
swsusp2 - both with and without patches worked fine for me for suspend to ram
and disk on a Thinkpad T40. Both messed up X on resume, which I can't recall
how to fix in swsusp1 - been using swsusp2 for too long.
I'll attach versions of the two patches above reformatted and line-numbered for
2.6.10 plain kernel, if they're helpful to someone here.
Still working on swsusp2 and my oops above - my init-in-a-spin problem may be
different (or only vaguely related) to the main problem here.
Created attachment 109723 [details]
patch1 for 2.6.10 - see comment #6
Created attachment 109724 [details]
patch2 for 2.6.10 - see comment #6
Problem persists with kernel-2.6.10-1.741_FC3, even though that is supposed to
include -ac9 patches. A one-hour suspend produced a hard freeze on resume.
Re: comment #22
It's always possible that the problem is being introduced by one of the FC3
*** Bug 145203 has been marked as a duplicate of this bug. ***
Just an update..
I haven't seen this probllem yet since moving to the 'ac' kernel builds.
Currently using ac9. (Earlier I've used ac7, ac8)
Problem is not limited to the Thinkpad. I have a Dell Latitude C840 and I have
identical problem. Kernel 2.6.10-1.741_FC3 still has the problem with this
Confirmed. 741_FC3 locks up my T41 Thinkpad.
I used to use 2.2.x on a ThinkPad 380 and APM worked perfectly.
Since I upgraded to a ThinkPad T22 with Fedora Core 2 I've had only
limited success (see for example bug 13095). ACPI seemed a
non-starter when I first tried it, so I don't know whether it has
improved since then.
On upgrading from 2.6.9-1.6_FC2 to 2.6.10-1.9_FC2 it appeared that
most of the issues had been resolved as the machine did a number of
textbook suspend/resume cycles in situations that hadn't worked
before. However, I then discovered that suspending for more than a
few minutes reliably kills the machine. There are two possible
results, which seem to occur at random: in one the machine seems
completely dead although SysRq can be used to reboot it; in the other
the caps-lock and scroll-lock LEDs flash and if I jiggle the SysRq key
enough I can get it to print stuff on the screen - though none of the
actions work except reboot.
I tried booting with serial console enabled and logging what came
through on another machine, but I didn't get anything at all after
the machine was suspended. Anyway, to get to the actual point of this
comment, I did copy down the results of SysRq's "show PC" function in
the hope that it would be useful. The appearance of RTC functions in
the traceback does seem to tally with the idea that it's dependent on
how long the machine was suspended for. I hope there aren't too many
transcription errors in the output, which I'll attach in just a
Created attachment 110004 [details]
"Show PC" output after resume has crashed the machine
See comment 28.
Just adding a "me too" for my T40 (2373-94U). Short APM suspends recover fine,
but longer ones lead to a kernel panic.
Just an extra data point. If I switch to a VC before I do a long suspend, when
I resume, I get a kernel panic on the screen. This is some of what I see:
Warning: CPU frequency is 16000000, cpufreq assumed 600000 kHz.
Kernel panic - not syncing: arch/i386/kernel/time.c:178:
spin_lock(arch/i386/kernel/time.c:c0342be8) already locked by
Badness in panic at kernel/panic.c:117
[what looks like a stack trace]
This is a 1.6Mhz Pentium M with SpeedStep enabled, but it went from a AC
connection to another AC connection, so it shouldn't have down-shifted to
600Mhz. Then again, that warning might just be a red herring.
Created attachment 110348 [details]
text of kernel panic on resume from APM suspend
I'm duplicating comment 31 but without the initial cpufreq complaint.
The attached is the entire text of the kernel panic which appears on screen
after resuming the machine. In this case the caps and scroll lock lights were
not flashing (and I have another failure almost exactly the same but with some
minor differences at the bottom of the trace).
Thanks to comment 31 I've been able to switch to VT-1 before suspned
(This is with 2.6.10-1.753_FC3 on a thinkpad 600E - 366MHz P-II).
In my case - the caps & scroll-lock lights blink.
I get the same stack trace as the attachment in comment 32.. Something
like (written down manually):
Badness in i8042_panic_blink at drivers/input/serio/i8042.c:917
[few more lines which I cou'dn't write down -as the
screen went blank]
My T41 survived a 2-hour suspend using kernel-2.6.10-1.1115_FC4 from
Rawhide. Unfortunately, that kernel's built with gcc-3.4 so I can't
build VMware modules against it. And it has too many Rawhide
dependencies for me to rebuild myself.
But it still does *not* work with kernel-2.6.10-1.760_FC3, even though
it is rebased to 2.6.10-ac11.
So still no completely functional kernel on my Thinkpad.
Based on what I'm reading here, I suspect the problem is being
triggered by one of the kernel-2.6.10-1.xxx_FC3 patches, aside from
the -ac patch.
Unfortunately I haven't been able to reproduce this on any of my
hardware (I don't have an IBM ThinkPad), otherwise I would be able to
narrow things down more.
Anything else we can do to help test, let us know.
BTW, the devel kernel-2.6.10-1.1115_FC4 seems to work fine WRT
suspend-to-RAM, although it's not a complete solution for other reasons.
Here's a strange thing... my 2.6.9-1.6_FC2 kernel is now printing
spin_lock messages in the syslog.
My message log begins on Jan 2. I have seven successful overnight
suspends, then on Jan 12:
Jan 12 00:18:03 starbright apmd: System Suspend
Jan 12 08:06:34 starbright kernel: arch/i386/kernel/time.c:178:
spin_lock(arch/i386/kernel/time.c:0235b028) already locked by
Jan 12 08:06:34 starbright kernel: arch/i386/kernel/time.c:317:
spin_unlock(arch/i386/kernel/time.c:0235b028) not locked
This happens every time except three since then, with the latest one
this morning. I've no idea what's changed (if anything) or whether
the messages were happening before then (as the logs have been rotated
out of existence), but I've been running this kernel since Nov 24,
except for mid-January when I tried 2.6.10-1.9_FC2. The difference
with 2.6.10 is linux-2.6.9-spinlock-debug-panic.patch which means that
instead of this message we get a kernel panic, as documented at length
in this bug report.
What this means is the underlying bug isn't new in late-2.6.9 and
2.6.10 kernels; only the panic is new.
(And this morning for the first time since installing the system last
May, I was hit by bug 142329 - grr!)
I am not a kernel hacker, but I would think that if it's possible to
block the timer interrupt while executing timer_resume() then that
would fix the problem.
[Now that my T40 is back from IBM-repair] I've tried kernel-2.6.10-1.760_FC3
(rebuilt with CONFIG_X86_HZ=100) & kernel-2.6.10-0.ac11
The experience is similar to comment 38.
kernel-2.6.10-0.ac11 gives the following on APM resume
Feb 4 09:02:07 asterix kernel: arch/i386/kernel/time.c:178:
spin_lock(arch/i386/kernel/time.c:c03bebe8) already locked by
Feb 4 09:02:07 asterix kernel: arch/i386/kernel/time.c:317:
spin_unlock(arch/i386/kernel/time.c:c03bebe8) not locked
[root@asterix ~]# grep spin_lock /var/log/messages* | wc -l
Badness in i8042_panic_blink
Re: Comment #36: Note that it's not just Thinkpads. #146457 looks
like a dup of this, and I've seen at least two reports of problems
with Dell Latitude C840s (one in comment #26 above).
DaveJ: please remove linux-2.6.9-spinlock-debug-panic.patch from
If not, maybe someone could update the patch so it is possible to turn
off this feature with a kernel parameter?
At http://people.redhat.com/davej/patchlist-fc3.txt the patch is
descibed like this:
"panic() instantly instead of printing a warning when spinlock
debugging is triggered. This reduces the possibility of silent data
What "silent data corruption" is this? Is it related to the annoying
And -- maybe most important -- why is this "spinlock debugging"
triggered at all?
Re: comment #41
According to comment #37, a recent rawhide kernel isn't showing this
problem -- and I looked at that kernel's specfile a few days ago; it
still seems to be applying the spinlock debug panic patch.
In my next comment I'll post quick instructions for recompiling a
rawhide/FC4 kernel for FC3. Right now I don't have a convenient place
for posting compiled kernel binaries, so my instructions will have to do.
> What "silent data corruption" is this?
Depends on what causes the panic...
Created attachment 110750 [details]
patch that converts FC4 kernel specfile for FC3 recompile
I decided it would be easier to do it as a patch than to write out instructions
for changing the specfile. Basically:
rpm -ivh kernel-2.6.XX-1.YYYY_FC4.src.rpm
cd /usr/src/redhat/SPECS (or wherever, if you've changed your RPM
patch -p0 -i /path/to/kernel-spec-fc4-to-fc3.patch (i.e. this attachment)
rpmbuild -ba --target i686 kernel-2.6.spec
If/when bug 147281 is fixed, this patch will no longer be necessary (and will
probably no longer apply to the specfile either).
Anyway, this should let people recompile the FC4 kernels for FC3, without
dependency or gcc version problems. That way, other people can test and see if
the FC4 kernels really fix this bug.
I've tried 2.6.10-1.1126 on the T40 [with a couple of mods: 1000Hz -> 100Hz,
2.6.11-rc3-bk2 -> 2.6.11-rc3-bk4]
After an overnight suspend - I get a crash [capslock blink]. On VT-1 - The stack
scrolls by - and I see repated prints of the form:
atkbd.c: Spurious %s on %s. Some program,like XFree86, might be trying access
I had to powercycle the machine.
Kernel 2.6.10-1.1126 compiled for FC3 i686 as per comment 43:
Obviously, since I haven't signed it, you use it at your own risk.
I installed it on my ThinkPad T22 last night [it's an FC2 system so
the post-install script failed - easily fixed by running
new-kernel-pkg manually]. Then suspended for 8 hours and got a
successful wakeup this
morning with no untoward messages at all. The machine was on a text
console at the time of the suspend (though a gdm login screen was
present on another VT) and my boot command line contains "atkbd.reset"
in case it matters.
I installed Ian Collier's 2.6.10-1.1126 RPM on a Dell Latitude C840
and still apmsleep does not work. I gave it apmsleep +1:00 and it went
to sleep all right. However, it did not wake up. On pressing the power
button, the screen went on to its dull mode, and nothing else
happened. I did not set atkbd.reset=1, though I will try that.
atkbd.reset=1 makes no difference....
OK, here is something more. If I go to a text console (Ctrl-Alt-F1-F2)
the system does wake up, but with the comment that: CPU frequency is
2400000Hz, but cpufreq is assumed/set at 1200000Hz. However,
Ctrl-Alt-F1-F7) to get back to the X screen reverts it back to the
dull state, so pretty useless IMO.
I built kernel-2.6.10-1.1137_FC3 using Barry's spec file. (What are
kernel-xen0 and kernel-xenU?) It survived an overnight suspend with
I have two (unrelated) issues with it, though.
(1) rhgb hangs occasionally (radeon driver, 7500 Mobility, only change
from default config is I've turned the DynamicClocks option on).
(2) vmware modules won't build for this kernel, even in its FC3 form.
This makes it not a solution for me, as I need vmware. (I haven't
investigated vmware patches yet, though.)
Re: Comment #48: I see that sort of message when resuming from ACPI
suspends. It seems not to be a problem there. It's related to
SpeedStep. Also, does it help to do the suspend/resume from a VC and
then switch to X instead of suspending directly from X?
Re Comment 49:
kernel-xenO, kernel-xenU - they are releated to xen virtual machine
[similar to vmware] - an upcoming feature for FC4. I just disable
these two variables when building kernel for FC3
vmware modules: did you install 'kernel-devel' package?
I've built 1141 kernel [aka 2.6.11-rc4-bk1] with the following changes]
- 1000Hz -> 100Hz
- Disable linux-2.6.9-spinlock-debug-panic.patch
It survived an overnight suspend - without any spinlock messages.
Re: Comment #50: Interesting. I'll be interested to see how xen
works. Meanwhile, disabling should cut kernel build time a bit 8^).
Yes, I did install kernel-devel. (Oh, dear. Yet another new model
for getting kernel buil;d environments. That will just thrill all the
fedora-list denizens who are finally just getting used to the FC3
model...) The issue is some undefined symbols and failure of the
module to insmod. I suppose I ought to file a separate bug for that,
though. It's a bit off-topic here.
Just another data point:
2.6.10-1.1126_FC3 (cf comment #45) has been running OK for me on a
Toshiba Portege 3440CT for a couple of days now, surviving several
suspend/resume events. This is considerably better than any of the
update kernels since 2.6.9-1.681_FC3.
I did see the effect of comment #45 when attempting a shutdown at one
kernel /vmlinuz-2.6.10-1.1126_FC3 ro root=/dev/VolGroup00/LogVol00
apic=no acpi=off rhgb quiet
(without acpi=off, the resume problem disappears - the system refuses
to enter suspend mode ;-) )
Re: Comment #49: vmware-any-any-update89 fixes the vmware-config.pl
issues. So far, no further hangs (fingers crossed).
Re: Comment #49, I tried apmsleep from VC and then it went to sleep
and wake up all right, but when I switched to X, it never went to X,
but the dull screen I mentioned.
May be I should kill X completely?
I experience pretty much the same problems on Toshiba Tecra8100,
including caps lock blinking and that a longer suspend is necessary to
trigger the bug, so it's not limited to ThinkPads.
I think I've hit the problem described in comment 46 with my rebuilt rawhide
kernels [2.6.11\-rc4-bk6, bk8].
On recovery the screen is blank - and nothing works [except Fn-F3 - which makes
the screen c\ompletely dark]
There were no blinking caps-lock or num-lock - but none of the following worked:
Fn-F4, Alt-\Ctl-Backspace, Alt-Ctl-F1/Alt-Ctl-Del
I had to powercycle to reboot. I'll start suspending in VT-1 to see if there is
a trace. Cur\rently there is none - in /var/log/messages. [but then - I disabled
the flags DEBUG_SLAB, DE\BUG_BUGVERBOSE, DEBUG_PAGEALLOC, DEBUG_HIGHMEM]
Feb 21 00:11:56 asterix apmd: System Suspend
< I guess reboot at this point>
Feb 21 08:51:42 asterix syslogd 1.4.1: restart.
Feb 21 08:51:42 asterix syslog: syslogd startup succeeded
Feb 21 08:51:42 asterix syslog: klogd startup succeeded
Tried again [ref comment 56] - this time suspending in VT-1. Its now same
problem as comment 44.
The stack-trace scrolls by so fast that I don't know if its the same spinlock
issue or some new problem [the atkbd.c messages - which causes the scroll is new]
I'll disable the linux-2.6.9-spinlock-debug-panic.patch and try again.
Just a followup to comment 57 - I had an uptime of a week with the kernel I
rebuilt without linux-2.6.9-spinlock-debug-panic.patch
There were 3 variables I changed here -
- disable linux-2.6.9-spinlock-debug-panic.patch
- update to 2.6.11-rc4-bk9 [from bk8]
- unload uhci_hcd/ehci_hcd after a couple of days.
I strongly suspect linux-2.6.9-spinlock-debug-panic.patch causing the initial
problem - but I'm not sure..
Today I've rebuilt by upping to 2.6.11 [with 1154 kernel from rawhile] and all
the mods metinoed in comment 56 & 57
Hoping the good uptime won't be affected.
all that removing the spinlock-debug-panic should do is make the spinlock bug
non-fatal. Ie, you should still find a message in dmesg output/logs saying
something bad happened. Continuing to run after such a situation, is very risky.
I didn't see any spin_lock messages after disabling the
linux-2.6.9-spinlock-debug-panic.patch [hence my hesitation about assuming this
to be the problem]
And the diff form bk8 to bk9 shows:
[jantu@asterix tmp]$ diff patch-2.6.11-rc4-bk8 patch-2.6.11-rc4-bk9 |grep diff
> diff -Nru a/arch/i386/kernel/setup.c b/arch/i386/kernel/setup.c
> diff -Nru a/drivers/ide/Kconfig b/drivers/ide/Kconfig
> diff -Nru a/drivers/ide/ide-io.c b/drivers/ide/ide-io.c
> diff -Nru a/drivers/ide/ide.c b/drivers/ide/ide.c
> diff -Nru a/drivers/net/natsemi.c b/drivers/net/natsemi.c
> diff -Nru a/drivers/net/s2io.c b/drivers/net/s2io.c
> diff -Nru a/drivers/net/wireless/strip.c b/drivers/net/wireless/strip.c
Maybe its the ide stuff?
Since the previous formula worked - I'm a bit hesitant to change the variables -
and try them all - one at a time [and see when things break]
*** Bug 146457 has been marked as a duplicate of this bug. ***
Interesting note: for me at least, disabling NTP (system-config-date -> Network
Time Protocol) appears to prevent my laptop (Tecra M2) from freezing after APM
resume, at least the first time I tried it. If this can be confirmed by someone
else, consider it one workaround for the bug.
I suspect that this is because do_timer_interrupt() (in arch/i386/kernel/time.c)
calls the apparently problematic set_rtc_mmss() only in case STA_UNSYNC if off
(i.e. sync on, acc. to timex.h), which I am guessing is true only for NTP users (?).
See bug #146457 for a few other notes, possibly of interest to someone debugging
this. I have symptoms similar to comments #29-33 in this bug.
More info: the stack traces seem to say that get_cmos_time() is getting an
interrupt somewhere inside its body while holding a lock, presumably really in
the inline mach_get_cmos_time() (why? is this predictable?), and
timer_interrupt() is handling that by calling set_rtc_mmss(). But both
get_cmos_time() and set_rtc_mmss() use the same spinlock, so of course it
results in an error. See Linus' explanation (ss. 3) in Documentation/spinlocks.txt:
... IFF you know that the spinlocks are never used in interrupt handlers, you
can use the non-irq versions:
Note the caveat. But this spinlock *is* being used in an interrupt handler. An
oversight? Would using spin_lock_irqsave() + spin_unlock_irqrestore() in
Or should get_cmos_time() just temporarily set some static flag which disables
the attempted call to set_rtc_mmss() in do_timer_interrupt() until it is done
with the lock - since the synching from software clock to CMOS in this case is
happening only after a resume, in which case it is presumably useless because we
just recently loaded the SW clock from CMOS?
Created attachment 111719 [details]
*UNTRIED* patch for sake of experimentation
My thinking is along the lines of the attached patch (have not tried it yet).
It might succeed in preventing unwanted NTP-triggered synch to CMOS during an
APM resume. Note that this use of spinlocks is not 100% safe since it is still
possible for a timer interrupt to come between the call to spin_lock() and
setting the flag, or between unsetting the flag and spin_unlock(); but I am
guessing that would be far less likely than hitting a timer interrupt while
inside mach_get_cmos_time(). Not sure what a completely safe version would look
like but I guess it would have to use IRQ blocking of some sort.
Based on comments 62--64 which suggest ntpd as a culprit, I've run:
/etc/init.d/ntpd stop ; /etc/init.d/pcmcia stop
and have gone through three successful suspend/resume cycles with
2.6.10-1.770_FC3. All suspends lasted less than two hours, but this is still an
improvement! Thanks! I'll try a longer suspend tonight.
With ntpd off, a 3+-hr suspend resulted in yet another lock-up (w/ blinking
shift-lock light) on a TP A22p running 2.6.10-1.770_FC3.
I have been experiencing the problem with a Dell Latitude c610 also for awhile
now (Sorry been very busy to participate in this discussion). I tried Ed's
recommendation of turning off ntpd but it does not work for me (#65).
So I guess my next question is should I try the Fc4 kernel or should I look at
something else (like the spinlock-debug-panic.patch)?
Had a blinking-caps-lock incident with the 2.6.10-1.1126 kernel the day before
yesterday. This was after several suspend/resume cycles per day for almost four
weeks. So it seems that it hasn't cured the problem but certainly reduced the
frequency with which it appears.
I experience the same problem once switched from FC2 to FC3 on Compaq Evo
N600c notebook. Well, solution to my APM problem was to install vanilla 2.6.10
and APM again start working like a charm. I'm 100% sure that source of APM
problem relies somewhere in FC3 patches to the kernel. It would be nice if
people confirm that vanilla kernel doesn't have APM problem.
My experience so far:
- with fedora kernels, [currently using modified 2.6.11-1.14_FC3] disabling
spinlock-debug-panic.patch avoids the crash&burn senario [replaced with friendly
messages in /var/log/messages]. If this happens one can reboot at a convinent time.
- disabling ntpd appears to get rid of the messages in /var/log/messages. I'm
guessing my earlier success report was perhaps because ntpd couldn't start [due
to a disabled network at boot] - and it remained disabled.
- I've briefly tried kernel 18.104.22.168 without fedora patches - it survived one
I've had shutdown prblems with 22.214.171.124 - a hang at shutting down 'iptables'. So
I switched to 2.6.11*FC3 kernels. Then I had this shudtown issue with one of the
modified 2.6.11*FC3 kernels as well. [This is not always reproduceable. When I
manually try 'service iptables restart' it always works]
Created attachment 113161 [details]
Show PC output from crash in 2.6.10-1.1126
I echo comment 68. I installed 2.6.10-1.1126 towards the beginning of February
and had several successful overnight suspend/resume cycles until suddenly it
crashed on the 27th. Attachment shows the text which appeared when I pressed
SysRq+P, though it was difficult to catch because it was spewing the atkbd
message (at the bottom) about once every second. Then it didn't crash again
until March 27th (with the same traceback).
Created attachment 113163 [details]
Replacement spinlock-debug-panic patch
...However, I seem to have an obscure hardware fault (memory problem?) which
makes my machine suddenly crash for no apparent reason maybe about once a month
(it's getting worse, though :-(). That's only relevant because it made me
reboot my machine last week - but since then, 2.6.10-1.1126 has panicked every
time I've tried an overnight suspend.
Which is why I now intend to run the standard (currently 2.6.10-11_FC2) kernel
with the spinlock-debug patch replaced by the attached. It's a horrible hack
which makes the spinlock error cause a panic *except* when it happens during
i386/kernel/time.c. So now I do sometimes get a spew of messages in the syslog
when I resume, but it doesn't crash any more. (On the other hand, it does
sometimes set the clock to a stupid value.)
<with my modified 2.6.11-1.14_FC3 kernel comment #70> I've noticed the following
in my /var/log/messages [happened during an APM recovery-from-suspend]
Apr 18 08:20:45 asterix kernel: drivers/block/cfq-iosched.c:1065: spin_is_locked
on uninitialized spinlock f7bb481c.
[and a stack trace with a taint flag for madwifi]
Perhaps this one is a completely unrelated issue...
Created attachment 113573 [details]
spinlock trace from /var/log/messages
I added the patch from comment 64 to my kernel (2.6.10-11_FC2 with the patch
from comment 72) and for some reason it made my system clock run at double speed!
An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which
may contain a fix for your problem. Please update to this new kernel, and
report whether or not it fixes your problem.
If you have updated to Fedora Core 4 since this bug was opened, and the problem
still occurs with the latest updates for that release, please change the version
field of this bug to 'fc4'.
Since disabling 'ntpd' - I don't remember having a single crash..
Now I've enabled ntpd with 2.6.12-1.1372_FC3 - and it survived a 8 hour APM
suspend. [which is a good sign]
Will keep monitoring - and report if i see a crash.
Seems to be working better on my workstation as well; it has survived two
overnight suspends so far.
kernel-2.6.12-1.1372_FC3 solved the problem on my Dell laptop, see comment #26
above. However, the latest kernel, kernel-2.6.12-1.1376_FC3 breaks it again.
The laptop does not recover from sleep. It didn't even survived a 2 min APM
suspend. Did it happen on the Thinkpad too?
kernel-2.6.12-1.1372_FC3 solved the problem on my Dell laptop, see comment #26
above. However, the latest kernel, kernel-2.6.12-1.1376_FC3 breaks it again.
The laptop does not recover from sleep. It didn't even survived a 2 min APM suspend.
Did it happen the same way for the Thinkpad?
Just a couple of data/no-data points:
- my ThinkPad A22p was sold so I no longer have it for testing purposes
- the replacement ThinkPad T42p (2373-HTU) has suspended very reliably
(using ACPI with the kernel options "pci=noacpi acpi_sleep=s3_bios")
with all FC4 kernel updates including 2.6.12-1.1447_FC4
I'll admit that, once I had a solution to the Radeon hot-suspend (bug #142928),
I switched to ACPI. I've had no problems since on my T41 (2373-JHU)--don't even
need the kernel options in comment #82. Note that kernel-2.6.12-1.1447_FC4
doesn't do ACPI suspend properly in my case (bug #165819), but 2.6.12-1398_FC4
I'm still using APM with FC3 on my T40. Currently using 2.6.12-1.1378_FC3 - no
I've been using 2.6.12-1.1376 backported to FC2 for just under a week with no
crashes on a ThinkPad T22. I'm still using the patch from comment 72, but haven't
seen any spinlock messages since August 23, when I was running 2.6.11-1.14.
(I never said, but comment 75 was a false alarm - apparently my clock always
goes at double speed when I boot on battery power and then connect the
there are a number of different problems reported here, across a variety of
kernels including a bunch of self compiled ones with add-ons, involving various
features nothing to do with apm.
if you're still having apm problems with the current fc3 errata, please file a
new bug, as this one has become far too cluttered to make any coherent analysis