Date: Thu, 1 Apr 2004 22:13:01 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Jean-Baptiste Quenot <jb.quenot@caraldi.com> Cc: orlando.bassotto@ieo-research.it Subject: Re: VMware3 on recent 5.2-CURRENT Message-ID: <20040401215645.D6727@gamplex.bde.org> In-Reply-To: <20040401081311.GA32457@anyware12.anyware> References: <20040324174618.GA18920@anyware12.anyware> <20040331214459.F657@odysseus.silby.com> <20040401081311.GA32457@anyware12.anyware>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 1 Apr 2004, Jean-Baptiste Quenot wrote: > Since I upgraded to 5.2-CURRENT, the system crashes as soon as the vmmon > module is loaded, with or without WITNESS. Disabling ACPI by typing 2 > at the boot prompt does not help either. > > Please find below some transcriptions of the panics. If you need > complete stack traces, I can manage to do it... > > ------------------------------------------------------------------------ > Booting with WITNESS disabled > ------------------------------------------------------------------------ > on pre-existing device (maj=0, min=0, name=console) > at line 495 in file /usr/src/sys/kern/kern_conf.c > cpuid=0; Device 0,0 has magic initialization in kern_conf.c, and anyway, it is an error to initialize a device twice. This error is detected and causes a panic if INVARIANTS is configured. > > db> trace > __panic make_dev() detects the vmware bug and panics. > make_dev +0x98 Here vmware apparently initializes the device twice. > init_module +0x83 > vmmon_modevent +0x2d > module_register_init +0x5a > linker_file_sysinit +0x7d > linker_load_file +0xdd > linker_load_module > kldload > syscall > > db> panic > > Fatal trap 3: breakpoint instruction fault while in kernel mode The ddb command "panic" has been broken for many years, at least if the debugger_on_panic sysctl is enabled. Although I wrote it, I'm not sure if it ever worked. Now it results in the debugger attempting to reenter itself via a breakpoint instruction. This never worked, and is detected (at last now). Control is returned to trap() and trap() panics again with the above message. So we're nested 3 deep in panics: first there is the primary panic, then the one from ddb, then the one for ddb's panic command shooting ddb. This is unrelated to the vmware bug. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040401215645.D6727>