floppy question of the hour

floppy question of the hour

[Gene Heskett]

Greetings all;

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@coyote coco3]# setfdprm /dev/fd0 COCO7203.5
[root@coyote coco3]# getfdprm /dev/fd0
get geometry parameters: No such device

Or: Assuming the above took,
[root@coyote 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...
May 23 21:02:08 coyote kernel: [20604.257007] floppy0: probe failed...
May 23 21:02:08 coyote kernel: [20604.658234] floppy0: probe failed...
May 23 21:02:08 coyote kernel: [20604.658546] end_request: I/O error, dev fd0, 
sector 0
May 23 21:02:08 coyote kernel: [20604.658552] Buffer I/O error on device fd0, 
logical block 0
May 23 21:02:15 coyote kernel: [20611.468471] floppy0: probe failed...
May 23 21:02:16 coyote kernel: [20612.269749] floppy0: probe failed...
May 23 21:02:16 coyote kernel: [20612.670448] floppy0: probe failed...
May 23 21:02:17 coyote kernel: [20613.071326] floppy0: probe failed...
May 23 21:02:17 coyote kernel: [20613.471699] floppy0: probe failed...
May 23 21:02:17 coyote kernel: [20613.872260] floppy0: probe failed...
May 23 21:02:18 coyote kernel: [20614.272896] floppy0: probe failed...
May 23 21:02:18 coyote kernel: [20614.673525] floppy0: probe failed...
May 23 21:02:19 coyote kernel: [20615.474809] floppy0: probe failed...
May 23 21:02:19 coyote kernel: [20615.879286] floppy0: probe failed...
May 23 21:02:20 coyote kernel: [20616.276125] floppy0: probe failed...
May 23 21:02:20 coyote kernel: [20616.676819] floppy0: probe failed...
May 23 21:02:21 coyote kernel: [20617.077384] floppy0: probe failed...
May 23 21:02:21 coyote kernel: [20617.478006] floppy0: probe failed...
May 23 21:02:21 coyote kernel: [20617.478326] end_request: I/O error, dev fd0, 
sector 0
May 23 21:02:21 coyote kernel: [20617.478333] Buffer I/O error on device fd0, 
logical block 0

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.

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.

It may be old technology, but really guys, we need a _working_ floppy driver. 
100% of the time.

I did not build it in when I built 2.6.26-rc1, so I'm going to reboot to it for 
long enough to see if it works when built as a module.
-- 
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)
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
		-- Benjamin Franklin, 1759

Re: floppy question of the hour

[Stefan Richter]

(Adding Cc: block layer maintainer for no solid reason...)

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@coyote coco3]# setfdprm /dev/fd0 COCO7203.5
> [root@coyote coco3]# getfdprm /dev/fd0
> get geometry parameters: No such device
> 
> Or: Assuming the above took,
> [root@coyote 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=commitdiff;h=7afea3bcb1f87f3ddf34b38f202ad0d03f29e120

This looks OK to me; I suppose the problem comes from somewhere else.

> 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?
-- 
Stefan Richter
-=====-==--- -=-= ==---
http://arcgraph.de/sr/

Re: floppy question of the hour

[Gene Heskett]

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@coyote coco3]# setfdprm /dev/fd0 COCO7203.5
>> [root@coyote coco3]# getfdprm /dev/fd0
>> get geometry parameters: No such device
>>
>> Or: Assuming the above took,
>> [root@coyote 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@coyote 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.

Re: floppy question of the hour

[Phillip Susi]

Gene Heskett wrote:
> 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.

Yes, the interleave slows you down, since after accessing sector 1, the 
head must wait to pass over 3 other sectors before finally reaching 
sector 2, therefore, you can only read 1/4 of the sectors on the track 
each revolution of the disk.  That leaves 4 revolutions at 300 rpm 
giving 0.8s to read a track, or 64 seconds to read all 80 tracks, plus 
seek time.  That still does not explain 3 minutes though... not sure 
what else could be slowing you down.

Re: floppy question of the hour

[Gene Heskett]

On Tuesday 27 May 2008, Phillip Susi wrote:
>Gene Heskett wrote:
>> 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.
>
>Yes, the interleave slows you down, since after accessing sector 1, the
>head must wait to pass over 3 other sectors before finally reaching
>sector 2, therefore, you can only read 1/4 of the sectors on the track
>each revolution of the disk.  That leaves 4 revolutions at 300 rpm
>giving 0.8s to read a track, or 64 seconds to read all 80 tracks, plus
>seek time.  That still does not explain 3 minutes though... not sure
>what else could be slowing you down.

Does anyone know if either the floppy driver, or dd, is doing a verification 
read after each sector is written?  That could make it just sort of ooze thru 
the data as that alone would add an additional 18 revolutions of the disk per 
track written, 256 byte sectors in this mode.  That thought has crossed my 
mind, but a full read of that same disk with dd which picks up another 200k of 
empty data, completes in maybe 10 seconds less in total elapsed time.

Also, does anyone know how long after a floppy is inserted before it is 
recognized?  From observation today, it appears to be something in the 5 minute 
territory before a getfdprm returns data instead of "/dev/fd0: no such device".

-- 
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)
I hear what you're saying but I just don't care.

