|
From: Jeff D. <jd...@ka...> - 2000-08-20 01:12:19
|
> Funny thing is that it thinks it's running on an um processor. Or
> something. Another thing that goofs up is that my bash login scripts
> add ~/bin.`uname -m` to my path, which works perfectly fine on
> {i386,sparc,sun4u} machines, but not on any of the virtual machines
> here (quite a few already...)
If you don't like 'um' as your arch, put 'fakearch' on the kernel command
line.
That will make it assume the underlying arch.
> Now this is of course easy to kludge around, but wouldn't it be saner
> if the uml 'kernel' just returned the name of the host architecture to
> 'uname -m' instead of just 'um'? There's not really supposed to be
> anything that distinguishes this virtual machine from a real i386,
> right?
I'm open to arguments on this one. It sort of seems like the right thing to
do.
It also happens automatically, which contributes to its rightness. In the
kernel pool, $ARCH is set to 'um' which causes it to build in arch/um. $ARCH
is automatically used to fill in the utsname structure. I'd have to modify
the generic kernel in order to change that.
> (Apart from some NFS unmount hangs (which might be in stock
> 2.4.0-test6 too, didn't check) and an occasional kernel panic once a
> day, these virtual machines seem to be working remarkably well.)
How is a kernel panic once a day working remarkably well? And why don't you
tell me when it panics? I can't fix things unless I know about them. And
until now, I didn't know about any extant panics.
So, what is the panic, and what's the backtrace, and do you know how to
reproduce it?
> When trying to load the ip_tables module in an uml I get:
> [root@dev0 netfilter]# insmod ./ip_tables.o
> ./ip_tables.o: unresolved symbol get_fault_addr
> ./ip_tables.o: unresolved symbol set_fault_addr
> ./ip_tables.o: unresolved symbol current_task
They just haven't been exported yet. Stick EXPORT_SYMBOL in the appropriate
places, and it should work. Then send me the patch.
Jeff
|