Mr Ian Primus | 13 Jul 2009 04:24
Picon
Favicon

Installing NetBSD 5.0 on MVME-147


I've got an MVME-147 here, 25mhz with 8mb of RAM. I'm attempting to install NetBSD 5.0 from tape. I'm using an
Archive Viper 150 tape drive. I have replaced the battery in the MVME-147's NVRAM module, and have gotten
the board to the point where it has the proper time and date, keeps time, sees the SCSI bus and properly
identifies the two devices - the tape drive and a 4 gig SCSI hard drive.

I have written a boot tape according to the instructions in the FAQ, and that all seems to work well. The tape
boots, loads the initial ramdisk, and starts to print messages to the screen. It identifies the SCSI
devices, etc. Then, it complains:

WARNING: preposterous TOD clock time
WARNING: using filesystem time
WARNING: CHECK AND RESET THE DATE!

This seems odd, since typing the time command at the 147-Bug> prompt returns the proper time, date and day.
(Sunday 7/12/9 22:11:24). But, this next bit is where it all goes horribly wrong:

 Mutex error: mutex_vector_enter: locking against myself

lock address : 0x000000000124cc20
current cpu  :                  0
current lwp  : 0x0000000000dae020
owner field  : 0x0000000000dae020 wait/spin:              0/0

panic: lock error

dump to dev 9,1 not possible
rebooting...

And then it reboots. Since this clears the screen, I had to quickly unplug the terminal's RS-232 cable so I
(Continue reading)

Steve Woodford | 14 Jul 2009 11:32
Picon

Re: Installing NetBSD 5.0 on MVME-147

On Monday 13 July 2009 03:24:12 Mr Ian Primus wrote:
> It identifies
> the SCSI devices, etc. Then, it complains:
>
> WARNING: preposterous TOD clock time
> WARNING: using filesystem time
> WARNING: CHECK AND RESET THE DATE!

That's ok. NetBSD and 147Bug use different date Epochs. Once you have 
NetBSD running with the correct date set, the TOD clock will contain 
the correct time/date based on NetBSD's Epoch.

> But,
> this next bit is where it all goes horribly wrong:
>
>  Mutex error: mutex_vector_enter: locking against myself

Ugh. I recall seeing and fixing something similar on an mvme177 under 
netbsd-current a few months ago. It was in code which should not have 
affected a '147.

I suggest trying NetBSD-4 for now until I can reproduce and fix this bug 
under 5.0/current.

Steve


Gmane