On Thu, Jun 16, 2005 at 08:09:34PM +0200, Blaisorblade wrote:
> +struct task_struct;
> +extern void arch_switch(struct task_struct *from, struct task_struct *to);
Is the task_struct; needed, considering that there is get_task returning
one a few lines higher?
> + /* XXX: This is bogus, it's a
I don't know if this is of interest, but I encountered the following while
trying to recreate the freeze. However, the UML will continue to load following
this error. For some reason, the freeze doesn't seem repeatable while under the
debugger (sigh). Here is the interesting GDB bug:
INIT: Ent
Okay, two items of interest:
First, both instances are running the "rngd" daemon for random support.
However, this daemon seems to be consuming between 8-15% of the CPU time on a
consistent basis. Even after running for 20-30 minutes, the daemon is till busy.
Second, I'm once again enountering
On Thu, Jun 16, 2005 at 03:49:43PM -0400, William Stearns wrote:
> Good afternoon, all,
> With a FC2 x86_64 host with no skas patch (stock RH kernel) and no
> tmpfs, I find that a 2.6.6 uml vm (happens to be i386 slackware) keeps
> getting more and more pids out on the host. By mounting /t
On Thu, Jun 16, 2005 at 08:51:20PM +0200, Blaisorblade wrote:
> > And also it makes tt a bit more removable, if Jeff decides to.
> Well, on this point I'd be cautious.
>
> Currently there is no way to even test UML in SMP mode other than using TT
> mode, so at least this must be solved.
Yeah, we
On Thu, Jun 16, 2005 at 02:26:13PM -0700, Anthony Brock wrote:
> Well, so far this seems to be running fine. However, I'm still
> seeing the load average >= 1 issue. This is a 2.6.12-rc6-mm1 host with
> your patches from this morning running on a 2.6.11.7-skas3-v8 custom
> built host kernel.
OK,
Well, so far this seems to be running fine. However, I'm still seeing the load
average >= 1 issue. This is a 2.6.12-rc6-mm1 host with your patches from this
morning running on a 2.6.11.7-skas3-v8 custom built host kernel.
I'll keep at eye on perform over the next few days.
Tony
>>> Jeff Dike
Good afternoon, all,
With a FC2 x86_64 host with no skas patch (stock RH kernel) and no
tmpfs, I find that a 2.6.6 uml vm (happens to be i386 slackware) keeps
getting more and more pids out on the host. By mounting /tmp as tmpfs,
this effect goes away; the vm stays around 140 pids and doesn't
On Thursday 16 June 2005 20:40, Bodo Stroesser wrote:
> Blaisorblade wrote:
> > On Thursday 16 June 2005 20:31, Bodo Stroesser wrote:
> >>Blaisorblade wrote:
> >>>arch_switch already exists (wasn't used for SKAS). About improving it
> >>> and making it more "general-purpose" (I've written this for
Blaisorblade wrote:
On Thursday 16 June 2005 20:31, Bodo Stroesser wrote:
Blaisorblade wrote:
arch_switch already exists (wasn't used for SKAS). About improving it and
making it more "general-purpose" (I've written this for the TLS code
needs), could you have a look to the attached patches? d
On Thursday 16 June 2005 20:31, Bodo Stroesser wrote:
> Blaisorblade wrote:
> > arch_switch already exists (wasn't used for SKAS). About improving it and
> > making it more "general-purpose" (I've written this for the TLS code
> > needs), could you have a look to the attached patches? do_fork-* is
Blaisorblade wrote:
arch_switch already exists (wasn't used for SKAS). About improving it and
making it more "general-purpose" (I've written this for the TLS code needs),
could you have a look to the attached patches? do_fork-* is another thing (a
cleanup discussed some time ago with Jeff) but
On Thursday 16 June 2005 19:55, Bodo Stroesser wrote:
> Jeff Dike wrote:
> > I'll fix things accordingly.
> Could you please make handling in switch_to subarch-specific,
> e.g. in arch_switch_to?
arch_switch already exists (wasn't used for SKAS). About improving it and
making it more "general-pur
Bodo Stroesser wrote:
Jeff Dike wrote:
I'll fix things accordingly.
Could you please make handling in switch_to subarch-specific,
e.g. in arch_switch_to?
s390 might have some special handling for fpregs and debug-regs
in a single syscall.
Bodo
Oh, I guess I forgot to add ptrace to the l
Jeff Dike wrote:
I'll fix things accordingly.
Could you please make handling in switch_to subarch-specific,
e.g. in arch_switch_to?
s390 might have some special handling for fpregs and debug-regs
in a single syscall.
Bodo
---
SF.Net
On Thu, Jun 16, 2005 at 07:36:57PM +0200, Bodo Stroesser wrote:
> Reading the patches
> only the one that makes me worry is "dont-save-fpregs".
> To not save fpregs on every syscall or interrupt is O.K.
> But you also have to modify signal-handling, that currently relies on
> fpregs being saved. An
Title: UML patch for red hat entreprise 3.0
Does anyone have a patch for red hat enterprise 3.0?
Majid.
Jeff Dike wrote:
I'd like to call attention to some recent patches that may be of interest
to people before they hit mainline. These are all on my incremental patches
page, http://user-mode-linux.sf.net/patches.html
First, sched-starve
(http://user-mode-linux.sourceforge.net/work/current/2.6/2
I'd like to call attention to some recent patches that may be of interest
to people before they hit mainline. These are all on my incremental patches
page, http://user-mode-linux.sf.net/patches.html
First, sched-starve
(http://user-mode-linux.sourceforge.net/work/current/2.6/2.6.12-rc6-mm1/patch
19 matches
Mail list logo
