Marko Rößler <[EMAIL PROTECTED]> writes: > Well, it seams to solve the key_sched.c problem. There is another > problem with the following Backtrace:
> <<snip>> > Starting program: /tmp/openafs-1.4.4.dfsg1/src/kauth/klog > Password: > stackcheck = 0: stack = 0 > topstack = 0xffcfbb1c: stackptr = 0xf7c5a008: stacksize = 0x48000 > Thu Jul 12 09:18:14 2007 LWP: stack overflow in process IO MANAGER! > Program received signal SIGABRT, Aborted. We've tracked this problem down, but unfortunately there isn't great news. This is a different problem, related to the glibc upgrade. OpenAFS supports two ways of implementing its LWP threading library: through knowing way too much about glibc internals, which broke with glibc 2.3 when glibc started XORing stack pointers, and through using getcontext/savecontext. We switched all platforms over to using getcontext/savecontext for glibc 2.3 and higher. However, getcontext/savecontext is not implemented for sparc32, only for sparc64. I'm currently doing a sparc64 build just to confirm that solves the problem. If it does, I'm going to check on debian-devel to see if it's okay at this point to build a sparc64 package for the Debian sparc architecture. I think that it may be at this point given that the kernel team is dropping support for the sparc32 kernels, but it's likely to cause at least some consternation. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
