On Monday 20 June 2005 19:59, William Stearns wrote:
> Good afternoon, all,
>
> On Mon, 20 Jun 2005, Jeff Dike wrote:
> > On Thu, Jun 16, 2005 at 03:36:24PM -0700, Anthony Brock wrote:
> >> Second, I'm once again enountering problems with launch the UML
> >> instance. It likes to hang at:
> >>
> >>
On Mon, Jun 20, 2005 at 10:19:12AM -0700, Anthony Brock wrote:
> Strange. This option doesn't seem to be available. I'm seeing the following
> in my .config file:
> # Hardware I/O ports
> #
> # CONFIG_SERIO is not set
It would have been here if you didn't have CONFIG_SERIO disabled. So that's
Good afternoon, all,
On Mon, 20 Jun 2005, Jeff Dike wrote:
On Thu, Jun 16, 2005 at 03:36:24PM -0700, Anthony Brock wrote:
Second, I'm once again enountering problems with launch the UML instance. It
likes to hang at:
Checking that ptrace can change system call numbers...OK
Checking syscall
Strange. This option doesn't seem to be available. I'm seeing the following in
my .config file:
*** BEGIN .config EXCERPT ***
#
# CONFIG_INPUT_KEYBOARD is not set
# CONFIG_INPUT_MOUSE is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
# CONFIG_INPUT_MISC is not se
On Thu, Jun 16, 2005 at 03:36:24PM -0700, Anthony Brock wrote:
> Second, I'm once again enountering problems with launch the UML instance. It
> likes to hang at:
>
>
> Checking that ptrace can change system call numbers...OK
> Checking syscall emulation patch for ptrace...OK
> Checking advanced
On Thu, Jun 16, 2005 at 03:59:24PM -0700, Anthony Brock wrote:
> Program received signal SIGSEGV, Segmentation fault.
> 0x080b86d0 in __vmalloc_area (area=0xbd15be0, gfp_mask=210, prot={pgprot =
> 0}) at string.h:363
Segfaults in vmalloc are completely normal. They are just page faults.
> BUG:
On Friday 17 June 2005 00:23, Jeff Dike wrote:
> 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
On Friday 17 June 2005 02:35, Jeff Dike wrote:
> 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
> o
Jeff Dike wrote:
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
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 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
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
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
24 matches
Mail list logo
