From: Miklos Szeredi
Fix the following compile error on UML.
arch/um/os-Linux/time.c: In function 'deliver_alarm':
arch/um/os-Linux/time.c:117:3: error: too few arguments to function
'alarm_handler'
arch/um/os-Linux/internal.h:1:6: note: declared here
The error was
From: Miklos Szeredi
Fix the following link error:
arch/um/sys-i386/built-in.o: In function `sys_call_table':
(.rodata+0x11c): undefined reference to `ptregs_fork'
arch/um/sys-i386/built-in.o: In function `sys_call_table':
(.rodata+0x140): undefined reference to `ptregs_execve&#x
From: Miklos Szeredi
Fix the following warnings:
arch/um/kernel/syscall.c: In function 'kernel_execve':
arch/um/kernel/syscall.c:130: warning: passing argument 1 of 'um_execve'
discards qualifiers from pointer target type
arch/um/kernel/syscall.c:130: warning: passing argu
BCC: miko
Subject: [patch 2/3] uml: fix link error from prefixing of i386 syscalls with
ptregs_
References:
--text follows this line--
From: Miklos Szeredi
Fix the following link error:
arch/um/sys-i386/built-in.o: In function `sys_call_table':
(.rodata+0x11c): undefined referen
From: Miklos Szeredi
Fix the following compile error:
arch/um/drivers/net_kern.c: In function 'uml_inetaddr_event':
arch/um/drivers/net_kern.c:760: error: 'struct net_device' has no member named
'open'
This was introduced by commit 8bb95b39, "uml: conv
On Mon, 23 Mar 2009, Ingo Molnar wrote:
> * Miklos Szeredi wrote:
>
> > This one incorporates comments from Oleg and Ingo. Please apply
> > to 2.6.29 and 2.6.2[78]-stable trees.
>
> The fix first needs to go upstream. There's an alternative patch
> below.
This one incorporates comments from Oleg and Ingo. Please apply to
2.6.29 and 2.6.2[78]-stable trees.
Thanks,
Miklos
From: Miklos Szeredi
This patch fixes bug #12208:
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12208
Subject : uml is very slow on 2.6.28 host
On Fri, 20 Mar 2009, Ingo Molnar wrote:
> > > The first line of attack for this problem is making
> > > wait_task_inactive() sucks less, which shouldn't be too hard,
> > > that unconditional 1 jiffy sleep is simply retarded.
> >
> > I completely agree. However, I'd like to have a non-invasive
On Thu, 19 Mar 2009, Roland McGrath wrote:
> I'm no scheduler expert and I don't know whether the exact placement in
> your change is the optimal one. But it's certainly fine from a ptrace
> perspective.
I'm no scheduler expert either.
Maybe a more generic solution in the scheduler (something li
On Fri, 20 Mar 2009, Peter Zijlstra wrote:
> On Fri, 2009-03-20 at 10:43 +0100, Miklos Szeredi wrote:
> > Ingo,
> >
> > I tested this one, and I think it makes sense in any case as an
> > optimization. It should also be good for -stable kernels.
> >
> >
Ingo,
I tested this one, and I think it makes sense in any case as an
optimization. It should also be good for -stable kernels.
Does it look OK?
Thanks,
Miklos
From: Miklos Szeredi
This patch fixes bug #12208:
http://bugzilla.kernel.org/show_bug.cgi?id=12208
Don't preempt tas
On Fri, 20 Mar 2009, Peter Zijlstra wrote:
> On Thu, 2009-03-19 at 23:23 +0100, Miklos Szeredi wrote:
> >
> > This patch solves this by not scheduling on preempt_enable() after
> > ptrace_stop() has woken up the tracer.
>
> Nice,.. however did you find this?
Ftrace
From: Miklos Szeredi
This patch fixes bug #12208.
This turned out to be not a scheduler regression, but an already
existing problem in ptrace being triggered by subtle scheduler
changes.
The problem is this:
- task A is ptracing task B
- task B stops on a trace event
- task A is woken up
On Sun, 21 Dec 2008, Peter Zijlstra wrote:
> On Fri, 2008-12-12 at 10:35 +0100, Miklos Szeredi wrote:
> > When the UML boot gets to the userspace part it gets really really
> > slow. It takes about 20 times the normal time to fully boot. CPU
> > seems to be idle.
> >
When the UML boot gets to the userspace part it gets really really
slow. It takes about 20 times the normal time to fully boot. CPU
seems to be idle.
Guest version doesn't matter. Host version 2.6.27 was OK, latest git
is not OK. I'm running 32bit guest on 64bit host.
Anyone else experiencing
> On Fri, Jan 18, 2008 at 03:42:54PM +0100, Miklos Szeredi wrote:
> > uml:~# grep arch_dup_mmap /proc/slab_allocators
> > size-32: 10861 arch_dup_mmap+0x9f/0x130
>
> Whoops - try the patch below.
Yup, that seems to have solved
On 2.6.24-rc8-mm1:
uml:~# grep arch_dup_mmap /proc/slab_allocators
size-32: 10861 arch_dup_mmap+0x9f/0x130
Miklos
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://c
> * Miklos Szeredi <[EMAIL PROTECTED]> wrote:
>
> > FASTCALL is defined empty in -mm, but UML is not compiled with
> > -mregparm=3 and so this breaks things (I noticed problems with
> > rwsem_down_write_failed).
> >
> > Tried recompiling UML with -
> FASTCALL is useless and should not make a difference. It enables
> regparm on specific functions, but that should not make a difference
> if it works or not.
__down_write() in include/asm-x86/rwsem.h seems to assume, that the
semaphore pointer is passed in %eax down to rwsem_down_write_failed(),
> Miklos Szeredi <[EMAIL PROTECTED]> writes:
>
> > FASTCALL is defined empty in -mm, but UML is not compiled with
> > -mregparm=3 and so this breaks things (I noticed problems with
> > rwsem_down_write_failed).
> >
> > Tried recompiling UML with -
FASTCALL is defined empty in -mm, but UML is not compiled with
-mregparm=3 and so this breaks things (I noticed problems with
rwsem_down_write_failed).
Tried recompiling UML with -mregparm=3, but that resulted in a strange
failure immediately after startup:
|%G�%@: Invalid argument
What's up
> > This is the one: uml-runtime-detection-of-host-vmsplit-on-i386.patch
> >
> > The relevant log line (both for successful and failed boots):
> >
> > Locating the top of the address space ... 0xffc0
>
> Thanks for narrowing it down. It turns out I can reproduce it with a
> defconfig, but i
> > 32bit UML, 64bit host, config attached.
>
> Hadn't tried that, but that works here too.
>
> I'll see if your config reproduces it.
>
> > Can't reproduce with plain -rc6.
>
> Feel like bisecting -mm1?
This is the one: uml-runtime-detection-of-host-vmsplit-on-i386.patch
The relevant log lin
> On Wed, Jan 02, 2008 at 06:53:00PM +0100, Miklos Szeredi wrote:
> > The below patch was needed to make UML compile in latest -mm.
>
> ACK on that - I've got the same patch on its way.
>
> > But sometimes it doesn't boot and does weird things (this i
The below patch was needed to make UML compile in latest -mm.
But sometimes it doesn't boot and does weird things (this is a sample
with init=/bin/bash):
[0.42] EXT3-fs: mounted filesystem with ordered data mode.
[0.42] VFS: Mounted root (ext3 filesystem) readonly.
(none):/# ls
(n
On 2.6.24, top started showing 100% iowait on one CPU when a UML
instance was running (but completely idle). I've traced it to this
commit. Reverting it cures the problem.
Miklos
commit 41d10da3717409de33d5441f2f6d8f072ab3fbb6
Author: Jeff Moyer <[EMAIL PROTECTED]>
Date: Tue Oct 16 23:27:20
Found some interesting things, the delays are caused by
1) throttle_vm_writeout()
I removed it, Andrew worries about that, but hopefully there's a
better solution to his worries
2) atime updates
my uml image did not have them turned off
3) UML timer tick does not seem very re
> > > to get symbolic stack backdumps for the wakeup points, and add
> > > trace_special_sym() calls to generate extra stackdump entries at
> > > arbitrary places. schedule() does not have it right now - it might
> > > make sense to add it.
> >
> > OK, this helped.
> >
> > It looks like the de
> > On Thu, Nov 29, 2007 at 11:19:40AM +0100, Miklos Szeredi wrote:
> > > date-7119 0 15636591us!: schedule (0 0)
> > > bash-502 0 15643908us!: schedule (0 0)
> > > bash-502 0 15646250us!: schedule (0 0)
> >
> > How ex
> > I can't say I'm understading these traces very well, but here's a
> > snippet that looks a bit strange. I'm running 'while true; do date;
> > done' in parallel with the dd.
> >
> > For some time it is doing 100% CPU as expected, then it goes into a
> > second or so of mosty idle (afaics),
> > I can't say I'm understading these traces very well, but here's a
> > snippet that looks a bit strange. I'm running 'while true; do date;
> > done' in parallel with the dd.
> >
> > For some time it is doing 100% CPU as expected, then it goes into a
> > second or so of mosty idle (afaics),
I can't say I'm understading these traces very well, but here's a
snippet that looks a bit strange. I'm running 'while true; do date;
done' in parallel with the dd.
For some time it is doing 100% CPU as expected, then it goes into a
second or so of mosty idle (afaics), and then returns to the nor
> > Something like:
> >
> > dd if=/host/tmp/bigfile of=/tmp/bigfile bs=1048576 count=100
> >
> > and run 'top' or 'watch something' in another terminal, which
> > sometimes completely stops updating during the write.
>
> Are you talking about missing updates for a few seconds, or for
> longer?
> > OK, managed to make it compile, but then something goes wrong in
> > tracer_alloc_bootmem().
>
> It needs 32M, and uml has that much by default. Doh.
>
> But something is still wrong:
>
> > /store/quilt/linux/linux mem=64
I'm an idiot, sorry. It should have been mem=64M. No wonder it
did
> OK, managed to make it compile, but then something goes wrong in
> tracer_alloc_bootmem().
It needs 32M, and uml has that much by default. Doh.
But something is still wrong:
> /store/quilt/linux/linux mem=64
Core dump limits :
soft - 0
hard - NONE
Checking that ptrace can chan
> so you can define irqs_off_flags to always-0 and you should be able to
> get pretty good traces still. It should have no functional impact.
OK, managed to make it compile, but then something goes wrong in
tracer_alloc_bootmem().
Jeff?
(attaching patch, which goes on top of
latency-tracer-v2.6
> > > On Wed, Nov 28, 2007 at 02:09:45PM +0100, Miklos Szeredi wrote:
> > > > kernel/latency_trace.c:28:21: error: asm/rtc.h: No such file or
> > > > directory
> > >
> > > For things like this, look at the host's asm/foo.h and see if it&
> On Wed, Nov 28, 2007 at 02:09:45PM +0100, Miklos Szeredi wrote:
> > kernel/latency_trace.c:28:21: error: asm/rtc.h: No such file or directory
>
> For things like this, look at the host's asm/foo.h and see if it's
> usable in UML (and contains things that you need).
> > When writing a big file to a ubd disk, everything in uml slows down to
> > a crawl, even though CPU usage is minimal.
>
> What exactly is your test case?
Something like:
dd if=/host/tmp/bigfile of=/tmp/bigfile bs=1048576 count=100
and run 'top' or 'watch something' in another terminal, wh
> > > CC kernel/latency_trace.o
> > > kernel/latency_trace.c:28:21: error: asm/rtc.h: No such file or directory
> > > kernel/latency_trace.c:63:3: error: #error Implement cycles_to_usecs.
> > > kernel/latency_trace.c: In function ???trace???:
> > > kernel/latency_trace.c:658: error: impl
> * Miklos Szeredi <[EMAIL PROTECTED]> wrote:
>
> > When writing a big file to a ubd disk, everything in uml slows down to
> > a crawl, even though CPU usage is minimal.
> >
> > So I wanted to try the latency tracer from -rt, but it doesn't compil
When writing a big file to a ubd disk, everything in uml slows down to
a crawl, even though CPU usage is minimal.
So I wanted to try the latency tracer from -rt, but it doesn't compile
with UML:
CC arch/um/kernel/asm-offsets.s
In file included from arch/um/include/sysdep/kernel-offsets.h:2
> On Tue, 27 Nov 2007 17:20:20 -0500 Jeff Dike <[EMAIL PROTECTED]> wrote:
>
> > On Tue, Nov 27, 2007 at 09:29:23PM +0100, Miklos Szeredi wrote:
> > > Sure. The patch works for me, but please check that it also makes
> > > sense.
> >
> > I did - it
> On Tue, Nov 27, 2007 at 07:26:38PM +0100, Miklos Szeredi wrote:
> > + kfree(io_req);
>
> Whoops, nice catch.
>
> Can you sign that off for me?
Sure. The patch works for me, but please check that it also makes
sense.
Signed-off-by: Miklos Szer
> There seems to be no corruption though. Looking at the code, I can't
> see how the requests could leak...
Didn't look close enough.
Index: linux/arch/um/drivers/ubd_kern.c
===
--- linux.orig/arch/um/drivers/ubd_kern.c 2007-1
When writing big files on 2.6.24-rc3-mm1, there can be substiantial
number of leaked requests (CONFIG_DEBUG_SLAB_LEAK enabled):
# cat /proc/slab_allocators |grep do_ubd_request
size-128: 25687 do_ubd_request+0xe0/0x19d
There seems to be no corruption though. Looking at the code, I can't
see how
> On Wed, Nov 14, 2007 at 04:26:11PM +0100, Miklos Szeredi wrote:
> > This one fixed the EINVAL messages, and now UML boots, but consumes
> > 100% CPU constantly.
>
> Can you disable NO_HZ and try the patch below, which WorksForMe (TM)?
Yes, it fixes the busy looping fo
> On Thu, Nov 22, 2007 at 07:08:47PM +0100, Miklos Szeredi wrote:
> > Thanks. My other problem is (probably you are aware) that recent -mm
> > kernels don't compile for UML.
>
> The patch below fixes the build for rc3-mm1 for me.
Yeah, I got as far as that (sorry a
> On Wed, Nov 14, 2007 at 10:29:57PM +0100, Miklos Szeredi wrote:
> > Config attached.
>
> Thanks - this reproduces it for me.
>
> BTW, you can work around this by enabling NO_HZ.
Thanks. My other problem is (probably you are aware) that recent -mm
kernels don'
> > This one fixed the EINVAL messages, and now UML boots, but consumes
> > 100% CPU constantly.
>
> Can you strace it and see if you are seeing zero-length nanosleeps,
> and then send me your config file? I've had one other report of this,
> but haven't reproduced it here.
Yes:
nanosleep({0, 0
> > Note, this is 32bit UML on 64bit host, to complicate matters. So I
> > think it's not PTRACE_ARCH_PRCTL, but PTRACE_SET_THREAD_AREA.
>
> Oh, that changes things. In this case, I believe this problem is fixed
> by fd181c72a3c202a3986bcee7551c0838265aec2a.
This one fixed the EINVAL messages,
> On Wed, Nov 14, 2007 at 12:32:43AM +0100, Miklos Szeredi wrote:
> > UML doesn't run on 2.6.24-rc2 as host (config attached). Guest is
> > 2.6.23-mm1, but I guess it's irrelevant. 2.6.23 as host was OK.
> >
> > When booting there are zillions of lines
UML doesn't run on 2.6.24-rc2 as host (config attached). Guest is
2.6.23-mm1, but I guess it's irrelevant. 2.6.23 as host was OK.
When booting there are zillions of lines like this:
"arch_switch_tls failed, errno = EINVAL"
then it finally fails with:
"BUG: spinlock cpu recursion on CPU#0, sys
I get errors in uml when writing to the xterm console. For example if I do
$ cat bigfile
[some output]
cat: write error: Operation not permitted
This is 2.6.23-rc1-mm2, I haven't yet checked other versions.
Miklos
-
This
From: Miklos Szeredi <[EMAIL PROTECTED]>
These haven't been fixed for ages. Just make comments out of them.
arch/um/kernel/skas/process.c:181:2: warning: #warning Need to look up
userspace_pid by cpu
arch/um/kernel/skas/process.c:187:2: warning: #warning Need to look up
userspace
From: Miklos Szeredi <[EMAIL PROTECTED]>
I get lot's of these on i386:
In file included from include/asm/atomic.h:10,
from include/linux/file.h:9,
from mm/fadvise.c:12:
include/asm/arch/atomic.h: In function ‘atomic_add_unless’:
include/asm/arch/a
> > Strangely enough after continuing in gdb, UML is back to normal, and I
> > can't make it hang any more. It must be something timing related.
>
> Can you see if the patch below fixes it?
Yay! Got my nice fast UML back instead of ugly slow QEmu ;)
Seems to work perfectly now.
Thanks,
Miklos
> No, it doesn't. This is a strace on the host, I take it?
Yes.
> Can you get backtraces from the processes?
Here's one:
#0 0xe410 in __kernel_vsyscall ()
#1 0xb7f0fbc3 in write () from /lib/tls/i686/cmov/libc.so.6
#2 0x08066f52 in file_io (fd=10, buf=0x8a0fc8b, len=1,
io_proc=0x805
Hi Jeff,
I'm having problems using 2.6.20 UML. It's a long time I last tried,
so don't know which version this started with.
It boots fine, then usually just after logging in and before starting
the shell (but sometimes after the shell started) it gets into some
loop. Looking at the strace show
UML now compiles on 2.6.17-rc4-mm3, but it fails to boot:
[...]
kinit: do_mounts
kinit: name_to_dev_t(98:0) = dev(0,0)
kinit: root_dev = dev(0,0)
kinit: trying to mount /dev/root on /root with type ext3
kinit: Cannot open root device dev(0,0)
[...]
Adding 'root=ubda' to the command line cures it.
[resent because prev. post bounced on hpa and akpm due to mail problems here]
I get this on 2.6.17-rc4-mm1:
CHK include/linux/compile.h
/usr/src/quilt/linux/scripts/Kbuild.klibc:60:
/usr/src/quilt/linux/usr/klibc/arch/um/MCONFIG: No such file or directory
usr/klibc/Kbuild:71: usr/klibc/arc
I get this on 2.6.17-rc4-mm1:
CHK include/linux/compile.h
/usr/src/quilt/linux/scripts/Kbuild.klibc:60:
/usr/src/quilt/linux/usr/klibc/arch/um/MCONFIG: No such file or directory
usr/klibc/Kbuild:71: usr/klibc/arch/um/Makefile.inc: No such file or directory
make[2]: *** No rule to make targe
> > I'm proud to announce a new version of my pet project 'mountlo', a
> > utility which works similarly to 'mount -o loop', but the filesystem
> > runs entirely in userspace.
> >
> > While arguably it is quite useless, I like it because it combines some
> > of my favorite technologies (Linux, UML
I'm proud to announce a new version of my pet project 'mountlo', a
utility which works similarly to 'mount -o loop', but the filesystem
runs entirely in userspace.
While arguably it is quite useless, I like it because it combines some
of my favorite technologies (Linux, UML and FUSE) with very lit
> > Here is a patch to correct a compile error on linux 2.6.12-rc4-mm2 for uml.
> > At the compilation of init/main.c, it complains because it doens't find
> > the 2 constants FIXADDR_USER_START and FIXADDR_USER_END
> Why deleting FIXADDR_START? Also FIXADDR_USER_* are defined, just in a
> differe
65 matches
Mail list logo
