headers
Jeff Dike | 27 Nov 2002 17:43

Re: [uml-devel] uml-patch-2.4.19-28

matthew <at> bytemark.co.uk said:
> Jeff, could you tell me what command to issue to the mconsole socket
> to get  it to give me the pty device for a particular conX please?

WorksForMe (tm):

jdike 1004: uml_mconsole debian
(debian) version
OK Linux usermode 2.4.19-33um #4 Wed Nov 27 11:25:07 EST 2002 i686
(debian) config con1
OK pty:/dev/ptyp0
(debian) config con2
OK pty:/dev/ptyp1
(debian) config con3
OK pty

con3 hadn't been opened yet, so it hadn't yet grabbed a host device.

				Jeff

-------------------------------------------------------
This SF.net email is sponsored by: Get the new Palm Tungsten T 
handheld. Power & Color in a compact size! 
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
Permalink | Reply | 0 comments |
headers
Cameron Kerr | 27 Nov 2002 21:27
Picon
Favicon

Re: [uml-devel] /tmp in arch/um/kernel/tempfile.c

On Wed, Nov 27, 2002 at 04:19:25PM +0100, Markus Hennig wrote:

> can anybody (simple) explain why /tmp is hardcoded in tempfile.c

That's the default.

> and not adjustable with a commandline parameter?

UML respects $TMP $TEMP and $TMPDIR for this. It will create a file
there for memory, open it, then delete it (the file still exists, only
you can't see it. It won't be closed until UML shuts down.

--

-- 
Cameron Kerr
Email:   cameron.kerr <at> paradise.net.nz
Website: http://nzgeeks.org/cameron/

-------------------------------------------------------
This SF.net email is sponsored by: Get the new Palm Tungsten T 
handheld. Power & Color in a compact size! 
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
Permalink | Reply | 0 comments |
headers
Cameron Kerr | 28 Nov 2002 01:02
Picon
Favicon

[uml-devel] Is gcc-3.0 safe for compiling UML?

Interested in making things go fast, I'd like to know if its safe (ie,
for production work, but not high availability), to use GCC 3.0 or 3.2
to compile the UML kernel?

--

-- 
Cameron Kerr
Email:   cameron.kerr <at> paradise.net.nz
Website: http://nzgeeks.org/cameron/

-------------------------------------------------------
This SF.net email is sponsored by: Get the new Palm Tungsten T 
handheld. Power & Color in a compact size! 
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
Permalink | Reply | 1 comment |
headers
David Coulson | 28 Nov 2002 01:08

Re: [uml-devel] Is gcc-3.0 safe for compiling UML?

Cameron Kerr wrote:
> Interested in making things go fast, I'd like to know if its safe (ie,
> for production work, but not high availability), to use GCC 3.0 or 3.2
> to compile the UML kernel?

Works for me.

David

--

-- 
David Coulson                                    email: d <at> vidcoulson.com
Linux Developer /                          web: http://davidcoulson.net/
Network Engineer                                   phone: (216) 533-6967

-------------------------------------------------------
This SF.net email is sponsored by: Get the new Palm Tungsten T 
handheld. Power & Color in a compact size! 
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
Permalink | Reply | 0 comments |
headers
Noah | 28 Nov 2002 05:52

[uml-devel] panic on -13um, backtrace included

Got the following panic:

Breakpoint 1, panic (
    fmt=0xa0186c40 "Kernel mode fault at addr 0x%lx, ip 0x%lx") at
panic.c:52
52              bust_spinlocks(1);
(gdb) bt
#0  panic (fmt=0xa0186c40 "Kernel mode fault at addr 0x%lx, ip 0x%lx")
    at panic.c:52
#1  0xa0118bd1 in segv (address=6648937, ip=2684414619, is_write=0,
is_user=0,
    sc=0xa01a7798) at trap_kern.c:101
