similar to: [PATCH] lhype: Add LFS support to lhype_add for disk images

Hi everybody, Attracted by the puppies, I'm trying to run lhype. The patch applies cleanly to 2.6.20-rc2, my .config is in accord with lhype.txt, but when I try to launch an instance, I get this: $ sudo drivers/lhype/lhype_add 64m 0 vmlinux --tunnet=192.168.19.1 --block=linux.img root=/dev/lhba lhype_add: Failed to get DMA buffer from 0xb7fff008: No such file or directory lhype_add: network:

Hi everybody, Attracted by the puppies, I'm trying to run lhype. The patch applies cleanly to 2.6.20-rc2, my .config is in accord with lhype.txt, but when I try to launch an instance, I get this: $ sudo drivers/lhype/lhype_add 64m 0 vmlinux --tunnet=192.168.19.1 --block=linux.img root=/dev/lhba lhype_add: Failed to get DMA buffer from 0xb7fff008: No such file or directory lhype_add: network:

Hi! Bored by previous lhype success, I tried to boot a debootstrapped debian over nfsroot, and lo, this almost works! Commandline: # drivers/lhype/lhype_add 256m 0 ./vmlinux --tunnet=192.168.1.20 root=/dev/root nfsroot=/home/ahu/lhype-root ip=192.168.1.21:192.168.1.20:192.168.1.20 This with lhype.patch current as of this message and 2.9.20-rc4. The boot process stops after: Starting periodic

Hi! Bored by previous lhype success, I tried to boot a debootstrapped debian over nfsroot, and lo, this almost works! Commandline: # drivers/lhype/lhype_add 256m 0 ./vmlinux --tunnet=192.168.1.20 root=/dev/root nfsroot=/home/ahu/lhype-root ip=192.168.1.21:192.168.1.20:192.168.1.20 This with lhype.patch current as of this message and 2.9.20-rc4. The boot process stops after: Starting periodic

