>
>This seemed to indicate that the problem was to do with probing for floppy
>drives after the first, so I changed the "for" loop in fd.c to only check for
>one drive.  The resulting kernel booted fine (with the external cache enabled).
>
>A slightly better fix seemed to be to change the config file to explicity name
>the fd device, rather than use wildcards. Ie:
>
>	fd0 at fdc0 drive 0
>
>Again this kernel booted fine.  As an experiment, I added explicitly configured
>additional floppy drives one at a time, and found the machine hung when booting
>a kernel with four floppy drives configured.  It also hung with less than 4
>drives when I didn't explicitly provide drive numbers.  Ie:
>
>	fd0 at fdc0 drive ?
>	fd1 at fdc0 drive ?
>	
>I guess this indicates some kind of hardware bug, but I would appreciate any
>comments on: 1) why turning the external cache off changes the behaviour; 2)
>what the floppy probe code could be doing to cause this, and whether there is a
>nicer fix than explicitly naming the fd devices.
>
>Thanks in advance.
>
>Duncan

Hello....

I belive I have seen this probe-for-non-present-floppy-and-crash
behavior on my P90 with a VLB multi-I/O card.  For me anyway, when the
probe hits the NE7CMD_SENSEI command, everything goes all funny.  The
video mode is messed with and junk is written to the screen.  Puting a
'return 1' in before the SENSEI command seems to allow the boot to
proceed.

        /* select drive and turn on motor */
        outb(iobase + fdout, drive | FDO_FRST | FDO_MOEN(drive));
        /* wait for motor to spin up */
        delay(250000);
        out_fdc(iobase, NE7CMD_RECAL);
        out_fdc(iobase, drive);
        /* wait for recalibrate */
        delay(2000000);
        out_fdc(iobase, NE7CMD_SENSEI);
        n = fdcresult(fdc);

I figured that this behavior was caused by a buggy multi-I/O card and
since I don't really use floppy disks very often, it wasn't a big
priority for me.


Brad Spencer - bspencer@bassun.cb.att.com [work]
               bspencer@cbnmva.att.com [more work]
               brad@anduin.eldar.org [home]