FDC motor left on

FDC motor left on

[Richard B. Johnson]

In linux-2.4.22 and earlier, if there is no FDC driver installed,
the FDC motor may continue to run after boot if the motor was
started as part of the BIOS boot sequence.
This patch turns OFF the motor once Linux gets control.


--- linux-2.4.22/arch/i386/boot/setup.S.orig	Fri Aug  2 20:39:42 2002
+++ linux-2.4.22/arch/i386/boot/setup.S	Fri Oct  3 11:50:43 2003
@@ -59,6 +59,8 @@
 #define SIG1	0xAA55
 #define SIG2	0x5A5A

+FDC_MOTOR = 0x3f2
+FDC_MOTON = 0x10
 INITSEG  = DEF_INITSEG		# 0x9000, we move boot here, out of the way
 SYSSEG   = DEF_SYSSEG		# 0x1000, system loaded at 0x10000 (65536).
 SETUPSEG = DEF_SETUPSEG		# 0x9020, this is the current segment
@@ -776,6 +778,12 @@

 	movb	$0xFB, %al			# mask all irq's but irq2 which
 	outb	%al, $0x21			# is cascaded
+
+	movl	$FDC_MOTOR, %edx		# FDC motor control
+	inb	%dx, %al			# Get what's there
+	andb	$~FDC_MOTON, %al		# Reset motor bit
+	outb	%al, %dx			# Turn OFF motor
+

 # Well, that certainly wasn't fun :-(. Hopefully it works, and we don't
 # need no steenking BIOS anyway (except for the initial loading :-).



Cheers,
Dick Johnson
Penguin : Linux version 2.4.22 on an i686 machine (797.90 BogoMips).
            Note 96.31% of all statistics are fiction.

Re: FDC motor left on

[Dave Jones]

On Fri, Oct 03, 2003 at 01:25:30PM -0400, Richard B. Johnson wrote:
 > In linux-2.4.22 and earlier, if there is no FDC driver installed,
 > the FDC motor may continue to run after boot if the motor was
 > started as part of the BIOS boot sequence.
 > This patch turns OFF the motor once Linux gets control.
 > 
 > 
 > --- linux-2.4.22/arch/i386/boot/setup.S.orig	Fri Aug  2 20:39:42 2002
 > +++ linux-2.4.22/arch/i386/boot/setup.S	Fri Oct  3 11:50:43 2003
 > @@ -59,6 +59,8 @@

Does this mean the 'kill_motor' function in bootsect.S isn't doing
what it should be? If so, maybe that needs fixing instead of turning
it off in two places ?

		Dave

-- 
 Dave Jones     http://www.codemonkey.org.uk

Re: FDC motor left on

[Richard B. Johnson]

On Sat, 4 Oct 2003, Dave Jones wrote:

> On Fri, Oct 03, 2003 at 01:25:30PM -0400, Richard B. Johnson wrote:
>  > In linux-2.4.22 and earlier, if there is no FDC driver installed,
>  > the FDC motor may continue to run after boot if the motor was
>  > started as part of the BIOS boot sequence.
>  > This patch turns OFF the motor once Linux gets control.
>  >
>  >
>  > --- linux-2.4.22/arch/i386/boot/setup.S.orig	Fri Aug  2 20:39:42 2002
>  > +++ linux-2.4.22/arch/i386/boot/setup.S	Fri Oct  3 11:50:43 2003
>  > @@ -59,6 +59,8 @@
>
> Does this mean the 'kill_motor' function in bootsect.S isn't doing
> what it should be? If so, maybe that needs fixing instead of turning
> it off in two places ?
>
> 		Dave

Yes. I didn't even see that. The code there makes me kinda sick.
Anyway, the kill_motor function executes "reset diskette/disk" function
which will never turn OFF the drive. Instead, it will restart
the motor timer because, as a condition of reseting the diskette,
it must make sure the motor is running.

I suggest that the FDC control byte be read, then the result be
ANDed with ~0x10, then written back. The ifed-out code clears
the whole control word which is inappropriate at a time the
diskette channel may be still be active.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.22 on an i686 machine (797.90 BogoMips).
            Note 96.31% of all statistics are fiction.

Re: FDC motor left on

[Maciej W. Rozycki]

On Mon, 6 Oct 2003, Richard B. Johnson wrote:

