From owner-freebsd-current  Fri Jan 19 23:36:42 1996
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id XAA15161
          for current-outgoing; Fri, 19 Jan 1996 23:36:42 -0800 (PST)
Received: from uni-sb.de (uni-sb.de [134.96.7.230])
          by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id XAA15154
          for <current@freebsd.org>; Fri, 19 Jan 1996 23:36:28 -0800 (PST)
Received: by uni-sb.de with ESMTP; Sat, 20 Jan 1996 08:36:05 +0100 (MET)
Received: by cs.uni-sb.de with ESMTP; Sat, 20 Jan 1996 08:36:03 +0100 (MET)
Received: (from rock@localhost)
          by wurzelausix.CS.Uni-SB.DE (8.7.3/wjp-SVR4/951126s)
          id IAA02800; Sat, 20 Jan 1996 08:36:08 +0100 (MET)
Date: Sat, 20 Jan 1996 08:36:08 +0100 (MET)
From: "D. Rock" <rock@wurzelausix.CS.Uni-SB.DE>
Message-Id: <199601200736.IAA02800@wurzelausix.CS.Uni-SB.DE>
To: current@freebsd.org
Subject: Re: current kernel panics on boot (Re: machdep.c, pmap.c and i386 CPUs)
X-Sun-Charset: US-ASCII
Sender: owner-current@freebsd.org
Precedence: bulk

> Don't know if this is related, but just compiled the newest kernel
> as of about 5PM this afternoon, and on boot up, it fails right after
> the "Copyright (c)..." line.
> 
> Fatal trap 1: privileged instruction fault while in kernel mode
> instruction pointer:	0x8:0xf019c5ec
> code segment:		base 0x0, limit 0xfffff, type 0x1b
> 			DPL 0, pres 1, def32 1, gran 1
> processor eflags:	resume, IOPL = 0;
> current process:	0 ()
> interrupt mask:		net tty bio
> kernel: type 1 trap, code=0
> Stopped at	0xf019c5ec:	invlpg	0(%eax)
> 
> And a trace comes up with a bunch of lines starting with (null)
> and that is it...
> 
> Oh...and its a 386 CPU
> 
> Marc G. Fournier | POP Mail  Telnet Acct  DNS Hosting
> System           |  WWW Services   Database Services  | Knowledge, 
>   Administrator  |                                    | Information and
>  scrappy@ki.net  |      WWW: http://www.ki.net        | Communications, Inc
> 
> 
This was exactly my problem. The machine panics at this point (in pmap.c):

static __inline void
pmap_update_1pg( vm_offset_t va) {
#if defined(I386_CPU)
        if (cpu_class == CPUCLASS_386)
                pmap_update();
        else
#endif
                __asm __volatile(".byte 0xf,0x1,0x38": :"a" (va));
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
}
After initializing cpu_class in /sys/i386/i386/machdep.c to a reasonable
value (CPUCLASS_386) the problem went away. I don't know of any negative
side effects on other processors, but I don't think there will be any
(what is worse: an unitialized variable or a variable initialized with
the wrong value?)

Daniel