Fdutils

fdutils@fdutils.linux.lu

80 discussions

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

superformat does not play well with devfs
by Jochen Voss 04 Jun '02

04 Jun '02

Hello, it seems that superformat has problems with the device file system devfs. There the floppy device files all live under /dev/floppy. With superformat this leeds to problems like the following: mnemaxa:~# strace superformat /dev/floppy/1h1200 execve("/usr/bin/superformat", ["superformat", "/dev/floppy/1h1200"], [/* 18 vars */]) = 0 uname({sys="Linux", node="mnemaxa", ...}) = 0 ..... open("/dev/floppy/1h1200", O_RDWR|O_NONBLOCK|O_EXCL) = 3 fstat64(0x3, 0xbfffc7bc) = 0 ioctl(3, FDRESET, 0x1) = 0 ioctl(3, FDGETDRVPRM, 0xbfffd2e4) = 0 open("/etc/driveprm", O_RDONLY) = -1 ENOENT (No such file or directory) ioctl(3, FDGETPRM, 0xbfffd254) = 0 close(3) = 0 open("/dev/fd1", O_RDWR|O_NONBLOCK|O_EXCL) = -1 ENOENT (No such file or directory) write(2, "open: No such file or directory\n", 32open: No such file or directory ) = 32 _exit(1) = ? The user tries to format /dev/floppy/1h1200, but superformat changes this to the non-existent /dev/fd1. I think that the following code in "superformat.c" (from fdutils-5.4-20020222) is responsible for this: Starting at line 734: /* this is not a generic format device. Close it, * and open the proper device instead */ if(argc == 0) ioctl(fd[0].fd, FDGETPRM, &geometry); have_geom = 1; close(fd[0].fd); snprintf(drivename,9,"/dev/fd%d", fd[0].drive); fd[0].name = drivename; I think it would help to change this as follows: 1) Check for the existence of /dev/.devfsd 2) If it exists (devfs is used), use "/dev/floppy/%d" as the device name. 3) If .devfsd does not exist, proceed as in the code sniplet above. I hope this helps, Jochen -- http://www.mathematik.uni-kl.de/~wwwstoch/voss/

1 0

suggestion for superformat usage message
by Jochen Voss 04 Jun '02

04 Jun '02

