Re: Commit 500f7147cf5bafd139056d521536b10c2bc2e154 breaks _resume_

[Marc Koschewski <marc@osknowledge.org>]

* Rafael J. Wysocki <rjw@sisk.pl> [2011-02-06 14:04:23 +0100]:

> On Sunday, February 06, 2011, Marc Koschewski wrote:
> > I've the NX stuff disabled, so to say DEBUG_RODATA=n and it doesn't resume... so
> > what's next?
> 
> Did you actually try to revert the NX commits or go back to the version of the
> kernel where they aren't present?
> 
> Also, what's the last known working kernel?

2.6.37 works perfectly. After the first chunk of code after the release of
2.6.37 (so to say 2.6.37 + some stuff, but not 2.6.38-rc1) is broke.

I did not bisect it down to something. But it seems many people have trapped
into it and have pointed at some things that probably broke it - see the
SandyBridge thread.

> 
> > I use an i7 with 32bit code as I think 64bit is a) useless for me
> 
> You're most probably wrong, because memory management is mush simpler in the
> 64-bit mode.  Basically, if your machine supports 64-bitness, you should use
> it.

I didn't see any advantage in 64 bit from what I've read. And I ignore the ~1% overhead
of PAE. The hardware is fat enough...

> 
> > and b) I just plugged my old HDD into my new machine.
> 
> Well, that's a good reason to stay backwards-compatible.
> 
> Thanks,
> Rafael
> 
> 
> > > >> I reverted the specified commit and my box still suffers the
> > > >> resume-turns-into-cold-boot behavior. Retried two times with the commit reverted
> > > >> on top of HEAD...
> > > >
> > > > The cold-boot problem is very likely irrelevant with i915 patches.
> > > > I've got the same issue with and without the i915 fix patches on test
> > > > machines here.
> > > >
> > > Yeah its the 32-bit NX stuff most likely if you are using 32-bit kernels.
> 
> 

-- 
Marc Koschewski