From: Blaisorblade <bla...@ya...> - 2004-11-04 18:33:21
|
You can find all on http://www.user-mode-linux.org/~blaisorblade/. The SKAS3/2.6-v7 was already released, but I probably forgot to announce it= =2E=20 So I'm announcing it now. Changes in SKAS: * echo 0 > /proc/sysemu on the guests works fine, finally! Changes in both 2.6.9 and 2.4.27: they run fine on 2.6.9 host kernels, without hanging at the exit. Changes in 2.6.9 only: included a large chunk of JDike tree (excluding all x86_64 related patches)= ,=20 and all the latest security patches from Bodo Stroesser; also it includes t= he=20 =2DV7 skas patch in it. Actually, however, to do this I had to include big, invasive patches from J= eff=20 Dike's tree. I've done it because it's needed and because Bodo Stroesser=20 worked with the incrementals very fine. Changes in 2.4.27 only: It's based on a fork from the official 2.4.24-1; the patches I've included= =20 come almost totally from there, but I dropped all the hostfs rewrite. I als= o=20 included some incrementals, the one I thought safe. Also, you can find on the page the instructions to avoid the "hwclock hang"= in=20 TT mode. I found the faulty patch, but it needs a more worse bug, which=20 affects everyone running in TT mode on a 2.6 host, so it's included. You ca= n=20 revert the patch if you want, and if you have to run it on a 2.4 host. I se= nt=20 a message about this about a week ago, but I got no answer. Distribution: * the patch are also in split-out form, both web-browsable and tarballed. * md5sums are available (to test with "md5sum -c *.md5"). Any testing and report is welcome. Bye =2D-=20 Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 |
From: kaz <shi...@ya...> - 2004-11-04 21:44:30
|
Hi, Blaisorblade wrote: > > The SKAS3/2.6-v7 was already released, but I probably forgot to announce it. > So I'm announcing it now. host-skas3-2.6.9-v7.patch failed with 2.6.8.1. The error message was as below; ~linux-2.6.8.1$ cat ../host-skas3-2.6.9-v7.patch | patch -p1 patching file arch/i386/kernel/entry.S Hunk #1 succeeded at 258 with fuzz 2 (offset 2 lines). Hunk #2 FAILED at 280. 1 out of 3 hunks FAILED -- saving rejects to file arch/i386/kernel/entry.S.rej patching file arch/i386/kernel/ptrace.c Hunk #2 succeeded at 358 (offset -1 lines). Hunk #3 succeeded at 366 with fuzz 1 (offset -1 lines). Hunk #4 succeeded at 417 (offset -3 lines). Hunk #5 succeeded at 524 (offset -4 lines). Hunk #6 succeeded at 589 (offset -4 lines). Hunk #7 FAILED at 600. Hunk #8 succeeded at 632 (offset -5 lines). 1 out of 8 hunks FAILED -- saving rejects to file arch/i386/kernel/ptrace.c.rej patching file include/asm-i386/thread_info.h Hunk #2 FAILED at 153. 1 out of 2 hunks FAILED -- saving rejects to file include/asm-i386/thread_info.h.rej patching file include/linux/ptrace.h patching file kernel/fork.c Hunk #1 succeeded at 1008 (offset -32 lines). patching file include/linux/mm.h Hunk #1 succeeded at 575 (offset -48 lines). Hunk #2 succeeded at 636 (offset -49 lines). patching file include/linux/proc_mm.h patching file mm/Makefile Hunk #1 FAILED at 18. 1 out of 1 hunk FAILED -- saving rejects to file mm/Makefile.rej patching file mm/mmap.c Hunk #1 succeeded at 736 (offset -23 lines). Hunk #2 succeeded at 1006 (offset -28 lines). patching file mm/mprotect.c Hunk #2 succeeded at 186 (offset -2 lines). Hunk #3 succeeded at 217 (offset -2 lines). Hunk #4 succeeded at 288 (offset -2 lines). patching file mm/proc_mm.c patching file arch/i386/Kconfig Hunk #1 succeeded at 757 (offset 33 lines). patching file arch/i386/kernel/ldt.c Hunk #6 succeeded at 172 (offset -5 lines). Hunk #7 succeeded at 197 (offset -5 lines). Hunk #8 succeeded at 233 (offset -5 lines). patching file arch/i386/kernel/sys_i386.c patching file include/asm-i386/desc.h Hunk #1 succeeded at 124 (offset -2 lines). patching file include/asm-i386/ptrace.h Hunk #1 succeeded at 59 with fuzz 1 (offset -5 lines). patching file include/asm-i386/mmu_context.h Hunk #3 FAILED at 66. 1 out of 3 hunks FAILED -- saving rejects to file include/asm-i386/mmu_context.h.rej patching file arch/um/include/skas_ptrace.h patching file localversion-skas |
From: kaz <shi...@ya...> - 2004-11-04 21:55:43
|
Hi, kaz wrote: > > host-skas3-2.6.9-v7.patch failed with 2.6.8.1. The error message was as below; Sorry. host-skas3-2.6.7-v7.patch finely applied to 2.6.8.1. $ cat ../host-skas3-2.6.7-v7.patch | patch -p1 patching file arch/i386/kernel/entry.S patching file arch/i386/kernel/ptrace.c patching file include/asm-i386/thread_info.h patching file include/linux/ptrace.h patching file kernel/fork.c Hunk #1 succeeded at 1008 (offset -1 lines). patching file include/linux/mm.h Hunk #1 succeeded at 575 (offset 1 line). Hunk #2 succeeded at 636 (offset 1 line). patching file include/linux/proc_mm.h patching file mm/Makefile patching file mm/mmap.c Hunk #1 succeeded at 736 (offset 11 lines). Hunk #2 succeeded at 1006 (offset 18 lines). patching file mm/mprotect.c Hunk #3 succeeded at 217 (offset 6 lines). Hunk #4 succeeded at 288 (offset 6 lines). patching file mm/proc_mm.c patching file arch/i386/Kconfig Hunk #1 succeeded at 757 (offset 37 lines). patching file arch/i386/kernel/ldt.c patching file arch/i386/kernel/sys_i386.c patching file include/asm-i386/desc.h Hunk #1 succeeded at 124 (offset 1 line). patching file include/asm-i386/ptrace.h patching file include/asm-i386/mmu_context.h patching file arch/um/include/skas_ptrace.h |
From: Brice G. <Bri...@en...> - 2004-11-04 21:57:12
|
kaz wrote: >=20 > host-skas3-2.6.9-v7.patch failed with 2.6.8.1. The error message was a= s below; This is why it is called host-skas3-2.6.9-v7.patch and not host-skas3-2.6.8.1-v7.patch Regards -- Brice Goglin =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Ph.D Student Laboratoire de l'Informatique et du Parall=C3=A9lisme CNRS-ENS Lyon-INRIA-UCB Lyon France |
From: Blaisorblade <bla...@ya...> - 2004-11-04 23:46:03
|
On Thursday 04 November 2004 21:30, jm...@gm... wrote: > > You can find all on http://www.user-mode-linux.org/~blaisorblade/. > > The SKAS3/2.6-v7 was already released, but I probably forgot to announce > > it. > > So I'm announcing it now. > > > > Changes in SKAS: > > * echo 0 > /proc/sysemu on the guests works fine, finally! > > > > Changes in both 2.6.9 and 2.4.27: > > they run fine on 2.6.9 host kernels, without hanging at the exit. Correction 1: for 2.6.9-bb1 (I maybe wasn't clear) and 2.4.27-bs1. > don't work for me. > my host is an 2.6.9 and uml is hanging after shutdown. Which UML version, please? 2.4 or 2.6? I tested the 2.6 one (make sure to do a "make clean ARCH=um" before recompiling), but not the 2.4 one yet, maybe. However, if you have this problem, please make sure you're using Uml 2.6.9-bb1 and compiling it from a clean tree. Also, try to see if it is the same kind of hang (which should be solved) or another one (which is, indeed, possible to happen). > > Changes in 2.6.9 only: > > included a large chunk of JDike tree (excluding all x86_64 related > > patches), > > and all the latest security patches from Bodo Stroesser; also it includes > > the > > -V7 skas patch in it. -- Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 |
From: Allen C. <al...@us...> - 2004-11-05 19:21:42
|
I just compiled a 2.6.9 + uml-2.6.9-bb1.patch.bz2 guest kernel, but it hangs on my system immediately after: ... Initializing software serial port version 1 Using anticipatory io scheduler /dev/ubd/disc0: unknown partition table Initializing stdio console driver My host kernel is 2.6.9-skas-v7 on Debian unstable. My previous guest kernel (2.6.9 + JDike Incrementals + ptrace() hang patch) works flawlessly under the same conditions. The http://www.user-mode-linux.org/~blaisorblade/ site appears to be inaccessible at this moment. When the site comes back up, I will try to play with the broken out version of the 2.6.9-bb1 patches to see if the cause of this problem can be isolated. On Thursday 04 November 2004 01:32 pm, Blaisorblade wrote: > You can find all on http://www.user-mode-linux.org/~blaisorblade/. > Any testing and report is welcome. |
From: Allen C. <al...@us...> - 2004-11-06 03:17:34
|
OK. The problem was due to user error in not setting the=20 configuration option CONFIG_FD_CHAN properly. When this option is=20 set to "Y", everything appears to work fine again. Just in case anyone else runs into this, here's what happened. In the=20 UML Incremental Patches site, the no-chans patch had dealt with this=20 possible problem by removing the CONFIG_FD_CHAN configuration option=20 from the config file. However, the bb1 patch does not contain the=20 no-chans patch, so it requires that the CONFIG_FD_CHAN option be put=20 back. For some reason, CONFIG_FD_CHAN defaulted to "N" when prompted=20 for on the screen as a new configuration option while doing a "make=20 oldconfig ARCH=3Dum" using an existing config file. On Friday 05 November 2004 02:21 pm, Allen Chan wrote: > I just compiled a 2.6.9 + uml-2.6.9-bb1.patch.bz2 guest kernel, > but it hangs on my system immediately after: > =20 > =A0 Initializing stdio console driver |
From: Nuutti K. <na...@ik...> - 2004-11-08 12:28:27
|
Blaisorblade wrote: > Changes in both 2.6.9 and 2.4.27: > they run fine on 2.6.9 host kernels, without hanging at the exit. I want to get this clear: Every older guest UML kernel will hang on exit on 2.6.9 hosts from now on, and there's nothing to fix it but to update the guest UML patches? This is a nasty limitation in general - because it means that on the update to 2.6.9, every kernel binary needs to be updated - and finding rock solid versions of kernels + UML patches is not a fast process. -- Naked |
From: Blaisorblade <bla...@ya...> - 2004-11-09 17:44:02
|
On Monday 08 November 2004 13:28, Nuutti Kotivuori wrote: > Blaisorblade wrote: > > Changes in both 2.6.9 and 2.4.27: > > they run fine on 2.6.9 host kernels, without hanging at the exit. > > I want to get this clear: > Every older guest UML kernel will hang on exit on 2.6.9 hosts from now > on, and there's nothing to fix it but to update the guest UML patches? > This is a nasty limitation in general - because it means that on the > update to 2.6.9, every kernel binary needs to be updated - and finding > rock solid versions of kernels + UML patches is not a fast process. Yes, I perfectly agree with you. However, there are, for 2.6, the security fixes which are needed. Well, it is possible that 2.6.10 (or even 2.6.11) will make again old UML binaries work. I.e., this is my hope, but no code is ready for this, yet. In fact, Linus always said "binary compatibility is important". UML was using a strange undocumented, and unwanted interface, but this is not a good reason for the kernel to break it. I think they did not even notice that. Also, however, I find that the breakage is a real bug. The splitout version of the patches is available, and the uml-hang-on-2.6.9-host.patch is the one to apply. For 2.4, it cannot be applied separately, though (it requires one of the current incrementals, which is included in the patchset). Unfortunately, it does not work on most kernel versions - it can be adapted, though, and if I find time, I will. -- Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 |
From: Bodo S. <bst...@fu...> - 2004-11-09 18:07:11
|
Blaisorblade wrote: > Any testing and report is welcome. OK. 2.6.9-bb1 is a fine list of patches! The first tests as UML are OK. At the moment, I saw one small problem only in uml-refuse-to-run-if-no-tt-mode-in.patch Use the following patch to fix it: --- --- a/arch/um/kernel/um_arch.c 2004-11-09 18:27:10.343338760 +0100 +++ b/arch/um/kernel/um_arch.c 2004-11-09 18:27:21.676615840 +0100 @@ -314,7 +314,7 @@ int linux_main(int argc, char **argv) mode_tt = force_tt ? 1 : !can_do_skas(); #ifndef CONFIG_MODE_TT - if (!mode_tt) { + if (mode_tt) { printf("Support for TT mode is disabled, and no SKAS support is present on the host.\n"); exit(1); } |
From: Blaisorblade <bla...@ya...> - 2004-11-09 18:50:02
|
On Tuesday 09 November 2004 19:06, Bodo Stroesser wrote: > Blaisorblade wrote: > > Any testing and report is welcome. > > OK. 2.6.9-bb1 is a fine list of patches! The first tests as UML > are OK. At the moment, I saw one small problem only in > uml-refuse-to-run-if-no-tt-mode-in.patch > Use the following patch to fix it: Yes, the problem was reported and I already was queueing up the fix. Btw, how can you do so much for UML? Thanks a lot for what you're doing. Bye -- Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 |