I am trying to experiment with lhype on a 32bit Intel box and when I launch a guest I get the following oops message: ----------- invalid opcode: 0000 [#1] Modules linked in: CPU: 0 EIP: 0061:[<c0101223>] Not tainted VLI EFLAGS: 00010246 (2.6.20-rc2 #1) EIP is at mwait_idle_with_hints+0x1e/0x3a eax: c03c8008 ebx: 00000000 ecx: 00000000 edx: 00000000 esi: 00000000 edi:

I am trying to experiment with lhype on a 32bit Intel box and when I launch a guest I get the following oops message: ----------- invalid opcode: 0000 [#1] Modules linked in: CPU: 0 EIP: 0061:[<c0101223>] Not tainted VLI EFLAGS: 00010246 (2.6.20-rc2 #1) EIP is at mwait_idle_with_hints+0x1e/0x3a eax: c03c8008 ebx: 00000000 ecx: 00000000 edx: 00000000 esi: 00000000 edi:

I get a compilation error with an undefined reference to PKMAP_BASE (on a fairly standard x86 box). This patch include asm/highmem.h, where the macro is defined. Please apply. Signed-off-by: James Morris <jmorris@redhat.com> --- diff -r 2f39210c8792 drivers/lhype/init.c --- a/drivers/lhype/init.c Mon Nov 13 17:16:49 2006 -0500 +++ b/drivers/lhype/init.c Mon Nov 13 17:23:38 2006 -0500 @@

I get a compilation error with an undefined reference to PKMAP_BASE (on a fairly standard x86 box). This patch include asm/highmem.h, where the macro is defined. Please apply. Signed-off-by: James Morris <jmorris@redhat.com> --- diff -r 2f39210c8792 drivers/lhype/init.c --- a/drivers/lhype/init.c Mon Nov 13 17:16:49 2006 -0500 +++ b/drivers/lhype/init.c Mon Nov 13 17:23:38 2006 -0500 @@

Hi all, Ingo was eloquantly passionate about hating the name lhype, so after some debate (and importantly, the rejection of both "Wonkavisor" and "Rustyvisor"), I decided to name it after the guest (which is what users care about), not the hypervisor (which is what hackers care about). Hence: lhype_add -> lguest lguest.ko -> lg /dev/lhba ->

Hi all, Ingo was eloquantly passionate about hating the name lhype, so after some debate (and importantly, the rejection of both "Wonkavisor" and "Rustyvisor"), I decided to name it after the guest (which is what users care about), not the hypervisor (which is what hackers care about). Hence: lhype_add -> lguest lguest.ko -> lg /dev/lhba ->

Hi all, Some of you know I've been working on a trivial in-kernel hypervisor to demonstrate paravirt_ops. The good news is that it works! (And not just for me!) The bad news is that I haven't written any documentation and now I'm going to be offline (moving to a farm) for several weeks. Nonetheless, if you're the kind of person who wants to poke around with hypervisors, no

Hi all, Some of you know I've been working on a trivial in-kernel hypervisor to demonstrate paravirt_ops. The good news is that it works! (And not just for me!) The bad news is that I haven't written any documentation and now I'm going to be offline (moving to a farm) for several weeks. Nonetheless, if you're the kind of person who wants to poke around with hypervisors, no

At http://namei.org/misc/lguest/patches/time/v02/ Current status: - Resync to recent upstream lguest patch queue - Rudimentary clock event device is working, but with a significant performance hit - Old TSC code included, still needs to be modified to handle freq change Next: - Check for pending interrupts after they're enabled again per suggestion from Rusty. -- James Morris

Why are these APIC clock init hooks dependent on CONFIG_X86_PAE ? include/asm/paravirt.h: static inline void setup_boot_clock(void) { paravirt_ops.setup_boot_clock(); } static inline void setup_secondary_clock(void) { paravirt_ops.setup_secondary_clock(); } (via the vmi timer patch). - James -- James Morris <jmorris@namei.org>

Currently, 020-paravirt-xen.patch contains inconsistent declarations for a bunch of native_read/write functions. This patch updates the declarations to use unsigned long for register values. Signed-off-by: James Morris <jmorris@redhat.com> --- include/asm-i386/paravirt.h | 18 +++++++++--------- 1 files changed, 9 insertions(+), 9 deletions(-) diff -purN -X dontdiff

Currently, 020-paravirt-xen.patch contains inconsistent declarations for a bunch of native_read/write functions. This patch updates the declarations to use unsigned long for register values. Signed-off-by: James Morris <jmorris@redhat.com> --- include/asm-i386/paravirt.h | 18 +++++++++--------- 1 files changed, 9 insertions(+), 9 deletions(-) diff -purN -X dontdiff

Why are these APIC clock init hooks dependent on CONFIG_X86_PAE ? include/asm/paravirt.h: static inline void setup_boot_clock(void) { paravirt_ops.setup_boot_clock(); } static inline void setup_secondary_clock(void) { paravirt_ops.setup_secondary_clock(); } (via the vmi timer patch). - James -- James Morris <jmorris@namei.org>

At http://namei.org/misc/lguest/patches/time/v02/ Current status: - Resync to recent upstream lguest patch queue - Rudimentary clock event device is working, but with a significant performance hit - Old TSC code included, still needs to be modified to handle freq change Next: - Check for pending interrupts after they're enabled again per suggestion from Rusty. -- James Morris

Hi All, I am experiencing issues with the use of DBase files on a Samba 2.0.5a share, that appear to be due to locking problems. Basically, I have test programs for both DOS and Win32 that does nothing but append records to a DBase database (DBF/MDX files). If more than one client PC is appending to this file, data loss occurs. I get random data loss, with records lost, and index file

In the Red Hat Linux spec file for the 2.2.19 kernel, there is a note not to enable ext3 and LFS at the same time. I'm wondering whether this is an old note, and that it is safe to use ext3 0.0.7a on a system with LFS enabled, or if there are still issues with it. I'm aware that 0.0.7a is a really old version, and 2.2 isn't the most modern kernel, but it is what I have to work with.