From owner-freebsd-current Sat Oct 17 20:05:42 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA27505 for freebsd-current-outgoing; Sat, 17 Oct 1998 20:05:42 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from spinner.netplex.com.au (spinner.netplex.com.au [202.12.86.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA27500 for ; Sat, 17 Oct 1998 20:05:37 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from spinner.netplex.com.au (localhost [127.0.0.1]) by spinner.netplex.com.au (8.9.1/8.9.1/Spinner) with ESMTP id LAA23805; Sun, 18 Oct 1998 11:05:02 +0800 (WST) (envelope-from peter@spinner.netplex.com.au) Message-Id: <199810180305.LAA23805@spinner.netplex.com.au> X-Mailer: exmh version 2.0.2 2/24/98 To: Chuck Robey cc: freebsd-current@FreeBSD.ORG Subject: Re: panic In-reply-to: Your message of "Sat, 17 Oct 1998 15:50:02 -0400." Date: Sun, 18 Oct 1998 11:05:01 +0800 From: Peter Wemm Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Chuck Robey wrote: > I'm now getting a panic on startup, SMP kernel, on a config file that > was working fine a few days ago. The panic is coming in module_register > + 14. I'd give you the stack dump, but I can't seem to get a kernel > dump captured yet. > > I checked, all my LKMs are brand new. This is a fresh build for both > the world and the kernel from equal sources (no intervening cvsup or cvs > actions), with all new LKMs. Normal ELF system you'd expect. > > Panic is supervisor read, page not present. Can't tell what module it > was trying to load without the kernel dump (I think). Panic message > says it's in the swapper process, but I think that's not germane here > (is it?). I have a fault virtual address of 8be58955, I'm not sure > that's useful, seeing as I can't translate that to a module address. It is useful, but bad news. :-( It means that the SYSINIT() process got scrambled somehow. There are a bunch of sysinit's like this: static moduledata_t root_bus_mod = { "rootbus", root_bus_module_handler, 0 }; DECLARE_MODULE(rootbus, root_bus_mod, SI_SUB_DRIVERS, SI_ORDER_FIRST); .. which turns into SYSINIT(rootbusmodule, SI_SUB_DRIVERS, SI_ORDER_FIRST, module_register_init, &root_bus_mod) Effectively, this causes init_main.c to call module_register_init((void *)&root_bus_mod); module_register_init(void *arg) { moduledata_t* data = (moduledata_t*) arg; error = module_register(data->name, data->evhand, data->priv, data->_file); } module_register(const char* name, modeventhand_t handler, void* arg, void *file) { size_t namelen; namelen = strlen(name) + 1; ^^^^^^^^^^^^ Here is where it's crashing. And there's the dilemma. Either the name in the moduledata_t struct got smashed somehow, or the sysinit process is passing the wrong pointer to module_register_init(). I picked this one out for the example for no particular reason, this has been in the kernel for a while. There are a number of these activated by new definitions of things like VFS_SET(), VNODEOP_SET(), EXEC_SET() macros in src/sys/*.h. Hmm, you don't have MATH_EMULATE or GPL_MATH_EMULATE options turned on by any chance, do you? Take them out if so. Another thought.. Please try a 'make clean' and do a rebuild of the kernel. Also, it would be helpful to know if the same problem happens with a plain a.out kernel booted from the standard bootblocks, not /boot/loader. I'd be suprised if it was different though. Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message