From: Gerd K. <kr...@by...> - 2004-08-20 12:42:06
|
Hi, I've just uploaded a bunch of uml kernel patches to http://www.suse.de/~kraxel/uml/patches/ This basically is the current state of the suse kernel for the next suse linux release. The patches create one source tree for both i386 and uml kernels. Some of these patches have been mailed to this list in the past. The README for the patch kit is attached below for convenience. What is the status of the amd64 port? The 2.6.4 patch on sf.net produces lots of rejects when I try to apply it on top of the 2.6.7 uml patch. Is a newer version available somewhere? Or can I just ignore all the rejects (guess not)? What is the status if the umlfb/x11/pthread issue, i.e. uml kernel crashing as soon as one tries to link against libpthread (which is needed for libX11)? Any progress here? Gerd ==============================[ cut here ]============================== kraxel's 2.6.8 uml patch kit [2004-08-20] ========================================= The patches must be applied in the order listed here. Patch descriptions: host-skas3-2.6.7-v1.patch blaisorblade's skas patch -- as-is uml-patch-2.6.7-2 jeff's uml patch -- with some stuff removed which is already in the skas patch. uml-fix-skas some fixes needed to make the resulting tree build for both i386 and um archs. uml-fixes-for-2.6.8 some updates to make uml build on 2.6.8 uml-extraversion don't change the EXTRAVERSION uml-raise-tty-limit use 16 instead of 8 ttys. uml-pretend-to-be-i586 make the uml virtual machine claim to be a i586 machine. At least suse's yast2 installer will pick the glibc version without tls/nptl support then, thus this avoids trouble due to the the not-yet implemented tls/nptl syscalls in uml kernels. Maybe useful for other distros as well. uml-core-on-panic Make the uml kernel dump core on kernel panics for later analysis. Default: off, there is a kernel cmd line arg to enable that. uml-fix-umldir-order fold the tree setup functions in umid.c into one, fixes some init call ordering issue I had some time ago. Also makes the error messages more verbose. uml-fix-export-symbol exports one missing symbol (needed for xfs). uml-general-protection-fault attempt to handle general protection faults more correctly. uml-net-flush-on-ifup flush incoming packets on ifup -- fixes networks stalls which happen in case the unix socket buffer is already full when the interface is up'ed (due to SIGIO never signaling arrived data). uml-fix-mconsole-proc fix kernel crash triggered by running "uml_mconsole <umid> proc <some-file>" multipole times. uml-terminal-cleanup tty / console handling cleanups. The patchfile itself has a long description. |
From: Geert U. <ge...@li...> - 2004-08-20 13:15:34
|
On Fri, 20 Aug 2004, Gerd Knorr wrote: > What is the status if the umlfb/x11/pthread issue, i.e. uml > kernel crashing as soon as one tries to link against libpthread > (which is needed for libX11)? Any progress here? Use SKAS mode, not TT, so UML is dynamically linked and libpthread is not needed. But no further progress since my last mail on August 2 (which you may have missed due to being abroad, check the archives). Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li... In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds |
From: Gerd K. <kr...@by...> - 2004-08-20 17:01:40
|
On Fri, Aug 20, 2004 at 03:14:55PM +0200, Geert Uytterhoeven wrote: > On Fri, 20 Aug 2004, Gerd Knorr wrote: > > What is the status if the umlfb/x11/pthread issue, i.e. uml > > kernel crashing as soon as one tries to link against libpthread > > (which is needed for libX11)? Any progress here? > > Use SKAS mode, not TT, so UML is dynamically linked and libpthread is not > needed. Ah, ok, thats the trick. Now I have a X11 window. I've build kernels with both skas+tt until now ... > But no further progress since my last mail on August 2 (which you may > have missed due to being abroad, check the archives). Yep, was offline at that time due to holidays. Gerd -- return -ENOSIG; |
From: Jeff D. <jd...@ad...> - 2004-08-20 17:59:58
|
kr...@by... said: > uml-core-on-panic > Make the uml kernel dump core on kernel panics for later analysis. > Default: off, there is a kernel cmd line arg to enable that. I like this, but I think it would be better done in a panic_notifier. > uml-fix-mconsole-proc > fix kernel crash triggered by running "uml_mconsole <umid> proc > <some-file>" > multipole times. I didn't do it this way on purpose. I create an internal procfs mount in case the UML root user has mounted something else on /proc. I don't want the mconsole on the host to be faked out by that. > uml-net-flush-on-ifup > flush incoming packets on ifup -- fixes networks stalls which happen > in > case the unix socket buffer is already full when the interface is > up'ed > (due to SIGIO never signaling arrived data). Applied, BTW, this one is mangled on your site: @@ -129,6 +129,7 @@ static int uml_net_open(struct net_devic It's in my 2.4 tree and will get moved over to 2.6 in due course. > uml-terminal-cleanup > tty / console handling cleanups. The patchfile itself has a long > description. I like this one, but it's big and I'm going to have to take a good look at it. I'm somewhat unhappy about the command line change, where you need to specify a console or UML doesn't boot. That'll break everyone's scripts. Is it possible to provide a default console if there isn't one on the command line? > What is the status of the amd64 port? The 2.6.4 patch on sf.net > produces lots of rejects when I try to apply it on top of the 2.6.7 > uml patch. Is a newer version available somewhere? Or can I just > ignore all the rejects (guess not)? It's stuck on 2.6.4 for now. I'm going to get it caught up, but haven't decided when yet. Jeff |
From: Geert U. <ge...@li...> - 2004-08-20 21:06:23
|
On Fri, 20 Aug 2004, Jeff Dike wrote: > kr...@by... said: > > uml-terminal-cleanup > > tty / console handling cleanups. The patchfile itself has a long > > description. > > I like this one, but it's big and I'm going to have to take a good look at it. > I'm somewhat unhappy about the command line change, where you need to specify > a console or UML doesn't boot. That'll break everyone's scripts. Is it > possible to provide a default console if there isn't one on the command line? IIRC, the default console is the one that gets registered first. So by reordering the code (in source files) and/or objects (in Makefiles) you can make sure the correct one is the default. BTW, what do you think of putting the stderr console in its own source file with its own CONFIG_* option? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li... In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds |
From: Gerd K. <kr...@by...> - 2004-08-21 19:40:18
|
On Fri, Aug 20, 2004 at 11:05:56PM +0200, Geert Uytterhoeven wrote: > On Fri, 20 Aug 2004, Jeff Dike wrote: > > I like this one, but it's big and I'm going to have to take a good look at it. > > I'm somewhat unhappy about the command line change, where you need to specify > > a console or UML doesn't boot. That'll break everyone's scripts. Is it > > possible to provide a default console if there isn't one on the command line? > > IIRC, the default console is the one that gets registered first. Yes. > So by reordering the code (in source files) and/or objects (in > Makefiles) you can make sure the correct one is the default. No. The stderr console is registered _much_ earlier in the boot process than the stdio console. And I don't want to change that as having printk work early is a cool debugging feature. The stdio_console can't be registered that early as it needs -- unlike stderr console -- several kernel subsystems being initialized already. > BTW, what do you think of putting the stderr console in its own source file > with its own CONFIG_* option? Thats IMHO a good idea in any case as one can turn on/off stderr console and stdio console independant of each other. That simplifies things for both backward compatibility (make the kernel with stderr console disabled behave like older versions should be easy, even without dirty tricks like silently appending console=tty0) and fbcon (disable stdio_console to get it out of the way but have stderr console for printk-debugging it). Gerd -- return -ENOSIG; |
From: Werner A. <wa...@al...> - 2004-08-22 13:22:15
|
Gerd Knorr wrote: > And I don't want to change that as having printk work early is a cool > debugging feature. Yeah ! I had a quick look at the code, and it seems that you could still occasionally lose printk data in non-catastrophic situations, e.g. when writing to a pipe. I've made a (less nice) patch a while ago that doesn't loses data unless it really really has to: http://marc.theaimsgroup.com/?l=user-mode-linux-devel&m=108093851702249&w=2 BTW, do the console changes also remove the requirement that stdin must be a tty, e.g. so that one could do ./linux </dev/null and that UML doesn't alter terminal settings ? (I've just worked around the latter problem in umlsim, but it's rather messy.) - Werner -- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina wa...@al... / /_http://www.almesberger.net/____________________________________________/ |
From: Gerd K. <kr...@by...> - 2004-08-23 11:20:57
|
> BTW, do the console changes also remove the requirement that > stdin must be a tty, e.g. so that one could do > ./linux </dev/null and that UML doesn't alter terminal > settings ? (I've just worked around the latter problem in > umlsim, but it's rather messy.) I think so, but havn't actually tried. I usually use the host terminal as serial console for the uml machine (i.e. "ssl0=fd:0,fd:1 console=ttyS0"). Gerd -- return -ENOSIG; |
From: Gerd K. <kr...@by...> - 2004-08-22 11:40:19
|
On Fri, Aug 20, 2004 at 03:01:40PM -0400, Jeff Dike wrote: > kr...@by... said: > > uml-core-on-panic > > Make the uml kernel dump core on kernel panics for later analysis. > > Default: off, there is a kernel cmd line arg to enable that. > > I like this, but I think it would be better done in a panic_notifier. I'll have a look. > > uml-fix-mconsole-proc > > fix kernel crash triggered by running "uml_mconsole <umid> proc > > <some-file>" > > multipole times. > > I didn't do it this way on purpose. I create an internal procfs mount in > case the UML root user has mounted something else on /proc. I don't want > the mconsole on the host to be faked out by that. I guessed that from reading the code already ;) I'm happy with any other fix for the kernel crash as well. I'm no VFS expert through and don't know what exactly is wrong in the original code. I know that my version has the drawback that it depends on procfs actually being mounted on /proc, but it's better that than being able to kill the kernel by calling "uml_mconsole proc <file>" a few timers ;) > > uml-terminal-cleanup > > I like this one, but it's big and I'm going to have to take a good look at it. > I'm somewhat unhappy about the command line change, where you need to specify > a console or UML doesn't boot. That'll break everyone's scripts. Is it > possible to provide a default console if there isn't one on the command line? See Geert's and my other mail. Gerd -- return -ENOSIG; |
From: D. B. <db...@en...> - 2004-08-31 00:26:42
Attachments:
signature.asc
core_on_panic.patch
|
Gerd Knorr wrote: > On Fri, Aug 20, 2004 at 03:01:40PM -0400, Jeff Dike wrote: > >>kr...@by... said: >> >>>uml-core-on-panic >>> Make the uml kernel dump core on kernel panics for later analysis. >>> Default: off, there is a kernel cmd line arg to enable that. >> >>I like this, but I think it would be better done in a panic_notifier. > > > I'll have a look. > I liked this too. Here's a pass at it if you like (attached). -- db |
From: Gerd K. <kr...@by...> - 2004-09-14 13:01:14
|
> I liked this too. Here's a pass at it if you like (attached). Sorry for the delay, going over this while being busy updating my patches right now ... > +static int panic_coreonpanic(struct notifier_block *self, unsigned long unused1, > + void *unused2) > +{ > + if(uml_coreonpanic){ > + uml_cleanup(); > + block_signals(); > + abort(); What is the point of doing that? I'd just let it dump core without any cleanups, to get the state of the uml kernel dumped to the disk with few modifications as possible. Any changes might make the analysis of the crash harder or even impossible. Gerd -- return -ENOSIG; |
From: D. B. <db...@en...> - 2004-09-15 20:59:27
Attachments:
signature.asc
|
actually it's worse than that in my current implementation: static int panic_coreonpanic(struct notifier_block *self, unsigned long unused1, void *unused2) { if ( uml_coreonpanic ) { /* cleanup so we have less to cleanup [linux] on the host */ /* could panic in uml_cleanup though so we need a check */ if ( uml_exitcode++ < 1 ) { uml_cleanup(); } /* to prevent keyboard from causing terminal to spew during dump */ block_signals(); abort(); } return(0); } Gerd Knorr wrote: >>I liked this too. Here's a pass at it if you like (attached). >> >> > >Sorry for the delay, going over this while being busy updating my >patches right now ... > > > >>+static int panic_coreonpanic(struct notifier_block *self, unsigned long unused1, >>+ void *unused2) >>+{ >>+ if(uml_coreonpanic){ >>+ uml_cleanup(); >>+ block_signals(); >>+ abort(); >> >> > >What is the point of doing that? I'd just let it dump core without any >cleanups, to get the state of the uml kernel dumped to the disk with few >modifications as possible. Any changes might make the analysis of the >crash harder or even impossible. > > Gerd > > > -- db |
From: Gerd K. <kr...@by...> - 2004-09-16 10:41:21
|
On Wed, Sep 15, 2004 at 04:59:16PM -0400, D. Bahi wrote: > actually it's worse than that in my current implementation: Thanks for the comments, merged that into my current version. Attached below. I've also moved it all into a single source file, so it is nicely separated and also can be trivialy made a compile time option if someone wants this. Gerd Index: uml-2.6.9-rc2/arch/um/kernel/Makefile =================================================================== --- uml-2.6.9-rc2.orig/arch/um/kernel/Makefile 2004-09-15 08:36:20.000000000 +0200 +++ uml-2.6.9-rc2/arch/um/kernel/Makefile 2004-09-15 08:36:20.000000000 +0200 @@ -11,7 +11,7 @@ obj-y = checksum.o config.o exec_kern.o sigio_user.o sigio_kern.o signal_kern.o signal_user.o smp.o \ syscall_kern.o syscall_user.o sysrq.o sys_call_table.o tempfile.o \ time.o time_kern.o tlb.o trap_kern.o trap_user.o uaccess_user.o \ - um_arch.o umid.o user_util.o + um_arch.o umid.o user_util.o core-on-panic.o obj-$(CONFIG_BLK_DEV_INITRD) += initrd_kern.o initrd_user.o obj-$(CONFIG_GPROF) += gprof_syms.o Index: uml-2.6.9-rc2/arch/um/kernel/core-on-panic.c =================================================================== --- uml-2.6.9-rc2.orig/arch/um/kernel/core-on-panic.c 2004-04-06 15:27:52.000000000 +0200 +++ uml-2.6.9-rc2/arch/um/kernel/core-on-panic.c 2004-09-16 12:19:08.303422237 +0200 @@ -0,0 +1,63 @@ +/* + * allow user mode linux kernels dump core on kernel panics, + * for later analysis of the crash. + * + * (c) 2004 Gerd Knorr + D. Bahi + */ +#include <linux/kernel.h> +#include <linux/init.h> +#include <linux/notifier.h> + +#include "init.h" +#include "os.h" + +static int core_on_panic_func(struct notifier_block *self, unsigned long unused1, + void *unused2) +{ + static int recurse = 0; + + /* cleanup so we have less to cleanup [linux] on the host */ + /* could panic in uml_cleanup though so we need a check */ + if (0 == recurse++) + uml_cleanup(); + + /* to prevent keyboard from causing terminal to spew during dump */ + block_signals(); + + /* actually dump ... */ + abort(); + + /* not reached */ + return 0; +} + +static struct notifier_block core_on_panic_notifier = { + .notifier_call = core_on_panic_func, + .priority = 1, +}; + +static int core_on_panic = 0; + +static int __init core_on_panic_setup(char *str) +{ + core_on_panic = 1; + return 0; +} + +static int __init core_on_panic_init(void) +{ + if (core_on_panic) + notifier_chain_register(&panic_notifier_list, &core_on_panic_notifier); + return 0; +} + +__initcall(core_on_panic_init); +__setup("coreonpanic", core_on_panic_setup); +__uml_help(core_on_panic_setup, + "coreonpanic\n" + " This flag make it so that UML will dump core on a kernel panic or segfault.\n" + " Shell environment restrictions on cores (limit or ulimit) still apply.\n" + "\n" + " Beware that your UML will not reboot with this flag.\n" +); + |