I've worked during this weekend to diagnose the problem I reported earlier, in
the thread " Please test 2.6.13-rc2 in TT mode! Big problem with syscall
parameters clobbering".
It can affect an application when these conditions are verified:
*) the host is running a 2.6 kernel with SKAS patch and
On Thursday 07 July 2005 20:31, Blaisorblade wrote:
> For this kernel (and for -rc1), I've been getting almost no reports (except
> a problem with GCC 2.95 I now solved) in TT mode, so I'd like some more
> testing, especially for users which have the latest SKAS patch installed.
> At least positive
On Monday 11 July 2005 10:48, Oleg Girko wrote:
> On Saturday 09 July 2005 13:18, Blaisorblade wrote:
> > Can you test on a UML file? Non urgent since my patch fixed it, but it
> > would still be useful. (do a make ARCH=um V=1 to take the right command
> > line, or even do make ARCH=um arch/um/.i a
On Monday 11 July 2005 09:48, Bernhard Schauer wrote:
> On Thu, 2005-07-07 at 07:59 -0400, Jeff Dike wrote:
> > So, I would say that skas0 is more a fix for this problem than
> > reverting the fork-not-clone patch is.
> No it isn't. Its an other method not a fix for anything.
I agree on this point
On Saturday 09 July 2005 12:50, Blaisorblade wrote:
> On Friday 08 July 2005 14:28, Oleg Girko wrote:
> > Hello!
> > But for unknown reason, CRYPTO_AES_586 option is enabled also if building
> > UML for X86 architecture, and CRYPTO_AES option is unavailable in this
> > case.
> >
> > There is no wa
Hey gang, if you follow the latest LFS books and try to run UML, it won't
work. LFS 6x has moved to NPTL, and as we all know, UML and NPTL don't
play well together. You can make two changes to the default book, both in
regards to building glibc, to get a LFS 6x box that uses linuxthreads
inste
On Saturday 09 July 2005 13:18, Blaisorblade wrote:
> On Friday 08 July 2005 13:33, Oleg Girko wrote:
> > On Thursday 07 July 2005 21:31, Blaisorblade wrote:
> > > I guess that in NPTL headers, instead of using __errno_location() the
> > > faster "__thread int errno;" is used; Oleg, can you verify
On Thu, 2005-07-07 at 07:59 -0400, Jeff Dike wrote:
> So, I would say that skas0 is more a fix for this problem than
> reverting the fork-not-clone patch is.
No it isn't. Its an other method not a fix for anything. As long as
skas0 is not in kernel mainline and enabled in main distributions, it
h