#2  0xa0119aa7 in segv_handler (sig=11, regs=0xa01a4280) at
trap_user.c:433
#3  0xa0119b5a in sig_handler_common (sig=11, sc=0xa01a7798) at
trap_user.c:484
#4  0xa0119bcd in sig_handler (sig=11, sc=
      {gs = 0, __gsh = 0, fs = 0, __fsh = 0, es = 43, __esh = 0, ds = 43,
__dsh
= 0, edi = 2685970294, esi = 1, ebp = 2686089876, esp = 2686089836, ebx =
664893
7, edx = 0, ecx = 2686089684, eax = 2, trapno = 14, err = 4, eip =
2684414619, c
s = 35, __csh = 0, eflags = 66195, esp_at_signal = 2686089836, ss = 43,
__ssh =
0, fpstate = 0x0, oldmask = 469827584, cr2 = 6648937}) at trap_user.c:500
#5  <signal handler called>
#6  __wake_up (q=0x657469, mode=3, nr=1) at sched.c:731
#7  0xa0124f0b in __up (sem=0xa1432320) at semaphore.c:52
#8  0xa012512c in __up_wakeup () at semaphore.c:167
(Continue reading)

Permalink | Reply | 1 comment |
headers
Steve Schmidtke | 28 Nov 2002 09:22
Picon
Favicon

[uml-devel] uml memfilemap

cameron.kerr <at> paradise.net.nz wrote:
>On Wed, Nov 27, 2002 at 04:19:25PM +0100, Markus Hennig wrote:
>
>>can anybody (simple) explain why /tmp is hardcoded in tempfile.c
>
>That's the default.

And annoying if you are trying to chroot to a read only fs, like a cdrom. :)

Attached is a concept hack that implements memfilemap, a method of mapping 
file descriptors to VM areas.  What it does is allow you to put the UML vm 
files anywhere you want them to reside and point the UML at pre-opened fds 
of those files.  This patch does not require the filemap feature patch I 
posted earlier, and should apply to most recent 2.4 UMLs fairly easily.  
Basic usage example:

./linux mem=200M mfm=11 11<>/usr/tmp/vm-$$_1 mfm=12 12<>/usr/tmp/vm-$$_2

There are no checks that the fd is valid, there are no warnings there isn't 
enough disk space.  There are no unlinks of the files, there are no 
provisions for restarting after reboot.  There are no warnings that the 
memory footprint requested is larger than the number of maps given, or that 
you opened the same memory file twice.  There are no guarantees it works at 
all.

What there is, is some code that handles a FIFO stack of file descriptors. 
Each fd represents a potential memory region inside the UML, which get 
handed out as the UML sets up its memory footprint.  Generally, the current 
UML allocation scheme will require at least one mfm= mapping for every 256M 
of memory requested.  If you do not provide enough maps, the UML will just
(Continue reading)

Permalink | Reply | 752 comments |
headers
Nick Craig-Wood | 28 Nov 2002 11:07
Picon
Picon

Re: [uml-devel] uml memfilemap

On Thu, Nov 28, 2002 at 08:22:31AM +0000, Steve Schmidtke wrote:
> Attached is a concept hack that implements memfilemap, a method of mapping 
> file descriptors to VM areas.  What it does is allow you to put the UML vm 
> files anywhere you want them to reside and point the UML at pre-opened fds 
> of those files.  This patch does not require the filemap feature patch I 
> posted earlier, and should apply to most recent 2.4 UMLs fairly easily.  
> Basic usage example:
> 
> ./linux mem=200M mfm=11 11<>/usr/tmp/vm-$$_1 mfm=12 12<>/usr/tmp/vm-$$_2

perhaps consider the alternative syntax mfm=11-15?

> There are no checks that the fd is valid, there are no warnings there isn't 
> enough disk space.  There are no unlinks of the files, there are no 
> provisions for restarting after reboot.  There are no warnings that the 
> memory footprint requested is larger than the number of maps given, or that 
> you opened the same memory file twice.  There are no guarantees it works at 
> all.

The only showstopper I can see is the fact it doesn't work after a
reboot, otherwise it looks good!

I guess you saw my earlier memfile patch which attempted a similar
thing?  Passing in file descriptors is better than filenames though.

