Anyone seen 4.8-RELEASE running on a real 386 (not 486 586 etc) ?

[Julian Stacey]

Erik Trulsson wrote:
> On Thu, Apr 10, 2003 at 08:43:04PM +0200, Julian Stacey wrote:
> > Anyone seen 4.8-RELEASE running on a real 386 processor (not a 486, 586 etc
> 
> Try the following patch.
> Makes my 386sx/33 work fine at least.
> (Without it I get the same panic as you do.)

This works :-)  I'm now running 4.8, Thanks !

-----------

> From: John Baldwin <jhb at FreeBSD.org>

> > Try the following patch.
> > Makes my 386sx/33 work fine at least.
> > (Without it I get the same panic as you do.)
> 
> Oh my, I hope that isn't it.  If so it's my fault. :(
> 
> Hmm, can you try this patch instead?
> 
> http://www.FreeBSD.org/~jhb/patches/4x_386.patch

Thanks, but these patches Did Not fix the problem. They also did not apply
cleanly to 4.8, perhaps made against current or stable ?
whatever, it was easy to see what you intended, so I produced a 4.8
compliant set, including both Erik's & yours commented out at:

http://www.berklix.com/~jhs/src/bsd/fixes/freebsd/src/gen/sys/i386/i386/i386_cpu.REL=4.8-RELEASE.diff

I'm not sure if Erik's one line patch is good to commit for all
processors (I haven't read the logic, just know i fixes my 386).
If anyone want to send me new patches to test before they commit,
feel free.  Ideally that would be in next day or so, before I return
machine to remote service (where boot failure is inconvenient, but
I could test later too if necessary).

--------------

> From: Peter Jeremy <peterjeremy at optushome.com.au>
> 
> AFAIK, the only difference is external bus width (SX is 16 bit, DX is
> 32 bit).  It's only 486 where the SX means half the CPU doesn't work.

Thanks, I'd forgotten that.

> >I recall 386 support was dropped in 5.0, but presume not dropped in 4.8,
> 
> It's only dropped in 5.0 GENERIC - you should still be able to compile
> your own kernel with I386_CPU specified (and all other CPU options removed).

I built one, but it hung, but no problem, it probably wanted 5 instead
of 4 type entries in /dev & /boot, maybe later I'll try 5 on that
box, but for now I want it as a 4 service machine so dont want to
change dev & boot, thanks though.

> More useful would be a debug kernel and a crash dump.  You can then
> use gdb on it and find the offending line of source code.

Yes, sorry I missed that.

> >   Fatal trap 1: priveleged instruction fault while in kernel mode
> >   instruction pointer = 0x8:0xc02695a0
> 
> If you can't get a crash dump, do an 'nm -n' on the kernel and find
> the function containing this address.

Not sure what the 0x8: means (I hated segmented 8086 asm from day one :-)

c02693cc T pmap_mincore
c02694a8 T pmap_activate
c026950c T pmap_addr_hint
c0269534 T pmap_pte
c0269570 T pmap_kenter
c02695a8 T pmap_kremove
c02695d8 T procfs_read_regs
c02695f8 T procfs_write_regs
c0269618 T procfs_read_dbregs

> >   stopped at 0xc02695a0:     invlpg  0(%ecx)
> 
> invlpg doesn't exist on i386 - you have to invalidate the entire TLB.
> It looks like someone forgot to protect an invlpg instruction.

OK, Erik & John seem to have a handle on this, thanks.

-
Julian Stacey       Freelance Systems Engineer, Unix & Net Consultant, Munich.