Hallo Alain, some user of the Debian version of superformat noted the following inconsistency: most programs include a synopsis line in the output of the --help option. Examples: voss@automatix [~] ls --help | head Usage: ls [OPTION]... [FILE]... List information about the FILEs (the current directory by default). Sort entries alphabetically if none of -cftuSUX nor --sort. -a, --all do not hide entries starting with . -A, --almost-all do not list implied . and .. -b, --escape print octal escapes for nongraphic characters --block-size=SIZE use SIZE-byte blocks -B, --ignore-backups do not list implied entries ending with ~ -c with -lt: sort by, and show, ctime (time of last voss@automatix [~] grep --help | head Usage: grep [OPTION]... PATTERN [FILE] ... Search for PATTERN in each FILE or standard input. Example: grep -i 'hello world' menu.h main.c Regexp selection and interpretation: -E, --extended-regexp PATTERN is an extended regular expression -F, --fixed-strings PATTERN is a set of newline-separated strings -G, --basic-regexp PATTERN is a basic regular expression -e, --regexp=PATTERN use PATTERN as a regular expression -f, --file=FILE obtain PATTERN from FILE Superformat does not follow this convention. voss@automatix [~] superformat --help | head -D --dosdrive set the dos drive -v --verbosity set verbosity level -f --noverify skip verification -B --dosverify verify disk using mbadblocks -V --verify_later verify floppy after all formatting is done -b --begin_cylinder set cylinder where to begin formatting -e --end_cylinder set cylinder where to end formatting -G --fmt_gap set the formatting gap -F --final_gap set the final gap -i --interleave set the interleave factor Maybe you could add an additional line to the "superformat --help" output, to make it more friedly. I hope this helps, Jochen PS: If you answer to this mail, the Debian bug tracking system would be glad to receive a copy (via Cc:) of your mail to the address 88297-forwarded(a)bugs.debian.org. -- http://www.mathematik.uni-kl.de/~wwwstoch/voss/

1 0

small fix for src/skews.c
by Jochen Voss 21 May '02

21 May '02

Hello, I have a small fix for the file src/skews.c from fdutils-5.4-20020222. The file uses the 'abort' function, which is declared in the header file "stdlib.h", but does not include this header file. This can be fixed by the following patch == patch starts at following line ========================== --- fdutils-5.4-20020222.orig/src/skews.c +++ fdutils-5.4-20020222/src/skews.c @@ -1,5 +1,6 @@ #include <sys/types.h> #include <stdio.h> +#include <stdlib.h> #include "fdutils.h" #include "superformat.h" == patch ends at previous line ============================= I hope this helps, Jochen -- Omm (0)-(0) http://www.mathematik.uni-kl.de/~wwwstoch/voss/privat.html

1 0

small fix for doc/texi-linearize.c
by Jochen Voss 21 May '02

21 May '02

Hello, I have a small fix for the file doc/texi-linearize.c from fdutils--5.4-20020222. The file uses the function 'exit', which is declared in the header file "stdlib.h", but does not include this header file. This can be fixed by the following patch. == patch starts at following line ========================== --- fdutils-5.4-20020222.orig/doc/texi-linearize.c +++ fdutils-5.4-20020222/doc/texi-linearize.c @@ -1,5 +1,6 @@ #include <stdio.h> #include <string.h> +#include <stdlib.h> FILE *my_open(char *directory, char *file) == patch ends at previous line ============================= I hope this helps, Jochen -- Omm (0)-(0) http://www.mathematik.uni-kl.de/~wwwstoch/voss/privat.html

1 0

minor mistake in doc/man-warning.texi
by Jochen Voss 21 May '02

21 May '02

Hello, there is a minor typo in the file doc/man-warning.texi from the fdutils-5.4-20020222 distribution. == patch starts at next line =============================== --- fdutils-5.4-20020222.orig/doc/man-warning.texi +++ fdutils-5.4-20020222/doc/man-warning.texi @@ -3,7 +3,7 @@ This manpage has been automatically generated from fdutils's texinfo documentation. However, this process is only approximative, and some items, such as crossreferences, footnotes and indices are lost in this -translation process. Indeed, this items have no appropriate +translation process. Indeed, these items have no appropriate representation in the manpage format. Moreover, only the items specific to each command have been translated, and the general information about fdutils has been dropped in the manpage version. Thus I strongly advise == patch ends at previous line ============================= Additionally I think that this warning is unnecessarily long. Maybe at least the instruction on how to generate different version of the documentation could be removed from the manual pages and be replaced by a notice similar to "... see the file doc/README from the fdutils source distribution ..."? I hope this helps, Jochen -- Omm (0)-(0) http://www.mathematik.uni-kl.de/~wwwstoch/voss/privat.html

1 0

patch for src/mediaprm
by Jochen Voss 21 May '02

21 May '02

Hello, looking at the src/mediaprm file from fdutils-5.4-20020222 I notice that the last two entries have no colon after the name. I do not know whether this causes problems, but it looks strange. If there is no special reason for the ommitted colons this could be changed by the following patch == patch starts at next line =============================== --- fdutils-5.4-20020222.orig/src/mediaprm +++ fdutils-5.4-20020222/src/mediaprm @@ -779,8 +779,8 @@ SS DD sect=18 cyl=35 ssize=256 # TO7 (Thomson), sides 1 and 2 -"TO7-1" +"TO7-1": SS DD sect=16 ssize=256 -"TO7-2" +"TO7-2": SS DD sect=16 ssize=256 swapsides == patch ends at previous line ============================= Jochen -- Omm (0)-(0) http://www.mathematik.uni-kl.de/~wwwstoch/voss/privat.html

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Fdutils