> The actual version of xeno-unstable (Changeset 1.506) segfaults with some
> standard commands - at least with my
> RedHat V8 (I haven't tested RedHat V9 yet) installation.
> If you enter "vi" or "vim" or "rpm -qa" as root or non-root user,
> xeno-linux just segfaults with no further comments (the next line of
> output just shows "Segmentation fault", nothing more).
> After a lot of tests with bk pull and bk undo, I was able to find out,
> that this bug was introduced with Changeset 1.478.
Oops.
I've just tried "rpm -qa" and "vi" under 1.506 on a RH7.2
installation, and it seems to work. I'll try setting up a RH8
install and retrying. My guess is that this is something to do
with our per-domain ldt switching code. The pthreads library uses
fs/gs for accessing thread local storage, and the exact mechanism
seems to change with every libc and RH version. However, its not
clear that rpm and vi use pthreads.
1.478 was a major change, so I'm not entirely
surprised. Shouldn't be hard to fix, though.
> BTW: Especially for production use, it would be nicer if xen could
> somehow pass up "printk"-output in xen to dom0's kernel logger,
> so that you don't need to configure and run a second machine for
> the serial line debug output all the time. While checking the segfault
> bug, I have not connected a debug machine to the serial line, so I
> don't know if it would have showed something helpful :-(
Yes, having Xen output (including boot messages) passed up to
domain0 would certainly be helpful.
Just writing into a ring buffer and then mapping it from dom0
and having a daemon dump it to syslog should work. Might be worth
looking to see how klogd does it.
> Another thing I realized while compiling and trying to load the
> HyperSCSI kernel module:
> When loading the HyperSCSI client kernel module (which was
> compiled against xeno-linux), it complains about 2 undefined
> Kernel Symbols:
>
> do_hypervisior_callback and
> HYPERVISOR_shared_info
>
> After adding 2 EXPORT_SYMBOL lines for these symbols in
> ../arch/xeno/kernel/i386_ksyms.c and
> recompiling the kernel, everything loaded and worked OK.
> I hope it was not against xen design principles to add the
> 2 EXPORT_SYMBOL lines ;-)
We generally don't use modules much, so I'm afraid we hadn't
spotted this. We'll add the exports into the master tree, thanks.
> Regards + many thanks to the Xen project team for this nice
> and professional software :))
Thanks.
Ian
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel
|
Home