Message-id: <200805240852.58268.gene.heskett@gmail.com>
Date:	Sat, 24 May 2008 08:52:58 -0400
From:	Gene Heskett <gene.heskett@...il.com>
To:	Stefan Richter <stefanr@...6.in-berlin.de>
Cc:	linux-kernel@...r.kernel.org, Jens Axboe <axboe@...nel.dk>
Subject: Re: floppy question of the hour

On Saturday 24 May 2008, Stefan Richter wrote:
>(Adding Cc: block layer maintainer for no solid reason...)

Thank you Stefan.  I've done a reply all.

>Gene Heskett wrote:
>> Who is the maintainer of drivers/block/floppy.c and associated files?
>>
>> I ask because there are a few of us still using it, in particular with
>> what some may call oddball disk formats & I'm up to here with doing such
>> as this:
>>
>> [root@...ote coco3]# setfdprm /dev/fd0 COCO7203.5
>> [root@...ote coco3]# getfdprm /dev/fd0
>> get geometry parameters: No such device
>>
>> Or: Assuming the above took,
>> [root@...ote coco3]# dd if=/dev/fd0 of=test.dsk
>> dd: reading `/dev/fd0': Input/output error
>> 0+0 records in
>> 0+0 records out
>> 0 bytes (0 B) copied, 25.5495 s, 0.0 kB/s
>>
>> /var/log/messages is full of these now:
>> May 23 21:02:07 coyote kernel: [20603.055178] floppy0: probe failed...
>> May 23 21:02:07 coyote kernel: [20603.455755] floppy0: unexpected
>> interrupt May 23 21:02:07 coyote kernel: [20603.455827] floppy0: sensei
>> repl[0]=80 May 23 21:02:07 coyote kernel: [20603.456135] floppy0: -- FDC
>> reply errorfloppy0: probe failed...
>
>[...]
>
>> The drive led is on and the disk is turning during that 25 seconds.
>> This is booted to 2.6.26-rc2, with the floppy driver built in.
>
>There was only a single change to drivers/block/floppy.c after 2.6.25:
>http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdif
>f;h=7afea3bcb1f87f3ddf34b38f202ad0d03f29e120
>
>This looks OK to me; I suppose the problem comes from somewhere else.

Floppy has not worked well for me since about the 2.6.22 time frame.  But I was 
usually able to make it work with minimal fussing before that, and there was a 
period where it appeared that fdutils-5.4 worked better than 5.5 too.

I don't know just yet.  On a whim yesterday after posting this, I rebuilt 
2.6.26-rc2 with the floppy as a module, and with one or two hiccups, like 
setfdprm might have to be done more than once after the disc is inserted, it 
worked nominally well, whereas if built in, it is a total failure.

Perhaps there is a clue in that?

One thing I've noted is that writing a 550k dsk image to a 720k DD OS-9 
(MicroWare OS-9, not Apples) formatted disc, while it works and the results cmp 
well, its very slow at 3.1kb a second for writes.  Reads are faster but 
similarly slow.

[root@...ote coco3_6309]# time dd if=/dev/fd0 of=/dev/null
1440+0 records in
1440+0 records out
737280 bytes (737 kB) copied, 112.984 s, 6.5 kB/s

real    1m53.023s
user    0m0.004s
sys     0m0.009s

This is a 250 kilobaud data rate format, the maximum the WD-1773 FDC chip in the 
target machine can handle, with 18, 256 byte sectors per track, two sides=73728 
bits to write a track, /250000 (baud rate)=0.294912 seconds to write one full 
tracks worth of data. 80 tracks=23.59296 seconds to write the whole disk if it 
were streaming, but it takes 3 minutes and change?  And nearly 2 to read it 
back as above?  Odd.  With the interleave of 3, I could see 75 seconds maybe 
for efficient methods.  I also understand this is a one size fits all scene 
too, and that there must be compromises.

I format these DD discs in the target machine with an interleave factor of 3 cuz 
that machines cpu is running at as low as .89MHZ and can't handle the read data 
any faster than that.

Is this non-1 interleave responsible for the slowness of the writes or reads on 
this box?  I can control the interleave on the target box, so I suppose I could 
test that effect easily enough.

>> 2.6.26-rc1 worked flawlessly yesterday, for both writing, then reading
>> back for a cmp session, twice each way, until it(2.6.26-rc1) went away
>> after about 3 hours uptime, the 5th time -rc1 had done this to me without
>> a single footprint in the logs.  -rc2 is doing better, uptime is 5:45 so
>> far.
>
>[...]
>
>By "until it(2.6.26-rc1) went away" you mean a crash during writing to
>or reading from the FDD, or during general usage?

General usage. While switching work screens several times the most common, the 
screen gets about half redrawn & the whole machine freezes up.  Reset button 
required.  The last time was in the middle of the nightly amanda run yesterday 
morning early & when I awoke, the space bar did nothing to unblank the screen, 
and the only other button that worked was the hardware reset on the case.  No 
screen switching there...  The last build of -rc2 has 10+ hours on it & still 
feels good.

-- 
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)
The fortune program is supported, in part, by user contributions and by
a major grant from the National Endowment for the Inanities.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists