Re: Commit 500f7147cf5bafd139056d521536b10c2bc2e154 breaks _resume_

["Rafael J. Wysocki" <rjw@sisk.pl>]

On Sunday, February 06, 2011, Marc Koschewski wrote:
> * 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 saw it, but it's not conclusive.  You're the last person reporting a suspend
problem which doesn't seem to be related to the NX patches and no one else
seems to be able to reproduce it (obviously including me).

If you suspend what might broke it, why don't you just try to confirm your
suspicions?

> > > 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.

Well, with all due respect to what you have read ...

> And I ignore the ~1% overhead of PAE. The hardware is fat enough...

... what about the kernel memory being confined to the first 1/4 of virtual
address space?  The fact that we have to use highmem on 32 bits is a good
enough reason to switch to 64 bits IMnsHO.

Thanks,
Rafael