nall@sun8.scri.fsu.edu (John Nall) (01/05/91)
I wrote in an earlier message (paraphrased): > ...for the third time, I have lost a 1.2MB floppy disk drive > on my Minix system. On the other hand, I have never lost one > on my MS-DOS system. > > so...I think...MINIX EATS FLOPPY DISK DRIVES. Several people have sent me comments regarding this message. A couple of them agreed (that is, they had similar problems) and the others wanted more information. Let me first of all say that this was SOMEWHAT put out as a "tongue-in-cheek' message. That is, it seems like a heck of a coincidence, but on the other hand I don't see how the software could make the drive fail. Having said that, let me answer the two questions that were asked: (1) WHAT TYPE OF DRIVE WAS IT? It just said "made in Japan for IBM". But the other two drives were not necessarily the same kind (I don't have them around). Anyway, just a run of the mill 1.2MB drive, half-height. (2) WHAT, EXACTLY, WAS THE PROBLEM? This is difficult for me to answer, because I'm not much of a hardware person. I can only give the symptoms, which are (1) under MS-DOS, it will read and write a 360K disk, but not a 1.2MB disk. Says "data error" when I try and read, and "access denied" when I try and write. (2) It will not format a 1.2MB disk - claims that "Invalid media or Track 0 bad - disk unusable". Under MS-DOS again, of course. With Minix, it will not boot from either my 1.2MB boot disk or a 360K boot disk. With a 360K boot disk, it gets the message "read error. Automatic rebooting" over and over. Trying to boot up a 1.2M Minix boot disk is more interesting. What happens is that it sits there for awhile, with the drive light on, and then just boots from the hard disk as if there were not a floppy disk in the drive at all! (Boots MS-DOS!) A friend of mine ran a diagnostic program on the drive, and it passed ok with a 360K disk, but would not even run the diagnostic with a 1.2M disk. My friend said that the rotation speed was incorrect, and that he could not bring it into line with a screwdriver adjustment. It could only be varied between about 308.29 rpm and 330 rmp, and he said that it should be 360.0 rmp for a 1.2M disk. So perhaps these clues will mean something. In the meantime, since I don't have another drive, I cannot boot up Minix. :-( But when I DO get that sucker booted up, I'm going to go in and modify it so that drive 0 is hardwired to a 5.25 inch 1.2M drive, and drive 1 is hardwired to a 3.5 inch 1.44M drive. Even though logic tells me that Minix can't possibly eat disk drives, hearing those grinding noises while it is figuring out what sort of drive it is always gives me the creeps. -- John W. Nall | Supercomputer Computations Research Institute nall@sun8.scri.fsu.edu | Florida State University, Tallahassee, FL 32306 WB4LOQ (why? I dunno....everyone else seems to be doing it. _._)
ghelmer@dsuvax.uucp (Guy Helmer) (01/05/91)
In <1806@sun13.scri.fsu.edu> nall@sun8.scri.fsu.edu (John Nall) writes: >I wrote in an earlier message (paraphrased): >> ...for the third time, I have lost a 1.2MB floppy disk drive >> on my Minix system. On the other hand, I have never lost one >> on my MS-DOS system. >> >> so...I think...MINIX EATS FLOPPY DISK DRIVES. > Even though logic tells me >that Minix can't possibly eat disk drives, hearing those grinding >noises while it is figuring out what sort of drive it is always >gives me the creeps. I don't know if I would say that MINIX doesn't eat disk drives. I think my 1.2M at work was damaged some by booting MINIX with 360K disks. I don't like the check for a 720K disk, which will bang the heads 24 times in succession if you are booting from a 360K disk. (Bootblok tries to seek out to track 64 in an attempt to find out if you've got a 720K boot disk) BTW, I'm going to clean up my bootblok.s that shouldn't be so hard on disk drives and post it tonight. It will include support for 1.44M boot disks and fix a bad thing regarding 720K boot disks. >-- >John W. Nall | Supercomputer Computations Research Institute >nall@sun8.scri.fsu.edu | Florida State University, Tallahassee, FL 32306 > WB4LOQ (why? I dunno....everyone else seems to be doing it. _._) -- Guy Helmer helmer@sdnet.bitnet, uunet!dsuvax!ghelmer work: DSU Computing Services, Business & Education Institute (605) 256-5315 play: MidIX System Support Services (605) 256-2788 postnews: message content ambiguous; spurious information added as required
agodwin@acorn.co.uk (Adrian Godwin) (01/08/91)
In article <1991Jan4.230711.25240@dsuvax.uucp> ghelmer@dsuvax.uucp (Guy Helmer) writes: >In <1806@sun13.scri.fsu.edu> nall@sun8.scri.fsu.edu (John Nall) writes: > >>I wrote in an earlier message (paraphrased): >>> ...for the third time, I have lost a 1.2MB floppy disk drive >>> on my Minix system. On the other hand, I have never lost one >>> on my MS-DOS system. >>> >>> so...I think...MINIX EATS FLOPPY DISK DRIVES. > >> Even though logic tells me >>that Minix can't possibly eat disk drives, hearing those grinding >>noises while it is figuring out what sort of drive it is always >>gives me the creeps. > >I don't know if I would say that MINIX doesn't eat disk drives. >.... > >BTW, I'm going to clean up my bootblok.s that shouldn't be so hard on >disk drives and post it tonight. It will include support for 1.44M >boot disks and fix a bad thing regarding 720K boot disks. > Thanks for these hints, folks ... I was impressed how easily my 1.5.10 system came up on a 1.44M AT, and surprised when the 360K disc I built wouldn't work on an AT. However, a quick look at the bootblok (and the 'config' scheme someone posted) raises some queries : When the 720K disc is tested, it uses disc parameters from a fixed place in the PS/2 ROM. This is probably a bad idea on another machine! - it's also probably the reason why the disc fails to boot on my friend`s AT - it may well get parameters that result in a successful read of track zero, but fails thereafter. The 720K parameters ought to be in the boot sector with the others - why aren't they ? Lack of space ? Perhaps this is the 'bad thing' Guy refers to. The worries about seeking to track 64 to find out how many tracks the drive has are reasonable - but I don't see how that will hurt a 1.2M drive, which has 80 tracks anyway. It might damage a 360K drive, of course - but that wasn't the problem. That's assuming that the drive isn't being double-stepped, which of course it shouldn't be in 720K mode ... unless the junk parameters at that hard-coded address say so! But why worry about 720K parameters anyway ? Most kernels are much smaller than 360k, so they'll stop long before 40 tracks. So why not just set up for 360K and read that ? I don't believe it will notice the difference! The step rate will be slow for the 3.5 inch drive, but I*M always get that wrong, anyway ! In any case, it will only matter for the recal - not sequential track reading. While I'm on the subject of bootbloks, any readers still using floppy root discs might be interested in my method of avoiding the disc swap at boot-up. I added a 'start' parameter to the data at the end of the bootblok to indicate where the kernel is to be loaded from. Since the root filesystem is also typically small, the boot track can be placed on the root disc, and the kernel code placed above the filesystem by a suitably-modified 'build'. I also replaced fsck (on a 1.3 system) with a fastboot loader that read the root filesystem into memory with cylinder-sized reads, but that isn't essential. If you do it, you have to modify FS to find the prebooted ramdisk and the memory sizing function to operate nondestructively. I haven't put these mods into my 1.5.10 system yet. -adrian -- -------------------------------------------------------------------------- Adrian Godwin (agodwin@acorn.co.uk)
jdudeck@polyslo.CalPoly.EDU (John R. Dudeck) (01/08/91)
In an article ghelmer@dsuvax.uucp (Guy Helmer) wrote: >I don't know if I would say that MINIX doesn't eat disk drives. >I think my 1.2M at work was damaged some by booting MINIX >with 360K disks. I don't like the check for a 720K disk, >which will bang the heads 24 times in succession if you are booting from a >360K disk. (Bootblok tries to seek out to track 64 in an attempt >to find out if you've got a 720K boot disk) If this is true, that it actually hits the stop, that could be enough to have knocked it out of line enough that it it won't boot from 1.2mb floppies, but it still is close enough for 360k floppies. -- John Dudeck "If it's Object Oriented then by jdudeck@Polyslo.CalPoly.Edu definition it's A Good Thing". ESL: 62013975 Tel: 805-545-9549 -- D. Stearns
ghelmer@dsuvax.uucp (Guy Helmer) (01/08/91)
In <4595@acorn.co.uk> agodwin@acorn.co.uk (Adrian Godwin) writes: >In article <1991Jan4.230711.25240@dsuvax.uucp> ghelmer@dsuvax.uucp (Guy Helmer) writes: >>In <1806@sun13.scri.fsu.edu> nall@sun8.scri.fsu.edu (John Nall) writes: >>>> so...I think...MINIX EATS FLOPPY DISK DRIVES. >>I don't know if I would say that MINIX doesn't eat disk drives. >When the 720K disc is tested, it uses disc parameters from a fixed place >in the PS/2 ROM. [...] >Perhaps this is the 'bad thing' Guy refers to. Yes, that's it. I don't know if it was such an awful thing, since a 720K disk was bootable on my '386 with the original bootblok. >The worries about seeking to track 64 to find out how many tracks the drive >has are reasonable - but I don't see how that will hurt a 1.2M drive, which >has 80 tracks anyway. It might damage a 360K drive, of course - but that >wasn't the problem. That's assuming that the drive isn't being double-stepped, >which of course it shouldn't be in 720K mode ... unless the junk parameters >at that hard-coded address say so! That might have been the case. All I know is, when booting a 360K disk in my 1.2M drive with the original bootblok, the disk drive would go @#$%*CRUNCH@#$%*GRIND@#$*%^ during the test for a 720K disk. >But why worry about 720K parameters anyway ? Most kernels are much smaller than >360k, so they'll stop long before 40 tracks. The '386 kernels I boot have use between 400K and 550K for a boot image. One could check for 1.44M and 1.2M, and if those fail then just set up for a 360K/720K disk. That's essentially what my bootblok.s does, which was posted a couple of days ago. >Adrian Godwin (agodwin@acorn.co.uk) -- Guy Helmer helmer@sdnet.bitnet, uunet!dsuvax!ghelmer work: DSU Computing Services, Business & Education Institute (605) 256-5315 play: MidIX System Support Services (605) 256-2788 postnews: message content ambiguous; spurious information added as required
HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) (01/10/91)
A boot image of 400 KBytes clearly points to a silly method of storing it (I guess WITH zeroes for bss segments)