On Thu, Nov 20, 2003 at 03:21:45PM -0800, Matt Thomas wrote:
> I have a possible fix which I'll test tonight on my IBM NWS1000.
> Rather than restoring ci_curpm, I'm moving the initial trapframe down
> by one callframe.  Then directly after the trapframe, I'm storing a pointer
> to the current process'es pmap.  This is nicer than ci_curpm since I don't
> have to swap it on context switch.  Since I know the page is mapped and
> accessible since I've restored the userstate from it, getting the pmap can
> not result in another DSI fault.
> 
> I've attached the diffs (they at least build) but haven't tested them yet.

Hi,
trying to test these diffs last week on my PM4400, I got in a situation
where I get "can't LOAD from this device" from console when typing "boot".
I think it's after mounting / R/W from a current kernel, or something
like that.
The funny thing is that I have no other way to boot than from hard
disk, and only from primary master (I couldn't get a NetBSD CD to load,
although it can boot a macos CD, the floppy is dead, and of course there's
no netbootable device).
I moved the disk to a i386 box. I couldn't read the disklabel, I could
mount the root partition (which starts at sector 0) and reinstall the boot
block (both the /boot, and ran installboot -m macppc). Moved the disk
back to the 4400, it booted but the disklabel was destroyed.
It accepted wd0c as root, and I could restore the disklabel from /var/backup.
rebooted, and got "can't LOAD from this device" again.
So it seems to be an issue with the disklabel.
Any idea of what's going wrong ?
I can reinstall from scratch (a dd of the macppc boot floppy to the disk
is enouth to get it boot and run sysinst) but I feel there's something wrong
here.

--
Manuel Bouyer, LIP6, Universite Paris VI.           Manuel.Bouyer@lip6.fr
     NetBSD: 24 ans d'experience feront toujours la difference
--