Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!metro!natmlab.dap.csiro.au!ditsydh.syd.dit.CSIRO.AU!evans
From: evans@syd.dit.CSIRO.AU (Bruce.Evans)
Newsgroups: comp.os.minix
Subject: Re: Receiving General Protection panic from 386 Minix
Keywords: general protection 386
Message-ID: <1990Oct3.082810.18880@syd.dit.CSIRO.AU>
Date: 3 Oct 90 08:28:10 GMT
References: <1990Sep22.055445.15470@dsuvax.uucp>
Organization: CSIRO Division of Info Tech, Sydney, Australia
Lines: 55

In article <1990Sep22.055445.15470@dsuvax.uucp> ghelmer@dsuvax.uucp (Guy Helmer) writes:
>I just built the 386 version of MINIX, and I've been searching for
>the source of this error for several hours now.  I receive a
>general protection from process number 1, pc = 0x0007:0x00000385
>and the friendly "Kernel panic: exception in kernel, mm, or fs"
>message immediately after pressing the '=' key at the boot menu.
>I'm trying to run this without shoelace or db.

Warren Toomey has already answered this. This reply has been delayed
by news timewarp.

The problem is that the 16-bit "build" messes up the 32-bit image with
the default number of buffers, because it uses unsigned to hold various
sizes, and silently truncates the long bss size in fs's exec header.
The 32-bit build seems to work OK but I still recommend shoelace.

The main other problem with building Minix-386 (again using the new
build) was that the makefile didn't cover "db". Add this:
---
AS86		=as -0 -a
LD86		=ld -0

/etc/db: db.s
	$(AS86) -o db.o db.s
	$(LD86) -o /etc/db db.o
	rm db.o
---

>For the gurus that have built 386 kernels that work, am I right
>in believing that the code segment of the above address (0x0007)
>is the segment descriptor for the BIOS code segment that the

No. 0x0007 = 0000 0000 0000 0 1 11 binary.
             ssss ssss ssss s t pp
Where 's' = descriptor table index (= 0), 't' = LDT/GDT table selector
(= 1 for LDT), 'p' = privilege level (= 3 for servers and users/0).
The index is never 0 for GDT entries so we can tell this is an LDT
selector without looking at the table selector bit. For servers and
users, the CS selector is always 0x0007 and the DS selector is always
0x000F so very little can be decided from the selector alone.

The next step in debugging is to look at the processes number:

>general protection from process number 1, pc = 0x0007:0x00000385

Assuming the kernel itself is working, this says that the faulty
task is FS and something bad happens at address 0x385 in the code
segment. The next step is to disassemble around address 0x385 using
db after stopping the boot at a convenient breakpoint, or using mdb 
on the fs binary on a working system. Either the instruction or the
data it references it could be wrong. In this case I think the trap
is caused by a data reference beyond the end of the data segment.
Build has caused the data segment to be too small.
-- 
Bruce Evans		evans@syd.dit.csiro.au