[comp.os.minix] minix 1.5 question

Ritzert%DMZRZU71.BITNET@cunyvm.cuny.edu (07/21/90)

I'm rather new in this group and run plain minix st 1.1. Could someone
please sum up the differences between this old version and the most
recent version (1.5.10 i think)? Are there new features such as having
support of an scsi drive with 4 partions of 45 MB each (Supra extended
format). With the old version only 32 MB are supported, and lots of
strange problems mounting additional file systems appear. Faster file
system? Faster screen io? More elaborate sceduling algorithms, eventually
priority sceduling? Support of other floppy sizes than 360 k / 720 k ?
My floppy supports at least and without any problems T:82 S:10, even
with no name disks. And being able to use ~90 tracks on such a floppy is
really interesting for backup purposes. Support of the 68881 ? Overscan
support? POSIX compatibility?

Thanks in advance
Michael Ritzert
ritzert@dfg.dbp.de

hyc@math.lsa.umich.edu (Howard Chu) (07/22/90)

In article <25277@nigel.udel.EDU> Ritzert%DMZRZU71.BITNET@cunyvm.cuny.edu writes:
>I'm rather new in this group and run plain minix st 1.1. Could someone
>please sum up the differences between this old version and the most
>recent version (1.5.10 i think)? Are there new features such as having
>support of an scsi drive with 4 partions of 45 MB each (Supra extended
>format). With the old version only 32 MB are supported, and lots of
>strange problems mounting additional file systems appear. Faster file

Dang, I wasn't aware of this problem! I am using a 45 MB partition
right now, in fact. I hope it doesn't bomb out on me as I get closer to
filling it. I was led to believe that there were no size limits to an
individual partition, though I don't know about the extended partitioning
(more than 4 partitions per drive).


>system? Faster screen io? More elaborate sceduling algorithms, eventually
>priority sceduling? Support of other floppy sizes than 360 k / 720 k ?
>My floppy supports at least and without any problems T:82 S:10, even
>with no name disks. And being able to use ~90 tracks on such a floppy is
>really interesting for backup purposes. Support of the 68881 ? Overscan
>support? POSIX compatibility?

Dunno. My patch to 1.1 allowing arbitrary floppy formats was a little
buggy, and isn't in 1.5. The library has been POSIXized. I'm in the
midst of upgrading to 1.5.10, and I'm not sure I've got it right yet.

Maybe one of you can help me - in upgrading to 1.5.0, building the kernel
yields the message "can only relocate longs" from /lib/cv. It seems to
only be a warning, as I get a kernel.mix output, and this can be built
into a running system.

I also seem to be having problems with my library. (Dunno if that's really
the cause yet.) Various programs die with Sig=11, dumping core. Many programs
die with Sig=10, which I have learned is a prompt to chmem them up a little
higher. I'm suspecting a flaky C library as the cause of Sig=11, but I
don't know. (The prominent example is more, which dies after one screen of
text.)

Just as an aside... My FS now occupies a whole 640K all by itself. 512 slots
and 480 blocks in the buffer cache. Yeehah! Time to pare down my 1.6M RAMdisk.
>
>Thanks in advance
>Michael Ritzert
>ritzert@dfg.dbp.de
--
  -- Howard Chu @ University of Michigan
  one million data bits stored on a chip, one million bits per chip
	if one of those data bits happens to flip,
		one million data bits stored on the chip...

hyc@math.lsa.umich.edu (Howard Chu) (07/23/90)

In article <1990Jul22.065622.14640@math.lsa.umich.edu> hyc@math.lsa.umich.edu (Howard Chu) writes:
%Maybe one of you can help me - in upgrading to 1.5.0, building the kernel
%yields the message "can only relocate longs" from /lib/cv. It seems to
%only be a warning, as I get a kernel.mix output, and this can be built
%into a running system.
%
%I also seem to be having problems with my library. (Dunno if that's really
%the cause yet.) Various programs die with Sig=11, dumping core. Many programs
%die with Sig=10, which I have learned is a prompt to chmem them up a little
%higher. I'm suspecting a flaky C library as the cause of Sig=11, but I
%don't know. (The prominent example is more, which dies after one screen of
%text.)

