[comp.os.minix] The Adventures of Minix on the AT&T PC6300

jcs@chinet.UUCP (John C. Sucilla) (04/20/87)

Well, I just spent 3 days recompiling the kernel with Don Dugger's
Z150 HD fix that was recently posted. I used his code because the 
symptoms were so similar to mine.

I removed my HD and reinstalled my second floppy to make life easier
recompiling the kernel.

I kept getting real weird errors from the compiler and optimizer.
Errors like:
	error on line 1136 (%*s): Unknown instruction byte
	error on line 1136 (%*s): label 8 multiple defined
	"tty.c", line 810: to undefined.

I even ran into 2 or 3 file system panics after a simple "rm file".

I finally realized that when it decided to blow up it took the source
file I was compiling with it. I found strange lines in my previously
good source that look like something you would find in a compressed
.s file. Once I finally got the kernel rebuilt, it took three tries
running build before I got a disk that would boot and recognize my
root file system as genuine root. Once up on the new kernel, mkfs
was tried on the hard disk again. Guess what. I got the same old
hard disk wont reset, cant write blah blah blah....

Moral of story: Minix and the AT&T PC6300's floppies are marginal!!!
                You aint gonna build Minix on one of these machines.
		At least, not on mine anyway...

Any other 6300 owners had better luck?
Anybody got a pre-compiled kernel hacked for the WD1002S-WX2 they 
could uuto to me (beg, beg)? If I could reliably talk to my hard
drive it wouldnt be so painful working on the floppy driver.....

-- 
  John "C". Sucilla  Chinet - Chicago, Illinois
  ...ihnp4!chinet!jcs

  Don't let reality stop you.....

jkg@gitpyr.gatech.EDU (Jim Greenlee) (04/21/87)

In article <876@chinet.UUCP> jcs@chinet.UUCP (John C. Sucilla) writes:
>Anybody got a pre-compiled kernel hacked for the WD1002S-WX2 they 
>could uuto to me (beg, beg)? If I could reliably talk to my hard
>drive it wouldnt be so painful working on the floppy driver.....

I'd be interested in this as well. I just got "The Book" and "The Disks"
this week and I was going to look into it. I basically haven't gotten
any farther than "Kernel panic: something's wrong with winchester 0" when
I try to load the root file system. However, I don't have a second floppy
to install in place of my HD. I was going to try to hack the sources on
a real IBM PC, but if somebody has the mods I'll gladly take them (I'm not 
that proud :-). Any takers?

						Jim Greenlee
-- 
The Shadow...!{akgua,allegra,amd,hplabs,ihnp4,seismo,ut-ngp}!gatech!gitpyr!jkg

Jryy, abj lbh'ir tbar naq qbar vg! Whfg unq gb xrrc svqqyvat jvgu vg hagvy lbh
oebxr vg, qvqa'g lbh?!

jcs@chinet.UUCP (John C. Sucilla) (06/26/87)

Miscelaneous info...
Since Minix does not have a shutdown script, it is necessary for
hard disk user's to stop the system as described below to prevent
file system damage.

1) Issue a sync.
2) Immediately kill -9 the /etc/update process (PID 12).
3) Unmount all file systems.
4) Stop the system.

Since I began using this procedure, fsck has not had to do a single
repair. Yea, I know... It's common sense, but maybe this will help
somebody somewhere!

While I'm at it, if anybody's having problems with mined truncating
files, execute sync upon leaving mined.

Did anybody get the complete source for the version of ed that was
recently posted? I seem to be missing several functions starting at
dowrite() in the makefile.
-- 

                /----------------------------------\
                |        John "C". Sucilla         |
                |     Chinet - Chicago, Ilinois    |
                |       ...ihnp4!chinet!jcs        |
                |                                  |
                |  Don't let reality stop you..... |
                \----------------------------------/

rmtodd@uokmax.UUCP (Richard Michael Todd) (06/26/87)

In article <1226@chinet.UUCP> jcs@chinet.UUCP (John C. Sucilla) writes:
>Since Minix does not have a shutdown script, it is necessary for
>hard disk user's to stop the system as described below to prevent
>file system damage.
>1) Issue a sync.
>2) Immediately kill -9 the /etc/update process (PID 12).
>3) Unmount all file systems.
>4) Stop the system.
>Since I began using this procedure, fsck has not had to do a single
>repair. Yea, I know... It's common sense, but maybe this will help
>somebody somewhere!
I doubt if all this caution is really necessary.  I just issue a sync, wait
for the I/O to finish, and then reboot (CTRL-ALT-DEL) or switch off power.
You shouldn't have to kill update, since all update does is do a sync call
every 30 sec., and once the file system is sync'ed once, subsequent sync calls
will do nothing unless some process has done some writing to the disk.  I've
been using the "sync once and reboot" procedure and have only had fsck report
problems when MINIX actually crashed/hung when executing a program such that
I couldn't shut down the system in an orderly fashion.  While the procedure
you give won't hurt anything, only the sync command is really needed. 


>Did anybody get the complete source for the version of ed that was
>recently posted? I seem to be missing several functions starting at
>dowrite() in the makefile.
There was a reposting of the ed files recently--apparently some sites got a
mangled version.
--------------------------------------------------------------------------
Richard Todd
USSnail:820 Annie Court,Norman OK 73069
UUCP: {allegra!cbosgd|ihnp4}!okstate!uokmax!rmtodd