user-mode-linux-user Mailing List for User-mode Linux kernel port (Page 793)

gm...@ri... said:
> Perhaps unrelated, I noticed that include/asm is linked to asm-i386.
> Should it be linked to asm-mu instead? 

I would recommend asm-um :-)

I've had strange build problems after accidentally leaving off the ARCH=um 
even when it didn't look like the i386 build didn't pollute anything.

Do a 'make mrproper ARCH=um', and repeat the whole process, remembering to put 
'ARCH=um' on everything, and things should be better.

				Jeff

First of all, to those who have worked on this, thanks. This looks very
cool.

After trying out the binary I decided to build a user-mode kernel for
debug.  I got the 2.4-test11 kernel and patch, but I'm having build
problems. I checked the archives but didn't find anything related.

The patch went smoothly.

'make config' did indeed proceed to ask me questions (despite what the
documentation expected). So I used 'make menuconfig' and just saved it
without changing anything.

'make dep' went ok.

'make linux' failed for lack of a target.

So I tried 'make ARCH=um linux' and things compiled fine until
arch/um/kernel/exec_kern.c, where the compiler complained:

make[1]: Entering directory `/usr/local/uml-linux/linux/arch/um/kernel'
gcc -D__KERNEL__ -I/usr/local/uml-linux/linux/include -Wall
-Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing
-U__i386__ -Ui386 -D__arch_um__ -DSUBARCH="i386" -DNESTING=0
-I../include  -c -o exec_kern.o exec_kern.c
exec_kern.c:48: parse error before `do'

This is an interesting error because the only 'do' in the file is on
line 77. Anybody seen and solved this one? I didn't find anything in the
archives.

Perhaps unrelated, I noticed that include/asm is linked to asm-i386.
Should it be linked to asm-mu instead?

Thanks for any help.

--Gordon

On Wed, 22 Nov 2000, Daniel Phillips wrote:
> On Wed, 22 Nov 2000, Jeff Dike wrote:
> 
> > Are you still only bringing it up to single-user?  You can probably bring it 
> > all the way up by fixing inittab to use non-devfs devices and then you'll have 
> > lots of consoles.
> > 
> > You could also background the dd.
> 
> yes of course :-)
> 
> I'll run it again.  Right now I'm focussed on the project I'm doing,
> and this isn't really an obstacle, but still, it needs to be tracked
> down.  Here goes again.

OK, backgrounding it in single user didn't work - top kept running but
as soon as I exited I didn't have a console any more.  I'd better try
to boot the system completely - about time I did.  I'll do it with
devfs, some time tomorrow.

-- 
Daniel

On Wed, 22 Nov 2000, Jeff Dike wrote:

> Are you still only bringing it up to single-user?  You can probably bring it 
> all the way up by fixing inittab to use non-devfs devices and then you'll have 
> lots of consoles.
> 
> You could also background the dd.

yes of course :-)

I'll run it again.  Right now I'm focussed on the project I'm doing,
and this isn't really an obstacle, but still, it needs to be tracked
down.  Here goes again.

-- 
Daniel

On Wed, 22 Nov 2000, Jeff Dike wrote:
> > Well, it's not my imagination.  
> 
> It would be convenient if it were, though.  Whenever some reported a bug, I 
> could just say "it's your imagination" :-)
> 
> > How should we proceed, should I email
> > you 15 meg worth of root_fs :-)?  (I can put it on our public server
> > instead, and you can download via ftp or http.) 
> 
> Is the dd not exiting?  What does ps think it's doing?  If ps thinks it's 
> running, can you get a backtrace from it?
Program received signal SIGINT, Interrupt.

I can break in gdb, and I find myself here:

