We got a very strange behavior of the floppy driver if an resource
manager is using timer
IRQs (0 or and a floppy has been mounted with mount /dev/fd0 /fd.
The resource manager waits receive blocked and writes - triggered by the
timer proxy - a value to 32 dual ported RAM locations and waits than
receive blocked again.
Every access (e.g ls) to the mounted floppy volume stucks or it kills
just the whole system.
Here is what the floppy driver tells us in verbose mode:
We got a very strange behavior of the floppy driver if an resource
manager is using timer
IRQs (0 or > > and a floppy has been mounted with mount /dev/fd0 /fd.
The resource manager waits receive blocked and writes - triggered by the
timer proxy - a value to 32 dual ported RAM locations and waits than
receive blocked again.
Floppy hardware is crap. It is a horrible hack interface.
There was a common problem back when console mode was more common…
if you ran the clock utility (it displayed the time in the upper
right corner of the screen by doing directly accessing VGA memory),
floppy drives would often fail. The vga memory access on every
tick (10 msec) was enough to cause the floppy DMA to fail.
I’ve seen tar/vol access to a floppy fail if the tar was done in
verbose listing to the screen, or to a QWindows wterm windows, but
if there was no screen output (redirected to a file), it would work
fine.
Floppy hardware is incredibly sensitive to the slightest problem on
the bus, or the smallest amount of bus contention. How often are
you doing those dua ported RAM writes? You say a timer proxy, but
not the frequency – but I’d almost guarantee that those bus accesses
are screwing up the floppy DMA.
Floppy hardware is crap.
If you have to use floppy disks, are LS-120 drives (on the IDE
controller) an option?
Also, you probably don’t want to use floppy drives in a real time
system if you can help it – the driver sometimes has to do some
nasty stuff to try and get the timing write for handling the
hardware.
We got a very strange behavior of the floppy driver if an resource
manager is using timer
IRQs (0 or > > and a floppy has been mounted with mount /dev/fd0 /fd.
The resource manager waits receive blocked and writes - triggered by the
timer proxy - a value to 32 dual ported RAM locations and waits than
receive blocked again.
Floppy hardware is crap. It is a horrible hack interface.
Hear hear!
So is VGA hardware. Complete and utter crap!!
ISA bus… crap!!
VL-BUS… crap!!
(Dave… do we still like PCI, or is that not crap until next year?)
Anyway… of all the crappy legacy hardware, floppy hardware is king crap
PS: as long as you don’t count the Gameport
PPS - or ISA network cards
PPPS - or that PCMCIA stuff
PPPPS - ok so it’s not king crap, but it is crap!
We got a very strange behavior of the floppy driver if an resource
manager is using timer
IRQs (0 or > > and a floppy has been mounted with mount /dev/fd0 /fd.
The resource manager waits receive blocked and writes - triggered by the
timer proxy - a value to 32 dual ported RAM locations and waits than
receive blocked again.
Floppy hardware is crap. It is a horrible hack interface.
Hmm … why makes this ‘crapy stuff’ only problems when the floppy
volume has been mounted ??
There was a common problem back when console mode was more common…
if you ran the clock utility (it displayed the time in the upper
right corner of the screen by doing directly accessing VGA memory),
floppy drives would often fail. The vga memory access on every
tick (10 msec) was enough to cause the floppy DMA to fail.
I’ve seen tar/vol access to a floppy fail if the tar was done in
verbose listing to the screen, or to a QWindows wterm windows, but
if there was no screen output (redirected to a file), it would work
fine.
Floppy hardware is incredibly sensitive to the slightest problem on
the bus, or the smallest amount of bus contention. How often are
you doing those dua ported RAM writes?
If IRQ 0 is used, we do the writes every timer tick defined by the
ticksize … mostly 10ms.
If we trigger the writes by the IRQ 8 … every 0.5 up to 4ms.
You say a timer proxy, but
not the frequency – but I’d almost guarantee that those bus accesses
are screwing up the floppy DMA.
Floppy hardware is crap.
If you have to use floppy disks, are LS-120 drives (on the IDE
controller) an option?
Will discuss it with the customer …
Also, you probably don’t want to use floppy drives in a real time
system if you can help it – the driver sometimes has to do some
nasty stuff to try and get the timing write for handling the
hardware.
We got a very strange behavior of the floppy driver if an resource
manager is using timer
IRQs (0 or > > and a floppy has been mounted with mount /dev/fd0 /fd.
The resource manager waits receive blocked and writes - triggered by
the
timer proxy - a value to 32 dual ported RAM locations and waits than
receive blocked again.
Floppy hardware is crap. It is a horrible hack interface.
Hear hear!
So is VGA hardware. Complete and utter crap!!
ISA bus… crap!!
VL-BUS… crap!!
(Dave… do we still like PCI, or is that not crap until next year?)
Anyway… of all the crappy legacy hardware, floppy hardware is king crap
PS: as long as you don’t count the Gameport
PPS - or ISA network cards
PPPS - or that PCMCIA stuff
PPPPS - ok so it’s not king crap, but it is crap!
and a floppy has been mounted with mount /dev/fd0 /fd.