> I suggest that the FDC control byte be read, then the result be
> ANDed with ~0x10, then written back. The ifed-out code clears
> the whole control word which is inappropriate at a time the
> diskette channel may be still be active.

 Which will work for a physical drive 0x0 only -- it won't work for a
BIOS-emulated drive swapping.  Supposedly the most reliable way should be
ANDing with ~0xf0, or better yet, using a BIOS call, preferably by fixing
the boot loader used. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: FDC motor left on

[Mikael Pettersson]

Richard B. Johnson writes:
 > On Sat, 4 Oct 2003, Dave Jones wrote:
 > 
 > > On Fri, Oct 03, 2003 at 01:25:30PM -0400, Richard B. Johnson wrote:
 > >  > In linux-2.4.22 and earlier, if there is no FDC driver installed,
 > >  > the FDC motor may continue to run after boot if the motor was
 > >  > started as part of the BIOS boot sequence.
 > >  > This patch turns OFF the motor once Linux gets control.
 > >  >
 > >  >
 > >  > --- linux-2.4.22/arch/i386/boot/setup.S.orig	Fri Aug  2 20:39:42 2002
 > >  > +++ linux-2.4.22/arch/i386/boot/setup.S	Fri Oct  3 11:50:43 2003
 > >  > @@ -59,6 +59,8 @@
 > >
 > > Does this mean the 'kill_motor' function in bootsect.S isn't doing
 > > what it should be? If so, maybe that needs fixing instead of turning
 > > it off in two places ?
 > >
 > > 		Dave
 > 
 > Yes. I didn't even see that. The code there makes me kinda sick.
 > Anyway, the kill_motor function executes "reset diskette/disk" function
 > which will never turn OFF the drive. Instead, it will restart
 > the motor timer because, as a condition of reseting the diskette,
 > it must make sure the motor is running.
 > 
 > I suggest that the FDC control byte be read, then the result be
 > ANDed with ~0x10, then written back. The ifed-out code clears
 > the whole control word which is inappropriate at a time the
 > diskette channel may be still be active.

Do NOT do any outbs to the FDC unless you've done the equivalent of
the HW detection done in the floppy driver. The BIOS call in kill_motor
is a workaround for the fact that the original raw accesses lock up
the FDCs in some SuperIO chips (including the one in my ASUS P4T-E).

The floppy driver gets it right, but it also does HW detection
first and does the reset differently for non-ancient FDCs.

/Mikael

Re: FDC motor left on

[Richard B. Johnson]

On Mon, 6 Oct 2003, Mikael Pettersson wrote:

> Richard B. Johnson writes:
>  > On Sat, 4 Oct 2003, Dave Jones wrote:
>  >
>  > > On Fri, Oct 03, 2003 at 01:25:30PM -0400, Richard B. Johnson wrote:
>  > >  > In linux-2.4.22 and earlier, if there is no FDC driver installed,
>  > >  > the FDC motor may continue to run after boot if the motor was
>  > >  > started as part of the BIOS boot sequence.
>  > >  > This patch turns OFF the motor once Linux gets control.
>  > >  >
>  > >  >
>  > >  > --- linux-2.4.22/arch/i386/boot/setup.S.orig	Fri Aug  2 20:39:42 2002
>  > >  > +++ linux-2.4.22/arch/i386/boot/setup.S	Fri Oct  3 11:50:43 2003
>  > >  > @@ -59,6 +59,8 @@
>  > >
>  > > Does this mean the 'kill_motor' function in bootsect.S isn't doing
>  > > what it should be? If so, maybe that needs fixing instead of turning
>  > > it off in two places ?
>  > >
>  > > 		Dave
>  >
>  > Yes. I didn't even see that. The code there makes me kinda sick.
>  > Anyway, the kill_motor function executes "reset diskette/disk" function
>  > which will never turn OFF the drive. Instead, it will restart
>  > the motor timer because, as a condition of reseting the diskette,
>  > it must make sure the motor is running.
>  >
>  > I suggest that the FDC control byte be read, then the result be
>  > ANDed with ~0x10, then written back. The ifed-out code clears
>  > the whole control word which is inappropriate at a time the
>  > diskette channel may be still be active.
>
> Do NOT do any outbs to the FDC unless you've done the equivalent of
> the HW detection done in the floppy driver. The BIOS call in kill_motor
> is a workaround for the fact that the original raw accesses lock up
> the FDCs in some SuperIO chips (including the one in my ASUS P4T-E).
>
> The floppy driver gets it right, but it also does HW detection
> first and does the reset differently for non-ancient FDCs.
>
> /Mikael
>

