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>
index | next in thread | previous in thread | raw e-mail
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. Brucehome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040401215645.D6727>