On Mon, Jan 16, 2006 at 08:50:03PM +, Antoine Martin wrote:
Found these in a guest running 2.6.15-rc1.
Note sure this is relevant anymore, but here it is anyway:
[45512066.14] Badness in handle_page_fault at
arch/um/kernel/trap_kern.c:101
[45512066.83] load_TLS(O_FORCE) in
On Monday 16 January 2006 18:14, Olaf Hering wrote:
Current Linus tree does not compile for me:
girgendwas:~/linux-2.6.15$ gcc -Wp,-MD,arch/um/drivers/.chan_user.o.d -Wall
-Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common
-ffreestanding -Os -fomit-frame-pointer
On Friday 13 January 2006 00:38, Jeff Dike wrote:
On Thu, Jan 12, 2006 at 12:02:16PM -0500, Young Koh wrote:
I found an old post discussing the possibility of turning a system
call into a procedure call using vsyscall. Is it really implemented in
recent versions? I tested with recent
I've taken TLS patches from Jeff Dike's tree today, and made them compile in
all SKAS/TT configurations. The errors were easy to fix, however (ever
because I still remember my code and the comments help).
Btw, D.Bahi, your fixup patch was a bit bogus (doesn't matter when not using
TT,
On Sunday 15 January 2006 22:39, Jeff Dike wrote:
This patch implements soft interrupts. Interrupt enabling and
disabling no longer map to sigprocmask. Rather, a flag is set
indicating whether interrupts may be handled. If a signal comes in
and interrupts are marked as OK, then it is
On Tue, Jan 17, 2006 at 01:04:21AM +0100, Blaisorblade wrote:
[...]
However, going through ptrace for interprocess comunication is far from
optimal - using something like, say, POSIX message queues (it's a wild guess)
would be probably faster. Something purely in userspace seems
On Tue, Jan 17, 2006 at 01:04:21AM +0100, Blaisorblade wrote:
No, wrong - on x86 it's used for everything, depending on userspace (it's
replacing int 0x80 with sysenter). For some reason, on x86-64 it was that
way, but it switched to what you say (implementing only a few syscalls
directly
On Tue, Jan 17, 2006 at 02:33:59AM +0100, Blaisorblade wrote:
what
about load_TLS? I only got -22, I fixed it by removing tls-debug
That's caused by referring to errno in kernel code. That gets you the
value of kernel_errno, which could be anything.
Jeff
On Tue, Jan 17, 2006 at 01:26:12AM +0100, Blaisorblade wrote:
I ran by accident scripts/checkstack.pl and found that slip_init and
slirp_init are two big offenders.
They are since of such lines:
*spri = ((struct slip_data)
{ .name = { '\0' },
On Tue, Jan 17, 2006 at 02:22:59AM +0100, Blaisorblade wrote:
On Monday 16 January 2006 18:14, Olaf Hering wrote:
It picks up the libc headers instead of the 2.6.15 ones.
Yep, that's correct, the bug is that shouldn't be using CONFIG_NR_CPUS.
No, I just fixed this. The bug is that
On Mon, Jan 16, 2006 at 10:45:04PM -0500, Jeff Dike wrote:
No, I just fixed this. The bug is that chan_user.c includes kern_util.h,
which is a kernel-only header.
This is just plain wrong. The correct fix is to remove the kernel stuff
(the NR_CPUS as BB did, plus the struct task things
Hey baby,
This worldweb store is so hot right now! We MUST take a peek!
Yours forever,
Feng
-Original Message-
From: Jezoir [mailto:[EMAIL PROTECTED]
Sent: Monday, January 09, 2006 6:16 PM
To: Feng
Subject: It will definitely outdo other curative store's pricestickers.
Hey
12 matches
Mail list logo