The write of zero to the FDC control byte may be the reason your
machine has its FDCs locked up. I assure you that all of the
super-io FDC emulation chips expect the FDC motors to be turned
OFF or ON with the bits at FDC_BASE+Offset 2. They are:

0x01	Drive Select
0x02	Drive select
0x04	Reset controller (always reads 0)
0x08	DMA enable
0x10	Drive 0 motor on
0x20	Drive 1 motor on
0x40	Drive 2 motor on
0x80	Drive 3 motor on

>From this, you can see that if this byte is written to zero,
then DMA is disabled. An attempt later on to access this
drive will result in a DMA operation that doesn't complete.

Any hardware detection of which you speak, is not required.
If you can end up with another floppy drive motor on under
any condition when the kernel is given control, then you
can simply reset both (or all) floppy motor control bits.

Any attempt to be cute and reset only the one that is
associated with the current drive-select bits will fail
because all the motor control bits can be on from a
previous access.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.22 on an i686 machine (797.90 BogoMips).
            Note 96.31% of all statistics are fiction.

Re: FDC motor left on

[John Bradford]

> If you can end up with another floppy drive motor on under
> any condition when the kernel is given control, then you
> can simply reset both (or all) floppy motor control bits.

This is not a problem to deal with in the kernel - what if there is
hardware other than a floppy controller at that address?

The bootloader needs to ensure that the hardware is at least in a
sensible state when the kernel is entered.  Infact, unless the system
is being booted from floppy, why is the BIOS accessing the floppy at
all?

Re-configure the BIOS not to try to boot from the floppy, or to seek
the drive to see whether it is capable of 40 or 80 tracks.

If that is not possible, (on a laptop with an obscure BIOS for
example), add a delay to the bootloader.  Assumng interupts are still
enabled, the BIOS will switch the floppy off after a few seconds.

John.

Re: FDC motor left on

[Richard B. Johnson]

On Mon, 6 Oct 2003, John Bradford wrote:

> > If you can end up with another floppy drive motor on under
> > any condition when the kernel is given control, then you
> > can simply reset both (or all) floppy motor control bits.
>
> This is not a problem to deal with in the kernel - what if there is
> hardware other than a floppy controller at that address?
>

In the ix86 architecture (and it is in arch-specific code), there
cannot be anything at this address except a floppy or nothing.
In both cases, you are covered.

I any embedded systems developer decides to put something besides
a FDC at that address, it is up to them to fix the problems they
create, not linux.

> The bootloader needs to ensure that the hardware is at least in a
> sensible state when the kernel is entered.  Infact, unless the system
> is being booted from floppy, why is the BIOS accessing the floppy at
> all?
>

The BIOS accesses the floppy (if one exists) because of the
boot order having been selected. Many who have computers,
that are not accessible to others, have the BIOS set up so
that the first thing to check for a boot-loader is the floppy,
then the CD-ROM, then the hard disk. This lets them do their
normal work without having to muck with the BIOS.

It is not an error to configure a machine this way. It
is an option. It is an error, however, to leave a floppy
disk-drive motor ON forever.

> Re-configure the BIOS not to try to boot from the floppy, or to seek
> the drive to see whether it is capable of 40 or 80 tracks.
>

The BIOS can be (correctly) set to any of many possible boot-
options.

> If that is not possible, (on a laptop with an obscure BIOS for
> example), add a delay to the bootloader.  Assumng interupts are still
> enabled, the BIOS will switch the floppy off after a few seconds.
>

An arbitrary delay is a very bad hack. If you need something OFF,
you turn it OFF. One should never work-around a primative like
ON or OFF. The digital-output registers at the FDC's specified
address is where this is done.

> John.
>

Cheers,
Dick Johnson
Penguin : Linux version 2.4.22 on an i686 machine (797.90 BogoMips).
            Note 96.31% of all statistics are fiction.

Re: FDC motor left on

[Maciej W. Rozycki]

On Mon, 6 Oct 2003, Richard B. Johnson wrote:

> > This is not a problem to deal with in the kernel - what if there is
> > hardware other than a floppy controller at that address?
> 
> In the ix86 architecture (and it is in arch-specific code), there
> cannot be anything at this address except a floppy or nothing.
> In both cases, you are covered.

 Huh?  The floppies use ordinary I/O ports at the ISA bus, not the range