Program received signal SIGINT, Interrupt.
0x100797e1 in __libc_nanosleep ()
(gdb) bt
#0  0x100797e1 in __libc_nanosleep ()
#1  0x100797a3 in __sleep (seconds=10) at ../sysdeps/unix/sysv/linux/sleep.c:82
#2  0x1006f15e in do_idle () at process_kern.c:431
#3  0x1006f20c in cpu_idle () at process_kern.c:457
#4  0x100af310 in start_kernel () at init/main.c:592
#5  0x1006d956 in start_kernel_proc (unused=0x0) at um_arch.c:70
#6  0x1006d36a in signal_tramp (arg=0x1006d918) at trap_user.c:49
(
I can't get ps because I don't know how to get another console - the
initial console is stuck.  I'd better figure out how to get another
console.

This is all I have for now - I could go examine the process lists in
gdb, but I'd rather just get another console open...

-- 
Daniel

phi...@in... said:
> Rik van Riel gave me this little gem for stress testing the buffer
> cache:
> 	usermode:~# dd if=/dev/ubd0 of=/dev/null
> After about 30 seconds of this we get a couple of:
> end_request: I/O error, dev 62:00 (User-mode block device), sector 204800
> end_request: I/O error, dev 62:00 (User-mode block device), sector 204802
> and can't break out of it. 

This is what happens when I try that:

darkstar:~# dd if=/dev/ubd/0 of=/dev/null
dd: /dev/ubd/0: Input/output error
1048576+0 records in
1048576+0 records out
darkstar:~# 

And in the log:

end_request: I/O error, dev 62:00 (User-mode block device), sector 1048576
end_request: I/O error, dev 62:00 (User-mode block device), sector 1048578
end_request: I/O error, dev 62:00 (User-mode block device), sector 1048580
end_request: I/O error, dev 62:00 (User-mode block device), sector 1048576
end_request: I/O error, dev 62:00 (User-mode block device), sector 1048578
end_request: I/O error, dev 62:00 (User-mode block device), sector 1048580
end_request: I/O error, dev 62:00 (User-mode block device), sector 1048582

The I/O error from dd is it running off the end of the device, and the log 
messages are the already-queued readahead requests failing (although I just 
noticed that they are mostly duplicates, which is a bit strange).

But I have no problem regaining control of anything.

> Update: there is no problem with a real device,
>   ./linux single debug ubd0=/dev/hda6 

That's because I can tell how big a file is (so the driver can tell the block 
device layer to go to hell when it tries some out-of-range I/O), but I looked 
and looked and failed to find a way to generically determine the size of a 
block device, so the driver can't tell when it has run off the end of the 
device and dd gets an infinite stream of empty buffers.

				Jeff

Update: there is no problem with a real device,

  ./linux single debug ubd0=/dev/hda6

only with the loopback mount.

-- 
Daniel

Rik van Riel gave me this little gem for stress testing the buffer
cache:

	usermode:~# dd if=/dev/ubd0 of=/dev/null

After about 30 seconds of this we get a couple of:

end_request: I/O error, dev 62:00 (User-mode block device), sector 204800
end_request: I/O error, dev 62:00 (User-mode block device), sector 204802

and can't break out of it.

I started uml with:

	./linux single debug   

Any ideas?  Want more info?

-- 
Daniel

phi...@in... said:
> Is it feasible to get gdb to load the module symbols automatically on
> insmod?

I can't think of an easy way to do it.  The insmod mechanism and gdb support 
are pretty disconnected from each other.  I don't even have any hooks into the 
module mechanism.  That's completely in the generic kernel.

gdb is pretty programmable.  It shouldn't be too hard to come up with macros 
that do the loading and reloading with one command.

> How about a 'pause' option to control that?

Sure.  Stuff like that beats fixing bugs any time.  Except it will probably be 
a "don't stop" option, since I think the common case is to set breakpoints and 
stuff there.  It also mimics the usual process-level gdb behavior which 
doesn't automatically run the process by default.

				Jeff

phi...@in... said:
> Well, I've got a solid day's vm hacking under uml, and I have to say
> it works like a dream.  It's really nice that the whole vm
> infrastructure is there. 

There's just one tiny little problem if you want to do VM hacking.  There's no 
equivalent of hardware access or dirty bits (I think i386 provides an access 
bit, not sure about dirty).

