I've spent some time working on the ubd and AIO problems that have cropped up
recently. Patches are attached - a critical look at them would be appreciated.
I'm going to start with a problem that hasn't exactly cropped up, and move on
to the other ones from there.
That is that the ubd driver mu
On Sat, Sep 17, 2005 at 07:15:19PM +0100, Antoine Martin wrote:
> Here is the repeated message:
> [42977981.36] Badness in local_bh_enable at kernel/softirq.c:140
> [42977981.36] a037f6c0: [] dump_stack+0x1e/0x20
> [42977981.36] a037f6e0: [] local_bh_enable+0x6c/0x90
> [42977981.36000
> Sorry, was talking about UML. But I assume it locks up. Was SMP enabled? In
> that case, there's a couple of things in -bs1 (just published) which may help
> it.
Initial testing reveals (one just one x86 box so far), that the kernel
stops booting right after:
Checking PROT_EXEC mmap in /tmp...O
> > It stopped complaining at about mem=200M (roughly IIRC)
> Well, that's too low, so yes, there's some problem. Especially because memory
> is shrunk down to 28M...
>
> Which is the host distro? Having a RH/Fc could be a cause (I don't know the
> current situation with these).
That box is a Ma
BTW, that ldt patch can go straight to mainline if it's not on its way
already.
Jeff
---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -a
On Sat, Sep 17, 2005 at 05:34:36PM +0200, Blaisorblade wrote:
> In fact, beyond this problem, we also fail to check whether the faulting
> address is under TASK_SIZE in TT mode on read accesses:
>
> #define access_ok_tt(type, addr, size) \
> ((type == VERIFY_READ) || (segment_eq(get_fs(),
On Friday 16 September 2005 12:40, [EMAIL PROTECTED] wrote:
>
> Hi, Blaisorblade:
> I have spend some time to test recent uml 2.6.13, and find that
> recent uml have improved at some aspect, but still have some potential
> problem at syscall, mainly because weakly check, the attchement
> incl
On Friday 16 September 2005 22:12, antoine wrote:
> > > UML running in SKAS3 mode
> > > Checking PROT_EXEC mmap in /tmp...OK
> > > Kernel virtual memory size shrunk to 28311552 bytes
> >
> > This is running in SKAS3 mode - see message. However, the problem may be
> > TT in the meaning you'd better
