This mail is 10 days old, and I should have responded to it long ago.
Sorry for taking so long.

Colin Wood wrote:

>> I don't know if you recognize it, but that's the same error I got when I
>> was trying to put BSD on a Jaz disk.  What an enormous pain in the ass.
>> After trying for three days (literally) I gave up.
>
> This is part of the reason why I suspect something screwy in the MI SCSI
> driver...hmmm...what kind of kernel are you using?  Is it ncrscsi or sbc?
> I've heard that sbc kernels are better for zip/jaz drives, but I don't
> know from experience.  Of course, getting an sbc version of Takashi's
> kernel (if it's not already) is going to be the hard part ;-)

OK.  Here's one important area that I think really needs to be cleared up.
I had seen someone else on the list once say that sbc kernels work better
with Zip/Jaz drives.  This didn't make any sense to me, because the SCSI
controler chip is in the Mac, not the disk drive.  So I thought if you
had an NCR based Mac you needed to use the NCR kernel, and vice versa for
an SBC based Mac.  However in one of those fits of desperation that often
causes us to try anything, no matter how rediculous it seems, I went
against better judgement and tried to use the SBC kernel (and yes, Takashi
has compiled both NCR and SBC based kernels).  It paniced when it tried to
mount root and ended up trashing all my BSD partions such that when I
tried to boot later the booter couldn't find them.

So, I don't think that using SBC kernels on NCR machines is a good idea.
Could someone with real driver writing experience please confirm or deny
this just so no one else does the same stupid thing I did?  Thanks.

>> I did find that that panic stopped happening when I used the /sbin/swapon
>> from the 1.2 distribution.  Then it gave me some new errors.  I eventually
>> gave up.
>
> If I remember correctly, the swap configuration can be one of those things
> that's kernel dependent, but what error messages did you get?  Do you
> remember?

I don't remeber.  I think I blocked it out immediately.

>> On a related note, the Jaz disk is a bitch to work with for several reasons.
>> First of all, no good partitioning software exists.  I was using APS 4.0.2
>> and it was a mess.  The APS driver replaces the Iomega driver when you
>> partion the disk (what was Apple smoking when they decided to put drivers
>> for the disks on the disks themselves?  Or am I not understanding what
>> happens here?).  That makes it so that the Iomega driver doesn't load
>> when you have that disk installed.  Then when you boot into MacBSD, the
>> disk is auto ejected (with no way to stop this from happening), because
>> the mechanism to prevent auto eject at shutdown is a function of the Iomega
>> driver.  So you have to hurry up and push the Jaz disk back into the drive
>> before the kernel scans the SCSI devices.
>
> Really?  I thought that partitioning it with a normal formatter prevented
> the system from detecting that it's ejectable.  Perhaps APS 4.0.2 is doing
> some strange stuff.  Have you tried the patched version of Apple's HDSC
> setup?  I here some good things about it...

I didn't know about the patched version that you have a link to in the
FAQ until a few days after this happened.  I stumbled across it for
an unrelated reason.  I haven't tried it yet because I don't want to
mess with this any more right now.

> [snip]
>
>> Then I had grief with (what I suspect) was Mkfs.  I got the new 1.45 and
>> reformatted my old 'fixed' hard disk which had been trashed in various
>> attempts to deal with the Jaz BSD.  I had a root and a usr partition.
>> When I first mounted the usr partition (before installing anything on it),
>> I get a message telling me it's not clean and to f-ck it (errr . . . fsck
>> it).
>
> This is because running Mkfs on it does not set the clean flag.  You need
> to run fsck after you create a new partition in order to make sure that it
> formatted correctly and to set the clean flag.
>
>> When I did a 'df' on it (before 'fsck'ing) it showed that several
>> hundred thousand blocks had already been allocated, but I had just 'newfs'ed
>> it from the Mac side.  Hmmm . . .  I 'newfs'ed it again from the BSD side,
>> and this time 'df' showed that the partition was indeed empty.
>
> Kinda strange....did you run 'fsck' and then look, or did you just go and
> 'newfs' it?

I ran 'fsck' first.  It didn't change anything. 'df' still showed several
hundred thousand blocks allocated until after I 'newfs'ed it.

[snip]

>> In case anyone needs to know, I'm running this on a PB160 w/ 12MB RAM on
>> an external 800MB Quantum hard disk with additioinal adventures on an
>> external Jaz drive.  My kernel is Takashi's powermanager w/ intvid build
>> from 1/9/97.  The newer ones from July '97 that Takashi has posted on his
>> web page don't boot (sorry Takashi) on my PB.  The rest of the distribution
>> is the 1.2.1 binaries.
>
> Where does the boot fail?

The boot fails right after the [preserving x bytes of netbsd symbol table]
thing.  Right where every kernel fails on the PB160 ;).

Sorry again for taking so long to write this.

Take care,

-Adam