If you need them, I can put in some emulation.  I haven't done it because I 
haven't heard of anyone needing them.

				Jeff

On Fri, Nov 17, 2000 at 11:02:00AM -0500, William Stearns wrote:
> 	It seems the module is already loaded.  Is it?  Is it possibly
> compiled straight into the kernel?

Yes it was - I thought I had explained my mistake already: the module
was already (auto)loaded, but with name "tap0".


> 	net_util has the sole job of getting packets back and forth
> between the uml kernel and the host kernel.  It has no responsibilities
> for routing, packet forwarding, packet filtering, or proxarp that may also
> be needed depending on your requirements.
> 	Think of um_eth_net_util as the virtual ethernet card on the host
> kernel side of the internal virtual ethernet network.

I can understand this for "um_eth_net_util tap0", but them what means
the (largely unexplained) "um_eth_net_util eth0" ?

I can understand that using kernel-level bridging would be needed to
bridge tap0 to the real ethernet, but the only explanation I found to
this line was that it was going to do the bridging itself without even
consuming an ethertap slot.  Obviously it doesn't work that way, so
I'm a bit lost.


> > Anyway, these should be documented on the networking page, where only
> > the net_util command-line is given.
> 
> 	If you look back in he archives of this list, I posted a recipe
> for Ethernet networking a few weeks back.

I'll look at it.  I may also have a try at putting the material from
the web site and the archives in a standalone document - no promise,
though.


> > I'll have a look at the kernel bridging stuff, then.

Not yet done :(

Best regards,
-- 
Yann Dirson    <yd...@al...> |    Why make M$-Bill richer & richer ?
debian-email:   <di...@de...> |   Support Debian GNU/Linux:
                                    | Cheaper, more Powerful, more Stable !
http://ydirson.free.fr/             | Check <http://www.debian.org/>

Well, I've got a solid day's vm hacking under uml, and I have to say it
works like a dream.  It's really nice that the whole vm infrastructure
is there.

Is it feasible to get gdb to load the module symbols automatically on
insmod?  (I should have just read your code and answered that for
myself, but, um - I guess I'm having too much fun just being a user
at the moment.)

One *tiny* niggle - 99% of the time I don't need the breakpoint at
system startup, it just turns out to be one more keyboard step in
doing a run.  How about a 'pause' option to control that?

-- 
Daniel

xi...@bo... said:
> (gdb) inspect current_task.comm 
> $1 = "kreiserfsd\000\000\000\000\000" 

That's a kernel thread, and I bet it's exiting, which is something that I 
never expected a kernel thread to do.

It should just work, since there isn't much difference between a kernel thread 
and a user process, but I guess I messed something up.

I'm going to grab the reiserfs sources and see exactly what that nasty little 
thread is doing.

				Jeff

Jeff Dike <jd...@ka...> writes:

> xi...@bo... said:
> > No, the last messages are the reiserfs initialization stuff: 
> 
> Well, something happened to that process.
> 
> Can you print current_task.comm and current_task.thread?

Yes:

(gdb) inspect current_task.comm
$1 = "kreiserfsd\000\000\000\000\000"
(gdb) inspect current_task.thread 
$2 = {extern_pid = 1581, tracing = 0, forking = 0, kernel_stack = 1387667456, real_mm = 0x53dc3180, starting_exec = 0, signal = {signal = 0, sp = 0, handler = 0}, npending = 0, saved_sigs = {sig = {0, 0}}, nsyscalls = 0, process_regs = {regs = {0 <repeats 17 times>}}, syscall_regs = {regs = {0 <repeats 17 times>}}, syscall_stack = 0x0, syscall_stack_size = 0, altstack_regs = {regs = {0 <repeats 17 times>}}, altstack = 0x0, altstack_size = 0, cr2 = 0, err = 0, check_sigs = 0, restore_state = 0, mm_changes = 0, fault_addr = 0x0, syscall = {id = -1, args = {4294967295, 4294967295, 4294967295, 4294967295, 4294967295, 4294967295}, have_result = 0, result = -1, again = 0}, request = {op = 0, u = {exec = {ip = 269762560, sp = 1363378176}, fork = {task = 0x10144000, tramp_stack = 1363378176, sp = 0}, cswitch = {to = 0x10144000, from = 0x51438000}, thread = {proc = 0x10144000 <init_task_union>, arg = 0x51438000, flags = 0, new_pid = 0, new_task = 0x0, cpu = 0}, fork_finish = {stack = 269762560, regs = {regs = {1363378176, 0 <repeats 16 times>}}, from = 0x0}, cb = {proc = 0x10144000 <init_task_union>, arg = 0x51438000}}}}

-- 
Best regards
    Christian Laursen

phi...@in... said:
> How about getting uml.sourceforge.net as an alias for
> user-mode-linux.sourceforge.net ? 

Have you been telling people to visit uml.sourceforge.net :-)

