On Thu, 2004-12-30 at 22:18, Matthew Orgass wrote:
> On 2004-12-30 matt@bodgit-n-scarper.com wrote:
> > On Thu, 2004-12-30 at 03:53, Matthew Orgass wrote:
> > > On 2004-12-29 algould@datawok.com wrote:
> > >
> > > > I've been having trouble installing NetBSD 2.0 on NEC MobilePro 780.
> > > >
> > > > Attempt #1:
> > > > I was able to get the 2GB Microdrive partitioned in the CF port.  I had
> > > > copied the contents of the installation CD onto a 128 MB memory card
> > > > which was in a PCMCIA adapter/slot.  (This worked when I installed
> > > > 1.6.2 onto a 1GB microdrive in the past.)  I was able to mount the
> > > > memory card; but I got the following message when the installer tried
> > > > to untar kern-GENERIC.tgz:
> > > >
> > > > panic: TLB out of universe: ksp 0xc2991fb8  epc 0x8014aee8  vaddr
> > > > 0xae71f000
> > > > Stopped at 0x801cdeb8:   jr   ra
> > > >                 bdslot:  nop
> > > > db>
> > >
> > >   If the booted kernel is same as installation/netbsd.gz then the epc is
> > > in panic, the first sw to the stack.  A trace would be helpful in any
> > > case.  It is possible that this is related to port-hpcmips/26158.
> >
> > Hmm, would that PR explain why my z50 keeps generating those 'TLB out of
> > universe' panics? I can't get the installer to complete in a similar
> > situation to the original poster, although this was still 1.6.2 last
> > time I tried.
> 
>   It might, although it could easily be something else.  The problem in
> the PR is that low priority interrupts are enabled while high priority
> interrupts are being processed, which could cause all sorts of odd
> behavior.  The interrupt code is the same in 1.6.2, but other code changes
> later caused it to be more visible on my Clio 1000, usually in the form of
> hangs although I do recall getting TLB out of universe occasionally as
> well.  The reason it isn't more of a problem is because current code has
> only three priorities in vr_intr: clock, soft interrupts, and everything
> else, and normally interrupt activity is not very high on hpcmips
> machines.
> 
> > I can dig it out and try the patches in the PR if that would help.
> 
>   I would say don't go out of your way to try it since that kind of
> problem can often disappear or reappear with any kernel changes so only
> continued presence would say anything.  A trace from the panic is more
> likely to help identify the problem, but it could be useless also.  I
> put a copy of the second patch (unmangled by the html PR display method
> and with a few other small changes to other files) at:
> http://www.city-net.com/~darkstar/netbsd/hpcmips.diff

Right, finally got time to look at this.

I cross-compiled current sources checked out as of yesterday, Workpad
z50, 256MB Lexar 8x CF card and an ne(4) PCMCIA network card.

My initial plan was to just unpack on an NFS share and run the Workpad
from that for the time being, so using the CF card with just a copy of
the GENERIC kernel, pbsdboot.exe and hpcboot.exe (Does it matter which?
Both seem to work here). However, with either my current GENERIC[*]
kernel or the one from the 2.0 release on the FTP server, I can't get
the Workpad to run from an NFS root. I boot from ne0, correct DHCP
settings from server, and NFS export is mounted from server, then I'm
prompted for the path to init. Hit the default for /sbin/init and then
nothing apart from a brief flash of activity from the network card. I've
set the NFS export up as per the diskless docs. Any idea why it doesn't
work?

So instead I went back to installing onto the CF card (with a small ~
5MB FAT partition to boot from) over the network. I used my
cross-compiled current, put the install kernel and miniroot bits onto
the CF, and booted the installer, partition/label the disk and pick just
kernel, base and etc to install, from an NFS export from the same
machine that was used for the NFS root originally.

~6% into installing base, it hung, so I rebuilt my current release from
scratch with the patch from the above URL, so that all the kernels would
be patched, and repeated. This time, I'm happy to say, it went all the
way :-) which previous to this patch I've never managed to do with
1.6.x.

[*] The problem I now have is my GENERIC kernel by default can't detect
the PCMCIA slots:

pcmcia at pcic0 controller 1 socket 0 not configured
pcmcia at pcic0 controller 1 socket 1 not configured

The GENERIC kernel config has:

pcmcia* at pcic? controller 0 socket ?

However, the RAMDISK kernel (which I presume is what I boot to start the
installer) detects the slots fine, and that is just a few lines of
memory disk config and the original GENERIC kernel config, so I can't
figure out why one is working and one isn't.

I can fiddle it to work by changing the config line to just:

pcmcia* at pcic? controller ? socket ?

But then I get a pcmcia3 and pcmcia4 appearing with bogus CIS.

Matt