[ On Thu, November 20, 1997 at 07:54:32 (GMT), Greg A. Woods wrote: ]
> Subject: Re: mapped device panic (fix)
>
> [ On Wed, November 19, 1997 at 20:33:24 (GMT), Gordon W. Ross wrote: ]
> > Subject: mapped device panic (fix)
> >
> > Here is the final fix (I hope).  This is what will appear in
> > the release, as soon as the releng people do their thing.
> 
> I downloaded the Nov 19 sys.tar.gz from netbsd.org (since that's all the
> space I've got available) and applied the pmap-88 patch Gordon posted.
> (Kernel build on MOUSETRAP, a 2-spindle 3/260 w/32MB:  2h34m)

(just three hours to build even in parallel with /etc/daily!)

Nope, it does not work here.  The GENERIC kernel has a slightly
different behaviour -- it freezes after trying to start xterms (xclock
appears) [well the mouse cursor and keyboard caps lock freeze].  When I
reboot from the DDB I then get:

	db>reboot
	syncing disks... done
	trap type=0x8, code=0x145, v=0xa8
	kernel: MMU fault trap
	Caught exception in ddb.
	db>

A second reboot then successfully calls the EPROM. 

Note this is on a diskless 3/60 (well a CD-ROM), 12MB RAM, and using the
bwtwo frame buffer.  I'm booting from the NetBSD server where I built
the kernel.

Gordon, even though your machines are headless, you should be able to
start the X server on them as most should have at least bwtwo, no?

Now that it's had time to reboot let's see if it freezes the same way
and maybe I can copy the trace from the other screen too...

Still running, but:
	/netbsd: nfs send error 55 for server sometimes:/export/swap/very

Hmm.... Twm started, and can pop up its menu, but everything else on the
machine seems frozen (no inetd services respond though connections are
made).  Xclock is running -- it moved the minute hand.  Oh, now twm
froze when I popped up the menu again, and yes, the keyboard is frozen
too.  It still responds to ping though....

DDB's ps shows six xterm processes (just like the first time I
remember), and it seems they were unable to start their shells.
One seems hung in netio, but the rest are in thrd_sleep.

The trace ends similarly to the way it did before but there's a few more
lines (clock) in it this time:

_Debugger(4d,e575c00,eef5df0,e0cd82c,e56ba30) + 6
_zs_abort(e56ba30,20,0,0,ffffffff) + 24
_kbd_rxint(e56ba30) + 5e
_zsc_intr_hard(e56ba00) + 42
_zshard(0) + 26
_isr_autovec(f4240,34746f92,0,0,21000e07) + 60
__isr_autovec(0) + 4
_softclock(3,e0ec47c,e588c0,e588c00,e0d4360) + 42
_hardclock(eef5ec0,eef5f00,e0043e6,20,0) + 180
_clock_intr(20,0,e0e6494,eef2000,20000e00) + 2a
__isr_clock(?)
_mi_switch(0,6f,20c139e,0,0,148) + 4
_tsleep(eef2184,128,0e18b82,0) + 132
_sys_sigsuspend(e588c00,eef5f84,eef5f7c) + 36
_syscall(6f) + 184
_trap() + e

(*that's all hand typed by just me staring at the other screen!)

I don't remember if it was the same syscall(6f) as before or not, but
I'm pretty sure it was....

In any case it seems essentially repeatable....

The 3/260 server is still running the 11/17 (pre pmap-88.c) kernel at
nearly 24 hours, and has done all the boot serving, kernel building,
etc. without any problems.

-- 
							Greg A. Woods

+1 416 443-1734      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>