Re: floppy question of the hour

[Lennart Sorensen]

On Tue, May 27, 2008 at 05:49:18PM -0400, Phillip Susi wrote:
> Yes, the interleave slows you down, since after accessing sector 1, the 
> head must wait to pass over 3 other sectors before finally reaching 
> sector 2, therefore, you can only read 1/4 of the sectors on the track 
> each revolution of the disk.  That leaves 4 revolutions at 300 rpm 
> giving 0.8s to read a track, or 64 seconds to read all 80 tracks, plus 
> seek time.  That still does not explain 3 minutes though... not sure 
> what else could be slowing you down.

Just do what the Amiga did:  Read the entire track into a buffer in
memory, then deal with the sectors, and write the entire track back. :)

-- 
Len Sorensen

Re: floppy question of the hour

[Phillip Susi]

Lennart Sorensen wrote:
> Just do what the Amiga did:  Read the entire track into a buffer in
> memory, then deal with the sectors, and write the entire track back. :)

IIRC, there is no way to detect the interleave factor that the media has 
been formatted with, unless you maybe try several and see which one 
reads fastest.

Re: floppy question of the hour

[Lennart Sorensen]

On Wed, May 28, 2008 at 03:38:05PM -0400, Phillip Susi wrote:
> Lennart Sorensen wrote:
> >Just do what the Amiga did:  Read the entire track into a buffer in
> >memory, then deal with the sectors, and write the entire track back. :)
> 
> IIRC, there is no way to detect the interleave factor that the media has 
> been formatted with, unless you maybe try several and see which one 
> reads fastest.

Yeah, the Amiga trick wouldn't work.  The Amiga had no interleave.  It
didn't even have sector gaps.  Just 11 consequtive sectors worth of data
per track and one gap at the end of the track.  I really doubt any other
system could emulate that floppy access method without extra hardware.

-- 
Len Sorensen

Re: floppy question of the hour

[Gene Heskett]

On Wednesday 28 May 2008, Lennart Sorensen wrote:
>On Tue, May 27, 2008 at 05:49:18PM -0400, Phillip Susi wrote:
>> Yes, the interleave slows you down, since after accessing sector 1, the
>> head must wait to pass over 3 other sectors before finally reaching
>> sector 2, therefore, you can only read 1/4 of the sectors on the track
>> each revolution of the disk.  That leaves 4 revolutions at 300 rpm
>> giving 0.8s to read a track, or 64 seconds to read all 80 tracks, plus
>> seek time.  That still does not explain 3 minutes though... not sure
>> what else could be slowing you down.
>
>Just do what the Amiga did:  Read the entire track into a buffer in
>memory, then deal with the sectors, and write the entire track back. :)

That would be a huge improvement, but I'm afraid it would need someone far more 
familiar with floppy.c than I.

I am beginning to figure out how to make it work though.  The sequence goes 
something like this:
1. insert disk in drive, wait 5 minutes just in case, didn't help.
2. setfdprm /dev/fd0 COCO7203.5
3. getfdprm /dev/fd0 (fails, no such device)
4. dd if=/dev/fd0 bs=256 count=1
5. wait 20 to 40 secs for it to fail with an i/o error
6. setfdprm /dev/fd0 COCO7203.5
7. getfdprm /dev/fd0
DS DD sect=18 ssize=256
8. dd if=disk.image of=/dev/fd0 bs=256

then about 4 minutes later:

9. dd if=dev/fd0 of=test.dsk;cmp disk.image test.dsk
Eof "disk.image" (its shorter than the 720k disk itself)

3 more minutes for step 9 and I know if I have a good write.  You can do the 
setfdprm 100 times and it fails silently everytime, but attack it with dd once, 
and /dev/fd0 gets well and works.  4 or 5 years ago it all worked straight off 
with the tools we had then.

FWIW, kernel is now 2.6.26-rc4, stable so far with a 49 hour uptime.

Hell of a way to run a train, guys, really. :)

-- 
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)
Ambidextrous, adj.:
	Able to pick with equal skill a right-hand pocket or a left.
		-- Ambrose Bierce, "The Devil's Dictionary"

Re: floppy question of the hour

[Gene Heskett]

On Wednesday 28 May 2008, Phillip Susi wrote:
>Lennart Sorensen wrote:
>> Just do what the Amiga did:  Read the entire track into a buffer in
>> memory, then deal with the sectors, and write the entire track back. :)
>
>IIRC, there is no way to detect the interleave factor that the media has
>been formatted with, unless you maybe try several and see which one
>reads fastest.

ilv=3 reads the fastest by a wide margin on the target machine.

Thanks Guys.

-- 
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)
God made everything out of nothing, but the nothingness shows through.
		-- Paul Valery

Re: floppy question of the hour

[Gene Heskett]

On Wednesday 28 May 2008, Lennart Sorensen wrote:
>On Wed, May 28, 2008 at 03:38:05PM -0400, Phillip Susi wrote:
>> Lennart Sorensen wrote:
>> >Just do what the Amiga did:  Read the entire track into a buffer in
>> >memory, then deal with the sectors, and write the entire track back. :)
>>
>> IIRC, there is no way to detect the interleave factor that the media has
>> been formatted with, unless you maybe try several and see which one
>> reads fastest.
>
>Yeah, the Amiga trick wouldn't work.  The Amiga had no interleave.  It
>didn't even have sector gaps.  Just 11 consequtive sectors worth of data
>per track and one gap at the end of the track.  I really doubt any other
>system could emulate that floppy access method without extra hardware.

The drives, at least for the 880k format, were std chinon 3.5" drives.  However, 
I was under the impression there was about a 20 byte gap with the sector number 
and a short A5 A5 synch string between the sectors.  I still have a big box 
A-2k, with one DD drive, and one of the special 1760k 150 rpm HD drives too.

But its been nearly a decade since an HD failure prompted me to store it in the 
basement and learn to really use the first linux box I ever built in 1998, 
RH-5.1 on it.  So my memory could be hazy, after all its 73 years old & 
counting. :)

-- 
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)
My philosophy is: Don't think.
		-- Charles Manson

Re: floppy question of the hour

[Jan Engelhardt]

On Wednesday 2008-05-28 00:26, Gene Heskett wrote:
>On Tuesday 27 May 2008, Phillip Susi wrote:
>>Gene Heskett wrote:
>
>Also, does anyone know how long after a floppy is inserted before it is 
>recognized?  From observation today, it appears to be something in the 5 minute 
>territory before a getfdprm returns data instead of "/dev/fd0: no such device".

I have a SONY USB floppy drive which used to get read within 2s
after inserting a new floppy. Which means it somehow signalled
the host, probably through an USB command.

Just as I tried again now (with 2.6.23.17), this does not happen
anymore so I suspect udev or the kernel changed in some way.

Re: floppy question of the hour

[Gene Heskett]

On Sunday 01 June 2008, Jan Engelhardt wrote:
>On Wednesday 2008-05-28 00:26, Gene Heskett wrote:
>>On Tuesday 27 May 2008, Phillip Susi wrote:
>>>Gene Heskett wrote:
>>
>>Also, does anyone know how long after a floppy is inserted before it is
>>recognized?  From observation today, it appears to be something in the 5
>> minute territory before a getfdprm returns data instead of "/dev/fd0: no
>> such device".
>
>I have a SONY USB floppy drive which used to get read within 2s
>after inserting a new floppy. Which means it somehow signalled
>the host, probably through an USB command.
>
>Just as I tried again now (with 2.6.23.17), this does not happen
>anymore so I suspect udev or the kernel changed in some way.

This is attached directly to end connector on the 34 pin floppy cable.

What I have found that seems to work, is to put the disk in, then hit it with a 
junk, 1 block read from dd.  That will take about 25-30 seconds to fail with an 
I/O error.

Then I can do the 'setfdprm' thing, check it with getfdprm, and go ahead and 
write the disk image with dd.

But if I don't knock on the door & fail once, just relying on getting a good 
response from getfdprm from the setfdprm operation before trying dd, it will 
_never_ work.  It has to be hammered on by dd before setfdprm and getfdprm will 
work, and then dd can write to it just fine.

Houston, we have a problem.  But I now know how to work around it sorta like 
McGiver would do I guess, but what about the next user who will never see this 
thread without a truly diligent search?  He will be similarly screwed, but the 
only heavy breathing will be from frustration.

If the kernel should somehow shrink so it could fit on a floppy again, I'd bet 
this would be fixed yet this week. :)  But we all know what the chances of that 
happening are. :(  It would however, be muchly appreciated by us old farts 
using floppies to get stuff to/from a legacy computer.

Thanks guys.

-- 
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)
Wash: "It's Jayne being so generous with his cut that confuses and frightens
me."

Zoe: "It does kind of freeze the blood."
				--Episode #10, "War Stories"

Re: floppy question of the hour

[Kay Sievers]

On Sun, Jun 1, 2008 at 9:00 PM, Jan Engelhardt <jengelh@medozas.de> wrote:
>
> On Wednesday 2008-05-28 00:26, Gene Heskett wrote:
>>On Tuesday 27 May 2008, Phillip Susi wrote:
>>>Gene Heskett wrote:
>>
>>Also, does anyone know how long after a floppy is inserted before it is
>>recognized?  From observation today, it appears to be something in the 5 minute
>>territory before a getfdprm returns data instead of "/dev/fd0: no such device".
>
> I have a SONY USB floppy drive which used to get read within 2s
> after inserting a new floppy. Which means it somehow signalled
> the host, probably through an USB command.
>
> Just as I tried again now (with 2.6.23.17), this does not happen
> anymore so I suspect udev or the kernel changed in some way.

There is no  USB command for media change notifications. We
periodically poll USB floppies with HAL. We can do this, because
unlike legacy floppies, USB floppies seems not to spin up the drive
when polled.

Kay