This seems odd. I'm running 2.3.99-pre9.1 with the classzone patch and I
need to change three lines in the vmmon and vmnet drivers to make it
work. It's been working great since and has actually been quite a bit
more responsive than before. Maybe I'm missing something in this, but I
have had no crashes or failures of the virtual machine in my current
configuration.
All in all though, it would be better if my company hadn't forced
Outlook down my throat, then I wouldn't need a VM in the first place.
Ah, it's good to be home in a Microsoft free environment. :o)
John
Petr Vandrovec wrote:
>
> Hi Ingo,
> was there good reason for moving software IPI calls from
> vectors 0x30/0x40/0x41 to 0xfd/0xfc/0xfb ? It brokes again
> VMware vmmon/vmnet (like every previous 2.3.99-preX did... are we
> really in any freeze?!), finaly moving it into state where
> it is not possible to fix it in vmmon code and change to VMware's
> non-GPLed code is required :-( [ok, I can try to create binary
> patch for vmware binary, but before I'll try that I'd like to know
> whether this is last IPI vectors move before 2.4.0 ;-) ]
> Thanks,
> Petr Vandrovec
> vandrove@vc.cvut.cz
>
> P.S.: Memory management in plain 2.3.99-pre9.1 is not still complete
> bugfree. Machine with 256MB of RAM, VMware doing 192MB virtual machine
> get killed (swap usage was 680kB (!) at time of kill. I just do not know
> why I have 0.5GB swapfile :-( ) But it is certainly much better than
> pre6/pre7 series.
>
> P.P.S.: If you want to run VMware on 2.3.99-pre9.1 (and laters), you
> must apply this patch. Unfortunately, change to hw_irq.h causes
> recompilation of whole kernel :-(
>
> diff -urN vger/include/asm-i386/hw_irq.h linux/include/asm-i386/hw_irq.h
> --- vger/include/asm-i386/hw_irq.h Mon May 15 16:51:35 2000
> +++ linux/include/asm-i386/hw_irq.h Mon May 15 17:27:23 2000
> @@ -36,17 +36,28 @@
> *
> * Vectors 0xf0-0xfa are free (reserved for future Linux use).
> */
> +//#define SPURIOUS_APIC_VECTOR 0xff
> +//#define ERROR_APIC_VECTOR 0xfe
> +//#define INVALIDATE_TLB_VECTOR 0xfd
> +//#define RESCHEDULE_VECTOR 0xfc
> +//#define CALL_FUNCTION_VECTOR 0xfb
> +/* Read from APIC, so OK */
> #define SPURIOUS_APIC_VECTOR 0xff
> +/* Read from APIC, so OK */
> #define ERROR_APIC_VECTOR 0xfe
> -#define INVALIDATE_TLB_VECTOR 0xfd
> -#define RESCHEDULE_VECTOR 0xfc
> -#define CALL_FUNCTION_VECTOR 0xfb
> +/* Software... */
> +#define INVALIDATE_TLB_VECTOR 0x30
> +/* Software... */
> +#define RESCHEDULE_VECTOR 0x40
> +/* Software... */
> +#define CALL_FUNCTION_VECTOR 0x41
>
> /*
> * Local APIC timer IRQ vector is on a different priority level,
> * to work around the 'lost local interrupt if more than 2 IRQ
> * sources per level' errata.
> */
> + /* Read from APIC, so OK */
> #define LOCAL_TIMER_VECTOR 0xef
>
> /*
> @@ -54,7 +65,9 @@
> * we start at 0x31 to spread out vectors evenly between priority
> * levels. (0x80 is the syscall vector)
> */
> -#define FIRST_DEVICE_VECTOR 0x31
> +/* We need 0x40/0x41/0x50 unused */
> +//#define FIRST_DEVICE_VECTOR 0x31
> +#define FIRST_DEVICE_VECTOR 0x51
> #define FIRST_SYSTEM_VECTOR 0xef
>
> extern int irq_vector[NR_IRQS];
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/
-- *********************************Tell me and I may forget, Show me and I may remember, Involve me and I will understand.
*********************************
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon May 15 2000 - 21:00:26 EST