Here's a strange little data point regarding my zip problems.
This is in reference to my earlier post below.  What I 
stumbled onto is that if I run xdm as part of the boot
process and log in that way, I get kernel panics when
I try and access my zip drive.  Details are in my original
post.  If I instead log into the console and use 'startx'
to get X going, I can acces the zip just fine!  So anyway,
I have a workable workaround for now, but thought maybe
someone here has seen this or that this may indicate some
nasty underlying bug.

Dan


In message <199801140034.TAA18250@sandia.mtl>, Dan McMahill writes:
>
>
>I am having zip drive problems again which I can't seem
>to explain.
>
>Yesterday, I used the stock 1.3 GENERICSBC kernel, mounted
>my zip drive
>
>mount /dev/sd2g /zip
>
>put the NetBSD source on it, added Paul Goyettes SLOTMAN stuff
>to it and made myself a slotman kernel with sbc instead of
>ncrscsi (because ncrscsi did not work in the past with the zip).
>
>Everything seemed fine, I could boot the new kernel and run fine.
>The problem was with the zip.  In single user mode, I could
>do stuff like
>fsck /dev/sd2g
>and 
>mount /dev/sd2g /zip
>cd /zip
>{do file operations successfully here}
>cd /
>umount /zip
>
>and everything was fine.  BUT, if I go ahead and boot all the way
>to multi user mode (I use xdm these days) and try
>su
>mount /dev/sd2g /zip
>ls /zip
>
>I get a kernel panic.  I tried to back up and use the GENERICSBC
>kernel I used last night (I think its the same one) and I get the
>same results (ok under single user, panic under multiuser with X).
>
>
>The panic is:
>
>panic:  pmap_alloc_pv: pgi_nfree inconsistent
>stopped at _Debugger
>
>db>t
>
>  _Debugger
>  _panic
>  _pmap_alloc_pv
>  _pmap_enter
>  _vm_fault
>  _trap
>   faultstkadj
>
>db>
>
>
>My machine is a IIci, 20MB
>
>I _know_ it worked last night with GENERICSBC because I put
>all the source on the zip and complied in the zip.  I don't 
>believe I'm doing anything different today.
>
>Anyone else see this problem?
>
>Dan
>
>