It's shorter and easier to type.  Are there other reasons for having it?

				Jeff

phi...@in... said:
> I tried this, and my disassemblies are consistent with the symbols, as
> promised.  What accounts for the difference between 0x50 and 0x60 ? 

Probably my inability to read.

I'm in the process of updating my debugging page to describe this.  My new 
method is module.size_of_struct + 4.  This seems more general.

				Jeff

> Find the module start by adding the address of that entry, 
> sizeof(*module_list), and 8.  Those last two add up to 0x50 (IIRC),
> and the  module entry will be on a page boundary, so the actual module
> start address  will be 0xzzzzz060 in that case.

I tried this, and my disassemblies are consistent with the symbols, as
promised.  What accounts for the difference between 0x50 and 0x60 ?

-- 
Daniel

How about getting uml.sourceforge.net as an alias for
user-mode-linux.sourceforge.net ?

-- 
Daniel

The user-mode port of 2.4.0-test11 is available.

UML is now able to run as a daemon, i.e. with no stdin/stdout/stderr.

The hostfs filesystem now works as a readonly filesystem.  It's now 
configurable.  I'm using it as a module.  It ought to work compiled into the 
kernel, but I haven't checked this.

I fixed a number of bugs.

NOTE:  If you compile from source, you must put 'ARCH=um' on the make command 
line or in the environment, like:
	make linux ARCH=um
or
	ARCH=um make linux
or
	export ARCH=um
	make linux

This is because I've changed the top-level Makefile to build either a native 
kernel or a usermode kernel, with the default being native.  This is in 
preparation for submitting this port to the main pool.  The ARCH calculation 
is now this:

# SUBARCH tells the usermode build what the underlying arch is.  That is set
# first, and if a usermode build is happening, the "ARCH=um" on the command
# line overrides the setting of ARCH below.  If a native build is happening,
# then ARCH is assigned, getting whatever value it gets normally, and 
# SUBARCH is subsequently ignored.

SUBARCH := $(shell uname -m | sed -e s/i.86/i386/ -e s/sun4u/sparc64/ -e 
s/arm.*/arm/ -e s/sa110/arm/)
ARCH := $(SUBARCH)

If anyone has any objections to this going in the main pool, let me know, and 
also let me know what you would suggest as a fix.

The project's home page is http://user-mode-linux.sourceforge.net

The project's download page is http://sourceforge.net/project/filelist.php?grou
p_id=429

				Jeff

xi...@bo... said:
> No, the last messages are the reiserfs initialization stuff: 

Well, something happened to that process.

Can you print current_task.comm and current_task.thread?

				Jeff

Jeff Dike <jd...@ka...> writes:

> xi...@bo... said:
> > It looks like it's stuck in __wait4() for some reason. 
> 
> That's where it's supposed to be.

Okay.

> You could try getting a backtrace the old way.  Look at 
> current_task.thread.extern_pid, and kill -STOP it.

(gdb) inspect current_task.thread.extern_pid
$1 = 909

[xi@x ~]$ kill -STOP 909
909: No such process

Isn't there supposed to be a process with pid 909 on the host?
(Or am I just clueless?)

