Subject: Re: 1.4 on LC 575..
To: None <email@example.com>
From: Colin Wood <firstname.lastname@example.org>
Date: 06/13/1999 22:50:06
> My Performa 575 with 36mb ram and fast 2 gig hard drive w/ hacked 800x600 video
> is up and running on 1.4C 19990606 release as of today.
> A few observations...
> X works in 16 bit mode @ 800x600 with the onboard video and the newest OSFA
> server, COOL, THANKS!!!
> The receive speed of the apple comm slot card with the sonic chipset is UNREAL.
> sn0 at obio0 address 00:a0:40:2b:c6:24
> I did a good sized ftp test receiving to /dev/null, 800k/sec on receive! Wow.
> Considerable slower on xmit, more like 170k/sec but that will include disk
> access of course.
i generally find we're a lot faster than macos on networking :-)
> A couple of error messages...
> iwm0 at obio0: Apple GCR floppy disk controller
> iwm: Chip revision not supported (-77)
> -I didn't REALLY expect this to work...
i get something similar on my q840av, i think
> PRAM time does not appear to have been read correctly.
> PRAM: 0x83da82c4, macos_boottime: 0x3763b7f2.
> -Is this normal?
more or less, although yours is off by quite a bit, so maybe not. is the
time set correctly for you under netbsd?
> Then finally, I got the same weird behavior when trying to install the
> "sets" from the distribution as I did with 1.3. Here is the symptom.
> I partitioned the drive with the patched apple hd setup util,
> made the filesystem (80 megs swap sd1b and 2g root&usr sd1a) with mkfs145 and
> went to install the base. After some period of time the install gets "write
> errors" and dies. Then I can't write to it at all. The only way I can
> get the OS installed is to first make the devs, then install etc (which
> goes cleanly if it is first) then the base.tgz. The install of the base gets
> most of the way through before dying. I then cpin the rest of the
> .tgz sets to the nstbsd root, boot to netbsd in single user mode and
> install all of the sets and X with gzip -dc file | tar xvf -
> commands. Usuable but kind of a pain...
> It's NOT a drive problem, does the same thing with several different
> drives and anyway, once in unix the drive behaves perfectly.
the above is a fairly common experience. when we switch to a
sysinst-based install, this problem will hopefully go away...