Re: 2.6.25-rc6 regression - hang on resume

[Rafael J. Wysocki]

On Sunday, 13 of April 2008, Soeren Sonnenburg wrote:
> On Sun, 2008-04-13 at 15:53 +0200, Rafael J. Wysocki wrote:
> > On Sunday, 13 of April 2008, Pavel Machek wrote:
> > > On Sat 2008-04-12 09:27:42, Soeren Sonnenburg wrote:
> > > > On Fri, 2008-04-11 at 23:04 +0200, Pavel Machek wrote:
> > > > > On Fri 2008-04-04 08:31:29, Soeren Sonnenburg wrote:
> > > > > > On Fri, 2008-04-04 at 01:22 +0200, Rafael J. Wysocki wrote:
> > > > > > > The following report is on the current list of known regressions
> > > > > > > from 2.6.24.  Please verify if the issue is still present in the
> > > > > > > mainline.
> > > > > > > 
> > > > > > > 
> > > > > > > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10319
> > > > > > > Subject		: 2.6.25-rc6 regression - hang on resume
> > > > > > > Submitter	: Soeren Sonnenburg <kernel@xxxxxx>
> > > > > > > Date		: 2008-03-25 04:44 (10 days old)
> > > > > > 
> > > > > > Yes. The machine resumes and display stays black using s2ram -f -p
> > > > > > (blindly typing reboot etc on keyboard does what is expected). However
> > > > > > display comes back on 2.6.24.
> > > > > 
> > > > > Could you get us any debugging output from s2ram? Or maybe even strace
> > > > > it in both working and broken case, and comparing them? (You may want
> > > > > to disable randomization so that results are comparable).
> > > > 
> > > > I did on 2.6.24
> > > > 
> > > > strace -ff s2ram >s2ram24.trace 2>&1
> > > > 
> > > > and .25
> > > > 
> > > > ???strace -ff s2ram >s2ram25.trace 2>&1
> > > > 
> > > > with the .24 bringing the display back and .25 not. Files are here
> > > > 
> > > > http://nn7.de/debugging/s2ram24.trace.bz2
> > > > ???http://nn7.de/debugging/s2ram25.trace.bz2
> > > 
> > > Hmm: 
> > > 
> > > /sys/bus/pci/devices/0000:00:1b.0/irq
> > > 
> > > contains 21 in one case and 22 in another... as do other
> > > interrupts. Is that expected? Can you post /proc/interrupts for both
> > > versions?
> > > 
> > > Hmm, big part of trace is:
> > > 
> > > vm86old(0xb7f76c8c)                     = -1 ENOSYS (Function not
> > > implemented)
> > > vm86old(0xb7f76c8c)                     = -1 ENOSYS (Function not
> > > implemented)
> > > 
> > > ...I wonder why we do it so many times?
> > > 
> > > And here's the difference. .25 says:
> > > 
> > > vm86old(0xb809ac8c)                     = -1 ENOSYS (Function not
> > > implemented)
> > > vm86old(0xb809ac8c)                     = -1 ENOSYS (Function not
> > > implemented)
> > > Error: something went wrong performing real mode call
> > > open("/sys/class/graphics",
> > > O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|0x80000) = -1 ENOENT (No
> > > such file or directory)
> > > open("/dev/tty", O_RDWR|O_LARGEFILE)    = 6
> > > ioctl(6, KDGKBTYPE, 0xbfae8887)         = 0
> > > 
> > > ...can you perhaps add printf-s to s2ram to find out what changed?
> > 
> > Well, that looks suspiciously similar to
> > http://bugzilla.kernel.org/show_bug.cgi?id=10155 .
> 
> OK I tried noexec=off now... same error in s2ram ... so I guess my CPU
> does not support NX ...

s2ram segfaulted in that bug, but your one desn't.  Still, we could have done
another thing that prevents s2ram from doing its job on your system.

Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/