> You might see that the UML debugger is a huge improvement over what preceded 
> it :-)

Indeed. :)

-- 
Best regards
    Christian Laursen

On Sun, 19 Nov 2000, Daniel Phillips wrote:
> 
> Did I say that this is such a powerful tool that a little bit of pain
> is worth it?  No?  Well I'm saying it now.
> 
> Now next problem:
> 
>  ./linux single ubd0=/dev/hda6
> 
> works, but:
> 
>  ./linux single debug ubd0=/dev/hda6
> 
> just hangs.
> 
> This is with 2.4.0-test10 as host.  I attached my .config.

OK, I'm happy to report that everthing works as it should - I don't
know why gdb wasn't starting the first attempt - I didn't have symbols
compiled in the kernel, but I *was* able to get gdb to come up with
them later.   Now I've rebuilt with symbols and I have a really nice
kernel hacking environment, a very tight edit-build-debug loop.  This
will be a major help with Tux2 - and I can take it with me, on my
laptop.

BTW,  asm("int3"); works fine as a way of getting into gdb, so you
can do:

	 #define BUG() asm("int $3")

And I was talking to someone who wants to develop a floppy driver, so
I suggested he try:

  ./linux ubd6=/dev/fd0 

and that seems to work.

-- 
Daniel

On Sun, Nov 19, 2000 at 06:45:49PM +0100, Yann Dirson wrote:
>  Described behaviour refers to test10 and test11 UMLs on

Oops... s/test11/test9/

-- 
Yann Dirson    <yd...@al...> |    Why make M$-Bill richer & richer ?
debian-email:   <di...@de...> |   Support Debian GNU/Linux:
                                    | Cheaper, more Powerful, more Stable !
http://ydirson.free.fr/             | Check <http://www.debian.org/>

On Fri, Nov 17, 2000 at 09:22:24PM -0500, Jeff Dike wrote:
> > Ah, my first real bug on UML ?   
> 
> And what's the alleged bug?
> 
> The option for turning on the virtual serial line is CONFIG_SSL, which is in 
> the 'General Setup' menu.

Hm... I do not have CONFIG_SSL, even commented out, in my .config's
(test10 nor 11).

I do not have a 'General Setup' top-level menu, it appears as
subsection under 'Processor features' in test11

In make xconfig I can see CONFIG_SSL greyed out there, but it does not
show with 'make menuconfig', which I probably used for the setup,
which may explain I did not find it.

Ah... config.in gives me the dep on UNIX98_PTYS...  This should be
documented in the online help for CONFIG_SSL (which appears empty for
now).

A section in the docs, describing the um-specific config options (and
what makes them available for selection in menuconfig) would make it
easier IMHO.  OK I could have looked at the patch on the config.in
files to find out, but for some reason I did not thought of it...


> yd...@al... said:
> > > serial line 0 assigned pty /dev/ptyp0
> > He he, that surely is the problem, I don't have such a line on a
> > test11 kernel, although I do have it on test10 :} 
> 
> You mean that the host is test11 and it doesn't have /dev/ptyp*, but your 
> test10 host does?

No, my host is 2.2.18pre21.  The only 2.4.0test I run for now are the
UML kernels.  Described behaviour refers to test10 and test11 UMLs on
the same 2.2 host.

Er... looks like the kernel I was running was probably not the one I
compiled, which should explain the difference :(

Regards,
-- 
Yann Dirson    <yd...@al...> |    Why make M$-Bill richer & richer ?
debian-email:   <di...@de...> |   Support Debian GNU/Linux:
                                    | Cheaper, more Powerful, more Stable !
http://ydirson.free.fr/             | Check <http://www.debian.org/>

Did I say that this is such a powerful tool that a little bit of pain
is worth it?  No?  Well I'm saying it now.

Now next problem:

 ./linux single ubd0=/dev/hda6

works, but:

 ./linux single debug ubd0=/dev/hda6

just hangs.

This is with 2.4.0-test10 as host.  I attached my .config.

-- 
Daniel