reserved for motherboard devices as, until quite recently, FDCs used to
exist solely as add-on cards (I still have one).  Any other ISA device is
free to use the port range if it's unused by anything else (e.g. no FDC
there).  Ditto for IRQ6 -- older cards used to have an option to use this
line, only newer ones often do not have it anymore, for unknown reason
(i.e. the cost is probably one).

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: FDC motor left on

[Richard B. Johnson]

On Mon, 6 Oct 2003, Maciej W. Rozycki wrote:

> On Mon, 6 Oct 2003, Richard B. Johnson wrote:
>
> > > This is not a problem to deal with in the kernel - what if there is
> > > hardware other than a floppy controller at that address?
> >
> > In the ix86 architecture (and it is in arch-specific code), there
> > cannot be anything at this address except a floppy or nothing.
> > In both cases, you are covered.
>
>  Huh?  The floppies use ordinary I/O ports at the ISA bus, not the range
> reserved for motherboard devices as, until quite recently, FDCs used to
> exist solely as add-on cards (I still have one).  Any other ISA device is
> free to use the port range if it's unused by anything else (e.g. no FDC
> there).  Ditto for IRQ6 -- older cards used to have an option to use this
> line, only newer ones often do not have it anymore, for unknown reason
> (i.e. the cost is probably one).