These problems have both gone away, after I slam-dunked the 1.5.3-1.5.10
patches on top of the 1.5.0 stuff. I've got two more problems though... It
seems that a DCD transition generates an SIA interrupt, which hangs my shell.
(Dunno how much else is hung, the Ctrl-Alt Fkeys still work.) I am also
occasionally getting "DMA interrupt discarded on devxx, block xx" and another
hang. Devxx is the major/minor for the partition currently in use on my hard
drive, which has a Supra host adapter.
--
  -- Howard Chu @ University of Michigan
  one million data bits stored on a chip, one million bits per chip
	if one of those data bits happens to flip,
		one million data bits stored on the chip...

hyc@math.lsa.umich.edu (Howard Chu) (07/23/90)

Well, I seem to be running fine on ST 1.5.10 now. (Using stterm to login and
write this article, in fact.)

Has this been discussed already - there weren't any hints I could find on
what new files I should create for various things. e.g., /usr/adm/wtmp,
/etc/utmp, or a number of other little things. (How do I get a getty going
on my serial port, what's the format of /etc/ttys, etc.) It took a really
long time to get ps working, 'cause I couldn't figure out how to get cv to
leave the symbols intact going from kernel.out to kernel.mix.

I guess that's what I get for not reading this newsgroup for several months
at a time, eh?

I figure I'll be done going thru the diff's pretty soon, and will be ready
to put up a 1.1 -> 1.5.10 kit Real Soon Now.
--
  -- Howard Chu @ University of Michigan
  one million data bits stored on a chip, one million bits per chip
	if one of those data bits happens to flip,
		one million data bits stored on the chip...

meulenbr@cst.philips.nl (Frans Meulenbroeks) (07/24/90)

I've not been able to test this extensively (the big disk I tested this
on is flakey), but as far as I know a partition can be up to 64 MB.
Not more, sorry.
If someone discovers that more than 32 MB does not work, I'd like to
know (Perhaps with a fix?)

As for more than 4 partitions. 
This was not included because at that time I could not test it.
In fact I've added supra partitioning in my code today, and I'll try to
add hdx 3.0 partitioning later this week. 
As soon as this is finished, I'll post it so you all can try it, and I
can get some feedback on these (and some other) changes.
I hate to use the net as guinea pigs, but there are things I just 
cannot try due to limited hardware.


--
Frans Meulenbroeks        (meulenbr@cst.philips.nl)
	Centre for Software Technology
	( or try: ...!mcsun!phigate!prle!cst!meulenbr)

HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) (07/24/90)

My personal opinion about the progress made from 1.1st --> 1.5 st is:

The disk-I/O is faster because the administration of the buffer pool is
much better.
When dumping dirty buffers to disk, they are sorted by block numbers and
FS talks to FLOPPY via (long) I/O-vectors.

P.S. This is an exellent hook for incorporating track buffering:
switch track buffering on when FLOPPY gets a SCATTERED_IO request,
dump dirty trackbuffers and invalidate all of them when the vector is processed
.

C.v.W.

UNM409%DBNRHRZ1.BITNET@cunyvm.cuny.edu (Volker A. Brandt) (07/26/90)

Hello Minix people,

Frans Meulenbroeks <meulenbr@CST.PHILIPS.NL> said:
>In fact I've added supra partitioning in my code today, and I'll try to
>add hdx 3.0 partitioning later this week.
>As soon as this is finished, I'll post it so you all can try it, and I
>can get some feedback on these (and some other) changes.

Yes, please do!

>I hate to use the net as guinea pigs, but there are things I just
>cannot try due to limited hardware.

I'll gladly act as guinea pig :-)  Don't worry!
Thanks for all the work you've invested into Minix for the ST.

----------------------------------------------------------------------------
Bitnet:  UNM409@DBNRHRZ1                              Volker A. Brandt
UUCP:    ...!unido!DBNRHRZ1.bitnet!unm409             Angewandte Mathematik
ARPAnet: UNM409%DBNRHRZ1.BITNET@CUNYVM.CUNY.EDU       (Bonn, West Germany)