--

-- 
Nick Craig-Wood
ncw1 <at> axis.demon.co.uk

-------------------------------------------------------
(Continue reading)

Permalink | Reply | 751 comments |
headers
Markus Hennig | 28 Nov 2002 13:37
Favicon

RE: /tmp in arch/um/kernel/tempfile.c

> -----Original Message-----
> From: Cameron Kerr [mailto:cameron.kerr <at> paradise.net.nz]
> Sent: Wednesday, November 27, 2002 9:28 PM
> To: user-mode-linux-devel <at> sourceforge.net
> Subject: Re: [uml-devel] /tmp in arch/um/kernel/tempfile.c
> 
> 
> On Wed, Nov 27, 2002 at 04:19:25PM +0100, Markus Hennig wrote:
> 
> > can anybody (simple) explain why /tmp is hardcoded in tempfile.c
> 
> That's the default.
> 
> > and not adjustable with a commandline parameter?
> 
> UML respects $TMP $TEMP and $TMPDIR for this. It will create a file
ok, i will try this

> there for memory, open it, then delete it (the file still exists, only
> you can't see it. It won't be closed until UML shuts down.
yes i saw this in the code, but why needs UML more RAM then i configured 
with mem=xxM? 

i mounted a tmpfs to /tmp with 330M and started 3 UMLs with 
mem=96, but they need more then 3*96M (288M) - they need all and crashed 
because for lack of memory....

Markus

> --
(Continue reading)

Permalink | Reply | 1 comment |
headers
Oleg Drokin | 28 Nov 2002 14:45

2.5.49-1 is not working for me

Hello!

   I tried 2.5.49-1 today and it did not worked for me.
   It always dies with "Child NNN exited with signal 11" just after
   "INIT: version NNN booting" message.
   Two uml "init" processes are visible from host.
   Host kernel is 2.4.19 without skas patch and without /proc/mm support.
   Any ideas/fixes on that?

   Also I should mention that it is not possible to compile 
   arch/um/kernel/skas/util/mk_ptregs.c on almost any sane distro, because
   /usr/include/asm/ptrace.h (and /usr/include/asm is NOT a symlink to kernel
   tree of course, like it used to be in libc5 times) does not define
   FRAME_SIZE.
   I circumviented the problem by changing mk_ptregs.c to look like this:
$ head -2 mk_ptregs.c
#include "../../../../../include/asm-i386/ptrace.h"
#include "../../../../../include/asm-i386/user.h"

Bye,
    Oleg   

-------------------------------------------------------
This SF.net email is sponsored by: Get the new Palm Tungsten T 
handheld. Power & Color in a compact size! 
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
Permalink | Reply | 6 comments |
headers
Steve Schmidtke | 28 Nov 2002 19:27
Picon
Favicon

Re: uml memfilemap

ncw1 <at> axis.demon.co.uk wrote:
>perhaps consider the alternative syntax mfm=11-15?

That's an excercise for the reader. :)

>The only showstopper I can see is the fact it doesn't work after a
>reboot, otherwise it looks good!

Since the memory files aren't zeroed before use, I felt it best not to even 
bother at this point.  Adding a dup() wrapper around the return of the 
memfilemap_aquirefd() call may be enough if you really want to play with 
that.  I'd also suggest close-on-exec be set on the mfm'd descriptors when 
they are added to the pool, and unset at reboot.

>I guess you saw my earlier memfile patch which attempted a similar
>thing?  Passing in file descriptors is better than filenames though.

Yeah, my goal is to end up with a completely empty chroot environment.  I 
want the UML suspended above a big black pit that it falls into if anything 
strange happens.

I'm thinking even the linux binary can be filemapped in to reach that goal.  
Your chroot tool would mmap in the binary, create executable pages from it, 
and jump to the start address.  Ok, a bit naive and perhaps a tinge 
demented, but it seems possible.

Steve Schmidtke

>--
>Nick Craig-Wood
(Continue reading)

Permalink | Reply | 2 comments |

Gmane