Bug 185108

Created attachment 125965 [details]
/var/log/messages during pm-hibernate and resuming

After rebooting from the above pm-hibernate, pm-suspend started acting the same
as pm-hibernate.  I have spent the last 4 hours attempting to characterize the
problem.

Xorg would start using 100% of the CPU.  /proc/interrupts would add an entry for
i915@pci:0000:00:02.0.  This entry does not appear when X works normally.

Attaching gdb to Xorg would give this backtrace:

#0  0x0052c552 in I830CheckModeSupport () from
/usr/lib/xorg/modules/drivers/i810_drv.so
#1  0x003f8df2 in XAAGetPixmapIndex () from /usr/lib/xorg/modules/libxaa.so
#2  0x00c770fb in xf86ForceHWCursor () from /usr/lib/xorg/modules/libramdac.so
#3  0x080bfc1c in xf86InitFBManagerArea ()
#4  0x080cc014 in xf86XVScreenInit ()
#5  0x080b9a03 in xf86Wakeup ()
#6  0x0808c9c9 in WakeupHandler ()
#7  0x081a73d9 in WaitForSomething ()
#8  0x080887dd in Dispatch ()
#9  0x080701d7 in main ()

I played around by reverting to:

udev-084-11
xorg-x11-server-Xorg-1.0.1-7
xorg-x11-xkbdata-1.0.1-6

I was able to get pm-suspend to resume correctly ONCE.  But trying to reduce the
rpm set to the problem one proved impossible.  I could not reproduce it even
with the same packages that worked.

I believe the only working setup I had was with xorg-x11-server-Xorg-1.0.1-7 and
xorg-x11-xkbdata-1.0.1-6 reverted (using the current udev).

Current packages for the above are:
 udev                    i386       084-13           development       631 k
 xorg-x11-server-Xorg    i386       1.0.1-8          development       3.3 M
 xorg-x11-xkbdata        noarch     1.0.1-7          development       329 k

Seems I wrote incorrectly, i915@pci:0000:00:02.0 does appear when X is behaving
correctly.

kernel versions:
2064 Works completely for pm-suspend.

2102 Does not work.  Screen stays dark for about a minute, then the backlight
turns on with garbage across the top 50 pixels.

2106 Apparently restarts, but has a journal I/O error.  "ls -l" lists files, but
there's garbage for some of the stats for random files.  Other comands won't run
from the terminal window (eg df resulted in a bus error).

pm-hibernate also works in 2064.

This looks much more like a kernel bug. Reassigning to correct component.

Read ya, Phil

Still doesn't work in 2200 and (possibly, did not check version before first
attempting a pm-suspend) 2196.  2064 still works.

I want to try a git bisect to see where the problem started.  Is the .config
used for 2064 the concatenation of the config-generic and config-i686 files?  I
got these from:

  http://cvs.fedora.redhat.com/viewcvs/rpms/kernel/devel/configs/

2064 happens between 2.6.16-rc6 and 2.6.16.  But the rpms I've used (still in my
yum development packages) places the upper bound at 2.6.16-git15 (pre 2.6.17-rc1).

Created attachment 130160 [details]
JPEG image of dmesg with results from resuming

It takes me 56 to 58 minutes to generate a kernel...

2.6.16 is good
2.6.17-rc1 is bad

first bisect: good 
  Bisecting: 2118 revisions left to test after this
  [a3ea9b584ed2acdeae817f0dc91a5880e0828a05] Merge
    master.kernel.org:/pub/scm/linux/kernel/git/gregkh/pci-2.6

second bisect: good
  Bisecting: 1045 revisions left to test after this
  [f4d1749e9570d3984800c371c6e06eb35b9718b1] powerpc: add hvc backend for rtas

third bisect: would not boot (unrelated to my problem) selected bad
  Bisecting: 528 revisions left to test after this
  [256414dee44eaa0983f5ab1a71877de23c4e9ce7] Merge branch 'upstream-linus' of 
    master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev

fouth bisect: root volume becomes RO on resume, unknown if this is related.
I initially though it was, but screen unblanked and I was able to peek around
a bit.  See the just previous attached JPEG for the problem announced in dmesg.
  Bisecting: 264 revisions left to test after this
  [50fc9999ec27ad66ce6db31ebb03759f77962bc1] Docs update: missing files and 
    descriptions for filesystems/00-INDEX

These are the results so far with 18 hours of work in the last 22 hours.

I'm going to attempt to continue with the assumption that the 4th bisect is bad...

Some additional clarification of #10:

The third bisect started having trouble while running the initrd.  I believe
compiling had problems with unresolved symbols in ext3 and reiserfs.  The
results were the root FS was not found.

On the Fourth bisect, my initial though that it was identical to my problem, but
after a few seconds the screen did unblank.  I did not actually attempt any
reads of the hard drive (what I used might have all resided in RAM already).  I
could not shutdown without using the power switch though.  So I'm proceed with
the assumption that this is the problem, just that it wasn't masked by a blank
screen.

Created attachment 130163 [details]
This patch fixes the problem

Mark Lord sent this patch to LKML.  It fixes the problem for me.

There is still a BUG() message that is reported in comment #9.

The above patch is in 2.6.17-rc5-git5.

kernel-2.6.16-1.2230_FC6 claims to contain 2.6.17-rc5-git5.

This kernel does not resume from a suspend.  It's as though the patch was
reverted.  Is the patch really in this version?

Created attachment 130393 [details]
This is the .config used in comment #10

Is this better with newer kernels?   I know I've hibernated since then...

No feedback on this for nearly 8 months, so insufficient data to be able to do
anything. Assuming the issue has been addressed by newer kernels. Please reopen
this bug if that's not the case.