Running linux with kernel 2.6.3* (2.6.32-rc6, for example) on a couple
of i386 boxes and an amd64 box, I cannot format floppies or do any low
level operations like dd direct to /dev/fd0.
I can read and write to floppies already containing file systems.
This is on debian testing, although I doubt if that is relevant.
I can format floppies under a 2.4.* kernel on an old i386 running an
ancient redhat release.
I have found no similar reports of such problems, but perhaps not many
people still use floppies.
fdformat (I realize that is not part of fdutils), gfloppy (ditto) and
superformat all fail. (Once gfloppy seemed to have succeeded, but I was
not able to replicate that success.) CRC errors are logged to
/var/log/messages.
More details including strace on superformat are here:-
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=548434
Can anyone help or suggest how to investigate further?
Can people here format floppies under 2.6.3* kernels?
Thanks in advance for any help,
ael
Hello ,
I have a problem setting drive/disk parameters with setfdprm ; eg:
'setfdprm /dev/fd0 ss dd sect=26 cyl=40 ssize=128' ;
then 'getfdprm' responds with : 'SS DD size=260 sect=24 ssize=128' ;
in which 'size=' would be '250' the correct value ;
If I do a 'dd' , indeed I only get these 24 sectors outof the 26 each sector ;
luckyly , using 'fdrawcmd' did the job - but 'dd' would be so much more elegant .
In fact I found that I only could set 'sect' to 16,20,24,... ; I checked against different FDC's .
What is wrong ? Anyone ?
Regards .
Greetings & Merry Christmas to all;
I need to support a disk format that has been built into the linux driver
floppy.c since about 2.5.47 or so.
That is the ability to format and use a floppy disk format whose LSN0 is
track 0, sector 0.
Unforch, attempting to do a setfdprm on a format
description in mediaprm that ends in the string 'zero-based' is such a shock
to setfdprm that it bails out with an error, before it reads the rest of the
mediaprm file.
Are there patches for fdutils that allow it to work with those zero-based
disk formats?
Without this, I cannot set for that condition, and an attempted dd
if=/dev/fd0u720 fails with an i/o error without reading a single byte of an
80 track, double-sided, double-density formatted on a color computer running
os9 system disk.
Thanks.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
But like the Good Book says... There's BIGGER DEALS to come!
On 12/10/2009 02:46 PM, Mark Hounschell wrote:
> I have many boxes. They all do the same thing. Running different versions of SuSE, 10.3-11.2. Any kernel at or above 2.6.28 fails to fdformat a floppy. These same machines, using the same floppies and drives, running kernels older than 2.6.28 work just fine. I googled and found other such reports but no solution. I know better than to just assume it's a kernel bug but it sure looks like it could be so I'm inquiring about it here.
>
>
> # fdformat /dev/fd0u1440
> Double-sided, 80 tracks, 18 sec/track. Total capacity 1440 kB.
> Formatting ... done
> Verifying ... Problem reading cylinder 1, expected 18432, read 2048
>
>
> dmesg from 2.6.32:
>
> Dec 10 14:24:21 harley kernel: end_request: I/O error, dev fd0, sector 45
> Dec 10 14:24:21 harley kernel: Buffer I/O error on device fd0, logical block 5
> Dec 10 14:24:23 harley kernel: end_request: I/O error, dev fd0, sector 72
> Dec 10 14:24:23 harley kernel: Buffer I/O error on device fd0, logical block 9
> Dec 10 14:24:26 harley kernel: end_request: I/O error, dev fd0, sector 117
> Dec 10 14:24:26 harley kernel: Buffer I/O error on device fd0, logical block 14
> Dec 10 14:24:28 harley kernel: end_request: I/O error, dev fd0, sector 127
> Dec 10 14:24:28 harley kernel: Buffer I/O error on device fd0, logical block 15
> Dec 10 14:24:30 harley kernel: end_request: I/O error, dev fd0, sector 45
> Dec 10 14:24:30 harley kernel: Buffer I/O error on device fd0, logical block 5
> Dec 10 14:24:32 harley kernel: end_request: I/O error, dev fd0, sector 144
> Dec 10 14:24:32 harley kernel: Buffer I/O error on device fd0, logical block 18
> Dec 10 14:24:34 harley kernel: end_request: I/O error, dev fd0, sector 189
> Dec 10 14:24:34 harley kernel: Buffer I/O error on device fd0, logical block 23
> Dec 10 14:24:36 harley kernel: end_request: I/O error, dev fd0, sector 216
> Dec 10 14:24:36 harley kernel: Buffer I/O error on device fd0, logical block 27
> Dec 10 14:24:39 harley kernel: end_request: I/O error, dev fd0, sector 261
> Dec 10 14:24:39 harley kernel: Buffer I/O error on device fd0, logical block 32
> Dec 10 14:24:41 harley kernel: end_request: I/O error, dev fd0, sector 288
> Dec 10 14:24:41 harley kernel: Buffer I/O error on device fd0, logical block 36
> Dec 10 14:24:43 harley kernel: end_request: I/O error, dev fd0, sector 333
> Dec 10 14:24:43 harley kernel: Buffer I/O error on device fd0, logical block 41
> Dec 10 14:24:45 harley kernel: end_request: I/O error, dev fd0, sector 360
> Dec 10 14:24:45 harley kernel: Buffer I/O error on device fd0, logical block 45
>
>
> # rpm -qf /usr/sbin/fdformat
> util-linux-2.16-4.5.1.i586
>
> Again, on this very machine, running 2.6.27.41 all is fine....
>
The last known working kernel here is 2.6.27.41. 2.6.28 fails. How many from
changes 2.7.27 to 2.6.28?
There has been some development on this problem on the fdutils list. It turns
out that if dma is disabled, (floppy=nodma) fdformat works just fine on kernels
from 2.6.28 to current. So Alain Knaff is trying to help sort it out over on the
fdutils list.
Dan, I'm adding Alain Knaff and the fdutils list to the CC list and quoting your
response in this email so he will see it there. I don't thinkAlain has been
monitoring this list for this problem and it might help.
> On 12/17/2009 03:30 AM, Dan Carpenter wrote:
> I don't know if this is related to your bug, but it's a weirdness in
> floppy.c (from 2.6.32-rc8 sorry I suck for being up to date).
>
> drivers/block/floppy.c
> 2532 size = blk_rq_cur_bytes(current_req);
> 2533
> 2534 rq_for_each_segment(bv, current_req, iter) {
> 2535 if (!remaining)
> 2536 break;
> 2537
> 2538 size = bv->bv_len;
>
> We never use the first size = blk_rq_cur_bytes() assignment.
What we have been able to see when dma is enabled appears to be corruption of
the track label buffer while in transit (dma) to the FDC. It seems that starting
with track 1 and then every 4 tracks or so after that, the track number in the
label for sector 0x0a is 1 less than it should be. We see the buffer (via
printks) is correct before and after transit but does not get transmitted
correctly when DMA is used.
The thread on the fdutils list is getting long but progress is being made.
Please CC that list if anyone can help further.
Thanks and regards
Mark
Hello all! I'm looking for easier ways of mounting floppies directly
from old computers - setfdprm is great for most of them, but it does
not seem to offer an option to read the entire of one side of a disk,
then the entire of the other side, rather than its current behaviour,
read one track from the first side, then one track from the second
side, etc. This is useful for the ADFS 'L' format as used on the later
Acorn BBC Micros, as detailed here: http://www.adsb.co.uk/bbc/linux/
Is it possible that such an option may be added in the future? Or does
the problem lie in kernel behaviour? If the latter, who should I
contact to request a feature there?
Thanks!
Muzer.