No. The range of addresses for floppy disk controllers is
"reserved" for floppy disk controllers. That's the rule for
IBM/PC/AT/Intel compatible devices. This is specified in
the literature like that written by Phoenix, IBM, etc.
(Phoenix Technical Reference Series, System BIOS for
IBM PC/XT/AT and Compatible Computers.  ISBN 0-201-51806-6

We have rules. That's what "Compatible" means. If you break
the compatibility by putting something else at that address,
you take your chances.

When the Super I/O chips are programmed, the floppy device,
(usually logical device 0) is (must) be put at the base
address reserved for floppy disks in compatible machines.
It's the rule. If you are using the same chip in some non-
compatible machine (like a power-PC), they have rules where
the floppy must be addressed, too. These addresses are
different for different architectures and, some machines
don't have I/O ports, they are memory mapped. In those
cases, the floppy is put at some memory-mapped address.

For the architecture in the linux i386 subdirectory, which
is what I was talking about, there will either be a FDC
controller output register at 0x372, with the bits previously
taught, or there will be nothing. It's that simple. If
you make it more complicated, then you don't understand
what compatibility means.


Cheers,
Dick Johnson
Penguin : Linux version 2.4.22 on an i686 machine (797.90 BogoMips).
            Note 96.31% of all statistics are fiction.

Re: FDC motor left on

[Maciej W. Rozycki]

On Mon, 6 Oct 2003, Richard B. Johnson wrote:

> >  Huh?  The floppies use ordinary I/O ports at the ISA bus, not the range
> > reserved for motherboard devices as, until quite recently, FDCs used to
> > exist solely as add-on cards (I still have one).  Any other ISA device is
> > free to use the port range if it's unused by anything else (e.g. no FDC
> > there).  Ditto for IRQ6 -- older cards used to have an option to use this
> > line, only newer ones often do not have it anymore, for unknown reason
> > (i.e. the cost is probably one).
> 
> No. The range of addresses for floppy disk controllers is
> "reserved" for floppy disk controllers. That's the rule for
> IBM/PC/AT/Intel compatible devices. This is specified in
> the literature like that written by Phoenix, IBM, etc.
> (Phoenix Technical Reference Series, System BIOS for
> IBM PC/XT/AT and Compatible Computers.  ISBN 0-201-51806-6

 That means standard ISA FDCs, if present, will be just there, not
elsewhere.  This is needed for the MB BIOS to recognize the controllers,
but an add-on card with its own BIOS is free to use other addresses as
long as it appropriately hooks the BIOS int 0x13 chain.

> We have rules. That's what "Compatible" means. If you break
> the compatibility by putting something else at that address,
> you take your chances.

 You disable the port addresses for floppies either with the PC/XT
configuration switches or with appropriate settings in the BBU RAM area of
the RTC chip for PC/AT.  Compatibility is preserved by only using BIOS
calls and predefined variables.  This is especially needed for controllers
with own BIOSes.

> When the Super I/O chips are programmed, the floppy device,
> (usually logical device 0) is (must) be put at the base
> address reserved for floppy disks in compatible machines.

 That's no problem -- when you have standard ISA FDC devices to be handled
by the system BIOS, you have to put them at the predefined addresses.  Of
course these need not be the so called "super I/O" chips -- they may well
be the original NEC uPD765 ones or compatible substitutes. 

> For the architecture in the linux i386 subdirectory, which
> is what I was talking about, there will either be a FDC
> controller output register at 0x372, with the bits previously
> taught, or there will be nothing. It's that simple. If
> you make it more complicated, then you don't understand
> what compatibility means.

 You need to query the BIOS if standard ISA floppy drives are supported,
either via a call or checking the BIOS variable area.  If there is no
floppy drive at the expected address, you can only assume exactly that and
not that there's nothing decoding these addresses at all. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: FDC motor left on

[John Bradford]

> > > If you can end up with another floppy drive motor on under
> > > any condition when the kernel is given control, then you
> > > can simply reset both (or all) floppy motor control bits.
> >
> > This is not a problem to deal with in the kernel - what if there is
> > hardware other than a floppy controller at that address?
> >
> 
> In the ix86 architecture (and it is in arch-specific code), there
> cannot be anything at this address except a floppy or nothing.
> In both cases, you are covered.
> 
> I any embedded systems developer decides to put something besides
> a FDC at that address, it is up to them to fix the problems they
> create, not linux.

If no support for floppy drives is compiled in to the kernel, it's
reasonable to expect no floppy-related accesses to be done to those
ports.

> > The bootloader needs to ensure that the hardware is at least in a
> > sensible state when the kernel is entered.  Infact, unless the system
> > is being booted from floppy, why is the BIOS accessing the floppy at
> > all?
> >
> 
> The BIOS accesses the floppy (if one exists) because of the
> boot order having been selected. Many who have computers,
> that are not accessible to others, have the BIOS set up so
> that the first thing to check for a boot-loader is the floppy,
> then the CD-ROM, then the hard disk. This lets them do their
> normal work without having to muck with the BIOS.
> 
> It is not an error to configure a machine this way. It
> is an option. It is an error, however, to leave a floppy
> disk-drive motor ON forever.

OK, so the bootloader is at fault, not the BIOS.  If the BIOS is
configured to allow booting from floppy, but you decide to boot from
other media on any occasion, the first code loaded, I.E. the
bootloader, should turn off the floppy motor.

> > Re-configure the BIOS not to try to boot from the floppy, or to seek
> > the drive to see whether it is capable of 40 or 80 tracks.
> >
> 
> The BIOS can be (correctly) set to any of many possible boot-
> options.

If the floppy motor ends up being on all the time, how is that a
correct configuration?

> > If that is not possible, (on a laptop with an obscure BIOS for
> > example), add a delay to the bootloader.  Assumng interupts are still
> > enabled, the BIOS will switch the floppy off after a few seconds.
> >
> 
> An arbitrary delay is a very bad hack.

Yes, it is, the real solution is to fix the bootloader.  I was simply
providing a workaround.

> If you need something OFF,
> you turn it OFF. One should never work-around a primative like
> ON or OFF. The digital-output registers at the FDC's specified
> address is where this is done.

I consider it just as much of a hack to add floppy-related code to all
i386 kernels whether they are for floppy-less machines or not.

John.

Re: FDC motor left on

[Richard B. Johnson]

On Mon, 6 Oct 2003, John Bradford wrote:

> > > > If you can end up with another floppy drive motor on under
> > > > any condition when the kernel is given control, then you
> > > > can simply reset both (or all) floppy motor control bits.
> > >
> > > This is not a problem to deal with in the kernel - what if there is
> > > hardware other than a floppy controller at that address?
> > >
> >
> > In the ix86 architecture (and it is in arch-specific code), there
> > cannot be anything at this address except a floppy or nothing.
> > In both cases, you are covered.
> >
> > I any embedded systems developer decides to put something besides
> > a FDC at that address, it is up to them to fix the problems they
> > create, not linux.
>
> If no support for floppy drives is compiled in to the kernel, it's
> reasonable to expect no floppy-related accesses to be done to those
> ports.
>
> > > The bootloader needs to ensure that the hardware is at least in a
> > > sensible state when the kernel is entered.  Infact, unless the system
> > > is being booted from floppy, why is the BIOS accessing the floppy at
> > > all?
> > >
> >
> > The BIOS accesses the floppy (if one exists) because of the
> > boot order having been selected. Many who have computers,
> > that are not accessible to others, have the BIOS set up so
> > that the first thing to check for a boot-loader is the floppy,
> > then the CD-ROM, then the hard disk. This lets them do their
> > normal work without having to muck with the BIOS.
> >
> > It is not an error to configure a machine this way. It
> > is an option. It is an error, however, to leave a floppy
> > disk-drive motor ON forever.
>
> OK, so the bootloader is at fault, not the BIOS.  If the BIOS is
> configured to allow booting from floppy, but you decide to boot from
> other media on any occasion, the first code loaded, I.E. the
> bootloader, should turn off the floppy motor.
>
> > > Re-configure the BIOS not to try to boot from the floppy, or to seek
> > > the drive to see whether it is capable of 40 or 80 tracks.
> > >
> >
> > The BIOS can be (correctly) set to any of many possible boot-
> > options.
>
> If the floppy motor ends up being on all the time, how is that a
> correct configuration?
>
> > > If that is not possible, (on a laptop with an obscure BIOS for
> > > example), add a delay to the bootloader.  Assumng interupts are still
> > > enabled, the BIOS will switch the floppy off after a few seconds.
> > >
> >
> > An arbitrary delay is a very bad hack.
>
> Yes, it is, the real solution is to fix the bootloader.  I was simply
> providing a workaround.
>
> > If you need something OFF,
> > you turn it OFF. One should never work-around a primative like
> > ON or OFF. The digital-output registers at the FDC's specified
> > address is where this is done.
>
> I consider it just as much of a hack to add floppy-related code to all
> i386 kernels whether they are for floppy-less machines or not.
>
> John.
>

Well we are in agreement that it must be turned OFF. The only
question is where it should be done. Already the kernel fixes
the video board (generic VGA) and other stuff that it may
find wrong (PCI bus), etc. So, a simple read/write to a
machine-compatible port might be the simplest accommodation.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.22 on an i686 machine (797.90 BogoMips).
            Note 96.31% of all statistics are fiction.

Re: FDC motor left on

[John Bradford]

> Well we are in agreement that it must be turned OFF. The only
> question is where it should be done. Already the kernel fixes
> the video board (generic VGA) and other stuff that it may
> find wrong (PCI bus), etc. So, a simple read/write to a
> machine-compatible port might be the simplest accommodation.

Maybe this fix should go in now, and a thorough overview of legacy
workarounds done during the 2.7 development cycle.

Overall, what I'm thinking is that while it's generally a good idea to
keep workarounds for really ancient hardware, just in case somebody
does want to still use it, workarounds for buggy hardware that, for
example, only ever existed on ISA cards, are at best pointless on
systems which don't have any ISA slots, and at worst could cause
problems with future hardware.

John.

Re: FDC motor left on

[Mikael Pettersson]

On Sat, 4 Oct 2003 00:58:02 +0100, Dave Jones wrote:
>On Fri, Oct 03, 2003 at 01:25:30PM -0400, Richard B. Johnson wrote:
> > In linux-2.4.22 and earlier, if there is no FDC driver installed,
> > the FDC motor may continue to run after boot if the motor was
> > started as part of the BIOS boot sequence.
> > This patch turns OFF the motor once Linux gets control.
> > 
> > 
> > --- linux-2.4.22/arch/i386/boot/setup.S.orig	Fri Aug  2 20:39:42 2002
> > +++ linux-2.4.22/arch/i386/boot/setup.S	Fri Oct  3 11:50:43 2003
> > @@ -59,6 +59,8 @@
>
>Does this mean the 'kill_motor' function in bootsect.S isn't doing
>what it should be? If so, maybe that needs fixing instead of turning
>it off in two places ?

It's my understanding that bootsect.S:kill_motor is part of
the kernel's old builtin boot-from-floppy code, and that it
doesn't run when some other boot loader loaded the kernel.
(And it shouldn't have to.)

The workaround if you have a buggy BIOS or external loader
is to configure BLK_DEV_FD as a built-in. I do that anyway
for other reasons (to avoid an unresolved module autoloading
failure in some cases; it's in RH bugzilla somewhere).

/Mikael