[uml-user] UML crash at shutdown

[Jan Evert van Grootheest <j.e.van.grootheest@hc...>]

Hi,

One UML instance I stopped got this in its log (screen is a useful 
thing...).
I don't understand what's going on, but I thought I'd report it, hoping 
it allows you to improbe UML.

By the way, this is self compiled from vanilla 2.6.11.6. I think I 
cannot provide the kernel configuration because the disk it was compiled 
on crashed. But I can tell you that it is a monolithic kernel, no module 
support.
Also, this UML (single CPU) has 58M assigned to it on a 128M host (dual 
PII, debian testing).

Thanks,
Jan Evert

PS: I'm not subscribed

Stopping apt-proxy [wait 1 2 3Kernel panic - not syncing: Kernel mode 
fault at addr 0x8, ip 0xa001fe59

EIP: 0073:[<a001fe59>] CPU: 0 Not tainted ESP: 007b:a1b237bc EFLAGS: 
00010292
     Not tainted
EAX: 00000008 EBX: a091d000 ECX: a1b237eb EDX: 00000008
ESI: a0926540 EDI: a142c2e8 EBP: a1b237d4 DS: 007b ES: 007b
Call Trace:
a1b23330:  [<a00482ad>] notifier_call_chain+0x2d/0x50
a1b23350:  [<a00362d2>] panic+0x72/0x120
a1b23364:  [<a001fe59>] chan_window_size+0x9/0x50
a1b23370:  [<a00172b1>] segv+0x241/0x280
a1b2337c:  [<a001fe59>] chan_window_size+0x9/0x50
a1b233e0:  [<a0015322>] change_signals+0x62/0x90
a1b23460:  [<a0017695>] segv_handler+0x175/0x230
a1b23468:  [<a001fe59>] chan_window_size+0x9/0x50
a1b23490:  [<a001b731>] sig_handler_common_tt+0x91/0x110
a1b2349c:  [<a00131d0>] copy_to_user_proc+0x0/0x50
a1b234d0:  [<a002ccf2>] sig_handler+0x22/0x40
a1b234e0:  [<a0151d28>] __restore+0x0/0x8
a1b23520:  [<a001fe59>] chan_window_size+0x9/0x50
a1b23544:  [<a0151e54>] sigemptyset+0x24/0x40
a1b23558:  [<a00154d1>] set_signals+0x81/0x130
a1b23614:  [<a0151e54>] sigemptyset+0x24/0x40
a1b2362c:  [<a0169dab>] tcgetattr+0x6b/0xa0
a1b23658:  [<a002bf44>] file_io+0x24/0x90
a1b23678:  [<a002c021>] os_write_file+0x31/0x40
a1b23688:  [<a0169050>] __libc_write+0x0/0x60
a1b2368c:  [<a00131d0>] copy_to_user_proc+0x0/0x50
a1b23698:  [<a00288cb>] do_ubd_request+0x6b/0xc0
a1b236f4:  [<a0151e54>] sigemptyset+0x24/0x40
a1b23708:  [<a0015322>] change_signals+0x62/0x90
a1b23718:  [<a0027474>] ubd_handler+0x124/0x140
a1b23778:  [<a002bf44>] file_io+0x24/0x90
a1b23798:  [<a002bfe1>] os_read_file+0x31/0x40
a1b237a8:  [<a0168ff0>] __libc_read+0x0/0x60
a1b237ac:  [<a0013220>] copy_from_user_proc+0x0/0x50
a1b237d8:  [<a00219ac>] winch_interrupt+0x5c/0xd0
a1b237f8:  [<a0056223>] handle_IRQ_event+0x33/0x80
a1b23828:  [<a005631b>] __do_IRQ+0xab/0xf0
a1b23840:  [<a00154d1>] set_signals+0x81/0x130
a1b23858:  [<a000fd30>] do_IRQ+0x30/0x40
a1b23868:  [<a000feca>] sigio_handler+0xda/0x140
a1b23888:  [<a001b731>] sig_handler_common_tt+0x91/0x110
a1b238c8:  [<a002ccf2>] sig_handler+0x22/0x40
a1b238d8:  [<a0151d28>] __restore+0x0/0x8
a1b23918:  [<a0151d82>] sigprocmask+0x22/0x50
a1b23980:  [<a002bf44>] file_io+0x24/0x90
a1b239a0:  [<a002ca70>] os_kill_process+0x20/0x70
a1b239b0:  [<a0169050>] __libc_write+0x0/0x60
a1b239c0:  [<a0019433>] switch_to_tt+0x203/0x230
a1b23a00:  [<a01969d5>] schedule+0x2d5/0x4f0
a1b23a70:  [<a00391a8>] do_exit+0x188/0x350
a1b23ac0:  [<a003940d>] do_group_exit+0x4d/0xf0
a1b23b00:  [<a00464bf>] get_signal_to_deliver+0x26f/0x3f0
a1b23b3c:  [<a0151e54>] sigemptyset+0x24/0x40
a1b23b50:  [<a00154d1>] set_signals+0x81/0x130
a1b23b80:  [<a0015322>] change_signals+0x62/0x90
a1b23bc0:  [<a0015322>] change_signals+0x62/0x90
a1b23c60:  [<a0015382>] unblock_signals+0x12/0x20
a1b23c70:  [<a00329e7>] finish_task_switch+0x27/0x70
a1b23c90:  [<a0032a4a>] schedule_tail+0x1a/0x190
a1b23cb0:  [<a001aab1>] force_flush_all_tt+0x71/0x80
a1b23cd0:  [<a0019853>] finish_fork_handler+0x163/0x170
a1b23d20:  [<a0151d28>] __restore+0x0/0x8

Re: [uml-user] host skas patch for Debian 2.6.11

[Dick Middleton <gmane@li...>]

Blaisorblade wrote:
> On Saturday 07 May 2005 21:24, Dick Middleton wrote:
> 
>>Anybody got a patch for host skas which works for the Debian 2.6.11
>>kernel source?  The 2,6,10 patch fails with 2.6.11.
> 
> Yes, the 2.6.10 patch fails even with vanilla 2.6.11. Try the one for vanilla 
> 2.6.11, no?

Scrub last message (slight misunderstanding) - no I've not tried plain 
vanilla kernel yet.

Dick

[uml-user] Re: 32bit uml guest kernel on 64bit host

[Antoine Martin <antoine@na...>]

> > Also, will there be a performance benefit from running uml 32bit guest on a
> > 64bit host (now or planned?)
> Difficult question... the host OS will anyway run faster and that will benefit 
> a bit UML, but I don't know how much that is. However, for now you have the 
> big disadvantage that SKAS does not run on x86-64 hosts, so you loose the 
> possibility to run in SKAS mode.
Without skas, there is no point in having a x86-64 host, the TT
performance is quite bad compared to a (even slower) x86 host with skas.
skas0 looks promising, but at the moment it locks up hard on x86_64.

Antoine

[uml-user] pcap transport and bridging?

[Antoine Martin <antoine@na...>]

I can't figure out how to use the pcap transport within a working
bridged environment: do I need a dedicated interface on the host to
attach to or can I reuse an interface already bound to a bridge?
I've got 'eth0 up promisc' on the host, attached to a bridge, I want to
start a UML instance with pcap transport to have access to all the
packets on the bridge, so I thought I would do: eth0=pcap,eth0,promisc
But the interface does not show up in the guest, am I missing something
or is there another way of achieving the same thing?
I can attach a normal tun/tap promiscuous interface to the bridge but
that is no use, it will not get all packets as the bridge will discard
any packets not destined to its mac address.

Thanks
Antoine

[uml-user] Re: 32bit uml guest kernel on 64bit host

[Blaisorblade <blaisorblade@ya...>]

On Sunday 08 May 2005 00:48, Chas Wareing wrote:
> Good Afternoon Blaisorblade --
>
> Wanted to run something quick past you -
>
> Can one compile a 32bit guest kernel on a 64bit host using SKAS/SYSEMU?
> Special options?
Something like SUBARCH=i386 CFLAGS=-m32 LDFLAGS=-m32 should more or less do 
the job... However I'm not sure of this, maybe some more tricks are needed.

> Here is the error during "make ARCH=um"
> gcc -Wall -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing
> -fno-common -ffreestanding -O2 -fno-omit-frame-pointer -g -U__x86_64__
> -fno-builtin -D__arch_um__ -DSUBARCH=\"x86_64\" -Iarch/um/include 
> -I/usr/src/uml-kernel/linux-2.6.11/arch/um/kernel/tt/include 
> -I/usr/src/uml-kernel/linux-2.6.11/arch/um/kernel/skas/include -D__x86_64__
> -D_GNU_SOURCE -D_LARGEFILE64_SOURCE  -c -o arch/um/kernel/process.o
> arch/um/kernel/process.c arch/um/kernel/process.c: In function
> `check_sysemu':
> arch/um/kernel/process.c:262: error: `RAX' undeclared (first use in this
> function) arch/um/kernel/process.c:262: error: (Each undeclared identifier
> is reported only once arch/um/kernel/process.c:262: error: for each
> function it appears in.) arch/um/kernel/process.c:288: error: `ORIG_RAX'
> undeclared (first use in this function) arch/um/kernel/process.c: In
> function `check_ptrace':
> arch/um/kernel/process.c:339: error: `ORIG_RAX' undeclared (first use in
> this function) make[1]: *** [arch/um/kernel/process.o] Error 1
> make: *** [arch/um/kernel] Error 2
The above command is trying to compile a 64-bit guest. Probably you should do 
a "make clean" or even a mrproper (save your .config!) to make it succeed.


> Also, will there be a performance benefit from running uml 32bit guest on a
> 64bit host (now or planned?)
Difficult question... the host OS will anyway run faster and that will benefit 
a bit UML, but I don't know how much that is. However, for now you have the 
big disadvantage that SKAS does not run on x86-64 hosts, so you loose the 
possibility to run in SKAS mode.
-- 
Paolo Giarrusso, aka Blaisorblade
Skype user "PaoloGiarrusso"
Linux registered user n. 292729
http://www.user-mode-linux.org/~blaisorblade

Re: [uml-user] Re: UML/x86_64

[Antoine Martin <antoine@na...>]

On Sat, 2005-05-07 at 17:53 +0200, Blaisorblade wrote:
> On Friday 06 May 2005 19:38, Antoine Martin wrote:
> > Now, I've hit some real problems. I've managed to crash the host twice
> > within a short period of time.
> 
> > I captured the messages from a serial 
> > console the second time
> Would you check that you haven't got an hardware problem?
It is repeatable and Andi Kleen says it is a kernel bug, he is working
on a fix. See LKML for details:
http://lkml.org/lkml/2005/5/8/47/index.html

> The stack traces you get come from kernelspace tasks (one is named "kernel-4", 
> the other is "events/0"). And they have nothing in common with each other, 
> and come from a vanilla kernel (i.e. we haven't a SKAS patch to blame :-)).
> 
> > (it seems that you only need to generate some 
> > load to trigger this bug - I was compiling some code with gcc):
> You need to do that *inside* UML to generate the bug?
Yep, it is pretty easy to trigger.

Antoine

Re: [uml-user] host skas patch for Debian 2.6.11

[Blaisorblade <blaisorblade@ya...>]

On Saturday 07 May 2005 21:24, Dick Middleton wrote:
> Anybody got a patch for host skas which works for the Debian 2.6.11
> kernel source?  The 2,6,10 patch fails with 2.6.11.
Yes, the 2.6.10 patch fails even with vanilla 2.6.11. Try the one for vanilla 
2.6.11, no?
-- 
Paolo Giarrusso, aka Blaisorblade
Skype user "PaoloGiarrusso"
Linux registered user n. 292729
http://www.user-mode-linux.org/~blaisorblade

Re: [uml-user] Re: UML/x86_64

[Blaisorblade <blaisorblade@ya...>]

On Friday 06 May 2005 19:38, Antoine Martin wrote:
> Now, I've hit some real problems. I've managed to crash the host twice
> within a short period of time.

> I captured the messages from a serial 
> console the second time
Would you check that you haven't got an hardware problem?

The stack traces you get come from kernelspace tasks (one is named "kernel-4", 
the other is "events/0"). And they have nothing in common with each other, 
and come from a vanilla kernel (i.e. we haven't a SKAS patch to blame :-)).

> (it seems that you only need to generate some 
> load to trigger this bug - I was compiling some code with gcc):
You need to do that *inside* UML to generate the bug?
-- 
Paolo Giarrusso, aka Blaisorblade
Skype user "PaoloGiarrusso"
Linux registered user n. 292729
http://www.user-mode-linux.org/~blaisorblade

Re: [uml-user] LiveCD and UML

[Blaisorblade <blaisorblade@ya...>]

On Friday 06 May 2005 15:12, Jason Clark wrote:
> SHould be possible using COW files.  Create your bootable CD, then create
> a COW file that exists on the CD. Then, mount a partion as tmpfs and place
> your RW file there. You will have to create the RW file at every boot
> obviously.

> I wonder if you could just mount /dev/rd/0 as ubd0. That would be pretty
> neat.
Technically it should be feasible, but IMHO it's not a good idea, at most you 
could use that as COW file; copying the whole UBD over a non-swappable 
ramdisk is slow and bad (while tmpfs is swappable memory, and both ramdisks 
and the ramfs filesystem, again, are not).
-- 
Paolo Giarrusso, aka Blaisorblade
Skype user "PaoloGiarrusso"
Linux registered user n. 292729
http://www.user-mode-linux.org/~blaisorblade

Re: [uml-user] Re: UML/x86_64

[Blaisorblade <blaisorblade@ya...>]

On Friday 06 May 2005 17:09, Antoine Martin wrote:
> > The 64-bit guest boots into existing 32-bit root_fs without problems, I
> > will rebuild all my 64-bit guests and let you know how this goes.
>
> Actually, I got mixed up, the 64-bit filesystems worked but the 32-bit
> didn't. I couldn't find any option to allow support for 32-bit binaries,
> has it been removed? Does this mean that we need pure 64-bit fs?
For now it's so. In fact when I read that I was quite astonished.
If you want to run the 32-bit FS, for now stay with 32-bit UMLs.

Jeff said he had some compatibility code but that it's still very rough.

> > But so far, the performance increase over TT guests on a x86_64 box is
> > quite simply breathtaking!

> That is still true. No figures yet, just the feeling of interactivity.

-- 
Paolo Giarrusso, aka Blaisorblade
Skype user "PaoloGiarrusso"
Linux registered user n. 292729
http://www.user-mode-linux.org/~blaisorblade