Bodo Stroesser wrote:
Working with the new UML skas0 mode on my Xeon HT host, sporadically I saw
some processes on UML segfaulting.
In all cases, I could track this down to be caused by a gs segment
register,
that had the wrong contents.
This again is caused by a problem in the host linux: A ptra
Ingo Molnar wrote:
* Nick Piggin <[EMAIL PROTECTED]> wrote:
When a task is put to sleep, it is dequeued from the runqueue
while it is still running. The problem is that the runqueue
lock can be dropped and retaken in schedule() before the task
actually schedules off, and wait_task_inacti
Nick Piggin wrote:
Ingo Molnar wrote:
* Nick Piggin <[EMAIL PROTECTED]> wrote:
When a task is put to sleep, it is dequeued from the runqueue
while it is still running. The problem is that the runqueue
lock can be dropped and retaken in schedule() before the task
actually schedules of
Bodo Stroesser wrote:
Nick Piggin wrote:
Bodo Stroesser wrote:
I don't see how this could help because AFAIKS, child->saving is only
set and cleared while the runqueue is locked. And the same runqueue lock
is taken by wait_task_inactive.
Sorry, that not right. There are some routines c
Andrew Morton wrote:
Nick Piggin <[EMAIL PROTECTED]> wrote:
Bodo Stroesser wrote:
Nick Piggin wrote:
Bodo Stroesser wrote:
I don't see how this could help because AFAIKS, child->saving is only
set and cleared while the runqueue is locked. And the same runqueue lock
is taken by wait
Nick Piggin wrote:
Andrew Morton wrote:
Nick Piggin <[EMAIL PROTECTED]> wrote:
Andrew, IMO this is another bug to hold 2.6.11 for.
Sure. I wouldn't consider Bodo's patch to be the one to use though..
No. Something similar could be done that works on all architectures
and all wa
Nick Piggin wrote:
Something like the following (untested) extension of Bodo's work
could be the minimal fix for 2.6.11. As I've said though, I'd
consider it a hack and prefer to do something about the locking.
That could be done after 2.6.11 though. Depends how you feel.
I think th
Blaisorblade wrote:
On Wednesday 23 March 2005 18:09, Bodo Stroesser wrote:
[EMAIL PROTECTED] wrote:
Use rep_nop instead of barrier for cpu_relax, following $(SUBARCH)'s
doing that (i.e. i386 and x86_64).
IIRC, Jeff had the idea, to use sched_yield() for this (from a discussion
on #uml).
Hmm, makes
Rusty Russell wrote:
On Sat, 2005-05-07 at 23:57 +0530, Srivatsa Vaddagiri wrote:
Two solutions have been proposed so far:
A. As per Nick's suggestion, impose a max limit (say some 100 ms or
say a second, Nick?) on how long a idle CPU can avoid taking
Yeah probably something arou
Srivatsa Vaddagiri wrote:
On Sun, May 08, 2005 at 02:14:23PM +1000, Nick Piggin wrote:
Yeah probably something around that order of magnitude. I suspect
there will fast be a point where either you'll get other timers
going off more frequently, and / or you simply get very quickly
dimini
Russell King wrote:
On Fri, Aug 12, 2005 at 08:21:45PM +0200, [EMAIL PROTECTED] wrote:
@@ -632,10 +632,11 @@ static inline int page_mapped(struct pag
* Used to decide whether a process gets delivered SIGBUS or
* just gets major/minor fault counters bumped up.
*/
-#define VM_FAULT_OOM (-1)
Jeff Dike wrote:
> The libc free wrapper wasn't correctly detecting buffers obtained with
> malloc(). This is now done by seeing if the page was reserved. This is
> the case for memory which is left aside for libc and isn't given to
> the page allocator. If we free a pointer in a reserved page,
On Thursday 05 March 2009 04:50:31 Jan Kara wrote:
> On Wed 04-03-09 16:55:35, Jan Kara wrote:
> > On Wed 04-03-09 15:51:09, Jan Kara wrote:
> > > first, I'd like to point out that this has happened under UML so it
> > > can be just some obscure bug in that architecture but I belive it's
> > > wo
On Thursday 05 March 2009 21:05:16 Jan Kara wrote:
> On Thu 05-03-09 13:55:43, Nick Piggin wrote:
> > On Thursday 05 March 2009 04:50:31 Jan Kara wrote:
> > > On Wed 04-03-09 16:55:35, Jan Kara wrote:
> > > > On Wed 04-03-09 15:51:09, Jan Kara wrote:
> > >
14 matches
Mail list logo
