Anyone seen 4.8-RELEASE running on a real 386 (not 486 586 etc)
jhs at berklix.com
Sun Apr 13 16:01:29 PDT 2003
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?
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:
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.
More information about the freebsd-hackers