Re: MFM disk geometry
The wrap-up: So I got the data off the drive. :) One issue is it turns out the drive is a bit flaky. I'm not sure how much of the issue is heat, and how much is tilt. I had done most of my fiddling with the drive perched in places that weren't quite flat, and I think these old drives must have been more sensitive to that, considering that I discovered this morning that the data sheet on TH99 says not to tilt it more than 5 degrees (!) from horizontal. I tried older hardware, and DOS-type stuff, but didn't get anywhere, although there were intermittent moments when things worked. See above. What finally worked was the same P3 setup and a bit of kernel hacking, plus getting past the flakiness. However, I think I found an obscure kernel bug that probably wouldn't affect anyone except people trying to do what I did. In wd_get_params() in dev/ata/wd.c, if the kernel gets an error when it tries to get ATA info from a drive (and this one is pre-ATA), it uses 1024/8/17 and single-sector transfers with no ATA capabilities. This is the comment: /* * We `know' there's a drive here; just assume it's old. * This geometry is only used to read the MBR and print a * (false) attach message. */ However, that doesn't seem to be the case. The P3's BIOS doesn't even provide info about the MFM drive, but on a P1, with an old OBSD boot floppy, 'machine diskinfo' at the boot prompt gave me 614(?!)/4/17, which is more or less correct - and then the dmesg used 1024/8/17. And I know that it wasn't just faked for the dmesg, because of the numbers in the error messages I got, eg 'blah blah fsbn xxx (bn x: cn y, tn z, sn q)' - to get those c/t/s numbers for that block number meant the kernel was using 1024/8/17 to access the drive. I haven't replicated this with a more recent kernel, but I suspect this code hasn't been touched in a while, considering that 4.6-release does the same thing. Presumably, if the kernel is actually going to use LBA mode, or the ATA-info error is transient or whatever, this hack won't cause any problems. But has anyone else tried to use a CHS-mode-only drive with geometry other than 1024/8/17 with success? Is there a provision somewhere else to get the correct numbers? In any case, I changed those numbers to the correct ones for the drive and recompiled the kernel. Initially it didn't work (flakiness), but when I tried again this morning with the drive level and cold, I was able to get almost everything off the drive. The rest is probably attributable to bad sectors, considering the drive is around 20 years old. Here are the results you've been waiting for :) --- dmesg: wdc0 at isa0 port 0x1f0/8 irq 14 wd1 at wdc0 channel 0 drive 0: ST506 wd1: 1-sector PIO, CHS, 68MB, 1024 cyl, 8 head, 17 sec, 139264 sectors wd1(wdc0:0:0): using BIOS timings --- fdisk: Disk: wd1 geometry: 615/4/17 [41820 Sectors] Offset: 0 Signature: 0xAA55 Starting Ending LBA Info: #: id C H S - C H S [ start:size ] --- 0: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 1: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused *3: 04 0 1 1 -613 3 17 [ 17: 41735 ] DOS FAT-16 --- disklabel: # /dev/rwd1c: type: ST506 disk: ST506/MFM/RLL label: ST506 flags: bytes/sector: 512 sectors/track: 17 tracks/cylinder: 4 sectors/cylinder: 68 cylinders: 615 total sectors: 41820 rpm: 3600 interleave: 1 boundstart: 0 boundend: 41820 drivedata: 0 16 partitions: #size offset fstype [fsize bsize cpg] c:418200 unused i:41735 17 MSDOS --- df: Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/wd0a 5038086 3078892 170729064%/ /dev/wd0d 148271564 101606904 3925108272%/data /dev/wd1i 20810 8924 1188643%/mnt
Re: MFM disk geometry
Results 1 - 10 of about 25,100 for Seagate ST225, possibly the most common 20MB 1/2 height MFM drive. Google is my friend. It could be your friend, too. I seem to recall that LBA and fake geometry and related stunts could be done on the controller. At least I recall a Promise IDE controller like that. Inspect the controller card. There will be a mfg name. Maybe a model. Try google. With luck you'll find out what the jumpers mean, and you could begin making progress, rather than poking around with a stick at it. Good luck. Dave On Tue, Feb 2, 2010 at 12:23 AM, Daniel Malament b...@anonix.net wrote: holy cow. of all the times NOT to post a dmesg! (and fdisk output). It snip -- In order to comply with government search warrants on user data, Google created a backdoor access system into Gmail accounts. This feature is what the Chinese hackers exploited to gain access.
Re: MFM disk geometry
On Tue, Feb 2, 2010 at 4:23 PM, Daniel Malament b...@anonix.net wrote: holy cow. of all the times NOT to post a dmesg! (and fdisk output). It probably wouldn't help diagnose the problem, but it would be cool to see. :) Obviously, you got a PIII machine with ISA slots, not the most common of beasts (though they certainly exist). (actually, the dmesg would probably just show wdc0 at ... , but it would be kinda cool to know that it was REALLY a wdc, not a low-end IDE interface pretending it was an AT controller). Heh. It does. I'll have to remember to save copies when I finally get all this working. :) And the machine is a Dell Dimension with one PCI/ISA shared slot. I think you need to go back to a P1 (or maybe some PII?) system before you will find one with manual drive parameter selections. That will lead to another problem, very, very very few of those will allow you to directly boot from the secondary controller. HOWEVER, you may be able to set the primary controller to the IDE, and put your MFM controller as secondary (many of the original ones had such a jumper) and be set, or install a SCSI controller and drive and use a boot floppy to boot from hd1a:/bsd... Yeah, I found it rather odd that it would do that in the first place. I think what's happening is the BIOS can tell there's a controller there, but then it doesn't recognize the drive as something bootable, so it goes to the next hd. The 90 MHz Pentium I tried was, well, highly bizarre. For example, the IDE jumpers were labeled 'PCI IDE' and 'ISA IDE'... and even with the IDE turned off in the BIOS, and a drive attached to the 'ISA IDE', it attempted to boot from that drive, which gave me a dmesg including wdc0 @ pci0. Oh, and I have no docs on the controller, and haven't found any online, and the (many) jumpers are unlabeled. So unfortunately... Yeah. Plus, the controller is physically HUGE (lengthwise). Not all of the machines I've tried can even get it into a slot. Try looking for Total Hardware '99 - your controller might be documented in there. (Just found this... Looks pretty similar. http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItemitem=250157575469 ) As you have probably (re)discovered, the OS takes its cues on the drive geometry from the BIOS. On modern IDE drives, it just doesn't matter, but on an MFM drive, head 3 was really head 3, cylinder 138 was really cylinder 138, and there were 17 sectors on each track, and where the OS requested is where the controller placed the drive and Yes. 615/4/17, although I've also seen 616 mentioned (it's an ST225 with no values on the label). The partition ends at 613 (i.e. 614th cyl), and I think the last track is the landing zone, so I'm going to go with 615 if I can get to that point... where the data came off, so yes, it really needs to be right. Yes, source could probably be modified to hard-code this in the OS, but getting it right would be interesting...and very much in untested code paths, I suspect. Well, on the one hand this seems like something you should be able to shoot yourself in the foot with if you really want, not to mention another way to be BIOS-agnostic. On the other, this is about the only time it would ever matter, so I guess the kernel doesn't need the added complexity of a way to change it... good luck, I'm curious how it all works out... Well, I can post the dmesg and fdisk when I get there. :) Thanks. -- Aaron Mason - Programmer, open source addict I've taken my software vows - for beta or for worse
Re: MFM disk geometry
Try looking for Total Hardware '99 - your controller might be documented in there. Nice! Thanks. http://th99.dyndns.org/c/C-D/20069.htm Unfortunately, it doesn't look like it's actually all that configurable. Although I don't know what some of those settings actually mean. Does anyone else see ways this can help, or care to explain the settings? :) [Ports I understand. Rate I understand but I don't know why you'd need to set it unless maybe it was a question of really really old controllers/CPUs being slower? The others...] [P.S. The controller and drive were pulled from a Wyse 286. Which I have, but seems not to want to boot ATM. The last time I got it to boot, it didn't seem to see the HD. And anyway, I'd like to avoid having to move 20 megs of data on floppies if possible. I'm guessing that that and serial cables would be the only workable choices, given driver difficulties with DOS 3.3 and the fact that the BIOS setup program was apparently originally on a disk which I don't have...]
Re: MFM disk geometry
From: Daniel Malament b...@anonix.net Subject: Re: MFM disk geometry Try looking for Total Hardware '99 - your controller might be documented in there. Nice! Thanks. http://th99.dyndns.org/c/C-D/20069.htm Unfortunately, it doesn't look like it's actually all that configurable. Although I don't know what some of those settings actually mean. Does anyone else see ways this can help, or care to explain the settings? :) I think my first course of action would be to use DOS, or possibly OS/2, to override the disk geometry, unless the disk has data on it that can only be accessed from OpenBSD. Yes, I know it's intellectually more fun to get OpenBSD to do it, but for a one off with little practical future use I think I'd use something else. DOS, OS/2 and OpenBSD can of course all be booted from floppy, thus avoiding any early initialisation nastiness. I'm curious as to exactly what the difference between 'driven to interface' and 'intercepted by controller' is. Is this a standard interface vs INT13 thing? I wouldn't call a P3 system with ISA particularly unusual - by the time the P4 came out they were rare (although, readily available especially if needed for industrial applications). PK
Re: MFM disk geometry
I think my first course of action would be to use DOS, or possibly OS/2, to override the disk geometry, unless the disk has data on it that can only be accessed from OpenBSD. Yes, I know it's intellectually more fun to get OpenBSD to do it, but for a one off with little practical future use I think I'd use something else. DOS, OS/2 and OpenBSD can of course all be booted from floppy, thus avoiding any early initialisation nastiness. I'm not sure what you're describing here. Also, accessing the data from DOS still leaves the problem of moving it. Or perhaps I didn't make it sufficiently clear that the goal was to copy the data off the drive...
Re: MFM disk geometry
From: Daniel Malament b...@anonix.net To: Peter Kay (Syllopsium) syllops...@syllopsium.com I think my first course of action would be to use DOS, or possibly OS/2, to override the disk geometry, unless the disk has data on it that can only be accessed from OpenBSD. Yes, I know it's intellectually more fun to get OpenBSD to do it, but for a one off with little practical future use I think I'd use something else. DOS, OS/2 and OpenBSD can of course all be booted from floppy, thus avoiding any early initialisation nastiness. I'm not sure what you're describing here. Also, accessing the data from DOS still leaves the problem of moving it. Or perhaps I didn't make it sufficiently clear that the goal was to copy the data off the drive... I'm just saying that some operating systems more of the era that the drive was created in are able to specify (override) disk geometries. Obviously moving the data off the drive requires another hard drive, floppies, a network etc exactly the same as under OpenBSD. Alternatively, can disktab be used? The documentation is not entirely transparent on this, but it does appear that disktab might be able to override BIOS parameters. PK
Re: MFM disk geometry
Alternatively, can disktab be used? The documentation is not entirely transparent on this, but it does appear that disktab might be able to override BIOS parameters. Apparently not. disktab looks like it's mostly used by disklabel. It turns out disklabel with -e will let you edit the geometry, but the kernel doesn't actually change the values it uses for drive access, even though the disklabel remains correct/consistent upon reload.
Re: MFM disk geometry
On Tue, Feb 2, 2010 at 12:19 PM, Daniel Malament b...@anonix.net wrote: I think my first course of action would be to use DOS, or possibly OS/2, to override the disk geometry, unless the disk has data on it that can only be accessed from OpenBSD. Yes, I know it's intellectually more fun to get OpenBSD to do it, but for a one off with little practical future use I think I'd use something else. DOS, OS/2 and OpenBSD can of course all be booted from floppy, thus avoiding any early initialisation nastiness. I'm not sure what you're describing here. Also, accessing the data from DOS still leaves the problem of moving it. Or perhaps I didn't make it sufficiently clear that the goal was to copy the data off the drive... You can install the Microsoft Network Client software for DOS. I still have it on a 386 box and used to use it to connect to an OpenBSD samba box. Download from ftp://ftp.microsoft.com/bussys/Clients/MSCLIENT the DSK3-1.EXE and DSK3-2.EXE files. Run these self extracting executables in a temp dir, and read the README. IIRC there is a setup program, which is a little bit confusing, and you have to edit protocol.ini and another *ini file. And you need a driver for your NIC. NIC's from that time came with a floppy with drivers for Microsoft Client or Lan Manager. Adriaan Adriaan IIRC these are self extracting
Re: MFM disk geometry
On Tue, 02 Feb 2010 08:01:41 -0500 Daniel Malament b...@anonix.net wrote: Alternatively, can disktab be used? The documentation is not entirely transparent on this, but it does appear that disktab might be able to override BIOS parameters. Apparently not. disktab looks like it's mostly used by disklabel. It turns out disklabel with -e will let you edit the geometry, but the kernel doesn't actually change the values it uses for drive access, even though the disklabel remains correct/consistent upon reload. If you know these MFM disks use MS file systems, then your best bet is using hardware/system of similar vintage along with another operating system such as MS-DOS or better FreeDOS. http://www.freedos.org/ If you can find a working network interface card, then your problem is solved. The trouble with OpenBSD is it lacks support for the 80386 (and lower). http://www.openbsd.org/i386.html except for the 80386 itself Your best bet is to try finding a 286/386/486 system that either does not have a built-in disk controller, or has a MFM disk controller built-in. If you cannot find anything locally, I might have what you need sitting someplace in my garage, so feel free to contact me off-list. -jon
MFM disk geometry
I'm trying to pull data off an old MFM HD, and I've gotten to the point where the only obstacle is disk geometry. I have a P3 machine which will disable the primary IDE controller in favor of the MFM controller, but boot off of an OpenBSD disk on the secondary IDE. OpenBSD sees the MFM disk just fine, but gives it the wrong CHS, which wouldn't matter except that it's evidently too old to do LBA, since OpenBSD is using CHS mode. I can pull the first few sectors off of the disk, but then I get errors I'm guessing are because of the geometry mismatch. Is there any way at all to change the CHS values the kernel is using for a disk? fdisk with -chs doesn't seem to produce a permanent change (I guess the values are just used for calculating?), and the machdep.bios.etc sysctls are read-only. Google and the archives haven't turned up anything terribly useful, although it sounds like what I'm trying to do may not be possible. If not, anyone have any alternate suggestions? Incidentally, I have a bunch of other old crap around, but my efforts to get everything working on a machine that will let me set the CHS in the BIOS haven't gotten anywhere yet...
Re: MFM disk geometry
Daniel Malament wrote: I'm trying to pull data off an old MFM HD, and I've gotten to the point where the only obstacle is disk geometry. I have a P3 machine which will disable the primary IDE controller in favor of the MFM controller, but boot off of an OpenBSD disk on the secondary IDE. OpenBSD sees the MFM disk just fine, but gives it the wrong CHS, which wouldn't matter except that it's evidently too old to do LBA, since OpenBSD is using CHS mode. I can pull the first few sectors off of the disk, but then I get errors I'm guessing are because of the geometry mismatch. Is there any way at all to change the CHS values the kernel is using for a disk? fdisk with -chs doesn't seem to produce a permanent change (I guess the values are just used for calculating?), and the machdep.bios.etc sysctls are read-only. Google and the archives haven't turned up anything terribly useful, although it sounds like what I'm trying to do may not be possible. If not, anyone have any alternate suggestions? Incidentally, I have a bunch of other old crap around, but my efforts to get everything working on a machine that will let me set the CHS in the BIOS haven't gotten anywhere yet... holy cow. of all the times NOT to post a dmesg! (and fdisk output). It probably wouldn't help diagnose the problem, but it would be cool to see. :) Obviously, you got a PIII machine with ISA slots, not the most common of beasts (though they certainly exist). (actually, the dmesg would probably just show wdc0 at ... , but it would be kinda cool to know that it was REALLY a wdc, not a low-end IDE interface pretending it was an AT controller). I think you need to go back to a P1 (or maybe some PII?) system before you will find one with manual drive parameter selections. That will lead to another problem, very, very very few of those will allow you to directly boot from the secondary controller. HOWEVER, you may be able to set the primary controller to the IDE, and put your MFM controller as secondary (many of the original ones had such a jumper) and be set, or install a SCSI controller and drive and use a boot floppy to boot from hd1a:/bsd... As you have probably (re)discovered, the OS takes its cues on the drive geometry from the BIOS. On modern IDE drives, it just doesn't matter, but on an MFM drive, head 3 was really head 3, cylinder 138 was really cylinder 138, and there were 17 sectors on each track, and where the OS requested is where the controller placed the drive and where the data came off, so yes, it really needs to be right. Yes, source could probably be modified to hard-code this in the OS, but getting it right would be interesting...and very much in untested code paths, I suspect. good luck, I'm curious how it all works out... Nick.
Re: MFM disk geometry
holy cow. of all the times NOT to post a dmesg! (and fdisk output). It probably wouldn't help diagnose the problem, but it would be cool to see. :) Obviously, you got a PIII machine with ISA slots, not the most common of beasts (though they certainly exist). (actually, the dmesg would probably just show wdc0 at ... , but it would be kinda cool to know that it was REALLY a wdc, not a low-end IDE interface pretending it was an AT controller). Heh. It does. I'll have to remember to save copies when I finally get all this working. :) And the machine is a Dell Dimension with one PCI/ISA shared slot. I think you need to go back to a P1 (or maybe some PII?) system before you will find one with manual drive parameter selections. That will lead to another problem, very, very very few of those will allow you to directly boot from the secondary controller. HOWEVER, you may be able to set the primary controller to the IDE, and put your MFM controller as secondary (many of the original ones had such a jumper) and be set, or install a SCSI controller and drive and use a boot floppy to boot from hd1a:/bsd... Yeah, I found it rather odd that it would do that in the first place. I think what's happening is the BIOS can tell there's a controller there, but then it doesn't recognize the drive as something bootable, so it goes to the next hd. The 90 MHz Pentium I tried was, well, highly bizarre. For example, the IDE jumpers were labeled 'PCI IDE' and 'ISA IDE'... and even with the IDE turned off in the BIOS, and a drive attached to the 'ISA IDE', it attempted to boot from that drive, which gave me a dmesg including wdc0 @ pci0. Oh, and I have no docs on the controller, and haven't found any online, and the (many) jumpers are unlabeled. So unfortunately... Yeah. Plus, the controller is physically HUGE (lengthwise). Not all of the machines I've tried can even get it into a slot. (Just found this... Looks pretty similar. http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItemitem=250157575469 ) As you have probably (re)discovered, the OS takes its cues on the drive geometry from the BIOS. On modern IDE drives, it just doesn't matter, but on an MFM drive, head 3 was really head 3, cylinder 138 was really cylinder 138, and there were 17 sectors on each track, and where the OS requested is where the controller placed the drive and Yes. 615/4/17, although I've also seen 616 mentioned (it's an ST225 with no values on the label). The partition ends at 613 (i.e. 614th cyl), and I think the last track is the landing zone, so I'm going to go with 615 if I can get to that point... where the data came off, so yes, it really needs to be right. Yes, source could probably be modified to hard-code this in the OS, but getting it right would be interesting...and very much in untested code paths, I suspect. Well, on the one hand this seems like something you should be able to shoot yourself in the foot with if you really want, not to mention another way to be BIOS-agnostic. On the other, this is about the only time it would ever matter, so I guess the kernel doesn't need the added complexity of a way to change it... good luck, I'm curious how it all works out... Well, I can post the dmesg and fdisk when I get there. :) Thanks.
