July 2002 - Fdutils

creating high-capacity disks without --verify_later does not work
by Jochen Voss 02 Nov '02

02 Nov '02

Hello Alain, there seems to be a severe bug in fdutils-5.4-20020222. At least for me superformat is not able to format high capacitiy disks without the --verify_later option. The original bug report I received is at http://bugs.debian.org/148587 It seems, that the verify code uses the _old_ drive parameters (either whatever was autodetected for media that was in the drive before, set with setfdprm, or the default) to verify the tracks, which are formatted with the new parameters. You can reproduce this as follows: # insert a disk with the usual 1440/1440 format into the drive # and make sure that the floppy driver uses this format. voss@automatix [~] setfdprm /dev/fd0 1440/1440 voss@automatix [~] mdir Volume in drive A has no label Volume Serial Number is 682D-7F39 Directory for A:/ No files 1 457 664 bytes free voss@automatix [~] superformat /dev/fd0 ds hd sect=21 This command results in a lot of I/O errors and noises like the floppy drive is suffering. The first few error messages are Jun 30 14:31:39 automatix kernel: end_request: I/O error, dev 02:00 (floppy), sector 60 Jun 30 14:31:40 automatix kernel: end_request: I/O error, dev 02:00 (floppy), sector 62 Jun 30 14:31:43 automatix kernel: end_request: I/O error, dev 02:00 (floppy), sector 81 Jun 30 14:31:44 automatix kernel: end_request: I/O error, dev 02:00 (floppy), sector 82 Jun 30 14:31:46 automatix kernel: end_request: I/O error, dev 02:00 (floppy), sector 102 If I try the same with the "--verify_later" option, everything works fine: voss@automatix [~] superformat --verify_later /dev/fd0 ds hd sect=21 Formatting cylinder 79, head 1 mformat -s21 -t80 -h2 -S2 -M512 a: Verifying cylinder 79, head 1 I hope this helps, Jochen PS.: if you reply to this mail, please send (via Cc:) a copy to 148587-forwarded(a)bugs.debian.org -- http://www.mathematik.uni-kl.de/~wwwstoch/voss/

2 1

minor fix for the clean target of doc/Makefile
by Jochen Voss 02 Nov '02

02 Nov '02

Hello, the clean target of doc/Makefile from fdutils-5.4-20020222 fails to remove some files. It tries to remove files of the form "fdutils.*" where is generates files of the form "Fdutils.*". The script "cleanup" is also affected. This can be fixed with the following patch. == patch starts at following line ========================== --- fdutils-5.4-20020222.orig/doc/Makefile.in +++ fdutils-5.4-20020222/doc/Makefile.in @@ -61,10 +61,10 @@ $(TEXI2DVI) Fdutils.texi clean: - rm -f fdutils.aux fdutils.cp fdutils.cps fdutils.dvi fdutils.fn - rm -f fdutils.log fdutils.pg fdutils.ps fdutils.toc fdutils.tp - rm -f fdutils.ky fdutils.vr fdutils.info fdutils.pgs - rm -f fdutils.info-1 fdutils.info-2 fdutils.info-3 + rm -f Fdutils.aux Fdutils.cp Fdutils.cps Fdutils.dvi Fdutils.fn + rm -f Fdutils.log Fdutils.pg Fdutils.pgs Fdutils.toc Fdutils.tp + rm -f Fdutils.ky Fdutils.vr Fdutils.pgs + rm -f fdutils.info* --- fdutils-5.4-20020222.orig/doc/cleanup +++ fdutils-5.4-20020222/doc/cleanup @@ -1,5 +1,5 @@ #!/bin/sh -rm -f fdutils.aux fdutils.cp fdutils.cps fdutils.dvi fdutils.fn fdutils.ky -rm -f fdutils.log fdutils.pg fdutils.ps fdutils.toc fdutils.tp fdutils.vr -rm -f fdutils.info* +rm -f Fdutils.aux Fdutils.cp Fdutils.cps Fdutils.dvi Fdutils.fn Fdutils.ky +rm -f Fdutils.log Fdutils.pg Fdutils.pgs Fdutils.toc Fdutils.tp Fdutils.vr +rm -f fdutils.info* fdutils.ps == patch ends at previous line ============================= I hope this helps Jochen PS.: this is my last report for today :-( -- Omm (0)-(0) http://www.mathematik.uni-kl.de/~wwwstoch/voss/privat.html

