ADAMGOOD@delphi.com wrote:
> 
> This mail is 10 days old, and I should have responded to it long ago.
> Sorry for taking so long.

's'ok ;-)

> 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 think that you are a bit confused here.  The older Macs have an ncr5380
(or something close) SCSI chip.  The newer Macs have an ncr53c96 SCSI
chip.  For the either chip, I believe there are 2 levels to the driver.  A
machine independent portion that knows how the particular chip works (i.e.
how the chip interacts with SCSI devices on the bus) and a machine
dependent portion that knows how the system works with the chip (i.e. how
the cpu talks to the SCSI controller chip).  For the ncr5380 SCSI
controller chip, there is one MI device interface available, and _2_
machine-dependent interfaces available.  These 2 interfaces are Allen's
ncrscsi interface and Scott's sbc interface.  Neither interface has
anything to do with the ncr53c96 controller chip.  Any Mac with an ncr5380
SCSI chip should, in theory anyway, be able to use either the ncrscsi or
the sbc driver.  Any Mac with the ncr53c96 chip _must_ use the esp
machine-dependent SCSI interface.  Does this make sense so far?

Anyway, for some systems (i.e. those with Quantum drives and the ncr5380
chip) the sbc driver appears to be more stable than the ncrscsi driver.
This seems to be the case for most systems using a Jaz/Zip drive as well.
However, there are a few systems where the sbc driver will totally hork
the filesystem and the ncrscsi driver works just fine (yours seems to
qualify).  Unfortunately, other than rather general statements like those
I've just given, there is no real way to determine which system is which
before actually running a kernel and seeing how it goes :-(

Now, as for the bug that I mentioned before, apparently there is a
somewhat well-known and long-standing bug present in the MI part of the
ncr5380 SCSI driver.  So, even tho the machine dependent parts of the
driver both appear to be rather stable, the bug in the MI part of the
driver still causes problems.  Hopefully, someone will figure out what
this bug is one day and fix the damn thing.

> >> 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.

Hmmm....in general, it's best to have kernels and binaries all in
sync...although I can't seem to remember where this part of the thread was
going...

> >> 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.

Well, if you're hosed, you're hosed :-(  I've to do a complete reinstall I
think twice in the last 2 years.  Normally, I keep a copy of my most
recent tar files sitting around just in case things fall apart.

> > [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.

Hmmmmmmm...I still don't know why this is happening.

> >> 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 ;).

Ugh...perhaps Takashi can shed some light on the changes he's made?

> Sorry again for taking so long to write this.

That's ok.  I hope the above clears up a few things.

Later.

-- 
Colin Wood                                 cwood@ichips.intel.com
Component Design Engineer - MD6                 Intel Corporation
-----------------------------------------------------------------
I speak only on my own behalf, not for my employer.