On Mon, 18 Aug 1997, Colin Wood wrote:

> ADAMGOOD@delphi.com wrote:
> > 
> > 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.

<snip>

> 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 :-(

hork?  Never seen that one before....  Systems known to have trouble with
both drivers include the PB145 (which gets a little fs glitchiness with
ncrscsi, and which panics when mounting the fs or in fsck, I forget which,
with sbc).  Submitting a trace when you get a panic might help in finding 
the glitch, depending on what the glitch is.  Dunno.  Anybody?

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

:-)

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

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

Once a week.  ;-)

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

They weren't by any chance marked bad by mkfs, were they?  Does it even
have that capability?  Maybe it's just generating buggy inodes on that
drive.  Have you tried using it for MacOS?  It could be either bad blocks
or a flaky SCSI bus (termination problems come to mind).  Another
possibility might be that the driver bugs are causing slightly bad reads
(flakiness) during the fsck check.  Normally, there should not be any fs
damage during an initial fsck after mkfs....  And since Apple's MacOS scsi
drivers tend to be less error-prone than the ones in NetBSD-mac68k, I'd
tend to blame the SCSI code rather than mkfs, _but_ that's only a guess.

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

Aha!  It's a PB160.  Same motherboard (essentially) as the 145, or at
least my 145 says PowerBook 145/160 on it....  So it's _not_ just mine....
;-)  Sounds like something inherent to the design of that particular model
that's not behaving well with either driver.  I have a kernel you might
want to try.  Allen Briggs made some changes fairly recently and compiled
a kernel for me with both the relevant powermgr stuff/HWDIRECT and intvid
using a slightly patched ncrscsi.  It's not perfect, but at least I can go
more than a few hours without totally reinstalling (average is up near a
week now.  Thanks, Allen.)  If you're interested, let me know and I'll
upload it to ftp://globegate.utm.edu/pub/NetBSD/something....

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

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

Try zapping PRAM.  That fixes hangs there for some people.  Not sure why.


David

-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/CC/FA/H/L/MC/M/MU/PA/TW d-@ s:>- a-- C++++>$ UBLAS*++++>$
P+?>$ L+++>$ !E--- W+++>$ N++(+++)>+++$ !o? K-? !w--- !O
M++>$ !V-- PS+>$ !PE- Y+>$ PGP+>$ t+++>$ 5+>++++$ !X- !R tv+>$
b++>$ !DI !D- G++(+++)>$ e>++++ h--! r--- !y-
------END GEEK CODE BLOCK------