cpm@datlog.co.uk (Paul Merriman) (01/26/89)
Hi,
I am considering buying a hard disk for my ST and want to use it
with MINIX (which I already own and have running on floppies). My probable
purchase will be the 32Mb drive from Third Coast Systems (UK) which uses a
Berkeley Micro Systems (BMS) controller board.
What I want to know is - will this work ok ?
Or, will I have to modify the device driver to get it working and
if so , can someone send me the diffs ?
Please Post to the net if possible - Email
is a bit flaky here.hcj@lzaz.ATT.COM (HC Johnson) (01/31/89)
In article <961@dlhpedg.co.uk>, cpm@datlog.co.uk (Paul Merriman) writes: > Hi, > I am considering buying a hard disk for my ST and want to use it > ... > purchase will be the 32Mb drive which uses a > Berkeley Micro Systems (BMS) controller board. > > What I want to know is - will this work ok ? > > Or, will I have to modify the device driver to get it working and > if so , can someone send me the diffs ? > I have BMS running with 80 MB drives and 20 MB drives. No problem. In face BMS seems to have no problems running on MINIX, unlike the (early) SUPRA, and maybe ICD. (The problem is that TOS is polled, no interrupts; MINIX is totally interrupt driven). BMS does not supply Supra style partitioning software to give more than 4 partitions, but Supra sells it separately. I know that 4 partitions of 16 mb each will work. I have seen references that fsck may have problems if the size is greater. I will be posting mods to stwini.c to read all 12 supra partitions. Its not dificult. Also, there is really nothing too magic or limiting about having 4 partitions. For example, If you were to create 1 5 meg and 2 1meg on a 32 meg disk, you would find that the partition table would give partition 1 5 megs partition 2 1 meg partition 3 1 meg partition 4 empty. Just edit the partition table to make the numbers (start,size) become what you want. Howard Johnson ATT-BL lzaz!hcj
hase@netmbx.UUCP (Hartmut Semken) (02/01/89)
In article <393@lzaz.ATT.COM> hcj@lzaz.ATT.COM (HC Johnson) writes: >I have BMS running with 80 MB drives and 20 MB drives. No problem. Do You use one controller with two drives? Today I drove me crazy by trying to get my second drive to work (I use an upgraded SH205. Should be SH205 compatible... :-) Formatting the drive (under TOS) and installing a file system (hd13: device 3,13, 10 Megabytes) did work. To test the drive, I filled it up with some nonsens. Mounting the drive as /tmp and recompiling the kernel worked well. Then I rebooted (needed TOS for a change; did not want to feel too comfteble... :-), restarted Minix and got no response from the second drive. Drive Zero still working very well... The Seagate ST412, I use, runs just fine with TOS and RTOS... Any idea, what the problem is? hase -- Hartmut Semken, Lupsteiner Weg 67, 1000 Berlin 37 hase@netmbx.UUCP In a space in the forest, on an empty patch of wet ground between a circle of craning trees, appeared quietly and without fuss a plain white door.
kirkenda@psu-cs.UUCP (Steve Kirkendall) (02/11/89)
I haven't seen anybody posting any news, good or bad, about using Minix-ST with older Supra hard drives. Not for a while, anyway. Did we all figure it out simultaneously about 6 weeks back, or what? Basically, the problem is that the older Supra board send extra interrupts after the DMA transfer is complete. This either causes the kernel to print "dma interrupt discarded" (a minor nuisance) or to panic when the hard disk driver task received a message from -1, which is hardware. I got my older Supra to work with Minix simply by bypassing that code. (I commented out the "dma interrupt discarded" message in stdma.c, and changed the panic() in stwini.c into a continue statement.) I have been using it quite heavily for several weeks now, with no problems at all. If anybody out there knows any reason why I would run into grief by ignoring those extra interrupts, PLEASE TELL ME! -- "If I seem insensitive to what you're going through, keep in mind that's the way I am." -- Mr. Spock
evans@ditsyda.oz (Bruce Evans) (02/14/89)
in article <1630@psu-cs.UUCP>, kirkenda@psu-cs.UUCP (Steve Kirkendall) says: > Basically, the problem is that the older Supra board send extra interrupts > after the DMA transfer is complete. This either causes the kernel to print > "dma interrupt discarded" (a minor nuisance) or to panic when the hard disk > driver task received a message from -1, which is hardware. In the PC at_wini.c, there is a potential bug which may be related to this. It doesn't matter yet because of the way interrupts are handled, but probably will matter for PS/2's. The bug is around line 215 of w_transfer(). After setting up DMA, it does receive message read buffer out of DMA port to memory get results Two interrupts should be geneated since there are two sectors per block. The code is in a loop to take care of this. But the interrupts are generated when the buffer is ready, before the buffer is read and not after. So the second interrupt may arrive before the results of the first have been read, leading to the second receive hanging. The fix is to get the results immediately after receiving the message. Bruce Evans evans@ditsyda.oz.au