2 1

Re: superformat does not work on m68k machines (fwd)
by David C Niemi 08 Jul '02

08 Jul '02

Received: from TrippleEggs.dorchain.net (TrippleEggs.dorchain.net [213.183.72.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id FAA00846 for <fdutils(a)tux.org>; Mon, 8 Jul 2002 05:35:05 -0400 Received: (from joerg@localhost) by TrippleEggs.dorchain.net (8.12.2/8.12.2) id g689YSHe016278; Mon, 8 Jul 2002 11:34:28 +0200 Date: Mon, 8 Jul 2002 11:34:28 +0200 From: Joerg Dorchain <joerg(a)dorchain.net> To: Geert Uytterhoeven <geert(a)linux-m68k.org> Cc: Michael Schmitz <schmitz(a)zirkon.biophys.uni-duesseldorf.de>, Jochen Voss <jvoss2(a)web.de>, fdutils list <fdutils(a)tux.org>, alain(a)linux.lu Subject: Re: superformat does not work on m68k machines (fwd) Message-ID: <20020708113428.C15757(a)TrippleEggs.dorchain.net> References: <Pine.GSO.4.21.0207081020520.3341-100000(a)vervain.sonytel.be> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="V88s5gaDVPzZ0KCq" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <Pine.GSO.4.21.0207081020520.3341-100000(a)vervain.sonytel.be>; from geert(a)linux-m68k.org on Mon, Jul 08, 2002 at 10:22:24AM +0200 X-message-flag: Formating hard disk. please wait... 10%... 20%... --V88s5gaDVPzZ0KCq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi all, (disclaimer: If I left out interested parties in the Cc, please correct) On Mon, Jul 08, 2002 at 10:22:24AM +0200, Geert Uytterhoeven wrote: > Subject: Re: superformat does not work on m68k machines >=20 > > > AFAIK, this is an m68k linux kernel limitation. > > Yes, I know. But fdformat is said to work, > > so formatting floppies should not be completely > > impossible. > >=20 > > Do you know, is anybody working on the m68k kernel > > floppy driver? >=20 > Nope. It works, why should anybody tamper with it?=20 >=20 > Adding the missing ioctls to the Amiga floppy driver does not seem to make > sense (though it would be easy: just add a fourth drive type for user > defined parameters at the head of the drive type list, then set=20 > unit[drive].type to &drive_types[0] and modify those parameters if a > matching set isn't found). Well, once I thaught about autorecognition features for the driver. The theory was easy: After the whole track is read, enter a stae machine and read enough bytes till you can make a decision instead of assuming a specific format slected by the minors. I boggled implementing it as bitwise state machines are scary monsters to me (character based ones are bad enough ;-). For writing, due to the nature of the amiga hardware, it is easiest to deal with whole tracks and not with single sectors (or even smaller units). So for this, I once calculated the gap lengths (which at that time PC hardware needed ;) and hardcoded them in the code for the supported formats. To get the disired flexibility here, the calculation has to be done at runtime. At least the first implemation will be prone to errors. The trackwise operation has two effects:=20 - it will read and write (and, along with the process, de- and encode) a whole track if only a single bit in it is written. - Formatting is easy: Write a whole track without reading it first. I.e. a track is reformatted everytime something is written to it. (Sidenote, the amigaos trackdisk.device does the same, but I discovered only afterwards.) BTW, there wre tools like this for the amiga to get more out of floppies. IIRC they still exists on Aminet.=20 Additionally, these non standard formats are not wide spread. So I decided for myself to dig into the problem when I get my first strangly formatted floppy disk. In the past five years I encountered none. This shall not prevent anyone from implementing it. In contrast, I can offer some help with testing the stuff and answer questions about programming the floppy hardware and MFM-encoding. It is just that I do not have the time anymore to go deeper into this.` To start experimenting, there is a special ioctl that I used for debugging that returns the content of the raw track buffer as it is read by the hardware, so you can leave the driver alone and test in user space wether the detections works. (Erorrs in user space are core dumps, errors in kernel space are oopses, errors in interrupts just freeze - YMMV ;-) >=20 > Disclaimer: I don't even know if the floppy hardware can be programmed to > support arbitrary formats. Drive formats are selected by opening the > corresponding device on the Amiga. Amiga floppy hardware is very flexible. It can basically read everything (even 1541 GCR disks) and also write it. The hardware is cabable of doing DMS from/to memory (within limits), and can syncronize the sync hole. The downside of this is that all de- and encoding has to be done is software between the raw format on disk and what is presented to the upper layers. Bye, Joerg --V88s5gaDVPzZ0KCq Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9KVyhjY4+4PdzvOARAtXLAKCInNQaP+L1rjjLox8BUiTR49bhHgCghgHx Jie86k3n2nivjwHZLQwFQP0= =+SFV -----END PGP SIGNATURE----- --V88s5gaDVPzZ0KCq--

1 1

Re: superformat does not work on m68k machines (fwd)
by David C Niemi 08 Jul '02

08 Jul '02

Received: from zirkon.biophys.uni-duesseldorf.de (zirkon.biophys.uni-duesseldorf.de [134.99.176.3]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id DAA27202 for <fdutils(a)tux.org>; Mon, 8 Jul 2002 03:09:42 -0400 Received: from localhost (schmitz@localhost) by zirkon.biophys.uni-duesseldorf.de (8.9.3/8.9.3) with ESMTP id JAA24395; Mon, 8 Jul 2002 09:09:37 +0200 Date: Mon, 8 Jul 2002 09:09:37 +0200 (CEST) From: Michael Schmitz <schmitz(a)zirkon.biophys.uni-duesseldorf.de> To: Jochen Voss <jvoss2(a)web.de> cc: Taral <taral(a)taral.net>, fdutils list <fdutils(a)tux.org>, Michael Schmitz <schmitz(a)opal.biophys.uni-duesseldorf.de>, 78915-forwarded(a)bugs.debian.org, alain(a)linux.lu, geert(a)linux-m68k.org Subject: Re: superformat does not work on m68k machines In-Reply-To: <20020707222911.GA9843(a)tatonka.pfalz.de> Message-ID: <Pine.LNX.4.10.10207080855260.24312-100000(a)zirkon.biophys.uni-duesseldorf.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > > AFAIK, this is an m68k linux kernel limitation. > Yes, I know. But fdformat is said to work, > so formatting floppies should not be completely > impossible. > > Do you know, is anybody working on the m68k kernel > floppy driver? Nope. It works, why should anybody tamper with it? Adding the missing ioctls to the Amiga floppy driver does not seem to make sense (though it would be easy: just add a fourth drive type for user defined parameters at the head of the drive type list, then set unit[drive].type to &drive_types[0] and modify those parameters if a matching set isn't found). Disclaimer: I don't even know if the floppy hardware can be programmed to support arbitrary formats. Drive formats are selected by opening the corresponding device on the Amiga. CC: to Geert who might know more about Amiga floppy hardware. Michael

1 0

Re: superformat does not work on m68k machines (fwd)
by David C Niemi 08 Jul '02

08 Jul '02

Received: from zirkon.biophys.uni-duesseldorf.de (zirkon.biophys.uni-duesseldorf.de [134.99.176.3]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id CAA26511 for <fdutils(a)tux.org>; Mon, 8 Jul 2002 02:53:52 -0400 Received: from localhost (schmitz@localhost) by zirkon.biophys.uni-duesseldorf.de (8.9.3/8.9.3) with ESMTP id IAA24362; Mon, 8 Jul 2002 08:53:44 +0200 Date: Mon, 8 Jul 2002 08:53:44 +0200 (CEST) From: Michael Schmitz <schmitz(a)zirkon.biophys.uni-duesseldorf.de> To: Jochen Voss <jvoss(a)rhrk.uni-kl.de> cc: fdutils list <fdutils(a)tux.org>, Michael Schmitz <schmitz(a)opal.biophys.uni-duesseldorf.de>, 78915-forwarded(a)bugs.debian.org, alain(a)linux.lu Subject: Re: superformat does not work on m68k machines In-Reply-To: <20020707190052.GA10341(a)automatix.mathematik.uni-kl.de> Message-ID: <Pine.LNX.4.10.10207080840440.24312-100000(a)zirkon.biophys.uni-duesseldorf.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > It is reported that on an Amiga2000 with a DD floppy drive, > fdutils 5.4-20020222 and kernel 2.2.20 the following error > occurs: > > root@aahz:~>superformat /dev/fd0 > get drive characteristics: Function not implemented > > It is rumored, that this is a general problem of the Linux > kernel for the m68k architecture. Is there any way to work > around this? Or is m68k unsupported? This rumor might be substantiated by a quick look at the Atari and Amiga floppy drivers. My prediction: the ioctl in question isn't implemented, or the ioctl data size mismatches. Both Amiga and Atari implement FDGETPRM. Atari also implements FDSETPRM and FDDEFPRM (and those used to work at the time they were written). Michael

1 0

Re: superformat does not work on m68k machines (fwd)
by Joerg Dorchain 08 Jul '02

08 Jul '02

Hi all, (disclaimer: If I left out interested parties in the Cc, please correct) On Mon, Jul 08, 2002 at 10:22:24AM +0200, Geert Uytterhoeven wrote: > Subject: Re: superformat does not work on m68k machines > > > > AFAIK, this is an m68k linux kernel limitation. > > Yes, I know. But fdformat is said to work, > > so formatting floppies should not be completely > > impossible. > > > > Do you know, is anybody working on the m68k kernel > > floppy driver? > > Nope. It works, why should anybody tamper with it? > > Adding the missing ioctls to the Amiga floppy driver does not seem to make > sense (though it would be easy: just add a fourth drive type for user > defined parameters at the head of the drive type list, then set > unit[drive].type to &drive_types[0] and modify those parameters if a > matching set isn't found). Well, once I thaught about autorecognition features for the driver. The theory was easy: After the whole track is read, enter a stae machine and read enough bytes till you can make a decision instead of assuming a specific format slected by the minors. I boggled implementing it as bitwise state machines are scary monsters to me (character based ones are bad enough ;-). For writing, due to the nature of the amiga hardware, it is easiest to deal with whole tracks and not with single sectors (or even smaller units). So for this, I once calculated the gap lengths (which at that time PC hardware needed ;) and hardcoded them in the code for the supported formats. To get the disired flexibility here, the calculation has to be done at runtime. At least the first implemation will be prone to errors. The trackwise operation has two effects: - it will read and write (and, along with the process, de- and encode) a whole track if only a single bit in it is written. - Formatting is easy: Write a whole track without reading it first. I.e. a track is reformatted everytime something is written to it. (Sidenote, the amigaos trackdisk.device does the same, but I discovered only afterwards.) BTW, there wre tools like this for the amiga to get more out of floppies. IIRC they still exists on Aminet. Additionally, these non standard formats are not wide spread. So I decided for myself to dig into the problem when I get my first strangly formatted floppy disk. In the past five years I encountered none. This shall not prevent anyone from implementing it. In contrast, I can offer some help with testing the stuff and answer questions about programming the floppy hardware and MFM-encoding. It is just that I do not have the time anymore to go deeper into this.` To start experimenting, there is a special ioctl that I used for debugging that returns the content of the raw track buffer as it is read by the hardware, so you can leave the driver alone and test in user space wether the detections works. (Erorrs in user space are core dumps, errors in kernel space are oopses, errors in interrupts just freeze - YMMV ;-) > > Disclaimer: I don't even know if the floppy hardware can be programmed to > support arbitrary formats. Drive formats are selected by opening the > corresponding device on the Amiga. Amiga floppy hardware is very flexible. It can basically read everything (even 1541 GCR disks) and also write it. The hardware is cabable of doing DMS from/to memory (within limits), and can syncronize the sync hole. The downside of this is that all de- and encoding has to be done is software between the raw format on disk and what is presented to the upper layers. Bye, Joerg

1 0

superformat does not work on m68k machines
by Jochen Voss 08 Jul '02

08 Jul '02

Hello again, I was told, that superformat does not work on m68k machines. Is this a know problem? A bug report against the Debian package can be found at http://bugs.debian.org/78915 It is reported that on an Amiga2000 with a DD floppy drive, fdutils 5.4-20020222 and kernel 2.2.20 the following error occurs: root@aahz:~>superformat /dev/fd0 get drive characteristics: Function not implemented It is rumored, that this is a general problem of the Linux kernel for the m68k architecture. Is there any way to work around this? Or is m68k unsupported? Jochen PS.: If you answer to this mail, the Debian bug tracking system would be glad to receive a copy (via Cc:) at 78915-forwarded(a)bugs.debian.org. -- http://www.mathematik.uni-kl.de/~wwwstoch/voss/

4 5

superformat does not work for USB floppy drives (fwd)
by David C Niemi 08 Jul '02

08 Jul '02

Received: from uni-kl.de (mail.uni-kl.de [131.246.137.52]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id OAA26933 for <fdutils(a)tux.org>; Sun, 7 Jul 2002 14:04:09 -0400 Received: from mathematik.uni-kl.de (IDENT:mmdf@helios.mathematik.uni-kl.de [131.246.164.27]) by uni-kl.de (8.12.4/8.12.4) with ESMTP id g67I3iUo003233; Sun, 7 Jul 2002 20:03:44 +0200 (MET DST) Received: from mathematik.uni-kl.de ( neutron.mathematik.uni-kl.de [131.246.164.16] ) by helios.mathematik.uni-kl.de with ESMTP id aa28392 ; 7 Jul 2002 20:03 +0200 Received: from automatix.mathematik.uni-kl.de ( mail(a)automatix.mathematik.uni-kl.de [131.246.163.119] ) by neutron.mathematik.uni-kl.de with ESMTP id aa21854 ; 7 Jul 2002 18:03 +0000 Received: from voss by automatix.mathematik.uni-kl.de with local (Exim 3.35 #1 (Debian)) id 17RGNr-0002cg-00; Sun, 07 Jul 2002 20:03:43 +0200 Date: Sun, 7 Jul 2002 20:03:43 +0200 From: Jochen Voss <voss(a)mathematik.uni-kl.de> To: fdutils list <fdutils(a)tux.org> Cc: 79362-forwarded(a)bugs.debian.org, John Goerzen <jgoerzen(a)complete.org>, alain(a)linux.lu Subject: superformat does not work for USB floppy drives Message-ID: <20020707180343.GA10028(a)automatix.mathematik.uni-kl.de> Mail-Followup-To: fdutils list <fdutils(a)tux.org>, 79362-forwarded(a)bugs.debian.org, John Goerzen <jgoerzen(a)complete.org>, alain(a)linux.lu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Hello, I got a bug report for the Debian fdutils package, which claims that superformat does not work for USB floppy drives. You may find the full report at http://bugs.debian.org/79362 I seems that the USB floppy driver makes the floppy look like a SCSI hard disk. So superformat's check whether it is talking to a floppy drive naturally fails. I have no idea what should be done here. Any suggestions? Jochen PS.: If you answer to this mail, the Debian bug tracking system would be glad to receive a copy (via Cc:) at 79362-forwarded(a)bugs.debian.org. PPS.: Alain, are you alive? I got no answers from you for my last ten or so emails. I hope everything is ok. -- http://www.mathematik.uni-kl.de/~wwwstoch/voss/

1 0

superformat does not work for USB floppy drives
by Jochen Voss 07 Jul '02

07 Jul '02

[ Second try: for the first mail I had accidentally chosen the wrong From address, so the first mail will probably not get behind the fdutil-lists's spam filter. I apologise for the inconvenience. ] Hello, I got a bug report for the Debian fdutils package, which claims that superformat does not work for USB floppy drives. You may find the full report at http://bugs.debian.org/79362 I seems that the USB floppy driver makes the floppy look like a SCSI hard disk. So superformat's check whether it is talking to a floppy drive naturally fails. I have no idea what should be done here. Any suggestions? Jochen PS.: If you answer to this mail, the Debian bug tracking system would be glad to receive a copy (via Cc:) at 79362-forwarded(a)bugs.debian.org. PPS.: Alain, are you alive? I got no answers from you for my last ten or so emails. I hope everything is ok. -- http://www.mathematik.uni-kl.de/~wwwstoch/voss/

2 1