On 24 Apr 2008, Jeff Dike uttered the following:
> OK, yell if it starts happening again...
I tempted fate, and lo, it happens within the hour...
(gdb) bt
#0 0x08083e3a in getnstimeofday ()
I will now do what I should have done long since and turn on frame
pointers and debugging info so I can g
On Thu, Apr 24, 2008 at 08:57:54PM +0100, Nix wrote:
> On 16 Apr 2008, [EMAIL PROTECTED] stated:
> > This *is* a change in behaviour: the backtrace is different! Yay! :)
>
> I upgraded the guest to 2.6.25 a week ago and it stopped happening.
> There is hope. (Mind you it's stopped going wrong for
On 16 Apr 2008, [EMAIL PROTECTED] stated:
> This *is* a change in behaviour: the backtrace is different! Yay! :)
I upgraded the guest to 2.6.25 a week ago and it stopped happening.
There is hope. (Mind you it's stopped going wrong for week-long periods
before...)
--
`If you are having a "ua lue
From: WANG Cong <[EMAIL PROTECTED]>
Date: Thu, 24 Apr 2008 16:36:55 +0800 (CST)
>
> Make some variables and functions static, since they don't need
> to be global.
>
> And remove an unused function - arch/um/kernel/time.c::sched_clock().
>
Sorry, Andrew.
I forgot to run checkpatch for this one.
Make some variables and functions static, since they don't need
to be global.
And remove an unused function - arch/um/kernel/time.c::sched_clock().
Cc: Jeff Dike <[EMAIL PROTECTED]>
Signed-off-by: WANG Cong <[EMAIL PROTECTED]>
---
arch/um/include/skas/skas.h |1 -
arch/um/include/um_ua
I just looked at what it would take to port SKAS3 to 2.6.25, and it
looks well beyond my C non-abilities. Porting 2.6.23's SKAS3 to
2.6.24 was mostly an exercise in figuring out what code from
i386/x86_64 moved to where, but 2.6.24 to 2.6.25 seems to have
reworked a lot of the ptrace/ldt code. Ho
