1993-06-12 14:58:17 +00:00
|
|
|
/*-
|
|
|
|
|
* Copyright (c) 1990 The Regents of the University of California.
|
|
|
|
|
* All rights reserved.
|
|
|
|
|
*
|
|
|
|
|
* This code is derived from software contributed to Berkeley by
|
|
|
|
|
* William Jolitz.
|
|
|
|
|
*
|
|
|
|
|
* Redistribution and use in source and binary forms, with or without
|
|
|
|
|
* modification, are permitted provided that the following conditions
|
|
|
|
|
* are met:
|
|
|
|
|
* 1. Redistributions of source code must retain the above copyright
|
|
|
|
|
* notice, this list of conditions and the following disclaimer.
|
|
|
|
|
* 2. Redistributions in binary form must reproduce the above copyright
|
|
|
|
|
* notice, this list of conditions and the following disclaimer in the
|
|
|
|
|
* documentation and/or other materials provided with the distribution.
|
|
|
|
|
* 3. All advertising materials mentioning features or use of this software
|
|
|
|
|
* must display the following acknowledgement:
|
|
|
|
|
* This product includes software developed by the University of
|
|
|
|
|
* California, Berkeley and its contributors.
|
|
|
|
|
* 4. Neither the name of the University nor the names of its contributors
|
|
|
|
|
* may be used to endorse or promote products derived from this software
|
|
|
|
|
* without specific prior written permission.
|
|
|
|
|
*
|
|
|
|
|
* THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
|
|
|
|
|
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
|
|
|
|
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
|
|
|
|
|
* ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
|
|
|
|
|
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
|
|
|
|
|
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
|
|
|
|
|
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
|
|
|
|
|
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
|
|
|
|
|
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
|
|
|
|
|
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
|
|
|
|
|
* SUCH DAMAGE.
|
|
|
|
|
*
|
1994-02-01 05:55:21 +00:00
|
|
|
* from: @(#)wd.c 7.2 (Berkeley) 5/9/91
|
1997-08-09 01:44:25 +00:00
|
|
|
* $Id: wd.c,v 1.134 1997/08/04 05:26:49 dyson Exp $
|
1993-06-12 14:58:17 +00:00
|
|
|
*/
|
|
|
|
|
|
1994-02-01 05:55:21 +00:00
|
|
|
/* TODO:
|
|
|
|
|
* o Bump error count after timeout.
|
|
|
|
|
* o Satisfy ATA timing in all cases.
|
|
|
|
|
* o Finish merging berry/sos timeout code (bump error count...).
|
|
|
|
|
* o Merge/fix TIH/NetBSD bad144 code.
|
|
|
|
|
* o Don't use polling except for initialization. Need to
|
|
|
|
|
* reorganize the state machine. Then "extra" interrupts
|
|
|
|
|
* shouldn't happen (except maybe one for initialization).
|
|
|
|
|
* o Fix disklabel, boot and driver inconsistencies with
|
|
|
|
|
* bad144 in standard versions.
|
|
|
|
|
* o Support extended DOS partitions.
|
|
|
|
|
* o Support swapping to DOS partitions.
|
|
|
|
|
* o Handle bad sectors, clustering, disklabelling, DOS
|
|
|
|
|
* partitions and swapping driver-independently. Use
|
|
|
|
|
* i386/dkbad.c for bad sectors. Swapping will need new
|
|
|
|
|
* driver entries for polled reinit and polled write).
|
|
|
|
|
*/
|
1993-06-12 14:58:17 +00:00
|
|
|
|
|
|
|
|
#include "wd.h"
|
1995-09-07 08:20:18 +00:00
|
|
|
#ifdef NWDC
|
|
|
|
|
#undef NWDC
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#include "wdc.h"
|
1997-04-28 19:26:18 +00:00
|
|
|
#include "opt_wd.h"
|
1996-09-06 23:32:55 +00:00
|
|
|
#include "opt_atapi.h"
|
|
|
|
|
|
1995-09-07 08:20:18 +00:00
|
|
|
#if NWDC > 0
|
1993-06-12 14:58:17 +00:00
|
|
|
|
1994-08-13 03:50:34 +00:00
|
|
|
#include <sys/param.h>
|
|
|
|
|
#include <sys/dkbad.h>
|
|
|
|
|
#include <sys/systm.h>
|
|
|
|
|
#include <sys/kernel.h>
|
|
|
|
|
#include <sys/conf.h>
|
|
|
|
|
#include <sys/disklabel.h>
|
1995-02-26 01:15:30 +00:00
|
|
|
#include <sys/diskslice.h>
|
1994-08-13 03:50:34 +00:00
|
|
|
#include <sys/buf.h>
|
|
|
|
|
#include <sys/malloc.h>
|
1995-12-08 11:19:42 +00:00
|
|
|
#ifdef DEVFS
|
|
|
|
|
#include <sys/devfsext.h>
|
|
|
|
|
#endif /*DEVFS*/
|
1994-11-18 11:27:41 +00:00
|
|
|
#include <machine/bootinfo.h>
|
1995-02-26 01:15:30 +00:00
|
|
|
#include <machine/clock.h>
|
1995-10-29 17:34:17 +00:00
|
|
|
#include <machine/cons.h>
|
1995-03-16 18:17:34 +00:00
|
|
|
#include <machine/md_var.h>
|
1994-08-13 03:50:34 +00:00
|
|
|
#include <i386/isa/isa.h>
|
|
|
|
|
#include <i386/isa/isa_device.h>
|
|
|
|
|
#include <i386/isa/wdreg.h>
|
|
|
|
|
#include <sys/syslog.h>
|
1994-10-16 03:50:36 +00:00
|
|
|
#include <sys/dkstat.h>
|
1994-08-13 03:50:34 +00:00
|
|
|
#include <vm/vm.h>
|
1995-12-07 12:48:31 +00:00
|
|
|
#include <vm/vm_prot.h>
|
|
|
|
|
#include <vm/pmap.h>
|
1993-06-12 14:58:17 +00:00
|
|
|
|
1997-03-11 23:17:28 +00:00
|
|
|
|
1995-08-18 11:26:35 +00:00
|
|
|
#ifdef ATAPI
|
|
|
|
|
#include <i386/isa/atapi.h>
|
|
|
|
|
#endif
|
|
|
|
|
|
1997-03-11 23:17:28 +00:00
|
|
|
#ifdef CMD640
|
|
|
|
|
#include <i386/isa/wdc_p.h>
|
|
|
|
|
#endif /*CMD640*/
|
|
|
|
|
|
1995-10-29 17:34:17 +00:00
|
|
|
extern void wdstart(int ctrlr);
|
|
|
|
|
|
1994-04-20 07:06:57 +00:00
|
|
|
#define TIMEOUT 10000
|
1993-06-12 14:58:17 +00:00
|
|
|
#define RETRIES 5 /* number of retries before giving up */
|
1994-01-04 20:05:26 +00:00
|
|
|
#define RECOVERYTIME 500000 /* usec for controller to recover after err */
|
1995-04-24 05:09:53 +00:00
|
|
|
#define MAXTRANSFER 255 /* max size of transfer in sectors */
|
1994-08-08 13:53:55 +00:00
|
|
|
/* correct max is 256 but some controllers */
|
|
|
|
|
/* can't handle that in all cases */
|
1995-04-24 04:32:31 +00:00
|
|
|
#define WDOPT_32BIT 0x8000
|
1995-04-24 05:12:29 +00:00
|
|
|
#define WDOPT_SLEEPHACK 0x4000
|
Add support for busmaster DMA on some PCI IDE chipsets.
I changed a few bits here and there, mainly renaming wd82371.c
to ide_pci.c now that it's supposed to handle different chipsets.
It runs on my P6 natoma board with two Maxtor drives, and also
on a Fujitsu machine I have at work with an Opti chipset and
a Quantum drive.
Submitted by:cgull@smoke.marlboro.vt.us <John Hood>
Original readme:
*** WARNING ***
This code has so far been tested on exactly one motherboard with two
identical drives known for their good DMA support.
This code, in the right circumstances, could corrupt data subtly,
silently, and invisibly, in much the same way that older PCI IDE
controllers do. It's ALPHA-quality code; there's one or two major
gaps in my understanding of PCI IDE still. Don't use this code on any
system with data that you care about; it's only good for hack boxes.
Expect that any data may be silently and randomly corrupted at any
moment. It's a disk driver. It has bugs. Disk drivers with bugs
munch data. It's a fact of life.
I also *STRONGLY* recommend getting a copy of your chipset's manual
and the ATA-2 or ATA-3 spec and making sure that timing modes on your
disk drives and IDE controller are being setup correctly by the BIOS--
because the driver makes only the lamest of attempts to do this just
now.
*** END WARNING ***
that said, i happen to think the code is working pretty well...
WHAT IT DOES:
this code adds support to the wd driver for bus mastering PCI IDE
controllers that follow the SFF-8038 standard. (all the bus mastering
PCI IDE controllers i've seen so far do follow this standard.) it
should provide busmastering on nearly any current P5 or P6 chipset,
specifically including any Intel chipset using one of the PIIX south
bridges-- this includes the '430FX, '430VX, '430HX, '430TX, '440LX,
and (i think) the Orion '450GX chipsets. specific support is also
included for the VIA Apollo VP-1 chipset, as it appears in the
relabeled "HXPro" incarnation seen on cheap US$70 taiwanese
motherboards (that's what's in my development machine). it works out
of the box on controllers that do DMA mode2; if my understanding is
correct, it'll probably work on Ultra-DMA33 controllers as well.
it'll probably work on busmastering IDE controllers in PCI slots, too,
but this is an area i am less sure about.
it cuts CPU usage considerably and improves drive performance
slightly. usable numbers are difficult to come by with existing
benchmark tools, but experimentation on my K5-P90 system, with VIA
VP-1 chipset and Quantum Fireball 1080 drives, shows that disk i/o on
raw partitions imposes perhaps 5% cpu load. cpu load during
filesystem i/o drops a lot, from near 100% to anywhere between 30% and
70%. (the improvement may not be as large on an Intel chipset; from
what i can tell, the VIA VP-1 may not be very efficient with PCI I/O.)
disk performance improves by 5% or 10% with these drives.
real, visible, end-user performance improvement on a single user
machine is about nil. :) a kernel compile was sped up by a whole three
seconds. it *does* feel a bit better-behaved when the system is
swapping heavily, but a better disk driver is not the fix for *that*
problem.
THE CODE:
this code is a patch to wd.c and wd82371.c, and associated header
files. it should be considered alpha code; more work needs to be
done.
wd.c has fairly clean patches to add calls to busmaster code, as
implemented in wd82371.c and potentially elsewhere (one could imagine,
say, a Mac having a different DMA controller).
wd82371.c has been considerably reworked: the wddma interface that it
presents has been changed (expect more changes), many bugs have been
fixed, a new internal interface has been added for supporting
different chipsets, and the PCI probe has been considerably extended.
the interface between wd82371.c and wd.c is still fairly clean, but
i'm not sure it's in the right place. there's a mess of issues around
ATA/ATAPI that need to be sorted out, including ATAPI support, CD-ROM
support, tape support, LS-120/Zip support, SFF-8038i DMA, UltraDMA,
PCI IDE controllers, bus probes, buggy controllers, controller timing
setup, drive timing setup, world peace and kitchen sinks. whatever
happens with all this and however it gets partitioned, it is fairly
clear that wd.c needs some significant rework-- probably a complete
rewrite.
timing setup on disk controllers is something i've entirely punted on.
on my development machine, it appears that the BIOS does at least some
of the necessary timing setup. i chose to restrict operation to
drives that are already configured for Mode4 PIO and Mode2 multiword
DMA, since the timing is essentially the same and many if not most
chipsets use the same control registers for DMA and PIO timing.
does anybody *know* whether BIOSes are required to do timing setup for
DMA modes on drives under their care?
error recovery is probably weak. early on in development, i was
getting drive errors induced by bugs in the driver; i used these to
flush out the worst of the bugs in the driver's error handling, but
problems may remain. i haven't got a drive with bad sectors i can
watch the driver flail on.
complaints about how wd82371.c has been reindented will be ignored
until the FreeBSD project has a real style policy, there is a
mechanism for individual authors to match it (indent flags or an emacs
c-mode or whatever), and it is enforced. if i'm going to use a source
style i don't like, it would help if i could figure out what it *is*
(style(9) is about half of a policy), and a way to reasonably
duplicate it. i ended up wasting a while trying to figure out what
the right thing to do was before deciding reformatting the whole thing
was the worst possible thing to do, except for all the other
possibilities.
i have maintained wd.c's indentation; that was not too hard,
fortunately.
TO INSTALL:
my dev box is freebsd 2.2.2 release. fortunately, wd.c is a living
fossil, and has diverged very little recently. included in this
tarball is a patch file, 'otherdiffs', for all files except wd82371.c,
my edited wd82371.c, a patch file, 'wd82371.c-diff-exact', against the
2.2.2 dist of 82371.c, and another patch file,
'wd82371.c-diff-whitespace', generated with diff -b (ignore
whitespace). most of you not using 2.2.2 will probably have to use
this last patchfile with 'patch --ignore-whitespace'. apply from the
kernel source tree root. as far as i can tell, this should apply
cleanly on anything from -current back to 2.2.2 and probably back to
2.2.0. you, the kernel hacker, can figure out what to do from here.
if you need more specific directions, you probably should not be
experimenting with this code yet.
to enable DMA support, set flag 0x2000 for that drive in your config
file or in userconfig, as you would the 32-bit-PIO flag. the driver
will then turn on DMA support if your drive and controller pass its
tests. it's a bit picky, probably. on discovering DMA mode failures
or disk errors or transfers that the DMA controller can't deal with,
the driver will fall back to PIO, so it is wise to setup the flags as
if PIO were still important.
'controller wdc0 at isa? port "IO_WD1" bio irq 14 flags 0xa0ffa0ff
vector wdintr' should work with nearly any PCI IDE controller.
i would *strongly* suggest booting single-user at first, and thrashing
the drive a bit while it's still mounted read-only. this should be
fairly safe, even if the driver goes completely out to lunch. it
might save you a reinstall.
one way to tell whether the driver is really using DMA is to check the
interrupt count during disk i/o with vmstat; DMA mode will add an
extremely low number of interrupts, as compared to even multi-sector
PIO.
boot -v will give you a copious register dump of timing-related info
on Intel and VIAtech chipsets, as well as PIO/DMA mode information on
all hard drives. refer to your ATA and chipset documentation to
interpret these.
WHAT I'D LIKE FROM YOU and THINGS TO TEST:
reports. success reports, failure reports, any kind of reports. :)
send them to cgull+ide@smoke.marlboro.vt.us.
i'd also like to see the kernel messages from various BIOSes (boot -v;
dmesg), along with info on the motherboard and BIOS on that machine.
i'm especially interested in reports on how this code works on the
various Intel chipsets, and whether the register dump works
correctly. i'm also interested in hearing about other chipsets.
i'm especially interested in hearing success/failure reports for PCI
IDE controllers on cards, such as CMD's or Promise's new busmastering
IDE controllers.
UltraDMA-33 reports.
interoperation with ATAPI peripherals-- FreeBSD doesn't work with my
old Hitachi IDE CDROM, so i can't tell if I've broken anything. :)
i'd especially like to hear how the drive copes in DMA operation on
drives with bad sectors. i haven't been able to find any such yet.
success/failure reports on older IDE drives with early support for DMA
modes-- those introduced between 1.5 and 3 years ago, typically
ranging from perhaps 400MB to 1.6GB.
failure reports on operation with more than one drive would be
appreciated. the driver was developed with two drives on one
controller, the worst-case situation, and has been tested with one
drive on each controller, but you never know...
any reports of messages from the driver during normal operation,
especially "reverting to PIO mode", or "dmaverify odd vaddr or length"
(the DMA controller is strongly halfword oriented, and i'm curious to
know if any FreeBSD usage actually needs misaligned transfers).
performance reports. beware that bonnie's CPU usage reporting is
useless for IDE drives; the best test i've found has been to run a
program that runs a spin loop at an idle priority and reports how many
iterations it manages, and even that sometimes produces numbers i
don't believe. performance reports of multi-drive operation are
especially interesting; my system cannot sustain full throughput on
two drives on separate controllers, but that may just be a lame
motherboard.
THINGS I'M STILL MISSING CLUE ON:
* who's responsible for configuring DMA timing modes on IDE drives?
the BIOS or the driver?
* is there a spec for dealing with Ultra-DMA extensions?
* are there any chipsets or with bugs relating to DMA transfer that
should be blacklisted?
* are there any ATA interfaces that use some other kind of DMA
controller in conjunction with standard ATA protocol?
FINAL NOTE:
after having looked at the ATA-3 spec, all i can say is, "it's ugly".
*especially* electrically. the IDE bus is best modeled as an
unterminated transmission line, these days.
for maximum reliability, keep your IDE cables as short as possible and
as few as possible. from what i can tell, most current chipsets have
both IDE ports wired into a single buss, to a greater or lesser
degree. using two cables means you double the length of this bus.
SCSI may have its warts, but at least the basic analog design of the
bus is still somewhat reasonable. IDE passed beyond the veil two
years ago.
--John Hood, cgull@smoke.marlboro.vt.us
1997-07-29 12:57:25 +00:00
|
|
|
#define WDOPT_DMA 0x2000
|
1996-07-21 09:28:50 +00:00
|
|
|
#define WDOPT_FORCEHD(x) (((x)&0x0f00)>>8)
|
1995-04-24 04:32:31 +00:00
|
|
|
#define WDOPT_MULTIMASK 0x00ff
|
1993-06-12 14:58:17 +00:00
|
|
|
|
1994-02-01 05:55:21 +00:00
|
|
|
/*
|
|
|
|
|
* This biotab field doubles as a field for the physical unit number on
|
|
|
|
|
* the controller.
|
|
|
|
|
*/
|
|
|
|
|
#define id_physid id_scsiid
|
1994-01-04 20:05:26 +00:00
|
|
|
|
1993-06-12 14:58:17 +00:00
|
|
|
/*
|
|
|
|
|
* Drive states. Used to initialize drive.
|
|
|
|
|
*/
|
|
|
|
|
|
1994-02-01 05:55:21 +00:00
|
|
|
#define CLOSED 0 /* disk is closed. */
|
|
|
|
|
#define WANTOPEN 1 /* open requested, not started */
|
|
|
|
|
#define RECAL 2 /* doing restore */
|
|
|
|
|
#define OPEN 3 /* done with open */
|
1993-06-12 14:58:17 +00:00
|
|
|
|
1997-03-11 23:17:28 +00:00
|
|
|
#define PRIMARY 0
|
|
|
|
|
|
1995-04-14 22:31:58 +00:00
|
|
|
/*
|
|
|
|
|
* Disk geometry. A small part of struct disklabel.
|
|
|
|
|
* XXX disklabel.5 contains an old clone of disklabel.h.
|
|
|
|
|
*/
|
|
|
|
|
struct diskgeom {
|
|
|
|
|
u_long d_secsize; /* # of bytes per sector */
|
|
|
|
|
u_long d_nsectors; /* # of data sectors per track */
|
|
|
|
|
u_long d_ntracks; /* # of tracks per cylinder */
|
|
|
|
|
u_long d_ncylinders; /* # of data cylinders per unit */
|
|
|
|
|
u_long d_secpercyl; /* # of data sectors per cylinder */
|
|
|
|
|
u_long d_secperunit; /* # of data sectors per unit */
|
|
|
|
|
u_long d_precompcyl; /* XXX always 0 */
|
|
|
|
|
};
|
|
|
|
|
|
1993-06-12 14:58:17 +00:00
|
|
|
/*
|
|
|
|
|
* The structure of a disk drive.
|
|
|
|
|
*/
|
1994-02-01 05:55:21 +00:00
|
|
|
struct disk {
|
1993-06-12 14:58:17 +00:00
|
|
|
long dk_bc; /* byte count left */
|
|
|
|
|
short dk_skip; /* blocks already transferred */
|
1995-12-11 04:58:34 +00:00
|
|
|
int dk_ctrlr; /* physical controller number */
|
1997-03-11 23:17:28 +00:00
|
|
|
#ifdef CMD640
|
|
|
|
|
int dk_ctrlr_cmd640;/* controller number for CMD640 quirk */
|
|
|
|
|
#endif
|
1995-12-11 04:58:34 +00:00
|
|
|
int dk_unit; /* physical unit number */
|
|
|
|
|
int dk_lunit; /* logical unit number */
|
1993-06-12 14:58:17 +00:00
|
|
|
char dk_state; /* control state */
|
|
|
|
|
u_char dk_status; /* copy of status reg. */
|
|
|
|
|
u_char dk_error; /* copy of error reg. */
|
1994-02-01 05:55:21 +00:00
|
|
|
u_char dk_timeout; /* countdown to next timeout */
|
1996-11-11 15:57:40 +00:00
|
|
|
int dk_port; /* i/o port base */
|
1996-01-27 04:18:15 +00:00
|
|
|
#ifdef DEVFS
|
|
|
|
|
void *dk_bdev; /* devfs token for whole disk */
|
|
|
|
|
void *dk_cdev; /* devfs token for raw whole disk */
|
|
|
|
|
#endif
|
1995-04-24 05:12:29 +00:00
|
|
|
u_long cfg_flags; /* configured characteristics */
|
1995-05-16 07:52:17 +00:00
|
|
|
short dk_flags; /* drive characteristics found */
|
1994-02-01 05:55:21 +00:00
|
|
|
#define DKFL_SINGLE 0x00004 /* sector at a time mode */
|
|
|
|
|
#define DKFL_ERROR 0x00008 /* processing a disk error */
|
|
|
|
|
#define DKFL_LABELLING 0x00080 /* readdisklabel() in progress */
|
1995-02-04 19:39:36 +00:00
|
|
|
#define DKFL_32BIT 0x00100 /* use 32-bit i/o mode */
|
1995-03-22 05:23:01 +00:00
|
|
|
#define DKFL_MULTI 0x00200 /* use multi-i/o mode */
|
1995-05-16 07:52:17 +00:00
|
|
|
#define DKFL_BADSCAN 0x00400 /* report all errors */
|
Add support for busmaster DMA on some PCI IDE chipsets.
I changed a few bits here and there, mainly renaming wd82371.c
to ide_pci.c now that it's supposed to handle different chipsets.
It runs on my P6 natoma board with two Maxtor drives, and also
on a Fujitsu machine I have at work with an Opti chipset and
a Quantum drive.
Submitted by:cgull@smoke.marlboro.vt.us <John Hood>
Original readme:
*** WARNING ***
This code has so far been tested on exactly one motherboard with two
identical drives known for their good DMA support.
This code, in the right circumstances, could corrupt data subtly,
silently, and invisibly, in much the same way that older PCI IDE
controllers do. It's ALPHA-quality code; there's one or two major
gaps in my understanding of PCI IDE still. Don't use this code on any
system with data that you care about; it's only good for hack boxes.
Expect that any data may be silently and randomly corrupted at any
moment. It's a disk driver. It has bugs. Disk drivers with bugs
munch data. It's a fact of life.
I also *STRONGLY* recommend getting a copy of your chipset's manual
and the ATA-2 or ATA-3 spec and making sure that timing modes on your
disk drives and IDE controller are being setup correctly by the BIOS--
because the driver makes only the lamest of attempts to do this just
now.
*** END WARNING ***
that said, i happen to think the code is working pretty well...
WHAT IT DOES:
this code adds support to the wd driver for bus mastering PCI IDE
controllers that follow the SFF-8038 standard. (all the bus mastering
PCI IDE controllers i've seen so far do follow this standard.) it
should provide busmastering on nearly any current P5 or P6 chipset,
specifically including any Intel chipset using one of the PIIX south
bridges-- this includes the '430FX, '430VX, '430HX, '430TX, '440LX,
and (i think) the Orion '450GX chipsets. specific support is also
included for the VIA Apollo VP-1 chipset, as it appears in the
relabeled "HXPro" incarnation seen on cheap US$70 taiwanese
motherboards (that's what's in my development machine). it works out
of the box on controllers that do DMA mode2; if my understanding is
correct, it'll probably work on Ultra-DMA33 controllers as well.
it'll probably work on busmastering IDE controllers in PCI slots, too,
but this is an area i am less sure about.
it cuts CPU usage considerably and improves drive performance
slightly. usable numbers are difficult to come by with existing
benchmark tools, but experimentation on my K5-P90 system, with VIA
VP-1 chipset and Quantum Fireball 1080 drives, shows that disk i/o on
raw partitions imposes perhaps 5% cpu load. cpu load during
filesystem i/o drops a lot, from near 100% to anywhere between 30% and
70%. (the improvement may not be as large on an Intel chipset; from
what i can tell, the VIA VP-1 may not be very efficient with PCI I/O.)
disk performance improves by 5% or 10% with these drives.
real, visible, end-user performance improvement on a single user
machine is about nil. :) a kernel compile was sped up by a whole three
seconds. it *does* feel a bit better-behaved when the system is
swapping heavily, but a better disk driver is not the fix for *that*
problem.
THE CODE:
this code is a patch to wd.c and wd82371.c, and associated header
files. it should be considered alpha code; more work needs to be
done.
wd.c has fairly clean patches to add calls to busmaster code, as
implemented in wd82371.c and potentially elsewhere (one could imagine,
say, a Mac having a different DMA controller).
wd82371.c has been considerably reworked: the wddma interface that it
presents has been changed (expect more changes), many bugs have been
fixed, a new internal interface has been added for supporting
different chipsets, and the PCI probe has been considerably extended.
the interface between wd82371.c and wd.c is still fairly clean, but
i'm not sure it's in the right place. there's a mess of issues around
ATA/ATAPI that need to be sorted out, including ATAPI support, CD-ROM
support, tape support, LS-120/Zip support, SFF-8038i DMA, UltraDMA,
PCI IDE controllers, bus probes, buggy controllers, controller timing
setup, drive timing setup, world peace and kitchen sinks. whatever
happens with all this and however it gets partitioned, it is fairly
clear that wd.c needs some significant rework-- probably a complete
rewrite.
timing setup on disk controllers is something i've entirely punted on.
on my development machine, it appears that the BIOS does at least some
of the necessary timing setup. i chose to restrict operation to
drives that are already configured for Mode4 PIO and Mode2 multiword
DMA, since the timing is essentially the same and many if not most
chipsets use the same control registers for DMA and PIO timing.
does anybody *know* whether BIOSes are required to do timing setup for
DMA modes on drives under their care?
error recovery is probably weak. early on in development, i was
getting drive errors induced by bugs in the driver; i used these to
flush out the worst of the bugs in the driver's error handling, but
problems may remain. i haven't got a drive with bad sectors i can
watch the driver flail on.
complaints about how wd82371.c has been reindented will be ignored
until the FreeBSD project has a real style policy, there is a
mechanism for individual authors to match it (indent flags or an emacs
c-mode or whatever), and it is enforced. if i'm going to use a source
style i don't like, it would help if i could figure out what it *is*
(style(9) is about half of a policy), and a way to reasonably
duplicate it. i ended up wasting a while trying to figure out what
the right thing to do was before deciding reformatting the whole thing
was the worst possible thing to do, except for all the other
possibilities.
i have maintained wd.c's indentation; that was not too hard,
fortunately.
TO INSTALL:
my dev box is freebsd 2.2.2 release. fortunately, wd.c is a living
fossil, and has diverged very little recently. included in this
tarball is a patch file, 'otherdiffs', for all files except wd82371.c,
my edited wd82371.c, a patch file, 'wd82371.c-diff-exact', against the
2.2.2 dist of 82371.c, and another patch file,
'wd82371.c-diff-whitespace', generated with diff -b (ignore
whitespace). most of you not using 2.2.2 will probably have to use
this last patchfile with 'patch --ignore-whitespace'. apply from the
kernel source tree root. as far as i can tell, this should apply
cleanly on anything from -current back to 2.2.2 and probably back to
2.2.0. you, the kernel hacker, can figure out what to do from here.
if you need more specific directions, you probably should not be
experimenting with this code yet.
to enable DMA support, set flag 0x2000 for that drive in your config
file or in userconfig, as you would the 32-bit-PIO flag. the driver
will then turn on DMA support if your drive and controller pass its
tests. it's a bit picky, probably. on discovering DMA mode failures
or disk errors or transfers that the DMA controller can't deal with,
the driver will fall back to PIO, so it is wise to setup the flags as
if PIO were still important.
'controller wdc0 at isa? port "IO_WD1" bio irq 14 flags 0xa0ffa0ff
vector wdintr' should work with nearly any PCI IDE controller.
i would *strongly* suggest booting single-user at first, and thrashing
the drive a bit while it's still mounted read-only. this should be
fairly safe, even if the driver goes completely out to lunch. it
might save you a reinstall.
one way to tell whether the driver is really using DMA is to check the
interrupt count during disk i/o with vmstat; DMA mode will add an
extremely low number of interrupts, as compared to even multi-sector
PIO.
boot -v will give you a copious register dump of timing-related info
on Intel and VIAtech chipsets, as well as PIO/DMA mode information on
all hard drives. refer to your ATA and chipset documentation to
interpret these.
WHAT I'D LIKE FROM YOU and THINGS TO TEST:
reports. success reports, failure reports, any kind of reports. :)
send them to cgull+ide@smoke.marlboro.vt.us.
i'd also like to see the kernel messages from various BIOSes (boot -v;
dmesg), along with info on the motherboard and BIOS on that machine.
i'm especially interested in reports on how this code works on the
various Intel chipsets, and whether the register dump works
correctly. i'm also interested in hearing about other chipsets.
i'm especially interested in hearing success/failure reports for PCI
IDE controllers on cards, such as CMD's or Promise's new busmastering
IDE controllers.
UltraDMA-33 reports.
interoperation with ATAPI peripherals-- FreeBSD doesn't work with my
old Hitachi IDE CDROM, so i can't tell if I've broken anything. :)
i'd especially like to hear how the drive copes in DMA operation on
drives with bad sectors. i haven't been able to find any such yet.
success/failure reports on older IDE drives with early support for DMA
modes-- those introduced between 1.5 and 3 years ago, typically
ranging from perhaps 400MB to 1.6GB.
failure reports on operation with more than one drive would be
appreciated. the driver was developed with two drives on one
controller, the worst-case situation, and has been tested with one
drive on each controller, but you never know...
any reports of messages from the driver during normal operation,
especially "reverting to PIO mode", or "dmaverify odd vaddr or length"
(the DMA controller is strongly halfword oriented, and i'm curious to
know if any FreeBSD usage actually needs misaligned transfers).
performance reports. beware that bonnie's CPU usage reporting is
useless for IDE drives; the best test i've found has been to run a
program that runs a spin loop at an idle priority and reports how many
iterations it manages, and even that sometimes produces numbers i
don't believe. performance reports of multi-drive operation are
especially interesting; my system cannot sustain full throughput on
two drives on separate controllers, but that may just be a lame
motherboard.
THINGS I'M STILL MISSING CLUE ON:
* who's responsible for configuring DMA timing modes on IDE drives?
the BIOS or the driver?
* is there a spec for dealing with Ultra-DMA extensions?
* are there any chipsets or with bugs relating to DMA transfer that
should be blacklisted?
* are there any ATA interfaces that use some other kind of DMA
controller in conjunction with standard ATA protocol?
FINAL NOTE:
after having looked at the ATA-3 spec, all i can say is, "it's ugly".
*especially* electrically. the IDE bus is best modeled as an
unterminated transmission line, these days.
for maximum reliability, keep your IDE cables as short as possible and
as few as possible. from what i can tell, most current chipsets have
both IDE ports wired into a single buss, to a greater or lesser
degree. using two cables means you double the length of this bus.
SCSI may have its warts, but at least the basic analog design of the
bus is still somewhat reasonable. IDE passed beyond the veil two
years ago.
--John Hood, cgull@smoke.marlboro.vt.us
1997-07-29 12:57:25 +00:00
|
|
|
#define DKFL_USEDMA 0x00800 /* use DMA for data transfers */
|
|
|
|
|
#define DKFL_DMA 0x01000 /* using DMA on this transfer-- DKFL_SINGLE
|
|
|
|
|
* overrides this
|
|
|
|
|
*/
|
1993-06-12 14:58:17 +00:00
|
|
|
struct wdparams dk_params; /* ESDI/IDE drive/controller parameters */
|
1995-04-14 22:31:58 +00:00
|
|
|
int dk_dkunit; /* disk stats unit number */
|
1995-03-22 05:23:01 +00:00
|
|
|
int dk_multi; /* multi transfers */
|
|
|
|
|
int dk_currentiosize; /* current io size */
|
1995-04-14 22:31:58 +00:00
|
|
|
struct diskgeom dk_dd; /* device configuration data */
|
|
|
|
|
struct diskslices *dk_slices; /* virtual drives */
|
Add support for busmaster DMA on some PCI IDE chipsets.
I changed a few bits here and there, mainly renaming wd82371.c
to ide_pci.c now that it's supposed to handle different chipsets.
It runs on my P6 natoma board with two Maxtor drives, and also
on a Fujitsu machine I have at work with an Opti chipset and
a Quantum drive.
Submitted by:cgull@smoke.marlboro.vt.us <John Hood>
Original readme:
*** WARNING ***
This code has so far been tested on exactly one motherboard with two
identical drives known for their good DMA support.
This code, in the right circumstances, could corrupt data subtly,
silently, and invisibly, in much the same way that older PCI IDE
controllers do. It's ALPHA-quality code; there's one or two major
gaps in my understanding of PCI IDE still. Don't use this code on any
system with data that you care about; it's only good for hack boxes.
Expect that any data may be silently and randomly corrupted at any
moment. It's a disk driver. It has bugs. Disk drivers with bugs
munch data. It's a fact of life.
I also *STRONGLY* recommend getting a copy of your chipset's manual
and the ATA-2 or ATA-3 spec and making sure that timing modes on your
disk drives and IDE controller are being setup correctly by the BIOS--
because the driver makes only the lamest of attempts to do this just
now.
*** END WARNING ***
that said, i happen to think the code is working pretty well...
WHAT IT DOES:
this code adds support to the wd driver for bus mastering PCI IDE
controllers that follow the SFF-8038 standard. (all the bus mastering
PCI IDE controllers i've seen so far do follow this standard.) it
should provide busmastering on nearly any current P5 or P6 chipset,
specifically including any Intel chipset using one of the PIIX south
bridges-- this includes the '430FX, '430VX, '430HX, '430TX, '440LX,
and (i think) the Orion '450GX chipsets. specific support is also
included for the VIA Apollo VP-1 chipset, as it appears in the
relabeled "HXPro" incarnation seen on cheap US$70 taiwanese
motherboards (that's what's in my development machine). it works out
of the box on controllers that do DMA mode2; if my understanding is
correct, it'll probably work on Ultra-DMA33 controllers as well.
it'll probably work on busmastering IDE controllers in PCI slots, too,
but this is an area i am less sure about.
it cuts CPU usage considerably and improves drive performance
slightly. usable numbers are difficult to come by with existing
benchmark tools, but experimentation on my K5-P90 system, with VIA
VP-1 chipset and Quantum Fireball 1080 drives, shows that disk i/o on
raw partitions imposes perhaps 5% cpu load. cpu load during
filesystem i/o drops a lot, from near 100% to anywhere between 30% and
70%. (the improvement may not be as large on an Intel chipset; from
what i can tell, the VIA VP-1 may not be very efficient with PCI I/O.)
disk performance improves by 5% or 10% with these drives.
real, visible, end-user performance improvement on a single user
machine is about nil. :) a kernel compile was sped up by a whole three
seconds. it *does* feel a bit better-behaved when the system is
swapping heavily, but a better disk driver is not the fix for *that*
problem.
THE CODE:
this code is a patch to wd.c and wd82371.c, and associated header
files. it should be considered alpha code; more work needs to be
done.
wd.c has fairly clean patches to add calls to busmaster code, as
implemented in wd82371.c and potentially elsewhere (one could imagine,
say, a Mac having a different DMA controller).
wd82371.c has been considerably reworked: the wddma interface that it
presents has been changed (expect more changes), many bugs have been
fixed, a new internal interface has been added for supporting
different chipsets, and the PCI probe has been considerably extended.
the interface between wd82371.c and wd.c is still fairly clean, but
i'm not sure it's in the right place. there's a mess of issues around
ATA/ATAPI that need to be sorted out, including ATAPI support, CD-ROM
support, tape support, LS-120/Zip support, SFF-8038i DMA, UltraDMA,
PCI IDE controllers, bus probes, buggy controllers, controller timing
setup, drive timing setup, world peace and kitchen sinks. whatever
happens with all this and however it gets partitioned, it is fairly
clear that wd.c needs some significant rework-- probably a complete
rewrite.
timing setup on disk controllers is something i've entirely punted on.
on my development machine, it appears that the BIOS does at least some
of the necessary timing setup. i chose to restrict operation to
drives that are already configured for Mode4 PIO and Mode2 multiword
DMA, since the timing is essentially the same and many if not most
chipsets use the same control registers for DMA and PIO timing.
does anybody *know* whether BIOSes are required to do timing setup for
DMA modes on drives under their care?
error recovery is probably weak. early on in development, i was
getting drive errors induced by bugs in the driver; i used these to
flush out the worst of the bugs in the driver's error handling, but
problems may remain. i haven't got a drive with bad sectors i can
watch the driver flail on.
complaints about how wd82371.c has been reindented will be ignored
until the FreeBSD project has a real style policy, there is a
mechanism for individual authors to match it (indent flags or an emacs
c-mode or whatever), and it is enforced. if i'm going to use a source
style i don't like, it would help if i could figure out what it *is*
(style(9) is about half of a policy), and a way to reasonably
duplicate it. i ended up wasting a while trying to figure out what
the right thing to do was before deciding reformatting the whole thing
was the worst possible thing to do, except for all the other
possibilities.
i have maintained wd.c's indentation; that was not too hard,
fortunately.
TO INSTALL:
my dev box is freebsd 2.2.2 release. fortunately, wd.c is a living
fossil, and has diverged very little recently. included in this
tarball is a patch file, 'otherdiffs', for all files except wd82371.c,
my edited wd82371.c, a patch file, 'wd82371.c-diff-exact', against the
2.2.2 dist of 82371.c, and another patch file,
'wd82371.c-diff-whitespace', generated with diff -b (ignore
whitespace). most of you not using 2.2.2 will probably have to use
this last patchfile with 'patch --ignore-whitespace'. apply from the
kernel source tree root. as far as i can tell, this should apply
cleanly on anything from -current back to 2.2.2 and probably back to
2.2.0. you, the kernel hacker, can figure out what to do from here.
if you need more specific directions, you probably should not be
experimenting with this code yet.
to enable DMA support, set flag 0x2000 for that drive in your config
file or in userconfig, as you would the 32-bit-PIO flag. the driver
will then turn on DMA support if your drive and controller pass its
tests. it's a bit picky, probably. on discovering DMA mode failures
or disk errors or transfers that the DMA controller can't deal with,
the driver will fall back to PIO, so it is wise to setup the flags as
if PIO were still important.
'controller wdc0 at isa? port "IO_WD1" bio irq 14 flags 0xa0ffa0ff
vector wdintr' should work with nearly any PCI IDE controller.
i would *strongly* suggest booting single-user at first, and thrashing
the drive a bit while it's still mounted read-only. this should be
fairly safe, even if the driver goes completely out to lunch. it
might save you a reinstall.
one way to tell whether the driver is really using DMA is to check the
interrupt count during disk i/o with vmstat; DMA mode will add an
extremely low number of interrupts, as compared to even multi-sector
PIO.
boot -v will give you a copious register dump of timing-related info
on Intel and VIAtech chipsets, as well as PIO/DMA mode information on
all hard drives. refer to your ATA and chipset documentation to
interpret these.
WHAT I'D LIKE FROM YOU and THINGS TO TEST:
reports. success reports, failure reports, any kind of reports. :)
send them to cgull+ide@smoke.marlboro.vt.us.
i'd also like to see the kernel messages from various BIOSes (boot -v;
dmesg), along with info on the motherboard and BIOS on that machine.
i'm especially interested in reports on how this code works on the
various Intel chipsets, and whether the register dump works
correctly. i'm also interested in hearing about other chipsets.
i'm especially interested in hearing success/failure reports for PCI
IDE controllers on cards, such as CMD's or Promise's new busmastering
IDE controllers.
UltraDMA-33 reports.
interoperation with ATAPI peripherals-- FreeBSD doesn't work with my
old Hitachi IDE CDROM, so i can't tell if I've broken anything. :)
i'd especially like to hear how the drive copes in DMA operation on
drives with bad sectors. i haven't been able to find any such yet.
success/failure reports on older IDE drives with early support for DMA
modes-- those introduced between 1.5 and 3 years ago, typically
ranging from perhaps 400MB to 1.6GB.
failure reports on operation with more than one drive would be
appreciated. the driver was developed with two drives on one
controller, the worst-case situation, and has been tested with one
drive on each controller, but you never know...
any reports of messages from the driver during normal operation,
especially "reverting to PIO mode", or "dmaverify odd vaddr or length"
(the DMA controller is strongly halfword oriented, and i'm curious to
know if any FreeBSD usage actually needs misaligned transfers).
performance reports. beware that bonnie's CPU usage reporting is
useless for IDE drives; the best test i've found has been to run a
program that runs a spin loop at an idle priority and reports how many
iterations it manages, and even that sometimes produces numbers i
don't believe. performance reports of multi-drive operation are
especially interesting; my system cannot sustain full throughput on
two drives on separate controllers, but that may just be a lame
motherboard.
THINGS I'M STILL MISSING CLUE ON:
* who's responsible for configuring DMA timing modes on IDE drives?
the BIOS or the driver?
* is there a spec for dealing with Ultra-DMA extensions?
* are there any chipsets or with bugs relating to DMA transfer that
should be blacklisted?
* are there any ATA interfaces that use some other kind of DMA
controller in conjunction with standard ATA protocol?
FINAL NOTE:
after having looked at the ATA-3 spec, all i can say is, "it's ugly".
*especially* electrically. the IDE bus is best modeled as an
unterminated transmission line, these days.
for maximum reliability, keep your IDE cables as short as possible and
as few as possible. from what i can tell, most current chipsets have
both IDE ports wired into a single buss, to a greater or lesser
degree. using two cables means you double the length of this bus.
SCSI may have its warts, but at least the basic analog design of the
bus is still somewhat reasonable. IDE passed beyond the veil two
years ago.
--John Hood, cgull@smoke.marlboro.vt.us
1997-07-29 12:57:25 +00:00
|
|
|
void *dk_dmacookie; /* handle for DMA services */
|
1993-06-12 14:58:17 +00:00
|
|
|
};
|
|
|
|
|
|
1995-03-22 05:23:01 +00:00
|
|
|
#define WD_COUNT_RETRIES
|
|
|
|
|
static int wdtest = 0;
|
|
|
|
|
|
1994-02-01 05:55:21 +00:00
|
|
|
static struct disk *wddrives[NWD]; /* table of units */
|
1995-11-23 07:24:41 +00:00
|
|
|
static struct buf_queue_head drive_queue[NWD]; /* head of queue per drive */
|
|
|
|
|
static struct {
|
|
|
|
|
int b_errcnt;
|
|
|
|
|
int b_active;
|
|
|
|
|
} wdutab[NWD];
|
|
|
|
|
/*
|
1994-02-01 05:55:21 +00:00
|
|
|
static struct buf wdtab[NWDC];
|
1995-11-23 07:24:41 +00:00
|
|
|
*/
|
|
|
|
|
static struct {
|
|
|
|
|
struct buf_queue_head controller_queue;
|
|
|
|
|
int b_errcnt;
|
|
|
|
|
int b_active;
|
|
|
|
|
} wdtab[NWDC];
|
|
|
|
|
|
1996-01-28 22:16:20 +00:00
|
|
|
struct wddma wddma;
|
|
|
|
|
|
1994-01-04 20:05:26 +00:00
|
|
|
#ifdef notyet
|
1994-02-01 05:55:21 +00:00
|
|
|
static struct buf rwdbuf[NWD]; /* buffers for raw IO */
|
1993-06-12 14:58:17 +00:00
|
|
|
#endif
|
1994-02-01 05:55:21 +00:00
|
|
|
|
|
|
|
|
static int wdprobe(struct isa_device *dvp);
|
|
|
|
|
static int wdattach(struct isa_device *dvp);
|
|
|
|
|
static void wdustart(struct disk *du);
|
|
|
|
|
static int wdcontrol(struct buf *bp);
|
|
|
|
|
static int wdcommand(struct disk *du, u_int cylinder, u_int head,
|
|
|
|
|
u_int sector, u_int count, u_int command);
|
|
|
|
|
static int wdsetctlr(struct disk *du);
|
1996-06-12 05:11:41 +00:00
|
|
|
#if 0
|
1994-02-01 05:55:21 +00:00
|
|
|
static int wdwsetctlr(struct disk *du);
|
1996-06-12 05:11:41 +00:00
|
|
|
#endif
|
Add support for busmaster DMA on some PCI IDE chipsets.
I changed a few bits here and there, mainly renaming wd82371.c
to ide_pci.c now that it's supposed to handle different chipsets.
It runs on my P6 natoma board with two Maxtor drives, and also
on a Fujitsu machine I have at work with an Opti chipset and
a Quantum drive.
Submitted by:cgull@smoke.marlboro.vt.us <John Hood>
Original readme:
*** WARNING ***
This code has so far been tested on exactly one motherboard with two
identical drives known for their good DMA support.
This code, in the right circumstances, could corrupt data subtly,
silently, and invisibly, in much the same way that older PCI IDE
controllers do. It's ALPHA-quality code; there's one or two major
gaps in my understanding of PCI IDE still. Don't use this code on any
system with data that you care about; it's only good for hack boxes.
Expect that any data may be silently and randomly corrupted at any
moment. It's a disk driver. It has bugs. Disk drivers with bugs
munch data. It's a fact of life.
I also *STRONGLY* recommend getting a copy of your chipset's manual
and the ATA-2 or ATA-3 spec and making sure that timing modes on your
disk drives and IDE controller are being setup correctly by the BIOS--
because the driver makes only the lamest of attempts to do this just
now.
*** END WARNING ***
that said, i happen to think the code is working pretty well...
WHAT IT DOES:
this code adds support to the wd driver for bus mastering PCI IDE
controllers that follow the SFF-8038 standard. (all the bus mastering
PCI IDE controllers i've seen so far do follow this standard.) it
should provide busmastering on nearly any current P5 or P6 chipset,
specifically including any Intel chipset using one of the PIIX south
bridges-- this includes the '430FX, '430VX, '430HX, '430TX, '440LX,
and (i think) the Orion '450GX chipsets. specific support is also
included for the VIA Apollo VP-1 chipset, as it appears in the
relabeled "HXPro" incarnation seen on cheap US$70 taiwanese
motherboards (that's what's in my development machine). it works out
of the box on controllers that do DMA mode2; if my understanding is
correct, it'll probably work on Ultra-DMA33 controllers as well.
it'll probably work on busmastering IDE controllers in PCI slots, too,
but this is an area i am less sure about.
it cuts CPU usage considerably and improves drive performance
slightly. usable numbers are difficult to come by with existing
benchmark tools, but experimentation on my K5-P90 system, with VIA
VP-1 chipset and Quantum Fireball 1080 drives, shows that disk i/o on
raw partitions imposes perhaps 5% cpu load. cpu load during
filesystem i/o drops a lot, from near 100% to anywhere between 30% and
70%. (the improvement may not be as large on an Intel chipset; from
what i can tell, the VIA VP-1 may not be very efficient with PCI I/O.)
disk performance improves by 5% or 10% with these drives.
real, visible, end-user performance improvement on a single user
machine is about nil. :) a kernel compile was sped up by a whole three
seconds. it *does* feel a bit better-behaved when the system is
swapping heavily, but a better disk driver is not the fix for *that*
problem.
THE CODE:
this code is a patch to wd.c and wd82371.c, and associated header
files. it should be considered alpha code; more work needs to be
done.
wd.c has fairly clean patches to add calls to busmaster code, as
implemented in wd82371.c and potentially elsewhere (one could imagine,
say, a Mac having a different DMA controller).
wd82371.c has been considerably reworked: the wddma interface that it
presents has been changed (expect more changes), many bugs have been
fixed, a new internal interface has been added for supporting
different chipsets, and the PCI probe has been considerably extended.
the interface between wd82371.c and wd.c is still fairly clean, but
i'm not sure it's in the right place. there's a mess of issues around
ATA/ATAPI that need to be sorted out, including ATAPI support, CD-ROM
support, tape support, LS-120/Zip support, SFF-8038i DMA, UltraDMA,
PCI IDE controllers, bus probes, buggy controllers, controller timing
setup, drive timing setup, world peace and kitchen sinks. whatever
happens with all this and however it gets partitioned, it is fairly
clear that wd.c needs some significant rework-- probably a complete
rewrite.
timing setup on disk controllers is something i've entirely punted on.
on my development machine, it appears that the BIOS does at least some
of the necessary timing setup. i chose to restrict operation to
drives that are already configured for Mode4 PIO and Mode2 multiword
DMA, since the timing is essentially the same and many if not most
chipsets use the same control registers for DMA and PIO timing.
does anybody *know* whether BIOSes are required to do timing setup for
DMA modes on drives under their care?
error recovery is probably weak. early on in development, i was
getting drive errors induced by bugs in the driver; i used these to
flush out the worst of the bugs in the driver's error handling, but
problems may remain. i haven't got a drive with bad sectors i can
watch the driver flail on.
complaints about how wd82371.c has been reindented will be ignored
until the FreeBSD project has a real style policy, there is a
mechanism for individual authors to match it (indent flags or an emacs
c-mode or whatever), and it is enforced. if i'm going to use a source
style i don't like, it would help if i could figure out what it *is*
(style(9) is about half of a policy), and a way to reasonably
duplicate it. i ended up wasting a while trying to figure out what
the right thing to do was before deciding reformatting the whole thing
was the worst possible thing to do, except for all the other
possibilities.
i have maintained wd.c's indentation; that was not too hard,
fortunately.
TO INSTALL:
my dev box is freebsd 2.2.2 release. fortunately, wd.c is a living
fossil, and has diverged very little recently. included in this
tarball is a patch file, 'otherdiffs', for all files except wd82371.c,
my edited wd82371.c, a patch file, 'wd82371.c-diff-exact', against the
2.2.2 dist of 82371.c, and another patch file,
'wd82371.c-diff-whitespace', generated with diff -b (ignore
whitespace). most of you not using 2.2.2 will probably have to use
this last patchfile with 'patch --ignore-whitespace'. apply from the
kernel source tree root. as far as i can tell, this should apply
cleanly on anything from -current back to 2.2.2 and probably back to
2.2.0. you, the kernel hacker, can figure out what to do from here.
if you need more specific directions, you probably should not be
experimenting with this code yet.
to enable DMA support, set flag 0x2000 for that drive in your config
file or in userconfig, as you would the 32-bit-PIO flag. the driver
will then turn on DMA support if your drive and controller pass its
tests. it's a bit picky, probably. on discovering DMA mode failures
or disk errors or transfers that the DMA controller can't deal with,
the driver will fall back to PIO, so it is wise to setup the flags as
if PIO were still important.
'controller wdc0 at isa? port "IO_WD1" bio irq 14 flags 0xa0ffa0ff
vector wdintr' should work with nearly any PCI IDE controller.
i would *strongly* suggest booting single-user at first, and thrashing
the drive a bit while it's still mounted read-only. this should be
fairly safe, even if the driver goes completely out to lunch. it
might save you a reinstall.
one way to tell whether the driver is really using DMA is to check the
interrupt count during disk i/o with vmstat; DMA mode will add an
extremely low number of interrupts, as compared to even multi-sector
PIO.
boot -v will give you a copious register dump of timing-related info
on Intel and VIAtech chipsets, as well as PIO/DMA mode information on
all hard drives. refer to your ATA and chipset documentation to
interpret these.
WHAT I'D LIKE FROM YOU and THINGS TO TEST:
reports. success reports, failure reports, any kind of reports. :)
send them to cgull+ide@smoke.marlboro.vt.us.
i'd also like to see the kernel messages from various BIOSes (boot -v;
dmesg), along with info on the motherboard and BIOS on that machine.
i'm especially interested in reports on how this code works on the
various Intel chipsets, and whether the register dump works
correctly. i'm also interested in hearing about other chipsets.
i'm especially interested in hearing success/failure reports for PCI
IDE controllers on cards, such as CMD's or Promise's new busmastering
IDE controllers.
UltraDMA-33 reports.
interoperation with ATAPI peripherals-- FreeBSD doesn't work with my
old Hitachi IDE CDROM, so i can't tell if I've broken anything. :)
i'd especially like to hear how the drive copes in DMA operation on
drives with bad sectors. i haven't been able to find any such yet.
success/failure reports on older IDE drives with early support for DMA
modes-- those introduced between 1.5 and 3 years ago, typically
ranging from perhaps 400MB to 1.6GB.
failure reports on operation with more than one drive would be
appreciated. the driver was developed with two drives on one
controller, the worst-case situation, and has been tested with one
drive on each controller, but you never know...
any reports of messages from the driver during normal operation,
especially "reverting to PIO mode", or "dmaverify odd vaddr or length"
(the DMA controller is strongly halfword oriented, and i'm curious to
know if any FreeBSD usage actually needs misaligned transfers).
performance reports. beware that bonnie's CPU usage reporting is
useless for IDE drives; the best test i've found has been to run a
program that runs a spin loop at an idle priority and reports how many
iterations it manages, and even that sometimes produces numbers i
don't believe. performance reports of multi-drive operation are
especially interesting; my system cannot sustain full throughput on
two drives on separate controllers, but that may just be a lame
motherboard.
THINGS I'M STILL MISSING CLUE ON:
* who's responsible for configuring DMA timing modes on IDE drives?
the BIOS or the driver?
* is there a spec for dealing with Ultra-DMA extensions?
* are there any chipsets or with bugs relating to DMA transfer that
should be blacklisted?
* are there any ATA interfaces that use some other kind of DMA
controller in conjunction with standard ATA protocol?
FINAL NOTE:
after having looked at the ATA-3 spec, all i can say is, "it's ugly".
*especially* electrically. the IDE bus is best modeled as an
unterminated transmission line, these days.
for maximum reliability, keep your IDE cables as short as possible and
as few as possible. from what i can tell, most current chipsets have
both IDE ports wired into a single buss, to a greater or lesser
degree. using two cables means you double the length of this bus.
SCSI may have its warts, but at least the basic analog design of the
bus is still somewhat reasonable. IDE passed beyond the veil two
years ago.
--John Hood, cgull@smoke.marlboro.vt.us
1997-07-29 12:57:25 +00:00
|
|
|
static int wdsetmode(int mode, void *wdinfo);
|
1995-04-24 05:12:29 +00:00
|
|
|
static int wdgetctlr(struct disk *du);
|
1994-02-01 05:55:21 +00:00
|
|
|
static void wderror(struct buf *bp, struct disk *du, char *mesg);
|
|
|
|
|
static void wdflushirq(struct disk *du, int old_ipl);
|
|
|
|
|
static int wdreset(struct disk *du);
|
|
|
|
|
static void wdsleep(int ctrlr, char *wmesg);
|
1995-04-14 22:31:58 +00:00
|
|
|
static void wdstrategy1(struct buf *bp);
|
1994-08-23 07:52:29 +00:00
|
|
|
static timeout_t wdtimeout;
|
1994-02-01 05:55:21 +00:00
|
|
|
static int wdunwedge(struct disk *du);
|
1994-02-11 12:02:35 +00:00
|
|
|
static int wdwait(struct disk *du, u_char bits_wanted, int timeout);
|
1994-02-01 05:55:21 +00:00
|
|
|
|
|
|
|
|
struct isa_driver wdcdriver = {
|
1994-01-04 20:05:26 +00:00
|
|
|
wdprobe, wdattach, "wdc",
|
1993-06-12 14:58:17 +00:00
|
|
|
};
|
|
|
|
|
|
1995-12-08 11:19:42 +00:00
|
|
|
static d_open_t wdopen;
|
|
|
|
|
static d_close_t wdclose;
|
1995-12-10 15:55:34 +00:00
|
|
|
static d_strategy_t wdstrategy;
|
1995-12-08 11:19:42 +00:00
|
|
|
static d_ioctl_t wdioctl;
|
|
|
|
|
static d_dump_t wddump;
|
1995-12-10 15:55:34 +00:00
|
|
|
static d_psize_t wdsize;
|
1995-12-08 11:19:42 +00:00
|
|
|
|
|
|
|
|
#define CDEV_MAJOR 3
|
|
|
|
|
#define BDEV_MAJOR 0
|
1996-07-23 21:52:43 +00:00
|
|
|
static struct cdevsw wd_cdevsw;
|
1995-12-08 23:23:00 +00:00
|
|
|
static struct bdevsw wd_bdevsw =
|
1995-12-08 11:19:42 +00:00
|
|
|
{ wdopen, wdclose, wdstrategy, wdioctl, /*0*/
|
1997-02-10 02:22:35 +00:00
|
|
|
wddump, wdsize, D_DISK, "wd", &wd_cdevsw, -1 };
|
1995-12-08 11:19:42 +00:00
|
|
|
|
1997-03-11 23:17:28 +00:00
|
|
|
#ifdef CMD640
|
|
|
|
|
static int atapictrlr;
|
|
|
|
|
static int eide_quirks;
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Here we use the pci-subsystem to find out, whether there is
|
|
|
|
|
* a cmd640b-chip attached on this pci-bus. This public routine
|
|
|
|
|
* will be called by wdc_p.c .
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#ifdef CMD640
|
|
|
|
|
void
|
|
|
|
|
wdc_pci(int quirks)
|
|
|
|
|
{
|
|
|
|
|
eide_quirks = quirks;
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
|
1993-06-12 14:58:17 +00:00
|
|
|
/*
|
|
|
|
|
* Probe for controller.
|
|
|
|
|
*/
|
1994-01-04 20:05:26 +00:00
|
|
|
static int
|
1993-06-12 14:58:17 +00:00
|
|
|
wdprobe(struct isa_device *dvp)
|
|
|
|
|
{
|
1994-02-01 05:55:21 +00:00
|
|
|
int unit = dvp->id_unit;
|
1993-06-12 14:58:17 +00:00
|
|
|
struct disk *du;
|
|
|
|
|
|
1994-02-01 05:55:21 +00:00
|
|
|
if (unit >= NWDC)
|
|
|
|
|
return (0);
|
1994-10-19 00:08:07 +00:00
|
|
|
|
1994-02-01 05:55:21 +00:00
|
|
|
du = malloc(sizeof *du, M_TEMP, M_NOWAIT);
|
|
|
|
|
if (du == NULL)
|
|
|
|
|
return (0);
|
|
|
|
|
bzero(du, sizeof *du);
|
1994-01-04 20:05:26 +00:00
|
|
|
du->dk_ctrlr = dvp->id_unit;
|
1994-02-01 05:55:21 +00:00
|
|
|
du->dk_port = dvp->id_iobase;
|
1994-01-04 20:05:26 +00:00
|
|
|
|
1995-04-12 20:48:13 +00:00
|
|
|
|
1993-06-12 14:58:17 +00:00
|
|
|
/* check if we have registers that work */
|
1995-09-30 00:11:19 +00:00
|
|
|
outb(du->dk_port + wd_sdh, WDSD_IBM); /* set unit 0 */
|
1994-02-01 05:55:21 +00:00
|
|
|
outb(du->dk_port + wd_cyl_lo, 0xa5); /* wd_cyl_lo is read/write */
|
Latest fixes from Serge:
I tried to solve the problem of IDE probing compatibility in this version.
When compiled without an ATAPI option, the wd driver is
fully backward compatible with 2.0.5. With ATAPI option,
the wdprobe becomes strictly weaker. That is, if wdprobe works
without ATAPI option, it will always work with it too.
Another problem was with the CD-ROM drive attached as a slave
in the IDE bus, where there is no master. All IDE CD-ROM
drives are shipped in slave configuration, and most users
just plug them in, never thinking about jumpers.
It works fine with ms-dos and ms-windows, and this
version of the driver supports it as well.
The eject op can now load disks. Just repeat it twice,
and the disk will be ejected and then loaded back.
The disc cannot be ejected if it is mounted.
Submitted by: Serge Vakulenko, <vak@cronyx.ru>
1995-10-14 15:41:10 +00:00
|
|
|
if (inb(du->dk_port + wd_cyl_lo) == 0xff) { /* XXX too weak */
|
|
|
|
|
#ifdef ATAPI
|
|
|
|
|
/* There is no master, try the ATAPI slave. */
|
|
|
|
|
outb(du->dk_port + wd_sdh, WDSD_IBM | 0x10);
|
|
|
|
|
outb(du->dk_port + wd_cyl_lo, 0xa5);
|
|
|
|
|
if (inb(du->dk_port + wd_cyl_lo) == 0xff)
|
|
|
|
|
#endif
|
|
|
|
|
goto nodevice;
|
|
|
|
|
}
|
1993-06-12 14:58:17 +00:00
|
|
|
|
Latest fixes from Serge:
I tried to solve the problem of IDE probing compatibility in this version.
When compiled without an ATAPI option, the wd driver is
fully backward compatible with 2.0.5. With ATAPI option,
the wdprobe becomes strictly weaker. That is, if wdprobe works
without ATAPI option, it will always work with it too.
Another problem was with the CD-ROM drive attached as a slave
in the IDE bus, where there is no master. All IDE CD-ROM
drives are shipped in slave configuration, and most users
just plug them in, never thinking about jumpers.
It works fine with ms-dos and ms-windows, and this
version of the driver supports it as well.
The eject op can now load disks. Just repeat it twice,
and the disk will be ejected and then loaded back.
The disc cannot be ejected if it is mounted.
Submitted by: Serge Vakulenko, <vak@cronyx.ru>
1995-10-14 15:41:10 +00:00
|
|
|
if (wdreset(du) == 0)
|
|
|
|
|
goto reset_ok;
|
|
|
|
|
#ifdef ATAPI
|
|
|
|
|
/* test for ATAPI signature */
|
|
|
|
|
outb(du->dk_port + wd_sdh, WDSD_IBM); /* master */
|
|
|
|
|
if (inb(du->dk_port + wd_cyl_lo) == 0x14 &&
|
|
|
|
|
inb(du->dk_port + wd_cyl_hi) == 0xeb)
|
|
|
|
|
goto reset_ok;
|
|
|
|
|
du->dk_unit = 1;
|
|
|
|
|
outb(du->dk_port + wd_sdh, WDSD_IBM | 0x10); /* slave */
|
|
|
|
|
if (inb(du->dk_port + wd_cyl_lo) == 0x14 &&
|
|
|
|
|
inb(du->dk_port + wd_cyl_hi) == 0xeb)
|
|
|
|
|
goto reset_ok;
|
|
|
|
|
#endif
|
|
|
|
|
DELAY(RECOVERYTIME);
|
|
|
|
|
if (wdreset(du) != 0)
|
1994-01-04 20:05:26 +00:00
|
|
|
goto nodevice;
|
Latest fixes from Serge:
I tried to solve the problem of IDE probing compatibility in this version.
When compiled without an ATAPI option, the wd driver is
fully backward compatible with 2.0.5. With ATAPI option,
the wdprobe becomes strictly weaker. That is, if wdprobe works
without ATAPI option, it will always work with it too.
Another problem was with the CD-ROM drive attached as a slave
in the IDE bus, where there is no master. All IDE CD-ROM
drives are shipped in slave configuration, and most users
just plug them in, never thinking about jumpers.
It works fine with ms-dos and ms-windows, and this
version of the driver supports it as well.
The eject op can now load disks. Just repeat it twice,
and the disk will be ejected and then loaded back.
The disc cannot be ejected if it is mounted.
Submitted by: Serge Vakulenko, <vak@cronyx.ru>
1995-10-14 15:41:10 +00:00
|
|
|
reset_ok:
|
1993-06-12 14:58:17 +00:00
|
|
|
|
|
|
|
|
/* execute a controller only command */
|
1994-01-04 20:05:26 +00:00
|
|
|
if (wdcommand(du, 0, 0, 0, 0, WDCC_DIAGNOSE) != 0
|
1994-04-10 11:17:13 +00:00
|
|
|
|| wdwait(du, 0, TIMEOUT) < 0)
|
1993-06-12 14:58:17 +00:00
|
|
|
goto nodevice;
|
|
|
|
|
|
1994-04-10 11:17:13 +00:00
|
|
|
/*
|
|
|
|
|
* drive(s) did not time out during diagnostic :
|
|
|
|
|
* Get error status and check that both drives are OK.
|
1995-04-24 05:09:53 +00:00
|
|
|
* Table 9-2 of ATA specs suggests that we must check for
|
|
|
|
|
* a value of 0x01
|
1994-04-10 11:17:13 +00:00
|
|
|
*
|
|
|
|
|
* Strangely, some controllers will return a status of
|
|
|
|
|
* 0x81 (drive 0 OK, drive 1 failure), and then when
|
|
|
|
|
* the DRV bit is set, return status of 0x01 (OK) for
|
|
|
|
|
* drive 2. (This seems to contradict the ATA spec.)
|
|
|
|
|
*/
|
|
|
|
|
du->dk_error = inb(du->dk_port + wd_error);
|
|
|
|
|
/* printf("Error : %x\n", du->dk_error); */
|
|
|
|
|
if(du->dk_error != 0x01) {
|
1995-04-24 05:09:53 +00:00
|
|
|
if(du->dk_error & 0x80) { /* drive 1 failure */
|
1994-04-10 11:17:13 +00:00
|
|
|
|
|
|
|
|
/* first set the DRV bit */
|
|
|
|
|
u_int sdh;
|
|
|
|
|
sdh = inb(du->dk_port+ wd_sdh);
|
|
|
|
|
sdh = sdh | 0x10;
|
|
|
|
|
outb(du->dk_port+ wd_sdh, sdh);
|
|
|
|
|
|
|
|
|
|
/* Wait, to make sure drv 1 has completed diags */
|
|
|
|
|
if ( wdwait(du, 0, TIMEOUT) < 0)
|
|
|
|
|
goto nodevice;
|
|
|
|
|
|
|
|
|
|
/* Get status for drive 1 */
|
1995-04-24 05:09:53 +00:00
|
|
|
du->dk_error = inb(du->dk_port + wd_error);
|
1994-04-10 11:17:13 +00:00
|
|
|
/* printf("Error (drv 1) : %x\n", du->dk_error); */
|
1996-08-12 00:53:02 +00:00
|
|
|
/*
|
|
|
|
|
* Sometimes (apparently mostly with ATAPI
|
|
|
|
|
* drives involved) 0x81 really means 0x81
|
|
|
|
|
* (drive 0 OK, drive 1 failed).
|
|
|
|
|
*/
|
|
|
|
|
if(du->dk_error != 0x01 && du->dk_error != 0x81)
|
1994-04-10 11:17:13 +00:00
|
|
|
goto nodevice;
|
|
|
|
|
} else /* drive 0 fail */
|
|
|
|
|
goto nodevice;
|
|
|
|
|
}
|
1995-04-24 05:09:53 +00:00
|
|
|
|
1994-04-10 11:17:13 +00:00
|
|
|
|
1994-01-04 20:05:26 +00:00
|
|
|
free(du, M_TEMP);
|
1993-08-28 03:02:52 +00:00
|
|
|
return (IO_WDCSIZE);
|
1993-06-12 14:58:17 +00:00
|
|
|
|
|
|
|
|
nodevice:
|
|
|
|
|
free(du, M_TEMP);
|
|
|
|
|
return (0);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Attach each drive if possible.
|
|
|
|
|
*/
|
1994-01-04 20:05:26 +00:00
|
|
|
static int
|
1993-06-12 14:58:17 +00:00
|
|
|
wdattach(struct isa_device *dvp)
|
|
|
|
|
{
|
1996-01-27 04:18:15 +00:00
|
|
|
#ifdef DEVFS
|
|
|
|
|
int mynor;
|
|
|
|
|
#endif
|
1994-02-01 05:55:21 +00:00
|
|
|
int unit, lunit;
|
1994-01-04 20:05:26 +00:00
|
|
|
struct isa_device *wdup;
|
|
|
|
|
struct disk *du;
|
Add support for busmaster DMA on some PCI IDE chipsets.
I changed a few bits here and there, mainly renaming wd82371.c
to ide_pci.c now that it's supposed to handle different chipsets.
It runs on my P6 natoma board with two Maxtor drives, and also
on a Fujitsu machine I have at work with an Opti chipset and
a Quantum drive.
Submitted by:cgull@smoke.marlboro.vt.us <John Hood>
Original readme:
*** WARNING ***
This code has so far been tested on exactly one motherboard with two
identical drives known for their good DMA support.
This code, in the right circumstances, could corrupt data subtly,
silently, and invisibly, in much the same way that older PCI IDE
controllers do. It's ALPHA-quality code; there's one or two major
gaps in my understanding of PCI IDE still. Don't use this code on any
system with data that you care about; it's only good for hack boxes.
Expect that any data may be silently and randomly corrupted at any
moment. It's a disk driver. It has bugs. Disk drivers with bugs
munch data. It's a fact of life.
I also *STRONGLY* recommend getting a copy of your chipset's manual
and the ATA-2 or ATA-3 spec and making sure that timing modes on your
disk drives and IDE controller are being setup correctly by the BIOS--
because the driver makes only the lamest of attempts to do this just
now.
*** END WARNING ***
that said, i happen to think the code is working pretty well...
WHAT IT DOES:
this code adds support to the wd driver for bus mastering PCI IDE
controllers that follow the SFF-8038 standard. (all the bus mastering
PCI IDE controllers i've seen so far do follow this standard.) it
should provide busmastering on nearly any current P5 or P6 chipset,
specifically including any Intel chipset using one of the PIIX south
bridges-- this includes the '430FX, '430VX, '430HX, '430TX, '440LX,
and (i think) the Orion '450GX chipsets. specific support is also
included for the VIA Apollo VP-1 chipset, as it appears in the
relabeled "HXPro" incarnation seen on cheap US$70 taiwanese
motherboards (that's what's in my development machine). it works out
of the box on controllers that do DMA mode2; if my understanding is
correct, it'll probably work on Ultra-DMA33 controllers as well.
it'll probably work on busmastering IDE controllers in PCI slots, too,
but this is an area i am less sure about.
it cuts CPU usage considerably and improves drive performance
slightly. usable numbers are difficult to come by with existing
benchmark tools, but experimentation on my K5-P90 system, with VIA
VP-1 chipset and Quantum Fireball 1080 drives, shows that disk i/o on
raw partitions imposes perhaps 5% cpu load. cpu load during
filesystem i/o drops a lot, from near 100% to anywhere between 30% and
70%. (the improvement may not be as large on an Intel chipset; from
what i can tell, the VIA VP-1 may not be very efficient with PCI I/O.)
disk performance improves by 5% or 10% with these drives.
real, visible, end-user performance improvement on a single user
machine is about nil. :) a kernel compile was sped up by a whole three
seconds. it *does* feel a bit better-behaved when the system is
swapping heavily, but a better disk driver is not the fix for *that*
problem.
THE CODE:
this code is a patch to wd.c and wd82371.c, and associated header
files. it should be considered alpha code; more work needs to be
done.
wd.c has fairly clean patches to add calls to busmaster code, as
implemented in wd82371.c and potentially elsewhere (one could imagine,
say, a Mac having a different DMA controller).
wd82371.c has been considerably reworked: the wddma interface that it
presents has been changed (expect more changes), many bugs have been
fixed, a new internal interface has been added for supporting
different chipsets, and the PCI probe has been considerably extended.
the interface between wd82371.c and wd.c is still fairly clean, but
i'm not sure it's in the right place. there's a mess of issues around
ATA/ATAPI that need to be sorted out, including ATAPI support, CD-ROM
support, tape support, LS-120/Zip support, SFF-8038i DMA, UltraDMA,
PCI IDE controllers, bus probes, buggy controllers, controller timing
setup, drive timing setup, world peace and kitchen sinks. whatever
happens with all this and however it gets partitioned, it is fairly
clear that wd.c needs some significant rework-- probably a complete
rewrite.
timing setup on disk controllers is something i've entirely punted on.
on my development machine, it appears that the BIOS does at least some
of the necessary timing setup. i chose to restrict operation to
drives that are already configured for Mode4 PIO and Mode2 multiword
DMA, since the timing is essentially the same and many if not most
chipsets use the same control registers for DMA and PIO timing.
does anybody *know* whether BIOSes are required to do timing setup for
DMA modes on drives under their care?
error recovery is probably weak. early on in development, i was
getting drive errors induced by bugs in the driver; i used these to
flush out the worst of the bugs in the driver's error handling, but
problems may remain. i haven't got a drive with bad sectors i can
watch the driver flail on.
complaints about how wd82371.c has been reindented will be ignored
until the FreeBSD project has a real style policy, there is a
mechanism for individual authors to match it (indent flags or an emacs
c-mode or whatever), and it is enforced. if i'm going to use a source
style i don't like, it would help if i could figure out what it *is*
(style(9) is about half of a policy), and a way to reasonably
duplicate it. i ended up wasting a while trying to figure out what
the right thing to do was before deciding reformatting the whole thing
was the worst possible thing to do, except for all the other
possibilities.
i have maintained wd.c's indentation; that was not too hard,
fortunately.
TO INSTALL:
my dev box is freebsd 2.2.2 release. fortunately, wd.c is a living
fossil, and has diverged very little recently. included in this
tarball is a patch file, 'otherdiffs', for all files except wd82371.c,
my edited wd82371.c, a patch file, 'wd82371.c-diff-exact', against the
2.2.2 dist of 82371.c, and another patch file,
'wd82371.c-diff-whitespace', generated with diff -b (ignore
whitespace). most of you not using 2.2.2 will probably have to use
this last patchfile with 'patch --ignore-whitespace'. apply from the
kernel source tree root. as far as i can tell, this should apply
cleanly on anything from -current back to 2.2.2 and probably back to
2.2.0. you, the kernel hacker, can figure out what to do from here.
if you need more specific directions, you probably should not be
experimenting with this code yet.
to enable DMA support, set flag 0x2000 for that drive in your config
file or in userconfig, as you would the 32-bit-PIO flag. the driver
will then turn on DMA support if your drive and controller pass its
tests. it's a bit picky, probably. on discovering DMA mode failures
or disk errors or transfers that the DMA controller can't deal with,
the driver will fall back to PIO, so it is wise to setup the flags as
if PIO were still important.
'controller wdc0 at isa? port "IO_WD1" bio irq 14 flags 0xa0ffa0ff
vector wdintr' should work with nearly any PCI IDE controller.
i would *strongly* suggest booting single-user at first, and thrashing
the drive a bit while it's still mounted read-only. this should be
fairly safe, even if the driver goes completely out to lunch. it
might save you a reinstall.
one way to tell whether the driver is really using DMA is to check the
interrupt count during disk i/o with vmstat; DMA mode will add an
extremely low number of interrupts, as compared to even multi-sector
PIO.
boot -v will give you a copious register dump of timing-related info
on Intel and VIAtech chipsets, as well as PIO/DMA mode information on
all hard drives. refer to your ATA and chipset documentation to
interpret these.
WHAT I'D LIKE FROM YOU and THINGS TO TEST:
reports. success reports, failure reports, any kind of reports. :)
send them to cgull+ide@smoke.marlboro.vt.us.
i'd also like to see the kernel messages from various BIOSes (boot -v;
dmesg), along with info on the motherboard and BIOS on that machine.
i'm especially interested in reports on how this code works on the
various Intel chipsets, and whether the register dump works
correctly. i'm also interested in hearing about other chipsets.
i'm especially interested in hearing success/failure reports for PCI
IDE controllers on cards, such as CMD's or Promise's new busmastering
IDE controllers.
UltraDMA-33 reports.
interoperation with ATAPI peripherals-- FreeBSD doesn't work with my
old Hitachi IDE CDROM, so i can't tell if I've broken anything. :)
i'd especially like to hear how the drive copes in DMA operation on
drives with bad sectors. i haven't been able to find any such yet.
success/failure reports on older IDE drives with early support for DMA
modes-- those introduced between 1.5 and 3 years ago, typically
ranging from perhaps 400MB to 1.6GB.
failure reports on operation with more than one drive would be
appreciated. the driver was developed with two drives on one
controller, the worst-case situation, and has been tested with one
drive on each controller, but you never know...
any reports of messages from the driver during normal operation,
especially "reverting to PIO mode", or "dmaverify odd vaddr or length"
(the DMA controller is strongly halfword oriented, and i'm curious to
know if any FreeBSD usage actually needs misaligned transfers).
performance reports. beware that bonnie's CPU usage reporting is
useless for IDE drives; the best test i've found has been to run a
program that runs a spin loop at an idle priority and reports how many
iterations it manages, and even that sometimes produces numbers i
don't believe. performance reports of multi-drive operation are
especially interesting; my system cannot sustain full throughput on
two drives on separate controllers, but that may just be a lame
motherboard.
THINGS I'M STILL MISSING CLUE ON:
* who's responsible for configuring DMA timing modes on IDE drives?
the BIOS or the driver?
* is there a spec for dealing with Ultra-DMA extensions?
* are there any chipsets or with bugs relating to DMA transfer that
should be blacklisted?
* are there any ATA interfaces that use some other kind of DMA
controller in conjunction with standard ATA protocol?
FINAL NOTE:
after having looked at the ATA-3 spec, all i can say is, "it's ugly".
*especially* electrically. the IDE bus is best modeled as an
unterminated transmission line, these days.
for maximum reliability, keep your IDE cables as short as possible and
as few as possible. from what i can tell, most current chipsets have
both IDE ports wired into a single buss, to a greater or lesser
degree. using two cables means you double the length of this bus.
SCSI may have its warts, but at least the basic analog design of the
bus is still somewhat reasonable. IDE passed beyond the veil two
years ago.
--John Hood, cgull@smoke.marlboro.vt.us
1997-07-29 12:57:25 +00:00
|
|
|
struct wdparams *wp;
|
1994-01-04 20:05:26 +00:00
|
|
|
|
|
|
|
|
if (dvp->id_unit >= NWDC)
|
1994-02-01 05:55:21 +00:00
|
|
|
return (0);
|
1994-01-04 20:05:26 +00:00
|
|
|
|
1997-03-11 23:17:28 +00:00
|
|
|
#ifdef CMD640
|
|
|
|
|
if (eide_quirks & Q_CMD640B) {
|
|
|
|
|
if (dvp->id_unit == PRIMARY) {
|
|
|
|
|
printf("wdc0: CMD640B workaround enabled\n");
|
|
|
|
|
TAILQ_INIT( &wdtab[PRIMARY].controller_queue);
|
|
|
|
|
}
|
|
|
|
|
} else
|
|
|
|
|
TAILQ_INIT( &wdtab[dvp->id_unit].controller_queue);
|
|
|
|
|
|
|
|
|
|
#else
|
1995-11-23 07:24:41 +00:00
|
|
|
TAILQ_INIT( &wdtab[dvp->id_unit].controller_queue);
|
1997-03-11 23:17:28 +00:00
|
|
|
#endif
|
1994-10-16 03:50:36 +00:00
|
|
|
|
1994-01-04 20:05:26 +00:00
|
|
|
for (wdup = isa_biotab_wdc; wdup->id_driver != 0; wdup++) {
|
|
|
|
|
if (wdup->id_iobase != dvp->id_iobase)
|
|
|
|
|
continue;
|
|
|
|
|
lunit = wdup->id_unit;
|
|
|
|
|
if (lunit >= NWD)
|
|
|
|
|
continue;
|
1995-11-23 07:24:41 +00:00
|
|
|
|
1994-01-04 20:05:26 +00:00
|
|
|
unit = wdup->id_physid;
|
|
|
|
|
|
1994-02-01 05:55:21 +00:00
|
|
|
du = malloc(sizeof *du, M_TEMP, M_NOWAIT);
|
|
|
|
|
if (du == NULL)
|
|
|
|
|
continue;
|
|
|
|
|
if (wddrives[lunit] != NULL)
|
|
|
|
|
panic("drive attached twice");
|
|
|
|
|
wddrives[lunit] = du;
|
1995-11-23 07:24:41 +00:00
|
|
|
TAILQ_INIT( &drive_queue[lunit]);
|
1994-02-01 05:55:21 +00:00
|
|
|
bzero(du, sizeof *du);
|
1994-01-04 20:05:26 +00:00
|
|
|
du->dk_ctrlr = dvp->id_unit;
|
1997-03-11 23:17:28 +00:00
|
|
|
#ifdef CMD640
|
|
|
|
|
if (eide_quirks & Q_CMD640B) {
|
|
|
|
|
du->dk_ctrlr_cmd640 = PRIMARY;
|
|
|
|
|
} else {
|
|
|
|
|
du->dk_ctrlr_cmd640 = du->dk_ctrlr;
|
|
|
|
|
}
|
|
|
|
|
#endif
|
1994-01-04 20:05:26 +00:00
|
|
|
du->dk_unit = unit;
|
|
|
|
|
du->dk_lunit = lunit;
|
|
|
|
|
du->dk_port = dvp->id_iobase;
|
1993-06-12 14:58:17 +00:00
|
|
|
|
1995-04-24 04:32:31 +00:00
|
|
|
/*
|
|
|
|
|
* Use the individual device flags or the controller
|
|
|
|
|
* flags.
|
|
|
|
|
*/
|
1995-04-24 05:12:29 +00:00
|
|
|
du->cfg_flags = wdup->id_flags |
|
|
|
|
|
((dvp->id_flags) >> (16 * unit));
|
|
|
|
|
|
|
|
|
|
if (wdgetctlr(du) == 0) {
|
1995-04-14 22:31:58 +00:00
|
|
|
/*
|
|
|
|
|
* Print out description of drive.
|
1996-01-16 18:13:18 +00:00
|
|
|
* wdp_model may not be null terminated.
|
1995-04-14 22:31:58 +00:00
|
|
|
*/
|
1996-01-16 18:13:18 +00:00
|
|
|
printf("wdc%d: unit %d (wd%d): <%.*s>",
|
|
|
|
|
dvp->id_unit, unit, lunit,
|
|
|
|
|
sizeof du->dk_params.wdp_model,
|
|
|
|
|
du->dk_params.wdp_model);
|
Add support for busmaster DMA on some PCI IDE chipsets.
I changed a few bits here and there, mainly renaming wd82371.c
to ide_pci.c now that it's supposed to handle different chipsets.
It runs on my P6 natoma board with two Maxtor drives, and also
on a Fujitsu machine I have at work with an Opti chipset and
a Quantum drive.
Submitted by:cgull@smoke.marlboro.vt.us <John Hood>
Original readme:
*** WARNING ***
This code has so far been tested on exactly one motherboard with two
identical drives known for their good DMA support.
This code, in the right circumstances, could corrupt data subtly,
silently, and invisibly, in much the same way that older PCI IDE
controllers do. It's ALPHA-quality code; there's one or two major
gaps in my understanding of PCI IDE still. Don't use this code on any
system with data that you care about; it's only good for hack boxes.
Expect that any data may be silently and randomly corrupted at any
moment. It's a disk driver. It has bugs. Disk drivers with bugs
munch data. It's a fact of life.
I also *STRONGLY* recommend getting a copy of your chipset's manual
and the ATA-2 or ATA-3 spec and making sure that timing modes on your
disk drives and IDE controller are being setup correctly by the BIOS--
because the driver makes only the lamest of attempts to do this just
now.
*** END WARNING ***
that said, i happen to think the code is working pretty well...
WHAT IT DOES:
this code adds support to the wd driver for bus mastering PCI IDE
controllers that follow the SFF-8038 standard. (all the bus mastering
PCI IDE controllers i've seen so far do follow this standard.) it
should provide busmastering on nearly any current P5 or P6 chipset,
specifically including any Intel chipset using one of the PIIX south
bridges-- this includes the '430FX, '430VX, '430HX, '430TX, '440LX,
and (i think) the Orion '450GX chipsets. specific support is also
included for the VIA Apollo VP-1 chipset, as it appears in the
relabeled "HXPro" incarnation seen on cheap US$70 taiwanese
motherboards (that's what's in my development machine). it works out
of the box on controllers that do DMA mode2; if my understanding is
correct, it'll probably work on Ultra-DMA33 controllers as well.
it'll probably work on busmastering IDE controllers in PCI slots, too,
but this is an area i am less sure about.
it cuts CPU usage considerably and improves drive performance
slightly. usable numbers are difficult to come by with existing
benchmark tools, but experimentation on my K5-P90 system, with VIA
VP-1 chipset and Quantum Fireball 1080 drives, shows that disk i/o on
raw partitions imposes perhaps 5% cpu load. cpu load during
filesystem i/o drops a lot, from near 100% to anywhere between 30% and
70%. (the improvement may not be as large on an Intel chipset; from
what i can tell, the VIA VP-1 may not be very efficient with PCI I/O.)
disk performance improves by 5% or 10% with these drives.
real, visible, end-user performance improvement on a single user
machine is about nil. :) a kernel compile was sped up by a whole three
seconds. it *does* feel a bit better-behaved when the system is
swapping heavily, but a better disk driver is not the fix for *that*
problem.
THE CODE:
this code is a patch to wd.c and wd82371.c, and associated header
files. it should be considered alpha code; more work needs to be
done.
wd.c has fairly clean patches to add calls to busmaster code, as
implemented in wd82371.c and potentially elsewhere (one could imagine,
say, a Mac having a different DMA controller).
wd82371.c has been considerably reworked: the wddma interface that it
presents has been changed (expect more changes), many bugs have been
fixed, a new internal interface has been added for supporting
different chipsets, and the PCI probe has been considerably extended.
the interface between wd82371.c and wd.c is still fairly clean, but
i'm not sure it's in the right place. there's a mess of issues around
ATA/ATAPI that need to be sorted out, including ATAPI support, CD-ROM
support, tape support, LS-120/Zip support, SFF-8038i DMA, UltraDMA,
PCI IDE controllers, bus probes, buggy controllers, controller timing
setup, drive timing setup, world peace and kitchen sinks. whatever
happens with all this and however it gets partitioned, it is fairly
clear that wd.c needs some significant rework-- probably a complete
rewrite.
timing setup on disk controllers is something i've entirely punted on.
on my development machine, it appears that the BIOS does at least some
of the necessary timing setup. i chose to restrict operation to
drives that are already configured for Mode4 PIO and Mode2 multiword
DMA, since the timing is essentially the same and many if not most
chipsets use the same control registers for DMA and PIO timing.
does anybody *know* whether BIOSes are required to do timing setup for
DMA modes on drives under their care?
error recovery is probably weak. early on in development, i was
getting drive errors induced by bugs in the driver; i used these to
flush out the worst of the bugs in the driver's error handling, but
problems may remain. i haven't got a drive with bad sectors i can
watch the driver flail on.
complaints about how wd82371.c has been reindented will be ignored
until the FreeBSD project has a real style policy, there is a
mechanism for individual authors to match it (indent flags or an emacs
c-mode or whatever), and it is enforced. if i'm going to use a source
style i don't like, it would help if i could figure out what it *is*
(style(9) is about half of a policy), and a way to reasonably
duplicate it. i ended up wasting a while trying to figure out what
the right thing to do was before deciding reformatting the whole thing
was the worst possible thing to do, except for all the other
possibilities.
i have maintained wd.c's indentation; that was not too hard,
fortunately.
TO INSTALL:
my dev box is freebsd 2.2.2 release. fortunately, wd.c is a living
fossil, and has diverged very little recently. included in this
tarball is a patch file, 'otherdiffs', for all files except wd82371.c,
my edited wd82371.c, a patch file, 'wd82371.c-diff-exact', against the
2.2.2 dist of 82371.c, and another patch file,
'wd82371.c-diff-whitespace', generated with diff -b (ignore
whitespace). most of you not using 2.2.2 will probably have to use
this last patchfile with 'patch --ignore-whitespace'. apply from the
kernel source tree root. as far as i can tell, this should apply
cleanly on anything from -current back to 2.2.2 and probably back to
2.2.0. you, the kernel hacker, can figure out what to do from here.
if you need more specific directions, you probably should not be
experimenting with this code yet.
to enable DMA support, set flag 0x2000 for that drive in your config
file or in userconfig, as you would the 32-bit-PIO flag. the driver
will then turn on DMA support if your drive and controller pass its
tests. it's a bit picky, probably. on discovering DMA mode failures
or disk errors or transfers that the DMA controller can't deal with,
the driver will fall back to PIO, so it is wise to setup the flags as
if PIO were still important.
'controller wdc0 at isa? port "IO_WD1" bio irq 14 flags 0xa0ffa0ff
vector wdintr' should work with nearly any PCI IDE controller.
i would *strongly* suggest booting single-user at first, and thrashing
the drive a bit while it's still mounted read-only. this should be
fairly safe, even if the driver goes completely out to lunch. it
might save you a reinstall.
one way to tell whether the driver is really using DMA is to check the
interrupt count during disk i/o with vmstat; DMA mode will add an
extremely low number of interrupts, as compared to even multi-sector
PIO.
boot -v will give you a copious register dump of timing-related info
on Intel and VIAtech chipsets, as well as PIO/DMA mode information on
all hard drives. refer to your ATA and chipset documentation to
interpret these.
WHAT I'D LIKE FROM YOU and THINGS TO TEST:
reports. success reports, failure reports, any kind of reports. :)
send them to cgull+ide@smoke.marlboro.vt.us.
i'd also like to see the kernel messages from various BIOSes (boot -v;
dmesg), along with info on the motherboard and BIOS on that machine.
i'm especially interested in reports on how this code works on the
various Intel chipsets, and whether the register dump works
correctly. i'm also interested in hearing about other chipsets.
i'm especially interested in hearing success/failure reports for PCI
IDE controllers on cards, such as CMD's or Promise's new busmastering
IDE controllers.
UltraDMA-33 reports.
interoperation with ATAPI peripherals-- FreeBSD doesn't work with my
old Hitachi IDE CDROM, so i can't tell if I've broken anything. :)
i'd especially like to hear how the drive copes in DMA operation on
drives with bad sectors. i haven't been able to find any such yet.
success/failure reports on older IDE drives with early support for DMA
modes-- those introduced between 1.5 and 3 years ago, typically
ranging from perhaps 400MB to 1.6GB.
failure reports on operation with more than one drive would be
appreciated. the driver was developed with two drives on one
controller, the worst-case situation, and has been tested with one
drive on each controller, but you never know...
any reports of messages from the driver during normal operation,
especially "reverting to PIO mode", or "dmaverify odd vaddr or length"
(the DMA controller is strongly halfword oriented, and i'm curious to
know if any FreeBSD usage actually needs misaligned transfers).
performance reports. beware that bonnie's CPU usage reporting is
useless for IDE drives; the best test i've found has been to run a
program that runs a spin loop at an idle priority and reports how many
iterations it manages, and even that sometimes produces numbers i
don't believe. performance reports of multi-drive operation are
especially interesting; my system cannot sustain full throughput on
two drives on separate controllers, but that may just be a lame
motherboard.
THINGS I'M STILL MISSING CLUE ON:
* who's responsible for configuring DMA timing modes on IDE drives?
the BIOS or the driver?
* is there a spec for dealing with Ultra-DMA extensions?
* are there any chipsets or with bugs relating to DMA transfer that
should be blacklisted?
* are there any ATA interfaces that use some other kind of DMA
controller in conjunction with standard ATA protocol?
FINAL NOTE:
after having looked at the ATA-3 spec, all i can say is, "it's ugly".
*especially* electrically. the IDE bus is best modeled as an
unterminated transmission line, these days.
for maximum reliability, keep your IDE cables as short as possible and
as few as possible. from what i can tell, most current chipsets have
both IDE ports wired into a single buss, to a greater or lesser
degree. using two cables means you double the length of this bus.
SCSI may have its warts, but at least the basic analog design of the
bus is still somewhat reasonable. IDE passed beyond the veil two
years ago.
--John Hood, cgull@smoke.marlboro.vt.us
1997-07-29 12:57:25 +00:00
|
|
|
if (du->dk_flags & DKFL_USEDMA)
|
|
|
|
|
printf(", DMA");
|
1995-04-14 22:31:58 +00:00
|
|
|
if (du->dk_flags & DKFL_32BIT)
|
|
|
|
|
printf(", 32-bit");
|
|
|
|
|
if (du->dk_multi > 1)
|
|
|
|
|
printf(", multi-block-%d", du->dk_multi);
|
1995-04-24 05:12:29 +00:00
|
|
|
if (du->cfg_flags & WDOPT_SLEEPHACK)
|
|
|
|
|
printf(", sleep-hack");
|
1995-04-14 22:31:58 +00:00
|
|
|
printf("\n");
|
|
|
|
|
if (du->dk_params.wdp_heads == 0)
|
|
|
|
|
printf("wd%d: size unknown, using %s values\n",
|
|
|
|
|
lunit, du->dk_dd.d_secperunit > 17
|
|
|
|
|
? "BIOS" : "fake");
|
|
|
|
|
printf(
|
|
|
|
|
"wd%d: %luMB (%lu sectors), %lu cyls, %lu heads, %lu S/T, %lu B/S\n",
|
|
|
|
|
lunit,
|
|
|
|
|
du->dk_dd.d_secperunit
|
1997-02-18 23:31:53 +00:00
|
|
|
/ ((1024L * 1024L) / du->dk_dd.d_secsize),
|
1995-04-14 22:31:58 +00:00
|
|
|
du->dk_dd.d_secperunit,
|
|
|
|
|
du->dk_dd.d_ncylinders,
|
|
|
|
|
du->dk_dd.d_ntracks,
|
|
|
|
|
du->dk_dd.d_nsectors,
|
|
|
|
|
du->dk_dd.d_secsize);
|
|
|
|
|
|
Add support for busmaster DMA on some PCI IDE chipsets.
I changed a few bits here and there, mainly renaming wd82371.c
to ide_pci.c now that it's supposed to handle different chipsets.
It runs on my P6 natoma board with two Maxtor drives, and also
on a Fujitsu machine I have at work with an Opti chipset and
a Quantum drive.
Submitted by:cgull@smoke.marlboro.vt.us <John Hood>
Original readme:
*** WARNING ***
This code has so far been tested on exactly one motherboard with two
identical drives known for their good DMA support.
This code, in the right circumstances, could corrupt data subtly,
silently, and invisibly, in much the same way that older PCI IDE
controllers do. It's ALPHA-quality code; there's one or two major
gaps in my understanding of PCI IDE still. Don't use this code on any
system with data that you care about; it's only good for hack boxes.
Expect that any data may be silently and randomly corrupted at any
moment. It's a disk driver. It has bugs. Disk drivers with bugs
munch data. It's a fact of life.
I also *STRONGLY* recommend getting a copy of your chipset's manual
and the ATA-2 or ATA-3 spec and making sure that timing modes on your
disk drives and IDE controller are being setup correctly by the BIOS--
because the driver makes only the lamest of attempts to do this just
now.
*** END WARNING ***
that said, i happen to think the code is working pretty well...
WHAT IT DOES:
this code adds support to the wd driver for bus mastering PCI IDE
controllers that follow the SFF-8038 standard. (all the bus mastering
PCI IDE controllers i've seen so far do follow this standard.) it
should provide busmastering on nearly any current P5 or P6 chipset,
specifically including any Intel chipset using one of the PIIX south
bridges-- this includes the '430FX, '430VX, '430HX, '430TX, '440LX,
and (i think) the Orion '450GX chipsets. specific support is also
included for the VIA Apollo VP-1 chipset, as it appears in the
relabeled "HXPro" incarnation seen on cheap US$70 taiwanese
motherboards (that's what's in my development machine). it works out
of the box on controllers that do DMA mode2; if my understanding is
correct, it'll probably work on Ultra-DMA33 controllers as well.
it'll probably work on busmastering IDE controllers in PCI slots, too,
but this is an area i am less sure about.
it cuts CPU usage considerably and improves drive performance
slightly. usable numbers are difficult to come by with existing
benchmark tools, but experimentation on my K5-P90 system, with VIA
VP-1 chipset and Quantum Fireball 1080 drives, shows that disk i/o on
raw partitions imposes perhaps 5% cpu load. cpu load during
filesystem i/o drops a lot, from near 100% to anywhere between 30% and
70%. (the improvement may not be as large on an Intel chipset; from
what i can tell, the VIA VP-1 may not be very efficient with PCI I/O.)
disk performance improves by 5% or 10% with these drives.
real, visible, end-user performance improvement on a single user
machine is about nil. :) a kernel compile was sped up by a whole three
seconds. it *does* feel a bit better-behaved when the system is
swapping heavily, but a better disk driver is not the fix for *that*
problem.
THE CODE:
this code is a patch to wd.c and wd82371.c, and associated header
files. it should be considered alpha code; more work needs to be
done.
wd.c has fairly clean patches to add calls to busmaster code, as
implemented in wd82371.c and potentially elsewhere (one could imagine,
say, a Mac having a different DMA controller).
wd82371.c has been considerably reworked: the wddma interface that it
presents has been changed (expect more changes), many bugs have been
fixed, a new internal interface has been added for supporting
different chipsets, and the PCI probe has been considerably extended.
the interface between wd82371.c and wd.c is still fairly clean, but
i'm not sure it's in the right place. there's a mess of issues around
ATA/ATAPI that need to be sorted out, including ATAPI support, CD-ROM
support, tape support, LS-120/Zip support, SFF-8038i DMA, UltraDMA,
PCI IDE controllers, bus probes, buggy controllers, controller timing
setup, drive timing setup, world peace and kitchen sinks. whatever
happens with all this and however it gets partitioned, it is fairly
clear that wd.c needs some significant rework-- probably a complete
rewrite.
timing setup on disk controllers is something i've entirely punted on.
on my development machine, it appears that the BIOS does at least some
of the necessary timing setup. i chose to restrict operation to
drives that are already configured for Mode4 PIO and Mode2 multiword
DMA, since the timing is essentially the same and many if not most
chipsets use the same control registers for DMA and PIO timing.
does anybody *know* whether BIOSes are required to do timing setup for
DMA modes on drives under their care?
error recovery is probably weak. early on in development, i was
getting drive errors induced by bugs in the driver; i used these to
flush out the worst of the bugs in the driver's error handling, but
problems may remain. i haven't got a drive with bad sectors i can
watch the driver flail on.
complaints about how wd82371.c has been reindented will be ignored
until the FreeBSD project has a real style policy, there is a
mechanism for individual authors to match it (indent flags or an emacs
c-mode or whatever), and it is enforced. if i'm going to use a source
style i don't like, it would help if i could figure out what it *is*
(style(9) is about half of a policy), and a way to reasonably
duplicate it. i ended up wasting a while trying to figure out what
the right thing to do was before deciding reformatting the whole thing
was the worst possible thing to do, except for all the other
possibilities.
i have maintained wd.c's indentation; that was not too hard,
fortunately.
TO INSTALL:
my dev box is freebsd 2.2.2 release. fortunately, wd.c is a living
fossil, and has diverged very little recently. included in this
tarball is a patch file, 'otherdiffs', for all files except wd82371.c,
my edited wd82371.c, a patch file, 'wd82371.c-diff-exact', against the
2.2.2 dist of 82371.c, and another patch file,
'wd82371.c-diff-whitespace', generated with diff -b (ignore
whitespace). most of you not using 2.2.2 will probably have to use
this last patchfile with 'patch --ignore-whitespace'. apply from the
kernel source tree root. as far as i can tell, this should apply
cleanly on anything from -current back to 2.2.2 and probably back to
2.2.0. you, the kernel hacker, can figure out what to do from here.
if you need more specific directions, you probably should not be
experimenting with this code yet.
to enable DMA support, set flag 0x2000 for that drive in your config
file or in userconfig, as you would the 32-bit-PIO flag. the driver
will then turn on DMA support if your drive and controller pass its
tests. it's a bit picky, probably. on discovering DMA mode failures
or disk errors or transfers that the DMA controller can't deal with,
the driver will fall back to PIO, so it is wise to setup the flags as
if PIO were still important.
'controller wdc0 at isa? port "IO_WD1" bio irq 14 flags 0xa0ffa0ff
vector wdintr' should work with nearly any PCI IDE controller.
i would *strongly* suggest booting single-user at first, and thrashing
the drive a bit while it's still mounted read-only. this should be
fairly safe, even if the driver goes completely out to lunch. it
might save you a reinstall.
one way to tell whether the driver is really using DMA is to check the
interrupt count during disk i/o with vmstat; DMA mode will add an
extremely low number of interrupts, as compared to even multi-sector
PIO.
boot -v will give you a copious register dump of timing-related info
on Intel and VIAtech chipsets, as well as PIO/DMA mode information on
all hard drives. refer to your ATA and chipset documentation to
interpret these.
WHAT I'D LIKE FROM YOU and THINGS TO TEST:
reports. success reports, failure reports, any kind of reports. :)
send them to cgull+ide@smoke.marlboro.vt.us.
i'd also like to see the kernel messages from various BIOSes (boot -v;
dmesg), along with info on the motherboard and BIOS on that machine.
i'm especially interested in reports on how this code works on the
various Intel chipsets, and whether the register dump works
correctly. i'm also interested in hearing about other chipsets.
i'm especially interested in hearing success/failure reports for PCI
IDE controllers on cards, such as CMD's or Promise's new busmastering
IDE controllers.
UltraDMA-33 reports.
interoperation with ATAPI peripherals-- FreeBSD doesn't work with my
old Hitachi IDE CDROM, so i can't tell if I've broken anything. :)
i'd especially like to hear how the drive copes in DMA operation on
drives with bad sectors. i haven't been able to find any such yet.
success/failure reports on older IDE drives with early support for DMA
modes-- those introduced between 1.5 and 3 years ago, typically
ranging from perhaps 400MB to 1.6GB.
failure reports on operation with more than one drive would be
appreciated. the driver was developed with two drives on one
controller, the worst-case situation, and has been tested with one
drive on each controller, but you never know...
any reports of messages from the driver during normal operation,
especially "reverting to PIO mode", or "dmaverify odd vaddr or length"
(the DMA controller is strongly halfword oriented, and i'm curious to
know if any FreeBSD usage actually needs misaligned transfers).
performance reports. beware that bonnie's CPU usage reporting is
useless for IDE drives; the best test i've found has been to run a
program that runs a spin loop at an idle priority and reports how many
iterations it manages, and even that sometimes produces numbers i
don't believe. performance reports of multi-drive operation are
especially interesting; my system cannot sustain full throughput on
two drives on separate controllers, but that may just be a lame
motherboard.
THINGS I'M STILL MISSING CLUE ON:
* who's responsible for configuring DMA timing modes on IDE drives?
the BIOS or the driver?
* is there a spec for dealing with Ultra-DMA extensions?
* are there any chipsets or with bugs relating to DMA transfer that
should be blacklisted?
* are there any ATA interfaces that use some other kind of DMA
controller in conjunction with standard ATA protocol?
FINAL NOTE:
after having looked at the ATA-3 spec, all i can say is, "it's ugly".
*especially* electrically. the IDE bus is best modeled as an
unterminated transmission line, these days.
for maximum reliability, keep your IDE cables as short as possible and
as few as possible. from what i can tell, most current chipsets have
both IDE ports wired into a single buss, to a greater or lesser
degree. using two cables means you double the length of this bus.
SCSI may have its warts, but at least the basic analog design of the
bus is still somewhat reasonable. IDE passed beyond the veil two
years ago.
--John Hood, cgull@smoke.marlboro.vt.us
1997-07-29 12:57:25 +00:00
|
|
|
if (bootverbose) {
|
|
|
|
|
wp = &du->dk_params;
|
|
|
|
|
printf(
|
|
|
|
|
"wd%d: ATA INQUIRE valid = %04x, dmamword = %04x, apio = %04x, udma = %04x\n",
|
|
|
|
|
du->dk_lunit,
|
|
|
|
|
wp->wdp_atavalid,
|
|
|
|
|
wp->wdp_dmamword,
|
|
|
|
|
wp->wdp_eidepiomodes,
|
|
|
|
|
wp->wdp_udmamode);
|
|
|
|
|
}
|
|
|
|
|
|
1995-04-14 22:31:58 +00:00
|
|
|
/*
|
|
|
|
|
* Start timeout routine for this drive.
|
|
|
|
|
* XXX timeout should be per controller.
|
|
|
|
|
*/
|
|
|
|
|
wdtimeout(du);
|
|
|
|
|
|
1996-01-27 04:18:15 +00:00
|
|
|
#ifdef DEVFS
|
|
|
|
|
mynor = dkmakeminor(unit, WHOLE_DISK_SLICE, RAW_PART);
|
1996-03-27 18:50:10 +00:00
|
|
|
du->dk_bdev = devfs_add_devswf(&wd_bdevsw, mynor,
|
|
|
|
|
DV_BLK, UID_ROOT,
|
|
|
|
|
GID_OPERATOR, 0640,
|
|
|
|
|
"wd%d", unit);
|
|
|
|
|
du->dk_cdev = devfs_add_devswf(&wd_cdevsw, mynor,
|
|
|
|
|
DV_CHR, UID_ROOT,
|
|
|
|
|
GID_OPERATOR, 0640,
|
|
|
|
|
"rwd%d", unit);
|
1996-01-27 04:18:15 +00:00
|
|
|
#endif
|
|
|
|
|
|
1995-04-14 22:31:58 +00:00
|
|
|
if (dk_ndrive < DK_NDRIVE) {
|
|
|
|
|
sprintf(dk_names[dk_ndrive], "wd%d", lunit);
|
|
|
|
|
/*
|
|
|
|
|
* XXX we don't know the transfer rate of the
|
|
|
|
|
* drive. Guess the maximum ISA rate of
|
|
|
|
|
* 4MB/sec. `wpms' is words per _second_
|
|
|
|
|
* according to iostat.
|
|
|
|
|
*/
|
|
|
|
|
dk_wpms[dk_ndrive] = 4 * 1024 * 1024 / 2;
|
|
|
|
|
du->dk_dkunit = dk_ndrive++;
|
|
|
|
|
} else {
|
|
|
|
|
du->dk_dkunit = -1;
|
|
|
|
|
}
|
1994-02-01 05:55:21 +00:00
|
|
|
} else {
|
1994-01-04 20:05:26 +00:00
|
|
|
free(du, M_TEMP);
|
1994-02-01 05:55:21 +00:00
|
|
|
wddrives[lunit] = NULL;
|
1993-06-12 14:58:17 +00:00
|
|
|
}
|
|
|
|
|
}
|
1995-08-18 11:26:35 +00:00
|
|
|
#ifdef ATAPI
|
|
|
|
|
/*
|
|
|
|
|
* Probe all free IDE units, searching for ATAPI drives.
|
|
|
|
|
*/
|
|
|
|
|
for (unit=0; unit<2; ++unit) {
|
|
|
|
|
for (lunit=0; lunit<NWD && wddrives[lunit]; ++lunit)
|
|
|
|
|
if (wddrives[lunit]->dk_ctrlr == dvp->id_unit &&
|
|
|
|
|
wddrives[lunit]->dk_unit == unit)
|
|
|
|
|
goto next;
|
1997-03-11 23:17:28 +00:00
|
|
|
#ifdef CMD640
|
|
|
|
|
if (atapi_attach (dvp->id_unit, unit, dvp->id_iobase))
|
|
|
|
|
atapictrlr = dvp->id_unit;
|
|
|
|
|
#else
|
1996-09-06 23:09:20 +00:00
|
|
|
atapi_attach (dvp->id_unit, unit, dvp->id_iobase);
|
1997-03-11 23:17:28 +00:00
|
|
|
#endif
|
1997-07-01 00:22:51 +00:00
|
|
|
next: ;
|
|
|
|
|
}
|
1995-08-18 11:26:35 +00:00
|
|
|
#endif
|
1994-02-01 05:55:21 +00:00
|
|
|
/*
|
|
|
|
|
* Discard any interrupts generated by wdgetctlr(). wdflushirq()
|
|
|
|
|
* doesn't work now because the ambient ipl is too high.
|
|
|
|
|
*/
|
1997-03-11 23:17:28 +00:00
|
|
|
#ifdef CMD640
|
1997-05-27 18:28:08 +00:00
|
|
|
if (eide_quirks & Q_CMD640B) {
|
|
|
|
|
wdtab[PRIMARY].b_active = 2;
|
|
|
|
|
} else {
|
|
|
|
|
wdtab[dvp->id_unit].b_active = 2;
|
|
|
|
|
}
|
1997-03-11 23:17:28 +00:00
|
|
|
#else
|
1994-02-01 05:55:21 +00:00
|
|
|
wdtab[dvp->id_unit].b_active = 2;
|
1997-03-11 23:17:28 +00:00
|
|
|
#endif
|
1994-02-01 05:55:21 +00:00
|
|
|
|
|
|
|
|
return (1);
|
1993-06-12 14:58:17 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Read/write routine for a buffer. Finds the proper unit, range checks
|
|
|
|
|
* arguments, and schedules the transfer. Does not wait for the transfer
|
|
|
|
|
* to complete. Multi-page transfers are supported. All I/O requests must
|
|
|
|
|
* be a multiple of a sector in length.
|
|
|
|
|
*/
|
1993-11-25 01:38:01 +00:00
|
|
|
void
|
1993-06-12 14:58:17 +00:00
|
|
|
wdstrategy(register struct buf *bp)
|
|
|
|
|
{
|
1994-02-01 05:55:21 +00:00
|
|
|
struct disk *du;
|
1995-04-14 22:31:58 +00:00
|
|
|
int lunit = dkunit(bp->b_dev);
|
1993-06-12 14:58:17 +00:00
|
|
|
int s;
|
|
|
|
|
|
|
|
|
|
/* valid unit, controller, and request? */
|
1994-11-03 18:20:15 +00:00
|
|
|
if (lunit >= NWD || bp->b_blkno < 0 || (du = wddrives[lunit]) == NULL
|
1994-11-04 05:21:17 +00:00
|
|
|
|| bp->b_bcount % DEV_BSIZE != 0) {
|
1993-06-12 14:58:17 +00:00
|
|
|
|
|
|
|
|
bp->b_error = EINVAL;
|
|
|
|
|
bp->b_flags |= B_ERROR;
|
|
|
|
|
goto done;
|
|
|
|
|
}
|
|
|
|
|
|
1994-02-01 05:55:21 +00:00
|
|
|
/*
|
1996-12-01 16:34:41 +00:00
|
|
|
* Do bounds checking, adjust transfer, and set b_pblkno.
|
1994-02-01 05:55:21 +00:00
|
|
|
*/
|
1995-04-14 22:31:58 +00:00
|
|
|
if (dscheck(bp, du->dk_slices) <= 0)
|
1994-02-01 05:55:21 +00:00
|
|
|
goto done;
|
1993-06-12 14:58:17 +00:00
|
|
|
|
1994-04-20 07:06:57 +00:00
|
|
|
/*
|
|
|
|
|
* Check for *any* block on this transfer being on the bad block list
|
|
|
|
|
* if it is, then flag the block as a transfer that requires
|
|
|
|
|
* bad block handling. Also, used as a hint for low level disksort
|
|
|
|
|
* clustering code to keep from coalescing a bad transfer into
|
|
|
|
|
* a normal transfer. Single block transfers for a large number of
|
1995-04-14 22:31:58 +00:00
|
|
|
* blocks associated with a cluster I/O are undesirable.
|
|
|
|
|
*
|
|
|
|
|
* XXX the old disksort() doesn't look at B_BAD. Coalescing _is_
|
|
|
|
|
* desirable. We should split the results at bad blocks just
|
|
|
|
|
* like we should split them at MAXTRANSFER boundaries.
|
1994-04-20 07:06:57 +00:00
|
|
|
*/
|
1995-04-14 22:31:58 +00:00
|
|
|
if (dsgetbad(bp->b_dev, du->dk_slices) != NULL) {
|
|
|
|
|
long *badsect = dsgetbad(bp->b_dev, du->dk_slices)->bi_bad;
|
1994-04-20 07:06:57 +00:00
|
|
|
int i;
|
|
|
|
|
int nsecs = howmany(bp->b_bcount, DEV_BSIZE);
|
1995-04-14 22:31:58 +00:00
|
|
|
/* XXX pblkno is too physical. */
|
|
|
|
|
daddr_t nspblkno = bp->b_pblkno
|
|
|
|
|
- du->dk_slices->dss_slices[dkslice(bp->b_dev)].ds_offset;
|
|
|
|
|
int blkend = nspblkno + nsecs;
|
|
|
|
|
|
|
|
|
|
for (i = 0; badsect[i] != -1 && badsect[i] < blkend; i++) {
|
|
|
|
|
if (badsect[i] >= nspblkno) {
|
1994-04-20 07:06:57 +00:00
|
|
|
bp->b_flags |= B_BAD;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
1993-06-12 14:58:17 +00:00
|
|
|
/* queue transfer on drive, activate drive and controller if idle */
|
|
|
|
|
s = splbio();
|
1994-04-20 07:06:57 +00:00
|
|
|
|
1995-11-23 07:24:41 +00:00
|
|
|
tqdisksort(&drive_queue[lunit], bp);
|
1994-04-20 07:06:57 +00:00
|
|
|
|
1995-11-23 07:24:41 +00:00
|
|
|
if (wdutab[lunit].b_active == 0)
|
1994-02-01 05:55:21 +00:00
|
|
|
wdustart(du); /* start drive */
|
1994-01-04 20:05:26 +00:00
|
|
|
|
|
|
|
|
/* Pick up changes made by readdisklabel(). */
|
|
|
|
|
if (du->dk_flags & DKFL_LABELLING && du->dk_state > RECAL) {
|
|
|
|
|
wdsleep(du->dk_ctrlr, "wdlab");
|
|
|
|
|
du->dk_state = WANTOPEN;
|
|
|
|
|
}
|
|
|
|
|
|
1997-03-11 23:17:28 +00:00
|
|
|
#ifdef CMD640
|
|
|
|
|
if (wdtab[du->dk_ctrlr_cmd640].b_active == 0)
|
|
|
|
|
#else
|
1994-01-04 20:05:26 +00:00
|
|
|
if (wdtab[du->dk_ctrlr].b_active == 0)
|
1997-03-11 23:17:28 +00:00
|
|
|
#endif
|
1994-02-01 05:55:21 +00:00
|
|
|
wdstart(du->dk_ctrlr); /* start controller */
|
1995-04-14 22:31:58 +00:00
|
|
|
|
|
|
|
|
if (du->dk_dkunit >= 0) {
|
|
|
|
|
/*
|
|
|
|
|
* XXX perhaps we should only count successful transfers.
|
|
|
|
|
*/
|
|
|
|
|
dk_xfer[du->dk_dkunit]++;
|
|
|
|
|
/*
|
|
|
|
|
* XXX we can't count seeks correctly but we can do better
|
|
|
|
|
* than this. E.g., assume that the geometry is correct
|
|
|
|
|
* and count 1 seek if the starting cylinder of this i/o
|
|
|
|
|
* differs from the starting cylinder of the previous i/o,
|
|
|
|
|
* or count 1 seek if the starting bn of this i/o doesn't
|
|
|
|
|
* immediately follow the ending bn of the previos i/o.
|
|
|
|
|
*/
|
|
|
|
|
dk_seek[du->dk_dkunit]++;
|
|
|
|
|
}
|
|
|
|
|
|
1993-06-12 14:58:17 +00:00
|
|
|
splx(s);
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
done:
|
1994-04-20 07:06:57 +00:00
|
|
|
s = splbio();
|
1993-06-12 14:58:17 +00:00
|
|
|
/* toss transfer, we're done early */
|
|
|
|
|
biodone(bp);
|
1994-04-20 07:06:57 +00:00
|
|
|
splx(s);
|
1993-06-12 14:58:17 +00:00
|
|
|
}
|
|
|
|
|
|
1995-04-14 22:31:58 +00:00
|
|
|
static void
|
|
|
|
|
wdstrategy1(struct buf *bp)
|
|
|
|
|
{
|
|
|
|
|
/*
|
|
|
|
|
* XXX - do something to make wdstrategy() but not this block while
|
|
|
|
|
* we're doing dsinit() and dsioctl().
|
|
|
|
|
*/
|
|
|
|
|
wdstrategy(bp);
|
|
|
|
|
}
|
|
|
|
|
|
1993-06-12 14:58:17 +00:00
|
|
|
/*
|
|
|
|
|
* Routine to queue a command to the controller. The unit's
|
|
|
|
|
* request is linked into the active list for the controller.
|
|
|
|
|
* If the controller is idle, the transfer is started.
|
|
|
|
|
*/
|
|
|
|
|
static void
|
|
|
|
|
wdustart(register struct disk *du)
|
|
|
|
|
{
|
1995-11-23 07:24:41 +00:00
|
|
|
register struct buf *bp;
|
1997-03-11 23:17:28 +00:00
|
|
|
#ifdef CMD640
|
|
|
|
|
int ctrlr = du->dk_ctrlr_cmd640;
|
|
|
|
|
#else
|
1994-02-01 05:55:21 +00:00
|
|
|
int ctrlr = du->dk_ctrlr;
|
1997-03-11 23:17:28 +00:00
|
|
|
#endif
|
1993-06-12 14:58:17 +00:00
|
|
|
|
|
|
|
|
/* unit already active? */
|
1995-11-23 07:24:41 +00:00
|
|
|
if (wdutab[du->dk_lunit].b_active)
|
1993-06-12 14:58:17 +00:00
|
|
|
return;
|
|
|
|
|
|
1995-11-23 07:24:41 +00:00
|
|
|
|
|
|
|
|
bp = drive_queue[du->dk_lunit].tqh_first;
|
|
|
|
|
if (bp == NULL) { /* yes, an assign */
|
1994-01-04 20:05:26 +00:00
|
|
|
return;
|
1995-11-23 07:24:41 +00:00
|
|
|
}
|
|
|
|
|
TAILQ_REMOVE( &drive_queue[du->dk_lunit], bp, b_act);
|
1993-06-12 14:58:17 +00:00
|
|
|
|
|
|
|
|
/* link onto controller queue */
|
1995-11-23 07:24:41 +00:00
|
|
|
TAILQ_INSERT_TAIL( &wdtab[ctrlr].controller_queue, bp, b_act);
|
1993-06-12 14:58:17 +00:00
|
|
|
|
|
|
|
|
/* mark the drive unit as busy */
|
1995-11-23 07:24:41 +00:00
|
|
|
wdutab[du->dk_lunit].b_active = 1;
|
1993-06-12 14:58:17 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Controller startup routine. This does the calculation, and starts
|
|
|
|
|
* a single-sector read or write operation. Called to start a transfer,
|
|
|
|
|
* or from the interrupt routine to continue a multi-sector transfer.
|
|
|
|
|
* RESTRICTIONS:
|
1994-01-04 20:05:26 +00:00
|
|
|
* 1. The transfer length must be an exact multiple of the sector size.
|
1993-06-12 14:58:17 +00:00
|
|
|
*/
|
|
|
|
|
|
1995-08-18 11:26:35 +00:00
|
|
|
void
|
1994-01-04 20:05:26 +00:00
|
|
|
wdstart(int ctrlr)
|
1993-06-12 14:58:17 +00:00
|
|
|
{
|
1994-02-01 05:55:21 +00:00
|
|
|
register struct disk *du;
|
1993-06-12 14:58:17 +00:00
|
|
|
register struct buf *bp;
|
1995-04-14 22:31:58 +00:00
|
|
|
struct diskgeom *lp; /* XXX sic */
|
|
|
|
|
long blknum;
|
1994-02-01 05:55:21 +00:00
|
|
|
long secpertrk, secpercyl;
|
|
|
|
|
int lunit;
|
1995-03-22 05:23:01 +00:00
|
|
|
int count;
|
1997-03-11 23:17:28 +00:00
|
|
|
#ifdef CMD640
|
|
|
|
|
int ctrlr_atapi;
|
|
|
|
|
|
|
|
|
|
if (eide_quirks & Q_CMD640B) {
|
|
|
|
|
ctrlr = PRIMARY;
|
|
|
|
|
ctrlr_atapi = atapictrlr;
|
|
|
|
|
} else {
|
|
|
|
|
ctrlr_atapi = ctrlr;
|
|
|
|
|
}
|
|
|
|
|
#endif
|
1993-06-12 14:58:17 +00:00
|
|
|
|
1995-09-30 15:19:44 +00:00
|
|
|
#ifdef ATAPI
|
1995-08-18 11:26:35 +00:00
|
|
|
if (wdtab[ctrlr].b_active == 2)
|
|
|
|
|
wdtab[ctrlr].b_active = 0;
|
|
|
|
|
if (wdtab[ctrlr].b_active)
|
|
|
|
|
return;
|
1995-09-30 15:19:44 +00:00
|
|
|
#endif
|
1993-06-12 14:58:17 +00:00
|
|
|
/* is there a drive for the controller to do a transfer with? */
|
1995-11-23 07:24:41 +00:00
|
|
|
bp = wdtab[ctrlr].controller_queue.tqh_first;
|
1995-08-18 11:26:35 +00:00
|
|
|
if (bp == NULL) {
|
|
|
|
|
#ifdef ATAPI
|
1997-03-11 23:17:28 +00:00
|
|
|
#ifdef CMD640
|
|
|
|
|
if (atapi_start && atapi_start (ctrlr_atapi))
|
|
|
|
|
wdtab[ctrlr].b_active = 3;
|
|
|
|
|
#else
|
Latest fixes from Serge:
I tried to solve the problem of IDE probing compatibility in this version.
When compiled without an ATAPI option, the wd driver is
fully backward compatible with 2.0.5. With ATAPI option,
the wdprobe becomes strictly weaker. That is, if wdprobe works
without ATAPI option, it will always work with it too.
Another problem was with the CD-ROM drive attached as a slave
in the IDE bus, where there is no master. All IDE CD-ROM
drives are shipped in slave configuration, and most users
just plug them in, never thinking about jumpers.
It works fine with ms-dos and ms-windows, and this
version of the driver supports it as well.
The eject op can now load disks. Just repeat it twice,
and the disk will be ejected and then loaded back.
The disc cannot be ejected if it is mounted.
Submitted by: Serge Vakulenko, <vak@cronyx.ru>
1995-10-14 15:41:10 +00:00
|
|
|
if (atapi_start && atapi_start (ctrlr))
|
1995-08-18 11:26:35 +00:00
|
|
|
/* mark controller active in ATAPI mode */
|
|
|
|
|
wdtab[ctrlr].b_active = 3;
|
1997-03-11 23:17:28 +00:00
|
|
|
#endif
|
1995-08-18 11:26:35 +00:00
|
|
|
#endif
|
1995-09-06 05:06:18 +00:00
|
|
|
return;
|
1995-08-18 11:26:35 +00:00
|
|
|
}
|
1993-06-12 14:58:17 +00:00
|
|
|
|
|
|
|
|
/* obtain controller and drive information */
|
1995-04-14 22:31:58 +00:00
|
|
|
lunit = dkunit(bp->b_dev);
|
1994-01-04 20:05:26 +00:00
|
|
|
du = wddrives[lunit];
|
1993-06-12 14:58:17 +00:00
|
|
|
|
|
|
|
|
/* if not really a transfer, do control operations specially */
|
|
|
|
|
if (du->dk_state < OPEN) {
|
1994-01-04 20:05:26 +00:00
|
|
|
if (du->dk_state != WANTOPEN)
|
|
|
|
|
printf("wd%d: wdstart: weird dk_state %d\n",
|
1994-02-01 05:55:21 +00:00
|
|
|
du->dk_lunit, du->dk_state);
|
1994-01-04 20:05:26 +00:00
|
|
|
if (wdcontrol(bp) != 0)
|
|
|
|
|
printf("wd%d: wdstart: wdcontrol returned nonzero, state = %d\n",
|
1994-02-01 05:55:21 +00:00
|
|
|
du->dk_lunit, du->dk_state);
|
1993-06-12 14:58:17 +00:00
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* calculate transfer details */
|
1994-04-20 07:06:57 +00:00
|
|
|
blknum = bp->b_pblkno + du->dk_skip;
|
1994-01-04 20:05:26 +00:00
|
|
|
#ifdef WDDEBUG
|
1993-06-12 14:58:17 +00:00
|
|
|
if (du->dk_skip == 0)
|
1994-01-04 20:05:26 +00:00
|
|
|
printf("wd%d: wdstart: %s %d@%d; map ", lunit,
|
1994-02-01 05:55:21 +00:00
|
|
|
(bp->b_flags & B_READ) ? "read" : "write",
|
|
|
|
|
bp->b_bcount, blknum);
|
1993-06-12 14:58:17 +00:00
|
|
|
else
|
1994-02-01 05:55:21 +00:00
|
|
|
printf(" %d)%x", du->dk_skip, inb(du->dk_port + wd_altsts));
|
1993-06-12 14:58:17 +00:00
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
lp = &du->dk_dd;
|
|
|
|
|
secpertrk = lp->d_nsectors;
|
|
|
|
|
secpercyl = lp->d_secpercyl;
|
|
|
|
|
|
1994-04-20 07:06:57 +00:00
|
|
|
if (du->dk_skip == 0) {
|
|
|
|
|
du->dk_bc = bp->b_bcount;
|
1994-10-16 05:02:37 +00:00
|
|
|
|
1994-08-08 13:53:55 +00:00
|
|
|
if (bp->b_flags & B_BAD
|
|
|
|
|
/*
|
|
|
|
|
* XXX handle large transfers inefficiently instead
|
|
|
|
|
* of crashing on them.
|
|
|
|
|
*/
|
|
|
|
|
|| howmany(du->dk_bc, DEV_BSIZE) > MAXTRANSFER)
|
1994-04-20 07:06:57 +00:00
|
|
|
du->dk_flags |= DKFL_SINGLE;
|
|
|
|
|
}
|
1994-01-04 20:05:26 +00:00
|
|
|
|
1995-04-14 22:31:58 +00:00
|
|
|
if (du->dk_flags & DKFL_SINGLE
|
|
|
|
|
&& dsgetbad(bp->b_dev, du->dk_slices) != NULL) {
|
|
|
|
|
/* XXX */
|
|
|
|
|
u_long ds_offset =
|
|
|
|
|
du->dk_slices->dss_slices[dkslice(bp->b_dev)].ds_offset;
|
1994-04-20 07:06:57 +00:00
|
|
|
|
1995-04-14 22:31:58 +00:00
|
|
|
blknum = transbad144(dsgetbad(bp->b_dev, du->dk_slices),
|
|
|
|
|
blknum - ds_offset) + ds_offset;
|
1993-06-12 14:58:17 +00:00
|
|
|
}
|
1995-04-14 22:31:58 +00:00
|
|
|
|
1994-02-01 05:55:21 +00:00
|
|
|
wdtab[ctrlr].b_active = 1; /* mark controller active */
|
1993-06-12 14:58:17 +00:00
|
|
|
|
|
|
|
|
/* if starting a multisector transfer, or doing single transfers */
|
|
|
|
|
if (du->dk_skip == 0 || (du->dk_flags & DKFL_SINGLE)) {
|
1994-02-01 05:55:21 +00:00
|
|
|
u_int command;
|
|
|
|
|
u_int count;
|
1995-04-14 22:31:58 +00:00
|
|
|
long cylin, head, sector;
|
1993-06-12 14:58:17 +00:00
|
|
|
|
1995-03-22 05:23:01 +00:00
|
|
|
cylin = blknum / secpercyl;
|
|
|
|
|
head = (blknum % secpercyl) / secpertrk;
|
|
|
|
|
sector = blknum % secpertrk;
|
|
|
|
|
|
1994-01-04 20:05:26 +00:00
|
|
|
if (wdtab[ctrlr].b_errcnt && (bp->b_flags & B_READ) == 0)
|
|
|
|
|
du->dk_bc += DEV_BSIZE;
|
1995-03-22 05:23:01 +00:00
|
|
|
count = howmany( du->dk_bc, DEV_BSIZE);
|
|
|
|
|
|
|
|
|
|
du->dk_flags &= ~DKFL_MULTI;
|
1993-09-07 02:08:51 +00:00
|
|
|
|
1994-02-01 05:55:21 +00:00
|
|
|
#ifdef B_FORMAT
|
1993-06-12 14:58:17 +00:00
|
|
|
if (bp->b_flags & B_FORMAT) {
|
1994-01-04 20:05:26 +00:00
|
|
|
command = WDCC_FORMAT;
|
|
|
|
|
count = lp->d_nsectors;
|
|
|
|
|
sector = lp->d_gap3 - 1; /* + 1 later */
|
|
|
|
|
} else
|
1993-06-12 14:58:17 +00:00
|
|
|
#endif
|
1995-03-22 05:23:01 +00:00
|
|
|
|
1994-01-04 20:05:26 +00:00
|
|
|
{
|
1995-03-22 05:23:01 +00:00
|
|
|
if (du->dk_flags & DKFL_SINGLE) {
|
|
|
|
|
command = (bp->b_flags & B_READ)
|
|
|
|
|
? WDCC_READ : WDCC_WRITE;
|
1994-02-01 05:55:21 +00:00
|
|
|
count = 1;
|
1995-03-22 05:23:01 +00:00
|
|
|
du->dk_currentiosize = 1;
|
|
|
|
|
} else {
|
Add support for busmaster DMA on some PCI IDE chipsets.
I changed a few bits here and there, mainly renaming wd82371.c
to ide_pci.c now that it's supposed to handle different chipsets.
It runs on my P6 natoma board with two Maxtor drives, and also
on a Fujitsu machine I have at work with an Opti chipset and
a Quantum drive.
Submitted by:cgull@smoke.marlboro.vt.us <John Hood>
Original readme:
*** WARNING ***
This code has so far been tested on exactly one motherboard with two
identical drives known for their good DMA support.
This code, in the right circumstances, could corrupt data subtly,
silently, and invisibly, in much the same way that older PCI IDE
controllers do. It's ALPHA-quality code; there's one or two major
gaps in my understanding of PCI IDE still. Don't use this code on any
system with data that you care about; it's only good for hack boxes.
Expect that any data may be silently and randomly corrupted at any
moment. It's a disk driver. It has bugs. Disk drivers with bugs
munch data. It's a fact of life.
I also *STRONGLY* recommend getting a copy of your chipset's manual
and the ATA-2 or ATA-3 spec and making sure that timing modes on your
disk drives and IDE controller are being setup correctly by the BIOS--
because the driver makes only the lamest of attempts to do this just
now.
*** END WARNING ***
that said, i happen to think the code is working pretty well...
WHAT IT DOES:
this code adds support to the wd driver for bus mastering PCI IDE
controllers that follow the SFF-8038 standard. (all the bus mastering
PCI IDE controllers i've seen so far do follow this standard.) it
should provide busmastering on nearly any current P5 or P6 chipset,
specifically including any Intel chipset using one of the PIIX south
bridges-- this includes the '430FX, '430VX, '430HX, '430TX, '440LX,
and (i think) the Orion '450GX chipsets. specific support is also
included for the VIA Apollo VP-1 chipset, as it appears in the
relabeled "HXPro" incarnation seen on cheap US$70 taiwanese
motherboards (that's what's in my development machine). it works out
of the box on controllers that do DMA mode2; if my understanding is
correct, it'll probably work on Ultra-DMA33 controllers as well.
it'll probably work on busmastering IDE controllers in PCI slots, too,
but this is an area i am less sure about.
it cuts CPU usage considerably and improves drive performance
slightly. usable numbers are difficult to come by with existing
benchmark tools, but experimentation on my K5-P90 system, with VIA
VP-1 chipset and Quantum Fireball 1080 drives, shows that disk i/o on
raw partitions imposes perhaps 5% cpu load. cpu load during
filesystem i/o drops a lot, from near 100% to anywhere between 30% and
70%. (the improvement may not be as large on an Intel chipset; from
what i can tell, the VIA VP-1 may not be very efficient with PCI I/O.)
disk performance improves by 5% or 10% with these drives.
real, visible, end-user performance improvement on a single user
machine is about nil. :) a kernel compile was sped up by a whole three
seconds. it *does* feel a bit better-behaved when the system is
swapping heavily, but a better disk driver is not the fix for *that*
problem.
THE CODE:
this code is a patch to wd.c and wd82371.c, and associated header
files. it should be considered alpha code; more work needs to be
done.
wd.c has fairly clean patches to add calls to busmaster code, as
implemented in wd82371.c and potentially elsewhere (one could imagine,
say, a Mac having a different DMA controller).
wd82371.c has been considerably reworked: the wddma interface that it
presents has been changed (expect more changes), many bugs have been
fixed, a new internal interface has been added for supporting
different chipsets, and the PCI probe has been considerably extended.
the interface between wd82371.c and wd.c is still fairly clean, but
i'm not sure it's in the right place. there's a mess of issues around
ATA/ATAPI that need to be sorted out, including ATAPI support, CD-ROM
support, tape support, LS-120/Zip support, SFF-8038i DMA, UltraDMA,
PCI IDE controllers, bus probes, buggy controllers, controller timing
setup, drive timing setup, world peace and kitchen sinks. whatever
happens with all this and however it gets partitioned, it is fairly
clear that wd.c needs some significant rework-- probably a complete
rewrite.
timing setup on disk controllers is something i've entirely punted on.
on my development machine, it appears that the BIOS does at least some
of the necessary timing setup. i chose to restrict operation to
drives that are already configured for Mode4 PIO and Mode2 multiword
DMA, since the timing is essentially the same and many if not most
chipsets use the same control registers for DMA and PIO timing.
does anybody *know* whether BIOSes are required to do timing setup for
DMA modes on drives under their care?
error recovery is probably weak. early on in development, i was
getting drive errors induced by bugs in the driver; i used these to
flush out the worst of the bugs in the driver's error handling, but
problems may remain. i haven't got a drive with bad sectors i can
watch the driver flail on.
complaints about how wd82371.c has been reindented will be ignored
until the FreeBSD project has a real style policy, there is a
mechanism for individual authors to match it (indent flags or an emacs
c-mode or whatever), and it is enforced. if i'm going to use a source
style i don't like, it would help if i could figure out what it *is*
(style(9) is about half of a policy), and a way to reasonably
duplicate it. i ended up wasting a while trying to figure out what
the right thing to do was before deciding reformatting the whole thing
was the worst possible thing to do, except for all the other
possibilities.
i have maintained wd.c's indentation; that was not too hard,
fortunately.
TO INSTALL:
my dev box is freebsd 2.2.2 release. fortunately, wd.c is a living
fossil, and has diverged very little recently. included in this
tarball is a patch file, 'otherdiffs', for all files except wd82371.c,
my edited wd82371.c, a patch file, 'wd82371.c-diff-exact', against the
2.2.2 dist of 82371.c, and another patch file,
'wd82371.c-diff-whitespace', generated with diff -b (ignore
whitespace). most of you not using 2.2.2 will probably have to use
this last patchfile with 'patch --ignore-whitespace'. apply from the
kernel source tree root. as far as i can tell, this should apply
cleanly on anything from -current back to 2.2.2 and probably back to
2.2.0. you, the kernel hacker, can figure out what to do from here.
if you need more specific directions, you probably should not be
experimenting with this code yet.
to enable DMA support, set flag 0x2000 for that drive in your config
file or in userconfig, as you would the 32-bit-PIO flag. the driver
will then turn on DMA support if your drive and controller pass its
tests. it's a bit picky, probably. on discovering DMA mode failures
or disk errors or transfers that the DMA controller can't deal with,
the driver will fall back to PIO, so it is wise to setup the flags as
if PIO were still important.
'controller wdc0 at isa? port "IO_WD1" bio irq 14 flags 0xa0ffa0ff
vector wdintr' should work with nearly any PCI IDE controller.
i would *strongly* suggest booting single-user at first, and thrashing
the drive a bit while it's still mounted read-only. this should be
fairly safe, even if the driver goes completely out to lunch. it
might save you a reinstall.
one way to tell whether the driver is really using DMA is to check the
interrupt count during disk i/o with vmstat; DMA mode will add an
extremely low number of interrupts, as compared to even multi-sector
PIO.
boot -v will give you a copious register dump of timing-related info
on Intel and VIAtech chipsets, as well as PIO/DMA mode information on
all hard drives. refer to your ATA and chipset documentation to
interpret these.
WHAT I'D LIKE FROM YOU and THINGS TO TEST:
reports. success reports, failure reports, any kind of reports. :)
send them to cgull+ide@smoke.marlboro.vt.us.
i'd also like to see the kernel messages from various BIOSes (boot -v;
dmesg), along with info on the motherboard and BIOS on that machine.
i'm especially interested in reports on how this code works on the
various Intel chipsets, and whether the register dump works
correctly. i'm also interested in hearing about other chipsets.
i'm especially interested in hearing success/failure reports for PCI
IDE controllers on cards, such as CMD's or Promise's new busmastering
IDE controllers.
UltraDMA-33 reports.
interoperation with ATAPI peripherals-- FreeBSD doesn't work with my
old Hitachi IDE CDROM, so i can't tell if I've broken anything. :)
i'd especially like to hear how the drive copes in DMA operation on
drives with bad sectors. i haven't been able to find any such yet.
success/failure reports on older IDE drives with early support for DMA
modes-- those introduced between 1.5 and 3 years ago, typically
ranging from perhaps 400MB to 1.6GB.
failure reports on operation with more than one drive would be
appreciated. the driver was developed with two drives on one
controller, the worst-case situation, and has been tested with one
drive on each controller, but you never know...
any reports of messages from the driver during normal operation,
especially "reverting to PIO mode", or "dmaverify odd vaddr or length"
(the DMA controller is strongly halfword oriented, and i'm curious to
know if any FreeBSD usage actually needs misaligned transfers).
performance reports. beware that bonnie's CPU usage reporting is
useless for IDE drives; the best test i've found has been to run a
program that runs a spin loop at an idle priority and reports how many
iterations it manages, and even that sometimes produces numbers i
don't believe. performance reports of multi-drive operation are
especially interesting; my system cannot sustain full throughput on
two drives on separate controllers, but that may just be a lame
motherboard.
THINGS I'M STILL MISSING CLUE ON:
* who's responsible for configuring DMA timing modes on IDE drives?
the BIOS or the driver?
* is there a spec for dealing with Ultra-DMA extensions?
* are there any chipsets or with bugs relating to DMA transfer that
should be blacklisted?
* are there any ATA interfaces that use some other kind of DMA
controller in conjunction with standard ATA protocol?
FINAL NOTE:
after having looked at the ATA-3 spec, all i can say is, "it's ugly".
*especially* electrically. the IDE bus is best modeled as an
unterminated transmission line, these days.
for maximum reliability, keep your IDE cables as short as possible and
as few as possible. from what i can tell, most current chipsets have
both IDE ports wired into a single buss, to a greater or lesser
degree. using two cables means you double the length of this bus.
SCSI may have its warts, but at least the basic analog design of the
bus is still somewhat reasonable. IDE passed beyond the veil two
years ago.
--John Hood, cgull@smoke.marlboro.vt.us
1997-07-29 12:57:25 +00:00
|
|
|
if((du->dk_flags & DKFL_USEDMA) &&
|
|
|
|
|
wddma.wdd_dmaverify(du->dk_dmacookie,
|
|
|
|
|
(void *)((int)bp->b_un.b_addr +
|
|
|
|
|
du->dk_skip * DEV_BSIZE),
|
|
|
|
|
du->dk_bc,
|
|
|
|
|
bp->b_flags & B_READ)) {
|
|
|
|
|
du->dk_flags |= DKFL_DMA;
|
|
|
|
|
if( bp->b_flags & B_READ)
|
|
|
|
|
command = WDCC_READ_DMA;
|
|
|
|
|
else
|
|
|
|
|
command = WDCC_WRITE_DMA;
|
|
|
|
|
du->dk_currentiosize = count;
|
|
|
|
|
} else if( (count > 1) && (du->dk_multi > 1)) {
|
1995-03-22 05:23:01 +00:00
|
|
|
du->dk_flags |= DKFL_MULTI;
|
|
|
|
|
if( bp->b_flags & B_READ) {
|
|
|
|
|
command = WDCC_READ_MULTI;
|
|
|
|
|
} else {
|
|
|
|
|
command = WDCC_WRITE_MULTI;
|
|
|
|
|
}
|
|
|
|
|
du->dk_currentiosize = du->dk_multi;
|
|
|
|
|
if( du->dk_currentiosize > count)
|
|
|
|
|
du->dk_currentiosize = count;
|
|
|
|
|
} else {
|
|
|
|
|
if( bp->b_flags & B_READ) {
|
|
|
|
|
command = WDCC_READ;
|
|
|
|
|
} else {
|
|
|
|
|
command = WDCC_WRITE;
|
|
|
|
|
}
|
|
|
|
|
du->dk_currentiosize = 1;
|
|
|
|
|
}
|
|
|
|
|
}
|
1993-06-12 14:58:17 +00:00
|
|
|
}
|
1993-09-07 02:08:51 +00:00
|
|
|
|
1994-01-04 20:05:26 +00:00
|
|
|
/*
|
|
|
|
|
* XXX this loop may never terminate. The code to handle
|
1994-02-01 05:55:21 +00:00
|
|
|
* counting down of retries and eventually failing the i/o
|
|
|
|
|
* is in wdintr() and we can't get there from here.
|
1994-01-04 20:05:26 +00:00
|
|
|
*/
|
|
|
|
|
if (wdtest != 0) {
|
|
|
|
|
if (--wdtest == 0) {
|
|
|
|
|
wdtest = 100;
|
|
|
|
|
printf("dummy wdunwedge\n");
|
|
|
|
|
wdunwedge(du);
|
|
|
|
|
}
|
|
|
|
|
}
|
1994-10-16 03:50:36 +00:00
|
|
|
if(du->dk_dkunit >= 0) {
|
|
|
|
|
dk_busy |= 1 << du->dk_dkunit;
|
|
|
|
|
}
|
Add support for busmaster DMA on some PCI IDE chipsets.
I changed a few bits here and there, mainly renaming wd82371.c
to ide_pci.c now that it's supposed to handle different chipsets.
It runs on my P6 natoma board with two Maxtor drives, and also
on a Fujitsu machine I have at work with an Opti chipset and
a Quantum drive.
Submitted by:cgull@smoke.marlboro.vt.us <John Hood>
Original readme:
*** WARNING ***
This code has so far been tested on exactly one motherboard with two
identical drives known for their good DMA support.
This code, in the right circumstances, could corrupt data subtly,
silently, and invisibly, in much the same way that older PCI IDE
controllers do. It's ALPHA-quality code; there's one or two major
gaps in my understanding of PCI IDE still. Don't use this code on any
system with data that you care about; it's only good for hack boxes.
Expect that any data may be silently and randomly corrupted at any
moment. It's a disk driver. It has bugs. Disk drivers with bugs
munch data. It's a fact of life.
I also *STRONGLY* recommend getting a copy of your chipset's manual
and the ATA-2 or ATA-3 spec and making sure that timing modes on your
disk drives and IDE controller are being setup correctly by the BIOS--
because the driver makes only the lamest of attempts to do this just
now.
*** END WARNING ***
that said, i happen to think the code is working pretty well...
WHAT IT DOES:
this code adds support to the wd driver for bus mastering PCI IDE
controllers that follow the SFF-8038 standard. (all the bus mastering
PCI IDE controllers i've seen so far do follow this standard.) it
should provide busmastering on nearly any current P5 or P6 chipset,
specifically including any Intel chipset using one of the PIIX south
bridges-- this includes the '430FX, '430VX, '430HX, '430TX, '440LX,
and (i think) the Orion '450GX chipsets. specific support is also
included for the VIA Apollo VP-1 chipset, as it appears in the
relabeled "HXPro" incarnation seen on cheap US$70 taiwanese
motherboards (that's what's in my development machine). it works out
of the box on controllers that do DMA mode2; if my understanding is
correct, it'll probably work on Ultra-DMA33 controllers as well.
it'll probably work on busmastering IDE controllers in PCI slots, too,
but this is an area i am less sure about.
it cuts CPU usage considerably and improves drive performance
slightly. usable numbers are difficult to come by with existing
benchmark tools, but experimentation on my K5-P90 system, with VIA
VP-1 chipset and Quantum Fireball 1080 drives, shows that disk i/o on
raw partitions imposes perhaps 5% cpu load. cpu load during
filesystem i/o drops a lot, from near 100% to anywhere between 30% and
70%. (the improvement may not be as large on an Intel chipset; from
what i can tell, the VIA VP-1 may not be very efficient with PCI I/O.)
disk performance improves by 5% or 10% with these drives.
real, visible, end-user performance improvement on a single user
machine is about nil. :) a kernel compile was sped up by a whole three
seconds. it *does* feel a bit better-behaved when the system is
swapping heavily, but a better disk driver is not the fix for *that*
problem.
THE CODE:
this code is a patch to wd.c and wd82371.c, and associated header
files. it should be considered alpha code; more work needs to be
done.
wd.c has fairly clean patches to add calls to busmaster code, as
implemented in wd82371.c and potentially elsewhere (one could imagine,
say, a Mac having a different DMA controller).
wd82371.c has been considerably reworked: the wddma interface that it
presents has been changed (expect more changes), many bugs have been
fixed, a new internal interface has been added for supporting
different chipsets, and the PCI probe has been considerably extended.
the interface between wd82371.c and wd.c is still fairly clean, but
i'm not sure it's in the right place. there's a mess of issues around
ATA/ATAPI that need to be sorted out, including ATAPI support, CD-ROM
support, tape support, LS-120/Zip support, SFF-8038i DMA, UltraDMA,
PCI IDE controllers, bus probes, buggy controllers, controller timing
setup, drive timing setup, world peace and kitchen sinks. whatever
happens with all this and however it gets partitioned, it is fairly
clear that wd.c needs some significant rework-- probably a complete
rewrite.
timing setup on disk controllers is something i've entirely punted on.
on my development machine, it appears that the BIOS does at least some
of the necessary timing setup. i chose to restrict operation to
drives that are already configured for Mode4 PIO and Mode2 multiword
DMA, since the timing is essentially the same and many if not most
chipsets use the same control registers for DMA and PIO timing.
does anybody *know* whether BIOSes are required to do timing setup for
DMA modes on drives under their care?
error recovery is probably weak. early on in development, i was
getting drive errors induced by bugs in the driver; i used these to
flush out the worst of the bugs in the driver's error handling, but
problems may remain. i haven't got a drive with bad sectors i can
watch the driver flail on.
complaints about how wd82371.c has been reindented will be ignored
until the FreeBSD project has a real style policy, there is a
mechanism for individual authors to match it (indent flags or an emacs
c-mode or whatever), and it is enforced. if i'm going to use a source
style i don't like, it would help if i could figure out what it *is*
(style(9) is about half of a policy), and a way to reasonably
duplicate it. i ended up wasting a while trying to figure out what
the right thing to do was before deciding reformatting the whole thing
was the worst possible thing to do, except for all the other
possibilities.
i have maintained wd.c's indentation; that was not too hard,
fortunately.
TO INSTALL:
my dev box is freebsd 2.2.2 release. fortunately, wd.c is a living
fossil, and has diverged very little recently. included in this
tarball is a patch file, 'otherdiffs', for all files except wd82371.c,
my edited wd82371.c, a patch file, 'wd82371.c-diff-exact', against the
2.2.2 dist of 82371.c, and another patch file,
'wd82371.c-diff-whitespace', generated with diff -b (ignore
whitespace). most of you not using 2.2.2 will probably have to use
this last patchfile with 'patch --ignore-whitespace'. apply from the
kernel source tree root. as far as i can tell, this should apply
cleanly on anything from -current back to 2.2.2 and probably back to
2.2.0. you, the kernel hacker, can figure out what to do from here.
if you need more specific directions, you probably should not be
experimenting with this code yet.
to enable DMA support, set flag 0x2000 for that drive in your config
file or in userconfig, as you would the 32-bit-PIO flag. the driver
will then turn on DMA support if your drive and controller pass its
tests. it's a bit picky, probably. on discovering DMA mode failures
or disk errors or transfers that the DMA controller can't deal with,
the driver will fall back to PIO, so it is wise to setup the flags as
if PIO were still important.
'controller wdc0 at isa? port "IO_WD1" bio irq 14 flags 0xa0ffa0ff
vector wdintr' should work with nearly any PCI IDE controller.
i would *strongly* suggest booting single-user at first, and thrashing
the drive a bit while it's still mounted read-only. this should be
fairly safe, even if the driver goes completely out to lunch. it
might save you a reinstall.
one way to tell whether the driver is really using DMA is to check the
interrupt count during disk i/o with vmstat; DMA mode will add an
extremely low number of interrupts, as compared to even multi-sector
PIO.
boot -v will give you a copious register dump of timing-related info
on Intel and VIAtech chipsets, as well as PIO/DMA mode information on
all hard drives. refer to your ATA and chipset documentation to
interpret these.
WHAT I'D LIKE FROM YOU and THINGS TO TEST:
reports. success reports, failure reports, any kind of reports. :)
send them to cgull+ide@smoke.marlboro.vt.us.
i'd also like to see the kernel messages from various BIOSes (boot -v;
dmesg), along with info on the motherboard and BIOS on that machine.
i'm especially interested in reports on how this code works on the
various Intel chipsets, and whether the register dump works
correctly. i'm also interested in hearing about other chipsets.
i'm especially interested in hearing success/failure reports for PCI
IDE controllers on cards, such as CMD's or Promise's new busmastering
IDE controllers.
UltraDMA-33 reports.
interoperation with ATAPI peripherals-- FreeBSD doesn't work with my
old Hitachi IDE CDROM, so i can't tell if I've broken anything. :)
i'd especially like to hear how the drive copes in DMA operation on
drives with bad sectors. i haven't been able to find any such yet.
success/failure reports on older IDE drives with early support for DMA
modes-- those introduced between 1.5 and 3 years ago, typically
ranging from perhaps 400MB to 1.6GB.
failure reports on operation with more than one drive would be
appreciated. the driver was developed with two drives on one
controller, the worst-case situation, and has been tested with one
drive on each controller, but you never know...
any reports of messages from the driver during normal operation,
especially "reverting to PIO mode", or "dmaverify odd vaddr or length"
(the DMA controller is strongly halfword oriented, and i'm curious to
know if any FreeBSD usage actually needs misaligned transfers).
performance reports. beware that bonnie's CPU usage reporting is
useless for IDE drives; the best test i've found has been to run a
program that runs a spin loop at an idle priority and reports how many
iterations it manages, and even that sometimes produces numbers i
don't believe. performance reports of multi-drive operation are
especially interesting; my system cannot sustain full throughput on
two drives on separate controllers, but that may just be a lame
motherboard.
THINGS I'M STILL MISSING CLUE ON:
* who's responsible for configuring DMA timing modes on IDE drives?
the BIOS or the driver?
* is there a spec for dealing with Ultra-DMA extensions?
* are there any chipsets or with bugs relating to DMA transfer that
should be blacklisted?
* are there any ATA interfaces that use some other kind of DMA
controller in conjunction with standard ATA protocol?
FINAL NOTE:
after having looked at the ATA-3 spec, all i can say is, "it's ugly".
*especially* electrically. the IDE bus is best modeled as an
unterminated transmission line, these days.
for maximum reliability, keep your IDE cables as short as possible and
as few as possible. from what i can tell, most current chipsets have
both IDE ports wired into a single buss, to a greater or lesser
degree. using two cables means you double the length of this bus.
SCSI may have its warts, but at least the basic analog design of the
bus is still somewhat reasonable. IDE passed beyond the veil two
years ago.
--John Hood, cgull@smoke.marlboro.vt.us
1997-07-29 12:57:25 +00:00
|
|
|
|
|
|
|
|
if ((du->dk_flags & (DKFL_DMA|DKFL_SINGLE)) == DKFL_DMA) {
|
|
|
|
|
wddma.wdd_dmaprep(du->dk_dmacookie,
|
|
|
|
|
(void *)((int)bp->b_un.b_addr +
|
|
|
|
|
du->dk_skip * DEV_BSIZE),
|
|
|
|
|
du->dk_bc,
|
|
|
|
|
bp->b_flags & B_READ);
|
|
|
|
|
}
|
1994-02-01 05:55:21 +00:00
|
|
|
while (wdcommand(du, cylin, head, sector, count, command)
|
|
|
|
|
!= 0) {
|
1994-01-04 20:05:26 +00:00
|
|
|
wderror(bp, du,
|
1994-02-01 05:55:21 +00:00
|
|
|
"wdstart: timeout waiting to give command");
|
1994-01-04 20:05:26 +00:00
|
|
|
wdunwedge(du);
|
1993-09-05 13:46:17 +00:00
|
|
|
}
|
1994-02-01 05:55:21 +00:00
|
|
|
#ifdef WDDEBUG
|
|
|
|
|
printf("cylin %ld head %ld sector %ld addr %x sts %x\n",
|
|
|
|
|
cylin, head, sector,
|
|
|
|
|
(int)bp->b_un.b_addr + du->dk_skip * DEV_BSIZE,
|
|
|
|
|
inb(du->dk_port + wd_altsts));
|
1993-06-12 14:58:17 +00:00
|
|
|
#endif
|
|
|
|
|
}
|
|
|
|
|
|
1994-02-01 05:55:21 +00:00
|
|
|
/*
|
|
|
|
|
* Schedule wdtimeout() to wake up after a few seconds. Retrying
|
|
|
|
|
* unmarked bad blocks can take 3 seconds! Then it is not good that
|
|
|
|
|
* we retry 5 times.
|
|
|
|
|
*
|
|
|
|
|
* XXX wdtimeout() doesn't increment the error count so we may loop
|
|
|
|
|
* forever. More seriously, the loop isn't forever but causes a
|
|
|
|
|
* crash.
|
|
|
|
|
*
|
|
|
|
|
* TODO fix b_resid bug elsewhere (fd.c....). Fix short but positive
|
|
|
|
|
* counts being discarded after there is an error (in physio I
|
|
|
|
|
* think). Discarding them would be OK if the (special) file offset
|
|
|
|
|
* was not advanced.
|
|
|
|
|
*/
|
1994-03-04 16:43:07 +00:00
|
|
|
du->dk_timeout = 1 + 3;
|
1994-02-01 05:55:21 +00:00
|
|
|
|
Add support for busmaster DMA on some PCI IDE chipsets.
I changed a few bits here and there, mainly renaming wd82371.c
to ide_pci.c now that it's supposed to handle different chipsets.
It runs on my P6 natoma board with two Maxtor drives, and also
on a Fujitsu machine I have at work with an Opti chipset and
a Quantum drive.
Submitted by:cgull@smoke.marlboro.vt.us <John Hood>
Original readme:
*** WARNING ***
This code has so far been tested on exactly one motherboard with two
identical drives known for their good DMA support.
This code, in the right circumstances, could corrupt data subtly,
silently, and invisibly, in much the same way that older PCI IDE
controllers do. It's ALPHA-quality code; there's one or two major
gaps in my understanding of PCI IDE still. Don't use this code on any
system with data that you care about; it's only good for hack boxes.
Expect that any data may be silently and randomly corrupted at any
moment. It's a disk driver. It has bugs. Disk drivers with bugs
munch data. It's a fact of life.
I also *STRONGLY* recommend getting a copy of your chipset's manual
and the ATA-2 or ATA-3 spec and making sure that timing modes on your
disk drives and IDE controller are being setup correctly by the BIOS--
because the driver makes only the lamest of attempts to do this just
now.
*** END WARNING ***
that said, i happen to think the code is working pretty well...
WHAT IT DOES:
this code adds support to the wd driver for bus mastering PCI IDE
controllers that follow the SFF-8038 standard. (all the bus mastering
PCI IDE controllers i've seen so far do follow this standard.) it
should provide busmastering on nearly any current P5 or P6 chipset,
specifically including any Intel chipset using one of the PIIX south
bridges-- this includes the '430FX, '430VX, '430HX, '430TX, '440LX,
and (i think) the Orion '450GX chipsets. specific support is also
included for the VIA Apollo VP-1 chipset, as it appears in the
relabeled "HXPro" incarnation seen on cheap US$70 taiwanese
motherboards (that's what's in my development machine). it works out
of the box on controllers that do DMA mode2; if my understanding is
correct, it'll probably work on Ultra-DMA33 controllers as well.
it'll probably work on busmastering IDE controllers in PCI slots, too,
but this is an area i am less sure about.
it cuts CPU usage considerably and improves drive performance
slightly. usable numbers are difficult to come by with existing
benchmark tools, but experimentation on my K5-P90 system, with VIA
VP-1 chipset and Quantum Fireball 1080 drives, shows that disk i/o on
raw partitions imposes perhaps 5% cpu load. cpu load during
filesystem i/o drops a lot, from near 100% to anywhere between 30% and
70%. (the improvement may not be as large on an Intel chipset; from
what i can tell, the VIA VP-1 may not be very efficient with PCI I/O.)
disk performance improves by 5% or 10% with these drives.
real, visible, end-user performance improvement on a single user
machine is about nil. :) a kernel compile was sped up by a whole three
seconds. it *does* feel a bit better-behaved when the system is
swapping heavily, but a better disk driver is not the fix for *that*
problem.
THE CODE:
this code is a patch to wd.c and wd82371.c, and associated header
files. it should be considered alpha code; more work needs to be
done.
wd.c has fairly clean patches to add calls to busmaster code, as
implemented in wd82371.c and potentially elsewhere (one could imagine,
say, a Mac having a different DMA controller).
wd82371.c has been considerably reworked: the wddma interface that it
presents has been changed (expect more changes), many bugs have been
fixed, a new internal interface has been added for supporting
different chipsets, and the PCI probe has been considerably extended.
the interface between wd82371.c and wd.c is still fairly clean, but
i'm not sure it's in the right place. there's a mess of issues around
ATA/ATAPI that need to be sorted out, including ATAPI support, CD-ROM
support, tape support, LS-120/Zip support, SFF-8038i DMA, UltraDMA,
PCI IDE controllers, bus probes, buggy controllers, controller timing
setup, drive timing setup, world peace and kitchen sinks. whatever
happens with all this and however it gets partitioned, it is fairly
clear that wd.c needs some significant rework-- probably a complete
rewrite.
timing setup on disk controllers is something i've entirely punted on.
on my development machine, it appears that the BIOS does at least some
of the necessary timing setup. i chose to restrict operation to
drives that are already configured for Mode4 PIO and Mode2 multiword
DMA, since the timing is essentially the same and many if not most
chipsets use the same control registers for DMA and PIO timing.
does anybody *know* whether BIOSes are required to do timing setup for
DMA modes on drives under their care?
error recovery is probably weak. early on in development, i was
getting drive errors induced by bugs in the driver; i used these to
flush out the worst of the bugs in the driver's error handling, but
problems may remain. i haven't got a drive with bad sectors i can
watch the driver flail on.
complaints about how wd82371.c has been reindented will be ignored
until the FreeBSD project has a real style policy, there is a
mechanism for individual authors to match it (indent flags or an emacs
c-mode or whatever), and it is enforced. if i'm going to use a source
style i don't like, it would help if i could figure out what it *is*
(style(9) is about half of a policy), and a way to reasonably
duplicate it. i ended up wasting a while trying to figure out what
the right thing to do was before deciding reformatting the whole thing
was the worst possible thing to do, except for all the other
possibilities.
i have maintained wd.c's indentation; that was not too hard,
fortunately.
TO INSTALL:
my dev box is freebsd 2.2.2 release. fortunately, wd.c is a living
fossil, and has diverged very little recently. included in this
tarball is a patch file, 'otherdiffs', for all files except wd82371.c,
my edited wd82371.c, a patch file, 'wd82371.c-diff-exact', against the
2.2.2 dist of 82371.c, and another patch file,
'wd82371.c-diff-whitespace', generated with diff -b (ignore
whitespace). most of you not using 2.2.2 will probably have to use
this last patchfile with 'patch --ignore-whitespace'. apply from the
kernel source tree root. as far as i can tell, this should apply
cleanly on anything from -current back to 2.2.2 and probably back to
2.2.0. you, the kernel hacker, can figure out what to do from here.
if you need more specific directions, you probably should not be
experimenting with this code yet.
to enable DMA support, set flag 0x2000 for that drive in your config
file or in userconfig, as you would the 32-bit-PIO flag. the driver
will then turn on DMA support if your drive and controller pass its
tests. it's a bit picky, probably. on discovering DMA mode failures
or disk errors or transfers that the DMA controller can't deal with,
the driver will fall back to PIO, so it is wise to setup the flags as
if PIO were still important.
'controller wdc0 at isa? port "IO_WD1" bio irq 14 flags 0xa0ffa0ff
vector wdintr' should work with nearly any PCI IDE controller.
i would *strongly* suggest booting single-user at first, and thrashing
the drive a bit while it's still mounted read-only. this should be
fairly safe, even if the driver goes completely out to lunch. it
might save you a reinstall.
one way to tell whether the driver is really using DMA is to check the
interrupt count during disk i/o with vmstat; DMA mode will add an
extremely low number of interrupts, as compared to even multi-sector
PIO.
boot -v will give you a copious register dump of timing-related info
on Intel and VIAtech chipsets, as well as PIO/DMA mode information on
all hard drives. refer to your ATA and chipset documentation to
interpret these.
WHAT I'D LIKE FROM YOU and THINGS TO TEST:
reports. success reports, failure reports, any kind of reports. :)
send them to cgull+ide@smoke.marlboro.vt.us.
i'd also like to see the kernel messages from various BIOSes (boot -v;
dmesg), along with info on the motherboard and BIOS on that machine.
i'm especially interested in reports on how this code works on the
various Intel chipsets, and whether the register dump works
correctly. i'm also interested in hearing about other chipsets.
i'm especially interested in hearing success/failure reports for PCI
IDE controllers on cards, such as CMD's or Promise's new busmastering
IDE controllers.
UltraDMA-33 reports.
interoperation with ATAPI peripherals-- FreeBSD doesn't work with my
old Hitachi IDE CDROM, so i can't tell if I've broken anything. :)
i'd especially like to hear how the drive copes in DMA operation on
drives with bad sectors. i haven't been able to find any such yet.
success/failure reports on older IDE drives with early support for DMA
modes-- those introduced between 1.5 and 3 years ago, typically
ranging from perhaps 400MB to 1.6GB.
failure reports on operation with more than one drive would be
appreciated. the driver was developed with two drives on one
controller, the worst-case situation, and has been tested with one
drive on each controller, but you never know...
any reports of messages from the driver during normal operation,
especially "reverting to PIO mode", or "dmaverify odd vaddr or length"
(the DMA controller is strongly halfword oriented, and i'm curious to
know if any FreeBSD usage actually needs misaligned transfers).
performance reports. beware that bonnie's CPU usage reporting is
useless for IDE drives; the best test i've found has been to run a
program that runs a spin loop at an idle priority and reports how many
iterations it manages, and even that sometimes produces numbers i
don't believe. performance reports of multi-drive operation are
especially interesting; my system cannot sustain full throughput on
two drives on separate controllers, but that may just be a lame
motherboard.
THINGS I'M STILL MISSING CLUE ON:
* who's responsible for configuring DMA timing modes on IDE drives?
the BIOS or the driver?
* is there a spec for dealing with Ultra-DMA extensions?
* are there any chipsets or with bugs relating to DMA transfer that
should be blacklisted?
* are there any ATA interfaces that use some other kind of DMA
controller in conjunction with standard ATA protocol?
FINAL NOTE:
after having looked at the ATA-3 spec, all i can say is, "it's ugly".
*especially* electrically. the IDE bus is best modeled as an
unterminated transmission line, these days.
for maximum reliability, keep your IDE cables as short as possible and
as few as possible. from what i can tell, most current chipsets have
both IDE ports wired into a single buss, to a greater or lesser
degree. using two cables means you double the length of this bus.
SCSI may have its warts, but at least the basic analog design of the
bus is still somewhat reasonable. IDE passed beyond the veil two
years ago.
--John Hood, cgull@smoke.marlboro.vt.us
1997-07-29 12:57:25 +00:00
|
|
|
/* if this is a DMA op, start DMA and go away until it's done. */
|
|
|
|
|
if ((du->dk_flags & (DKFL_DMA|DKFL_SINGLE)) == DKFL_DMA) {
|
|
|
|
|
wddma.wdd_dmastart(du->dk_dmacookie);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
1994-02-01 05:55:21 +00:00
|
|
|
/* If this is a read operation, just go away until it's done. */
|
|
|
|
|
if (bp->b_flags & B_READ)
|
|
|
|
|
return;
|
1993-06-12 14:58:17 +00:00
|
|
|
|
1994-02-01 05:55:21 +00:00
|
|
|
/* Ready to send data? */
|
1994-02-11 12:02:35 +00:00
|
|
|
if (wdwait(du, WDCS_READY | WDCS_SEEKCMPLT | WDCS_DRQ, TIMEOUT) < 0) {
|
1994-01-04 20:05:26 +00:00
|
|
|
wderror(bp, du, "wdstart: timeout waiting for DRQ");
|
|
|
|
|
/*
|
|
|
|
|
* XXX what do we do now? If we've just issued the command,
|
|
|
|
|
* then we can treat this failure the same as a command
|
|
|
|
|
* failure. But if we are continuing a multi-sector write,
|
|
|
|
|
* the command was issued ages ago, so we can't simply
|
|
|
|
|
* restart it.
|
|
|
|
|
*
|
1994-02-01 05:55:21 +00:00
|
|
|
* XXX we waste a lot of time unnecessarily translating block
|
|
|
|
|
* numbers to cylin/head/sector for continued i/o's.
|
1994-01-04 20:05:26 +00:00
|
|
|
*/
|
1993-06-12 14:58:17 +00:00
|
|
|
}
|
|
|
|
|
|
1995-03-22 05:23:01 +00:00
|
|
|
count = 1;
|
|
|
|
|
if( du->dk_flags & DKFL_MULTI) {
|
|
|
|
|
count = howmany(du->dk_bc, DEV_BSIZE);
|
|
|
|
|
if( count > du->dk_multi)
|
|
|
|
|
count = du->dk_multi;
|
|
|
|
|
if( du->dk_currentiosize > count)
|
|
|
|
|
du->dk_currentiosize = count;
|
|
|
|
|
}
|
1995-04-24 05:09:53 +00:00
|
|
|
|
1995-02-04 19:39:36 +00:00
|
|
|
if (du->dk_flags & DKFL_32BIT)
|
|
|
|
|
outsl(du->dk_port + wd_data,
|
|
|
|
|
(void *)((int)bp->b_un.b_addr + du->dk_skip * DEV_BSIZE),
|
1995-03-22 05:23:01 +00:00
|
|
|
(count * DEV_BSIZE) / sizeof(long));
|
1995-02-04 19:39:36 +00:00
|
|
|
else
|
|
|
|
|
outsw(du->dk_port + wd_data,
|
|
|
|
|
(void *)((int)bp->b_un.b_addr + du->dk_skip * DEV_BSIZE),
|
1995-03-22 05:23:01 +00:00
|
|
|
(count * DEV_BSIZE) / sizeof(short));
|
|
|
|
|
du->dk_bc -= DEV_BSIZE * count;
|
1995-04-14 22:31:58 +00:00
|
|
|
if (du->dk_dkunit >= 0) {
|
|
|
|
|
/*
|
|
|
|
|
* `wd's are blocks of 32 16-bit `word's according to
|
|
|
|
|
* iostat. dk_wds[] is the one disk i/o statistic that
|
|
|
|
|
* we can record correctly.
|
|
|
|
|
* XXX perhaps we shouldn't record words for failed
|
|
|
|
|
* transfers.
|
|
|
|
|
*/
|
|
|
|
|
dk_wds[du->dk_dkunit] += (count * DEV_BSIZE) >> 6;
|
|
|
|
|
}
|
1993-06-12 14:58:17 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Interrupt routine for the controller. Acknowledge the interrupt, check for
|
|
|
|
|
* errors on the current operation, mark it done if necessary, and start
|
|
|
|
|
* the next request. Also check for a partially done transfer, and
|
|
|
|
|
* continue with the next chunk if so.
|
|
|
|
|
*/
|
|
|
|
|
void
|
1994-01-04 20:05:26 +00:00
|
|
|
wdintr(int unit)
|
1993-06-12 14:58:17 +00:00
|
|
|
{
|
|
|
|
|
register struct disk *du;
|
1995-12-11 04:58:34 +00:00
|
|
|
register struct buf *bp;
|
1993-06-12 14:58:17 +00:00
|
|
|
|
1997-03-11 23:17:28 +00:00
|
|
|
#ifdef CMD640
|
|
|
|
|
int ctrlr_atapi;
|
|
|
|
|
|
|
|
|
|
if (eide_quirks & Q_CMD640B) {
|
|
|
|
|
unit = PRIMARY;
|
|
|
|
|
ctrlr_atapi = atapictrlr;
|
|
|
|
|
} else {
|
|
|
|
|
ctrlr_atapi = unit;
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
|
1994-02-01 05:55:21 +00:00
|
|
|
if (wdtab[unit].b_active == 2)
|
|
|
|
|
return; /* intr in wdflushirq() */
|
1994-01-04 20:05:26 +00:00
|
|
|
if (!wdtab[unit].b_active) {
|
1995-04-24 05:12:29 +00:00
|
|
|
#ifdef WDDEBUG
|
|
|
|
|
/*
|
|
|
|
|
* These happen mostly because the power-mgt part of the
|
|
|
|
|
* bios shuts us down, and we just manage to see the
|
|
|
|
|
* interrupt from the "SLEEP" command.
|
|
|
|
|
*/
|
1994-01-04 20:05:26 +00:00
|
|
|
printf("wdc%d: extra interrupt\n", unit);
|
1995-04-24 05:12:29 +00:00
|
|
|
#endif
|
1993-06-12 14:58:17 +00:00
|
|
|
return;
|
|
|
|
|
}
|
1995-08-18 11:26:35 +00:00
|
|
|
#ifdef ATAPI
|
|
|
|
|
if (wdtab[unit].b_active == 3) {
|
|
|
|
|
/* process an ATAPI interrupt */
|
1997-03-11 23:17:28 +00:00
|
|
|
#ifdef CMD640
|
|
|
|
|
if (atapi_intr && atapi_intr (ctrlr_atapi))
|
|
|
|
|
#else
|
Latest fixes from Serge:
I tried to solve the problem of IDE probing compatibility in this version.
When compiled without an ATAPI option, the wd driver is
fully backward compatible with 2.0.5. With ATAPI option,
the wdprobe becomes strictly weaker. That is, if wdprobe works
without ATAPI option, it will always work with it too.
Another problem was with the CD-ROM drive attached as a slave
in the IDE bus, where there is no master. All IDE CD-ROM
drives are shipped in slave configuration, and most users
just plug them in, never thinking about jumpers.
It works fine with ms-dos and ms-windows, and this
version of the driver supports it as well.
The eject op can now load disks. Just repeat it twice,
and the disk will be ejected and then loaded back.
The disc cannot be ejected if it is mounted.
Submitted by: Serge Vakulenko, <vak@cronyx.ru>
1995-10-14 15:41:10 +00:00
|
|
|
if (atapi_intr && atapi_intr (unit))
|
1997-03-11 23:17:28 +00:00
|
|
|
#endif
|
1995-08-18 11:26:35 +00:00
|
|
|
/* ATAPI op continues */
|
|
|
|
|
return;
|
|
|
|
|
/* controller is free, start new op */
|
|
|
|
|
wdtab[unit].b_active = 0;
|
|
|
|
|
wdstart (unit);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
#endif
|
1995-11-23 07:24:41 +00:00
|
|
|
bp = wdtab[unit].controller_queue.tqh_first;
|
1995-04-14 22:31:58 +00:00
|
|
|
du = wddrives[dkunit(bp->b_dev)];
|
1994-02-01 05:55:21 +00:00
|
|
|
du->dk_timeout = 0;
|
1993-06-12 14:58:17 +00:00
|
|
|
|
Add support for busmaster DMA on some PCI IDE chipsets.
I changed a few bits here and there, mainly renaming wd82371.c
to ide_pci.c now that it's supposed to handle different chipsets.
It runs on my P6 natoma board with two Maxtor drives, and also
on a Fujitsu machine I have at work with an Opti chipset and
a Quantum drive.
Submitted by:cgull@smoke.marlboro.vt.us <John Hood>
Original readme:
*** WARNING ***
This code has so far been tested on exactly one motherboard with two
identical drives known for their good DMA support.
This code, in the right circumstances, could corrupt data subtly,
silently, and invisibly, in much the same way that older PCI IDE
controllers do. It's ALPHA-quality code; there's one or two major
gaps in my understanding of PCI IDE still. Don't use this code on any
system with data that you care about; it's only good for hack boxes.
Expect that any data may be silently and randomly corrupted at any
moment. It's a disk driver. It has bugs. Disk drivers with bugs
munch data. It's a fact of life.
I also *STRONGLY* recommend getting a copy of your chipset's manual
and the ATA-2 or ATA-3 spec and making sure that timing modes on your
disk drives and IDE controller are being setup correctly by the BIOS--
because the driver makes only the lamest of attempts to do this just
now.
*** END WARNING ***
that said, i happen to think the code is working pretty well...
WHAT IT DOES:
this code adds support to the wd driver for bus mastering PCI IDE
controllers that follow the SFF-8038 standard. (all the bus mastering
PCI IDE controllers i've seen so far do follow this standard.) it
should provide busmastering on nearly any current P5 or P6 chipset,
specifically including any Intel chipset using one of the PIIX south
bridges-- this includes the '430FX, '430VX, '430HX, '430TX, '440LX,
and (i think) the Orion '450GX chipsets. specific support is also
included for the VIA Apollo VP-1 chipset, as it appears in the
relabeled "HXPro" incarnation seen on cheap US$70 taiwanese
motherboards (that's what's in my development machine). it works out
of the box on controllers that do DMA mode2; if my understanding is
correct, it'll probably work on Ultra-DMA33 controllers as well.
it'll probably work on busmastering IDE controllers in PCI slots, too,
but this is an area i am less sure about.
it cuts CPU usage considerably and improves drive performance
slightly. usable numbers are difficult to come by with existing
benchmark tools, but experimentation on my K5-P90 system, with VIA
VP-1 chipset and Quantum Fireball 1080 drives, shows that disk i/o on
raw partitions imposes perhaps 5% cpu load. cpu load during
filesystem i/o drops a lot, from near 100% to anywhere between 30% and
70%. (the improvement may not be as large on an Intel chipset; from
what i can tell, the VIA VP-1 may not be very efficient with PCI I/O.)
disk performance improves by 5% or 10% with these drives.
real, visible, end-user performance improvement on a single user
machine is about nil. :) a kernel compile was sped up by a whole three
seconds. it *does* feel a bit better-behaved when the system is
swapping heavily, but a better disk driver is not the fix for *that*
problem.
THE CODE:
this code is a patch to wd.c and wd82371.c, and associated header
files. it should be considered alpha code; more work needs to be
done.
wd.c has fairly clean patches to add calls to busmaster code, as
implemented in wd82371.c and potentially elsewhere (one could imagine,
say, a Mac having a different DMA controller).
wd82371.c has been considerably reworked: the wddma interface that it
presents has been changed (expect more changes), many bugs have been
fixed, a new internal interface has been added for supporting
different chipsets, and the PCI probe has been considerably extended.
the interface between wd82371.c and wd.c is still fairly clean, but
i'm not sure it's in the right place. there's a mess of issues around
ATA/ATAPI that need to be sorted out, including ATAPI support, CD-ROM
support, tape support, LS-120/Zip support, SFF-8038i DMA, UltraDMA,
PCI IDE controllers, bus probes, buggy controllers, controller timing
setup, drive timing setup, world peace and kitchen sinks. whatever
happens with all this and however it gets partitioned, it is fairly
clear that wd.c needs some significant rework-- probably a complete
rewrite.
timing setup on disk controllers is something i've entirely punted on.
on my development machine, it appears that the BIOS does at least some
of the necessary timing setup. i chose to restrict operation to
drives that are already configured for Mode4 PIO and Mode2 multiword
DMA, since the timing is essentially the same and many if not most
chipsets use the same control registers for DMA and PIO timing.
does anybody *know* whether BIOSes are required to do timing setup for
DMA modes on drives under their care?
error recovery is probably weak. early on in development, i was
getting drive errors induced by bugs in the driver; i used these to
flush out the worst of the bugs in the driver's error handling, but
problems may remain. i haven't got a drive with bad sectors i can
watch the driver flail on.
complaints about how wd82371.c has been reindented will be ignored
until the FreeBSD project has a real style policy, there is a
mechanism for individual authors to match it (indent flags or an emacs
c-mode or whatever), and it is enforced. if i'm going to use a source
style i don't like, it would help if i could figure out what it *is*
(style(9) is about half of a policy), and a way to reasonably
duplicate it. i ended up wasting a while trying to figure out what
the right thing to do was before deciding reformatting the whole thing
was the worst possible thing to do, except for all the other
possibilities.
i have maintained wd.c's indentation; that was not too hard,
fortunately.
TO INSTALL:
my dev box is freebsd 2.2.2 release. fortunately, wd.c is a living
fossil, and has diverged very little recently. included in this
tarball is a patch file, 'otherdiffs', for all files except wd82371.c,
my edited wd82371.c, a patch file, 'wd82371.c-diff-exact', against the
2.2.2 dist of 82371.c, and another patch file,
'wd82371.c-diff-whitespace', generated with diff -b (ignore
whitespace). most of you not using 2.2.2 will probably have to use
this last patchfile with 'patch --ignore-whitespace'. apply from the
kernel source tree root. as far as i can tell, this should apply
cleanly on anything from -current back to 2.2.2 and probably back to
2.2.0. you, the kernel hacker, can figure out what to do from here.
if you need more specific directions, you probably should not be
experimenting with this code yet.
to enable DMA support, set flag 0x2000 for that drive in your config
file or in userconfig, as you would the 32-bit-PIO flag. the driver
will then turn on DMA support if your drive and controller pass its
tests. it's a bit picky, probably. on discovering DMA mode failures
or disk errors or transfers that the DMA controller can't deal with,
the driver will fall back to PIO, so it is wise to setup the flags as
if PIO were still important.
'controller wdc0 at isa? port "IO_WD1" bio irq 14 flags 0xa0ffa0ff
vector wdintr' should work with nearly any PCI IDE controller.
i would *strongly* suggest booting single-user at first, and thrashing
the drive a bit while it's still mounted read-only. this should be
fairly safe, even if the driver goes completely out to lunch. it
might save you a reinstall.
one way to tell whether the driver is really using DMA is to check the
interrupt count during disk i/o with vmstat; DMA mode will add an
extremely low number of interrupts, as compared to even multi-sector
PIO.
boot -v will give you a copious register dump of timing-related info
on Intel and VIAtech chipsets, as well as PIO/DMA mode information on
all hard drives. refer to your ATA and chipset documentation to
interpret these.
WHAT I'D LIKE FROM YOU and THINGS TO TEST:
reports. success reports, failure reports, any kind of reports. :)
send them to cgull+ide@smoke.marlboro.vt.us.
i'd also like to see the kernel messages from various BIOSes (boot -v;
dmesg), along with info on the motherboard and BIOS on that machine.
i'm especially interested in reports on how this code works on the
various Intel chipsets, and whether the register dump works
correctly. i'm also interested in hearing about other chipsets.
i'm especially interested in hearing success/failure reports for PCI
IDE controllers on cards, such as CMD's or Promise's new busmastering
IDE controllers.
UltraDMA-33 reports.
interoperation with ATAPI peripherals-- FreeBSD doesn't work with my
old Hitachi IDE CDROM, so i can't tell if I've broken anything. :)
i'd especially like to hear how the drive copes in DMA operation on
drives with bad sectors. i haven't been able to find any such yet.
success/failure reports on older IDE drives with early support for DMA
modes-- those introduced between 1.5 and 3 years ago, typically
ranging from perhaps 400MB to 1.6GB.
failure reports on operation with more than one drive would be
appreciated. the driver was developed with two drives on one
controller, the worst-case situation, and has been tested with one
drive on each controller, but you never know...
any reports of messages from the driver during normal operation,
especially "reverting to PIO mode", or "dmaverify odd vaddr or length"
(the DMA controller is strongly halfword oriented, and i'm curious to
know if any FreeBSD usage actually needs misaligned transfers).
performance reports. beware that bonnie's CPU usage reporting is
useless for IDE drives; the best test i've found has been to run a
program that runs a spin loop at an idle priority and reports how many
iterations it manages, and even that sometimes produces numbers i
don't believe. performance reports of multi-drive operation are
especially interesting; my system cannot sustain full throughput on
two drives on separate controllers, but that may just be a lame
motherboard.
THINGS I'M STILL MISSING CLUE ON:
* who's responsible for configuring DMA timing modes on IDE drives?
the BIOS or the driver?
* is there a spec for dealing with Ultra-DMA extensions?
* are there any chipsets or with bugs relating to DMA transfer that
should be blacklisted?
* are there any ATA interfaces that use some other kind of DMA
controller in conjunction with standard ATA protocol?
FINAL NOTE:
after having looked at the ATA-3 spec, all i can say is, "it's ugly".
*especially* electrically. the IDE bus is best modeled as an
unterminated transmission line, these days.
for maximum reliability, keep your IDE cables as short as possible and
as few as possible. from what i can tell, most current chipsets have
both IDE ports wired into a single buss, to a greater or lesser
degree. using two cables means you double the length of this bus.
SCSI may have its warts, but at least the basic analog design of the
bus is still somewhat reasonable. IDE passed beyond the veil two
years ago.
--John Hood, cgull@smoke.marlboro.vt.us
1997-07-29 12:57:25 +00:00
|
|
|
/* finish off DMA. ignore errors if we're not using it. */
|
|
|
|
|
if (du->dk_flags & (DKFL_DMA|DKFL_USEDMA)) {
|
1997-08-04 05:26:49 +00:00
|
|
|
if ((wddma.wdd_dmastatus(du->dk_dmacookie) & WDDS_INTERRUPT) == 0)
|
|
|
|
|
return;
|
|
|
|
|
|
Add support for busmaster DMA on some PCI IDE chipsets.
I changed a few bits here and there, mainly renaming wd82371.c
to ide_pci.c now that it's supposed to handle different chipsets.
It runs on my P6 natoma board with two Maxtor drives, and also
on a Fujitsu machine I have at work with an Opti chipset and
a Quantum drive.
Submitted by:cgull@smoke.marlboro.vt.us <John Hood>
Original readme:
*** WARNING ***
This code has so far been tested on exactly one motherboard with two
identical drives known for their good DMA support.
This code, in the right circumstances, could corrupt data subtly,
silently, and invisibly, in much the same way that older PCI IDE
controllers do. It's ALPHA-quality code; there's one or two major
gaps in my understanding of PCI IDE still. Don't use this code on any
system with data that you care about; it's only good for hack boxes.
Expect that any data may be silently and randomly corrupted at any
moment. It's a disk driver. It has bugs. Disk drivers with bugs
munch data. It's a fact of life.
I also *STRONGLY* recommend getting a copy of your chipset's manual
and the ATA-2 or ATA-3 spec and making sure that timing modes on your
disk drives and IDE controller are being setup correctly by the BIOS--
because the driver makes only the lamest of attempts to do this just
now.
*** END WARNING ***
that said, i happen to think the code is working pretty well...
WHAT IT DOES:
this code adds support to the wd driver for bus mastering PCI IDE
controllers that follow the SFF-8038 standard. (all the bus mastering
PCI IDE controllers i've seen so far do follow this standard.) it
should provide busmastering on nearly any current P5 or P6 chipset,
specifically including any Intel chipset using one of the PIIX south
bridges-- this includes the '430FX, '430VX, '430HX, '430TX, '440LX,
and (i think) the Orion '450GX chipsets. specific support is also
included for the VIA Apollo VP-1 chipset, as it appears in the
relabeled "HXPro" incarnation seen on cheap US$70 taiwanese
motherboards (that's what's in my development machine). it works out
of the box on controllers that do DMA mode2; if my understanding is
correct, it'll probably work on Ultra-DMA33 controllers as well.
it'll probably work on busmastering IDE controllers in PCI slots, too,
but this is an area i am less sure about.
it cuts CPU usage considerably and improves drive performance
slightly. usable numbers are difficult to come by with existing
benchmark tools, but experimentation on my K5-P90 system, with VIA
VP-1 chipset and Quantum Fireball 1080 drives, shows that disk i/o on
raw partitions imposes perhaps 5% cpu load. cpu load during
filesystem i/o drops a lot, from near 100% to anywhere between 30% and
70%. (the improvement may not be as large on an Intel chipset; from
what i can tell, the VIA VP-1 may not be very efficient with PCI I/O.)
disk performance improves by 5% or 10% with these drives.
real, visible, end-user performance improvement on a single user
machine is about nil. :) a kernel compile was sped up by a whole three
seconds. it *does* feel a bit better-behaved when the system is
swapping heavily, but a better disk driver is not the fix for *that*
problem.
THE CODE:
this code is a patch to wd.c and wd82371.c, and associated header
files. it should be considered alpha code; more work needs to be
done.
wd.c has fairly clean patches to add calls to busmaster code, as
implemented in wd82371.c and potentially elsewhere (one could imagine,
say, a Mac having a different DMA controller).
wd82371.c has been considerably reworked: the wddma interface that it
presents has been changed (expect more changes), many bugs have been
fixed, a new internal interface has been added for supporting
different chipsets, and the PCI probe has been considerably extended.
the interface between wd82371.c and wd.c is still fairly clean, but
i'm not sure it's in the right place. there's a mess of issues around
ATA/ATAPI that need to be sorted out, including ATAPI support, CD-ROM
support, tape support, LS-120/Zip support, SFF-8038i DMA, UltraDMA,
PCI IDE controllers, bus probes, buggy controllers, controller timing
setup, drive timing setup, world peace and kitchen sinks. whatever
happens with all this and however it gets partitioned, it is fairly
clear that wd.c needs some significant rework-- probably a complete
rewrite.
timing setup on disk controllers is something i've entirely punted on.
on my development machine, it appears that the BIOS does at least some
of the necessary timing setup. i chose to restrict operation to
drives that are already configured for Mode4 PIO and Mode2 multiword
DMA, since the timing is essentially the same and many if not most
chipsets use the same control registers for DMA and PIO timing.
does anybody *know* whether BIOSes are required to do timing setup for
DMA modes on drives under their care?
error recovery is probably weak. early on in development, i was
getting drive errors induced by bugs in the driver; i used these to
flush out the worst of the bugs in the driver's error handling, but
problems may remain. i haven't got a drive with bad sectors i can
watch the driver flail on.
complaints about how wd82371.c has been reindented will be ignored
until the FreeBSD project has a real style policy, there is a
mechanism for individual authors to match it (indent flags or an emacs
c-mode or whatever), and it is enforced. if i'm going to use a source
style i don't like, it would help if i could figure out what it *is*
(style(9) is about half of a policy), and a way to reasonably
duplicate it. i ended up wasting a while trying to figure out what
the right thing to do was before deciding reformatting the whole thing
was the worst possible thing to do, except for all the other
possibilities.
i have maintained wd.c's indentation; that was not too hard,
fortunately.
TO INSTALL:
my dev box is freebsd 2.2.2 release. fortunately, wd.c is a living
fossil, and has diverged very little recently. included in this
tarball is a patch file, 'otherdiffs', for all files except wd82371.c,
my edited wd82371.c, a patch file, 'wd82371.c-diff-exact', against the
2.2.2 dist of 82371.c, and another patch file,
'wd82371.c-diff-whitespace', generated with diff -b (ignore
whitespace). most of you not using 2.2.2 will probably have to use
this last patchfile with 'patch --ignore-whitespace'. apply from the
kernel source tree root. as far as i can tell, this should apply
cleanly on anything from -current back to 2.2.2 and probably back to
2.2.0. you, the kernel hacker, can figure out what to do from here.
if you need more specific directions, you probably should not be
experimenting with this code yet.
to enable DMA support, set flag 0x2000 for that drive in your config
file or in userconfig, as you would the 32-bit-PIO flag. the driver
will then turn on DMA support if your drive and controller pass its
tests. it's a bit picky, probably. on discovering DMA mode failures
or disk errors or transfers that the DMA controller can't deal with,
the driver will fall back to PIO, so it is wise to setup the flags as
if PIO were still important.
'controller wdc0 at isa? port "IO_WD1" bio irq 14 flags 0xa0ffa0ff
vector wdintr' should work with nearly any PCI IDE controller.
i would *strongly* suggest booting single-user at first, and thrashing
the drive a bit while it's still mounted read-only. this should be
fairly safe, even if the driver goes completely out to lunch. it
might save you a reinstall.
one way to tell whether the driver is really using DMA is to check the
interrupt count during disk i/o with vmstat; DMA mode will add an
extremely low number of interrupts, as compared to even multi-sector
PIO.
boot -v will give you a copious register dump of timing-related info
on Intel and VIAtech chipsets, as well as PIO/DMA mode information on
all hard drives. refer to your ATA and chipset documentation to
interpret these.
WHAT I'D LIKE FROM YOU and THINGS TO TEST:
reports. success reports, failure reports, any kind of reports. :)
send them to cgull+ide@smoke.marlboro.vt.us.
i'd also like to see the kernel messages from various BIOSes (boot -v;
dmesg), along with info on the motherboard and BIOS on that machine.
i'm especially interested in reports on how this code works on the
various Intel chipsets, and whether the register dump works
correctly. i'm also interested in hearing about other chipsets.
i'm especially interested in hearing success/failure reports for PCI
IDE controllers on cards, such as CMD's or Promise's new busmastering
IDE controllers.
UltraDMA-33 reports.
interoperation with ATAPI peripherals-- FreeBSD doesn't work with my
old Hitachi IDE CDROM, so i can't tell if I've broken anything. :)
i'd especially like to hear how the drive copes in DMA operation on
drives with bad sectors. i haven't been able to find any such yet.
success/failure reports on older IDE drives with early support for DMA
modes-- those introduced between 1.5 and 3 years ago, typically
ranging from perhaps 400MB to 1.6GB.
failure reports on operation with more than one drive would be
appreciated. the driver was developed with two drives on one
controller, the worst-case situation, and has been tested with one
drive on each controller, but you never know...
any reports of messages from the driver during normal operation,
especially "reverting to PIO mode", or "dmaverify odd vaddr or length"
(the DMA controller is strongly halfword oriented, and i'm curious to
know if any FreeBSD usage actually needs misaligned transfers).
performance reports. beware that bonnie's CPU usage reporting is
useless for IDE drives; the best test i've found has been to run a
program that runs a spin loop at an idle priority and reports how many
iterations it manages, and even that sometimes produces numbers i
don't believe. performance reports of multi-drive operation are
especially interesting; my system cannot sustain full throughput on
two drives on separate controllers, but that may just be a lame
motherboard.
THINGS I'M STILL MISSING CLUE ON:
* who's responsible for configuring DMA timing modes on IDE drives?
the BIOS or the driver?
* is there a spec for dealing with Ultra-DMA extensions?
* are there any chipsets or with bugs relating to DMA transfer that
should be blacklisted?
* are there any ATA interfaces that use some other kind of DMA
controller in conjunction with standard ATA protocol?
FINAL NOTE:
after having looked at the ATA-3 spec, all i can say is, "it's ugly".
*especially* electrically. the IDE bus is best modeled as an
unterminated transmission line, these days.
for maximum reliability, keep your IDE cables as short as possible and
as few as possible. from what i can tell, most current chipsets have
both IDE ports wired into a single buss, to a greater or lesser
degree. using two cables means you double the length of this bus.
SCSI may have its warts, but at least the basic analog design of the
bus is still somewhat reasonable. IDE passed beyond the veil two
years ago.
--John Hood, cgull@smoke.marlboro.vt.us
1997-07-29 12:57:25 +00:00
|
|
|
if ((wddma.wdd_dmadone(du->dk_dmacookie) != WDDS_INTERRUPT) &&
|
|
|
|
|
!(du->dk_flags & DKFL_USEDMA)) {
|
|
|
|
|
wderror(bp, du, "wdintr: DMA failure");
|
|
|
|
|
du->dk_status |= WDCS_ERR; /* XXX totally bogus err */
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
1994-02-11 12:02:35 +00:00
|
|
|
if (wdwait(du, 0, TIMEOUT) < 0) {
|
1994-01-04 20:05:26 +00:00
|
|
|
wderror(bp, du, "wdintr: timeout waiting for status");
|
|
|
|
|
du->dk_status |= WDCS_ERR; /* XXX */
|
|
|
|
|
}
|
1993-06-12 14:58:17 +00:00
|
|
|
|
|
|
|
|
/* is it not a transfer, but a control operation? */
|
|
|
|
|
if (du->dk_state < OPEN) {
|
1994-01-04 20:05:26 +00:00
|
|
|
wdtab[unit].b_active = 0;
|
1994-03-04 16:43:07 +00:00
|
|
|
switch (wdcontrol(bp)) {
|
|
|
|
|
case 0:
|
|
|
|
|
return;
|
|
|
|
|
case 1:
|
1994-01-04 20:05:26 +00:00
|
|
|
wdstart(unit);
|
1994-04-20 07:06:57 +00:00
|
|
|
return;
|
1994-03-04 16:43:07 +00:00
|
|
|
case 2:
|
|
|
|
|
goto done;
|
|
|
|
|
}
|
1993-06-12 14:58:17 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* have we an error? */
|
1994-01-04 20:05:26 +00:00
|
|
|
if (du->dk_status & (WDCS_ERR | WDCS_ECCCOR)) {
|
|
|
|
|
oops:
|
1995-04-14 22:31:58 +00:00
|
|
|
/*
|
|
|
|
|
* XXX bogus inb() here, register 0 is assumed and intr status
|
|
|
|
|
* is reset.
|
|
|
|
|
*/
|
Add support for busmaster DMA on some PCI IDE chipsets.
I changed a few bits here and there, mainly renaming wd82371.c
to ide_pci.c now that it's supposed to handle different chipsets.
It runs on my P6 natoma board with two Maxtor drives, and also
on a Fujitsu machine I have at work with an Opti chipset and
a Quantum drive.
Submitted by:cgull@smoke.marlboro.vt.us <John Hood>
Original readme:
*** WARNING ***
This code has so far been tested on exactly one motherboard with two
identical drives known for their good DMA support.
This code, in the right circumstances, could corrupt data subtly,
silently, and invisibly, in much the same way that older PCI IDE
controllers do. It's ALPHA-quality code; there's one or two major
gaps in my understanding of PCI IDE still. Don't use this code on any
system with data that you care about; it's only good for hack boxes.
Expect that any data may be silently and randomly corrupted at any
moment. It's a disk driver. It has bugs. Disk drivers with bugs
munch data. It's a fact of life.
I also *STRONGLY* recommend getting a copy of your chipset's manual
and the ATA-2 or ATA-3 spec and making sure that timing modes on your
disk drives and IDE controller are being setup correctly by the BIOS--
because the driver makes only the lamest of attempts to do this just
now.
*** END WARNING ***
that said, i happen to think the code is working pretty well...
WHAT IT DOES:
this code adds support to the wd driver for bus mastering PCI IDE
controllers that follow the SFF-8038 standard. (all the bus mastering
PCI IDE controllers i've seen so far do follow this standard.) it
should provide busmastering on nearly any current P5 or P6 chipset,
specifically including any Intel chipset using one of the PIIX south
bridges-- this includes the '430FX, '430VX, '430HX, '430TX, '440LX,
and (i think) the Orion '450GX chipsets. specific support is also
included for the VIA Apollo VP-1 chipset, as it appears in the
relabeled "HXPro" incarnation seen on cheap US$70 taiwanese
motherboards (that's what's in my development machine). it works out
of the box on controllers that do DMA mode2; if my understanding is
correct, it'll probably work on Ultra-DMA33 controllers as well.
it'll probably work on busmastering IDE controllers in PCI slots, too,
but this is an area i am less sure about.
it cuts CPU usage considerably and improves drive performance
slightly. usable numbers are difficult to come by with existing
benchmark tools, but experimentation on my K5-P90 system, with VIA
VP-1 chipset and Quantum Fireball 1080 drives, shows that disk i/o on
raw partitions imposes perhaps 5% cpu load. cpu load during
filesystem i/o drops a lot, from near 100% to anywhere between 30% and
70%. (the improvement may not be as large on an Intel chipset; from
what i can tell, the VIA VP-1 may not be very efficient with PCI I/O.)
disk performance improves by 5% or 10% with these drives.
real, visible, end-user performance improvement on a single user
machine is about nil. :) a kernel compile was sped up by a whole three
seconds. it *does* feel a bit better-behaved when the system is
swapping heavily, but a better disk driver is not the fix for *that*
problem.
THE CODE:
this code is a patch to wd.c and wd82371.c, and associated header
files. it should be considered alpha code; more work needs to be
done.
wd.c has fairly clean patches to add calls to busmaster code, as
implemented in wd82371.c and potentially elsewhere (one could imagine,
say, a Mac having a different DMA controller).
wd82371.c has been considerably reworked: the wddma interface that it
presents has been changed (expect more changes), many bugs have been
fixed, a new internal interface has been added for supporting
different chipsets, and the PCI probe has been considerably extended.
the interface between wd82371.c and wd.c is still fairly clean, but
i'm not sure it's in the right place. there's a mess of issues around
ATA/ATAPI that need to be sorted out, including ATAPI support, CD-ROM
support, tape support, LS-120/Zip support, SFF-8038i DMA, UltraDMA,
PCI IDE controllers, bus probes, buggy controllers, controller timing
setup, drive timing setup, world peace and kitchen sinks. whatever
happens with all this and however it gets partitioned, it is fairly
clear that wd.c needs some significant rework-- probably a complete
rewrite.
timing setup on disk controllers is something i've entirely punted on.
on my development machine, it appears that the BIOS does at least some
of the necessary timing setup. i chose to restrict operation to
drives that are already configured for Mode4 PIO and Mode2 multiword
DMA, since the timing is essentially the same and many if not most
chipsets use the same control registers for DMA and PIO timing.
does anybody *know* whether BIOSes are required to do timing setup for
DMA modes on drives under their care?
error recovery is probably weak. early on in development, i was
getting drive errors induced by bugs in the driver; i used these to
flush out the worst of the bugs in the driver's error handling, but
problems may remain. i haven't got a drive with bad sectors i can
watch the driver flail on.
complaints about how wd82371.c has been reindented will be ignored
until the FreeBSD project has a real style policy, there is a
mechanism for individual authors to match it (indent flags or an emacs
c-mode or whatever), and it is enforced. if i'm going to use a source
style i don't like, it would help if i could figure out what it *is*
(style(9) is about half of a policy), and a way to reasonably
duplicate it. i ended up wasting a while trying to figure out what
the right thing to do was before deciding reformatting the whole thing
was the worst possible thing to do, except for all the other
possibilities.
i have maintained wd.c's indentation; that was not too hard,
fortunately.
TO INSTALL:
my dev box is freebsd 2.2.2 release. fortunately, wd.c is a living
fossil, and has diverged very little recently. included in this
tarball is a patch file, 'otherdiffs', for all files except wd82371.c,
my edited wd82371.c, a patch file, 'wd82371.c-diff-exact', against the
2.2.2 dist of 82371.c, and another patch file,
'wd82371.c-diff-whitespace', generated with diff -b (ignore
whitespace). most of you not using 2.2.2 will probably have to use
this last patchfile with 'patch --ignore-whitespace'. apply from the
kernel source tree root. as far as i can tell, this should apply
cleanly on anything from -current back to 2.2.2 and probably back to
2.2.0. you, the kernel hacker, can figure out what to do from here.
if you need more specific directions, you probably should not be
experimenting with this code yet.
to enable DMA support, set flag 0x2000 for that drive in your config
file or in userconfig, as you would the 32-bit-PIO flag. the driver
will then turn on DMA support if your drive and controller pass its
tests. it's a bit picky, probably. on discovering DMA mode failures
or disk errors or transfers that the DMA controller can't deal with,
the driver will fall back to PIO, so it is wise to setup the flags as
if PIO were still important.
'controller wdc0 at isa? port "IO_WD1" bio irq 14 flags 0xa0ffa0ff
vector wdintr' should work with nearly any PCI IDE controller.
i would *strongly* suggest booting single-user at first, and thrashing
the drive a bit while it's still mounted read-only. this should be
fairly safe, even if the driver goes completely out to lunch. it
might save you a reinstall.
one way to tell whether the driver is really using DMA is to check the
interrupt count during disk i/o with vmstat; DMA mode will add an
extremely low number of interrupts, as compared to even multi-sector
PIO.
boot -v will give you a copious register dump of timing-related info
on Intel and VIAtech chipsets, as well as PIO/DMA mode information on
all hard drives. refer to your ATA and chipset documentation to
interpret these.
WHAT I'D LIKE FROM YOU and THINGS TO TEST:
reports. success reports, failure reports, any kind of reports. :)
send them to cgull+ide@smoke.marlboro.vt.us.
i'd also like to see the kernel messages from various BIOSes (boot -v;
dmesg), along with info on the motherboard and BIOS on that machine.
i'm especially interested in reports on how this code works on the
various Intel chipsets, and whether the register dump works
correctly. i'm also interested in hearing about other chipsets.
i'm especially interested in hearing success/failure reports for PCI
IDE controllers on cards, such as CMD's or Promise's new busmastering
IDE controllers.
UltraDMA-33 reports.
interoperation with ATAPI peripherals-- FreeBSD doesn't work with my
old Hitachi IDE CDROM, so i can't tell if I've broken anything. :)
i'd especially like to hear how the drive copes in DMA operation on
drives with bad sectors. i haven't been able to find any such yet.
success/failure reports on older IDE drives with early support for DMA
modes-- those introduced between 1.5 and 3 years ago, typically
ranging from perhaps 400MB to 1.6GB.
failure reports on operation with more than one drive would be
appreciated. the driver was developed with two drives on one
controller, the worst-case situation, and has been tested with one
drive on each controller, but you never know...
any reports of messages from the driver during normal operation,
especially "reverting to PIO mode", or "dmaverify odd vaddr or length"
(the DMA controller is strongly halfword oriented, and i'm curious to
know if any FreeBSD usage actually needs misaligned transfers).
performance reports. beware that bonnie's CPU usage reporting is
useless for IDE drives; the best test i've found has been to run a
program that runs a spin loop at an idle priority and reports how many
iterations it manages, and even that sometimes produces numbers i
don't believe. performance reports of multi-drive operation are
especially interesting; my system cannot sustain full throughput on
two drives on separate controllers, but that may just be a lame
motherboard.
THINGS I'M STILL MISSING CLUE ON:
* who's responsible for configuring DMA timing modes on IDE drives?
the BIOS or the driver?
* is there a spec for dealing with Ultra-DMA extensions?
* are there any chipsets or with bugs relating to DMA transfer that
should be blacklisted?
* are there any ATA interfaces that use some other kind of DMA
controller in conjunction with standard ATA protocol?
FINAL NOTE:
after having looked at the ATA-3 spec, all i can say is, "it's ugly".
*especially* electrically. the IDE bus is best modeled as an
unterminated transmission line, these days.
for maximum reliability, keep your IDE cables as short as possible and
as few as possible. from what i can tell, most current chipsets have
both IDE ports wired into a single buss, to a greater or lesser
degree. using two cables means you double the length of this bus.
SCSI may have its warts, but at least the basic analog design of the
bus is still somewhat reasonable. IDE passed beyond the veil two
years ago.
--John Hood, cgull@smoke.marlboro.vt.us
1997-07-29 12:57:25 +00:00
|
|
|
if((du->dk_flags & DKFL_DMA ) &&
|
|
|
|
|
(inb(du->dk_port) & WDERR_ABORT)) {
|
|
|
|
|
wderror(bp, du, "reverting to PIO mode");
|
|
|
|
|
du->dk_flags |= ~DKFL_USEDMA;
|
|
|
|
|
} else if((du->dk_flags & DKFL_MULTI) &&
|
|
|
|
|
(inb(du->dk_port) & WDERR_ABORT)) {
|
1995-03-22 05:23:01 +00:00
|
|
|
wderror(bp, du, "reverting to non-multi sector mode");
|
|
|
|
|
du->dk_multi = 1;
|
|
|
|
|
}
|
1994-02-01 05:55:21 +00:00
|
|
|
#ifdef WDDEBUG
|
1994-01-04 20:05:26 +00:00
|
|
|
wderror(bp, du, "wdintr");
|
1993-06-12 14:58:17 +00:00
|
|
|
#endif
|
1994-02-01 05:55:21 +00:00
|
|
|
if ((du->dk_flags & DKFL_SINGLE) == 0) {
|
|
|
|
|
du->dk_flags |= DKFL_ERROR;
|
1993-06-12 14:58:17 +00:00
|
|
|
goto outt;
|
|
|
|
|
}
|
|
|
|
|
#ifdef B_FORMAT
|
|
|
|
|
if (bp->b_flags & B_FORMAT) {
|
1994-02-01 05:55:21 +00:00
|
|
|
bp->b_error = EIO;
|
1993-06-12 14:58:17 +00:00
|
|
|
bp->b_flags |= B_ERROR;
|
|
|
|
|
goto done;
|
|
|
|
|
}
|
|
|
|
|
#endif
|
1994-01-04 20:05:26 +00:00
|
|
|
|
1995-05-16 07:52:17 +00:00
|
|
|
if (du->dk_flags & DKFL_BADSCAN) {
|
|
|
|
|
bp->b_error = EIO;
|
|
|
|
|
bp->b_flags |= B_ERROR;
|
|
|
|
|
} else if (du->dk_status & WDCS_ERR) {
|
1994-01-04 20:05:26 +00:00
|
|
|
if (++wdtab[unit].b_errcnt < RETRIES) {
|
|
|
|
|
wdtab[unit].b_active = 0;
|
1993-06-12 14:58:17 +00:00
|
|
|
} else {
|
1994-01-04 20:05:26 +00:00
|
|
|
wderror(bp, du, "hard error");
|
1994-02-01 05:55:21 +00:00
|
|
|
bp->b_error = EIO;
|
1993-06-12 14:58:17 +00:00
|
|
|
bp->b_flags |= B_ERROR; /* flag the error */
|
|
|
|
|
}
|
1994-01-04 20:05:26 +00:00
|
|
|
} else
|
|
|
|
|
wderror(bp, du, "soft ecc");
|
1993-06-12 14:58:17 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* If this was a successful read operation, fetch the data.
|
|
|
|
|
*/
|
1994-02-01 05:55:21 +00:00
|
|
|
if (((bp->b_flags & (B_READ | B_ERROR)) == B_READ)
|
Add support for busmaster DMA on some PCI IDE chipsets.
I changed a few bits here and there, mainly renaming wd82371.c
to ide_pci.c now that it's supposed to handle different chipsets.
It runs on my P6 natoma board with two Maxtor drives, and also
on a Fujitsu machine I have at work with an Opti chipset and
a Quantum drive.
Submitted by:cgull@smoke.marlboro.vt.us <John Hood>
Original readme:
*** WARNING ***
This code has so far been tested on exactly one motherboard with two
identical drives known for their good DMA support.
This code, in the right circumstances, could corrupt data subtly,
silently, and invisibly, in much the same way that older PCI IDE
controllers do. It's ALPHA-quality code; there's one or two major
gaps in my understanding of PCI IDE still. Don't use this code on any
system with data that you care about; it's only good for hack boxes.
Expect that any data may be silently and randomly corrupted at any
moment. It's a disk driver. It has bugs. Disk drivers with bugs
munch data. It's a fact of life.
I also *STRONGLY* recommend getting a copy of your chipset's manual
and the ATA-2 or ATA-3 spec and making sure that timing modes on your
disk drives and IDE controller are being setup correctly by the BIOS--
because the driver makes only the lamest of attempts to do this just
now.
*** END WARNING ***
that said, i happen to think the code is working pretty well...
WHAT IT DOES:
this code adds support to the wd driver for bus mastering PCI IDE
controllers that follow the SFF-8038 standard. (all the bus mastering
PCI IDE controllers i've seen so far do follow this standard.) it
should provide busmastering on nearly any current P5 or P6 chipset,
specifically including any Intel chipset using one of the PIIX south
bridges-- this includes the '430FX, '430VX, '430HX, '430TX, '440LX,
and (i think) the Orion '450GX chipsets. specific support is also
included for the VIA Apollo VP-1 chipset, as it appears in the
relabeled "HXPro" incarnation seen on cheap US$70 taiwanese
motherboards (that's what's in my development machine). it works out
of the box on controllers that do DMA mode2; if my understanding is
correct, it'll probably work on Ultra-DMA33 controllers as well.
it'll probably work on busmastering IDE controllers in PCI slots, too,
but this is an area i am less sure about.
it cuts CPU usage considerably and improves drive performance
slightly. usable numbers are difficult to come by with existing
benchmark tools, but experimentation on my K5-P90 system, with VIA
VP-1 chipset and Quantum Fireball 1080 drives, shows that disk i/o on
raw partitions imposes perhaps 5% cpu load. cpu load during
filesystem i/o drops a lot, from near 100% to anywhere between 30% and
70%. (the improvement may not be as large on an Intel chipset; from
what i can tell, the VIA VP-1 may not be very efficient with PCI I/O.)
disk performance improves by 5% or 10% with these drives.
real, visible, end-user performance improvement on a single user
machine is about nil. :) a kernel compile was sped up by a whole three
seconds. it *does* feel a bit better-behaved when the system is
swapping heavily, but a better disk driver is not the fix for *that*
problem.
THE CODE:
this code is a patch to wd.c and wd82371.c, and associated header
files. it should be considered alpha code; more work needs to be
done.
wd.c has fairly clean patches to add calls to busmaster code, as
implemented in wd82371.c and potentially elsewhere (one could imagine,
say, a Mac having a different DMA controller).
wd82371.c has been considerably reworked: the wddma interface that it
presents has been changed (expect more changes), many bugs have been
fixed, a new internal interface has been added for supporting
different chipsets, and the PCI probe has been considerably extended.
the interface between wd82371.c and wd.c is still fairly clean, but
i'm not sure it's in the right place. there's a mess of issues around
ATA/ATAPI that need to be sorted out, including ATAPI support, CD-ROM
support, tape support, LS-120/Zip support, SFF-8038i DMA, UltraDMA,
PCI IDE controllers, bus probes, buggy controllers, controller timing
setup, drive timing setup, world peace and kitchen sinks. whatever
happens with all this and however it gets partitioned, it is fairly
clear that wd.c needs some significant rework-- probably a complete
rewrite.
timing setup on disk controllers is something i've entirely punted on.
on my development machine, it appears that the BIOS does at least some
of the necessary timing setup. i chose to restrict operation to
drives that are already configured for Mode4 PIO and Mode2 multiword
DMA, since the timing is essentially the same and many if not most
chipsets use the same control registers for DMA and PIO timing.
does anybody *know* whether BIOSes are required to do timing setup for
DMA modes on drives under their care?
error recovery is probably weak. early on in development, i was
getting drive errors induced by bugs in the driver; i used these to
flush out the worst of the bugs in the driver's error handling, but
problems may remain. i haven't got a drive with bad sectors i can
watch the driver flail on.
complaints about how wd82371.c has been reindented will be ignored
until the FreeBSD project has a real style policy, there is a
mechanism for individual authors to match it (indent flags or an emacs
c-mode or whatever), and it is enforced. if i'm going to use a source
style i don't like, it would help if i could figure out what it *is*
(style(9) is about half of a policy), and a way to reasonably
duplicate it. i ended up wasting a while trying to figure out what
the right thing to do was before deciding reformatting the whole thing
was the worst possible thing to do, except for all the other
possibilities.
i have maintained wd.c's indentation; that was not too hard,
fortunately.
TO INSTALL:
my dev box is freebsd 2.2.2 release. fortunately, wd.c is a living
fossil, and has diverged very little recently. included in this
tarball is a patch file, 'otherdiffs', for all files except wd82371.c,
my edited wd82371.c, a patch file, 'wd82371.c-diff-exact', against the
2.2.2 dist of 82371.c, and another patch file,
'wd82371.c-diff-whitespace', generated with diff -b (ignore
whitespace). most of you not using 2.2.2 will probably have to use
this last patchfile with 'patch --ignore-whitespace'. apply from the
kernel source tree root. as far as i can tell, this should apply
cleanly on anything from -current back to 2.2.2 and probably back to
2.2.0. you, the kernel hacker, can figure out what to do from here.
if you need more specific directions, you probably should not be
experimenting with this code yet.
to enable DMA support, set flag 0x2000 for that drive in your config
file or in userconfig, as you would the 32-bit-PIO flag. the driver
will then turn on DMA support if your drive and controller pass its
tests. it's a bit picky, probably. on discovering DMA mode failures
or disk errors or transfers that the DMA controller can't deal with,
the driver will fall back to PIO, so it is wise to setup the flags as
if PIO were still important.
'controller wdc0 at isa? port "IO_WD1" bio irq 14 flags 0xa0ffa0ff
vector wdintr' should work with nearly any PCI IDE controller.
i would *strongly* suggest booting single-user at first, and thrashing
the drive a bit while it's still mounted read-only. this should be
fairly safe, even if the driver goes completely out to lunch. it
might save you a reinstall.
one way to tell whether the driver is really using DMA is to check the
interrupt count during disk i/o with vmstat; DMA mode will add an
extremely low number of interrupts, as compared to even multi-sector
PIO.
boot -v will give you a copious register dump of timing-related info
on Intel and VIAtech chipsets, as well as PIO/DMA mode information on
all hard drives. refer to your ATA and chipset documentation to
interpret these.
WHAT I'D LIKE FROM YOU and THINGS TO TEST:
reports. success reports, failure reports, any kind of reports. :)
send them to cgull+ide@smoke.marlboro.vt.us.
i'd also like to see the kernel messages from various BIOSes (boot -v;
dmesg), along with info on the motherboard and BIOS on that machine.
i'm especially interested in reports on how this code works on the
various Intel chipsets, and whether the register dump works
correctly. i'm also interested in hearing about other chipsets.
i'm especially interested in hearing success/failure reports for PCI
IDE controllers on cards, such as CMD's or Promise's new busmastering
IDE controllers.
UltraDMA-33 reports.
interoperation with ATAPI peripherals-- FreeBSD doesn't work with my
old Hitachi IDE CDROM, so i can't tell if I've broken anything. :)
i'd especially like to hear how the drive copes in DMA operation on
drives with bad sectors. i haven't been able to find any such yet.
success/failure reports on older IDE drives with early support for DMA
modes-- those introduced between 1.5 and 3 years ago, typically
ranging from perhaps 400MB to 1.6GB.
failure reports on operation with more than one drive would be
appreciated. the driver was developed with two drives on one
controller, the worst-case situation, and has been tested with one
drive on each controller, but you never know...
any reports of messages from the driver during normal operation,
especially "reverting to PIO mode", or "dmaverify odd vaddr or length"
(the DMA controller is strongly halfword oriented, and i'm curious to
know if any FreeBSD usage actually needs misaligned transfers).
performance reports. beware that bonnie's CPU usage reporting is
useless for IDE drives; the best test i've found has been to run a
program that runs a spin loop at an idle priority and reports how many
iterations it manages, and even that sometimes produces numbers i
don't believe. performance reports of multi-drive operation are
especially interesting; my system cannot sustain full throughput on
two drives on separate controllers, but that may just be a lame
motherboard.
THINGS I'M STILL MISSING CLUE ON:
* who's responsible for configuring DMA timing modes on IDE drives?
the BIOS or the driver?
* is there a spec for dealing with Ultra-DMA extensions?
* are there any chipsets or with bugs relating to DMA transfer that
should be blacklisted?
* are there any ATA interfaces that use some other kind of DMA
controller in conjunction with standard ATA protocol?
FINAL NOTE:
after having looked at the ATA-3 spec, all i can say is, "it's ugly".
*especially* electrically. the IDE bus is best modeled as an
unterminated transmission line, these days.
for maximum reliability, keep your IDE cables as short as possible and
as few as possible. from what i can tell, most current chipsets have
both IDE ports wired into a single buss, to a greater or lesser
degree. using two cables means you double the length of this bus.
SCSI may have its warts, but at least the basic analog design of the
bus is still somewhat reasonable. IDE passed beyond the veil two
years ago.
--John Hood, cgull@smoke.marlboro.vt.us
1997-07-29 12:57:25 +00:00
|
|
|
&& !(du->dk_flags & DKFL_DMA)
|
1994-02-01 05:55:21 +00:00
|
|
|
&& wdtab[unit].b_active) {
|
1995-03-22 05:23:01 +00:00
|
|
|
int chk, dummy, multisize;
|
|
|
|
|
multisize = chk = du->dk_currentiosize * DEV_BSIZE;
|
|
|
|
|
if( du->dk_bc < chk) {
|
|
|
|
|
chk = du->dk_bc;
|
|
|
|
|
if( ((chk + DEV_BSIZE - 1) / DEV_BSIZE) < du->dk_currentiosize) {
|
|
|
|
|
du->dk_currentiosize = (chk + DEV_BSIZE - 1) / DEV_BSIZE;
|
|
|
|
|
multisize = du->dk_currentiosize * DEV_BSIZE;
|
|
|
|
|
}
|
|
|
|
|
}
|
1995-04-24 05:09:53 +00:00
|
|
|
|
1993-06-12 14:58:17 +00:00
|
|
|
/* ready to receive data? */
|
1994-04-20 07:06:57 +00:00
|
|
|
if ((du->dk_status & (WDCS_READY | WDCS_SEEKCMPLT | WDCS_DRQ))
|
|
|
|
|
!= (WDCS_READY | WDCS_SEEKCMPLT | WDCS_DRQ))
|
|
|
|
|
wderror(bp, du, "wdintr: read intr arrived early");
|
1994-02-11 12:02:35 +00:00
|
|
|
if (wdwait(du, WDCS_READY | WDCS_SEEKCMPLT | WDCS_DRQ, TIMEOUT) != 0) {
|
1994-01-04 20:05:26 +00:00
|
|
|
wderror(bp, du, "wdintr: read error detected late");
|
|
|
|
|
goto oops;
|
|
|
|
|
}
|
1993-06-12 14:58:17 +00:00
|
|
|
|
|
|
|
|
/* suck in data */
|
1995-03-22 05:23:01 +00:00
|
|
|
if( du->dk_flags & DKFL_32BIT)
|
1995-02-04 19:39:36 +00:00
|
|
|
insl(du->dk_port + wd_data,
|
1995-03-22 05:23:01 +00:00
|
|
|
(void *)((int)bp->b_un.b_addr + du->dk_skip * DEV_BSIZE),
|
|
|
|
|
chk / sizeof(long));
|
1995-02-04 19:39:36 +00:00
|
|
|
else
|
|
|
|
|
insw(du->dk_port + wd_data,
|
1995-03-22 05:23:01 +00:00
|
|
|
(void *)((int)bp->b_un.b_addr + du->dk_skip * DEV_BSIZE),
|
|
|
|
|
chk / sizeof(short));
|
|
|
|
|
du->dk_bc -= chk;
|
|
|
|
|
|
|
|
|
|
/* XXX for obsolete fractional sector reads. */
|
|
|
|
|
while (chk < multisize) {
|
|
|
|
|
insw(du->dk_port + wd_data, &dummy, 1);
|
|
|
|
|
chk += sizeof(short);
|
|
|
|
|
}
|
1993-06-12 14:58:17 +00:00
|
|
|
|
1995-04-14 22:31:58 +00:00
|
|
|
if (du->dk_dkunit >= 0)
|
|
|
|
|
dk_wds[du->dk_dkunit] += chk >> 6;
|
1994-10-16 03:50:36 +00:00
|
|
|
}
|
1995-04-14 22:31:58 +00:00
|
|
|
|
Add support for busmaster DMA on some PCI IDE chipsets.
I changed a few bits here and there, mainly renaming wd82371.c
to ide_pci.c now that it's supposed to handle different chipsets.
It runs on my P6 natoma board with two Maxtor drives, and also
on a Fujitsu machine I have at work with an Opti chipset and
a Quantum drive.
Submitted by:cgull@smoke.marlboro.vt.us <John Hood>
Original readme:
*** WARNING ***
This code has so far been tested on exactly one motherboard with two
identical drives known for their good DMA support.
This code, in the right circumstances, could corrupt data subtly,
silently, and invisibly, in much the same way that older PCI IDE
controllers do. It's ALPHA-quality code; there's one or two major
gaps in my understanding of PCI IDE still. Don't use this code on any
system with data that you care about; it's only good for hack boxes.
Expect that any data may be silently and randomly corrupted at any
moment. It's a disk driver. It has bugs. Disk drivers with bugs
munch data. It's a fact of life.
I also *STRONGLY* recommend getting a copy of your chipset's manual
and the ATA-2 or ATA-3 spec and making sure that timing modes on your
disk drives and IDE controller are being setup correctly by the BIOS--
because the driver makes only the lamest of attempts to do this just
now.
*** END WARNING ***
that said, i happen to think the code is working pretty well...
WHAT IT DOES:
this code adds support to the wd driver for bus mastering PCI IDE
controllers that follow the SFF-8038 standard. (all the bus mastering
PCI IDE controllers i've seen so far do follow this standard.) it
should provide busmastering on nearly any current P5 or P6 chipset,
specifically including any Intel chipset using one of the PIIX south
bridges-- this includes the '430FX, '430VX, '430HX, '430TX, '440LX,
and (i think) the Orion '450GX chipsets. specific support is also
included for the VIA Apollo VP-1 chipset, as it appears in the
relabeled "HXPro" incarnation seen on cheap US$70 taiwanese
motherboards (that's what's in my development machine). it works out
of the box on controllers that do DMA mode2; if my understanding is
correct, it'll probably work on Ultra-DMA33 controllers as well.
it'll probably work on busmastering IDE controllers in PCI slots, too,
but this is an area i am less sure about.
it cuts CPU usage considerably and improves drive performance
slightly. usable numbers are difficult to come by with existing
benchmark tools, but experimentation on my K5-P90 system, with VIA
VP-1 chipset and Quantum Fireball 1080 drives, shows that disk i/o on
raw partitions imposes perhaps 5% cpu load. cpu load during
filesystem i/o drops a lot, from near 100% to anywhere between 30% and
70%. (the improvement may not be as large on an Intel chipset; from
what i can tell, the VIA VP-1 may not be very efficient with PCI I/O.)
disk performance improves by 5% or 10% with these drives.
real, visible, end-user performance improvement on a single user
machine is about nil. :) a kernel compile was sped up by a whole three
seconds. it *does* feel a bit better-behaved when the system is
swapping heavily, but a better disk driver is not the fix for *that*
problem.
THE CODE:
this code is a patch to wd.c and wd82371.c, and associated header
files. it should be considered alpha code; more work needs to be
done.
wd.c has fairly clean patches to add calls to busmaster code, as
implemented in wd82371.c and potentially elsewhere (one could imagine,
say, a Mac having a different DMA controller).
wd82371.c has been considerably reworked: the wddma interface that it
presents has been changed (expect more changes), many bugs have been
fixed, a new internal interface has been added for supporting
different chipsets, and the PCI probe has been considerably extended.
the interface between wd82371.c and wd.c is still fairly clean, but
i'm not sure it's in the right place. there's a mess of issues around
ATA/ATAPI that need to be sorted out, including ATAPI support, CD-ROM
support, tape support, LS-120/Zip support, SFF-8038i DMA, UltraDMA,
PCI IDE controllers, bus probes, buggy controllers, controller timing
setup, drive timing setup, world peace and kitchen sinks. whatever
happens with all this and however it gets partitioned, it is fairly
clear that wd.c needs some significant rework-- probably a complete
rewrite.
timing setup on disk controllers is something i've entirely punted on.
on my development machine, it appears that the BIOS does at least some
of the necessary timing setup. i chose to restrict operation to
drives that are already configured for Mode4 PIO and Mode2 multiword
DMA, since the timing is essentially the same and many if not most
chipsets use the same control registers for DMA and PIO timing.
does anybody *know* whether BIOSes are required to do timing setup for
DMA modes on drives under their care?
error recovery is probably weak. early on in development, i was
getting drive errors induced by bugs in the driver; i used these to
flush out the worst of the bugs in the driver's error handling, but
problems may remain. i haven't got a drive with bad sectors i can
watch the driver flail on.
complaints about how wd82371.c has been reindented will be ignored
until the FreeBSD project has a real style policy, there is a
mechanism for individual authors to match it (indent flags or an emacs
c-mode or whatever), and it is enforced. if i'm going to use a source
style i don't like, it would help if i could figure out what it *is*
(style(9) is about half of a policy), and a way to reasonably
duplicate it. i ended up wasting a while trying to figure out what
the right thing to do was before deciding reformatting the whole thing
was the worst possible thing to do, except for all the other
possibilities.
i have maintained wd.c's indentation; that was not too hard,
fortunately.
TO INSTALL:
my dev box is freebsd 2.2.2 release. fortunately, wd.c is a living
fossil, and has diverged very little recently. included in this
tarball is a patch file, 'otherdiffs', for all files except wd82371.c,
my edited wd82371.c, a patch file, 'wd82371.c-diff-exact', against the
2.2.2 dist of 82371.c, and another patch file,
'wd82371.c-diff-whitespace', generated with diff -b (ignore
whitespace). most of you not using 2.2.2 will probably have to use
this last patchfile with 'patch --ignore-whitespace'. apply from the
kernel source tree root. as far as i can tell, this should apply
cleanly on anything from -current back to 2.2.2 and probably back to
2.2.0. you, the kernel hacker, can figure out what to do from here.
if you need more specific directions, you probably should not be
experimenting with this code yet.
to enable DMA support, set flag 0x2000 for that drive in your config
file or in userconfig, as you would the 32-bit-PIO flag. the driver
will then turn on DMA support if your drive and controller pass its
tests. it's a bit picky, probably. on discovering DMA mode failures
or disk errors or transfers that the DMA controller can't deal with,
the driver will fall back to PIO, so it is wise to setup the flags as
if PIO were still important.
'controller wdc0 at isa? port "IO_WD1" bio irq 14 flags 0xa0ffa0ff
vector wdintr' should work with nearly any PCI IDE controller.
i would *strongly* suggest booting single-user at first, and thrashing
the drive a bit while it's still mounted read-only. this should be
fairly safe, even if the driver goes completely out to lunch. it
might save you a reinstall.
one way to tell whether the driver is really using DMA is to check the
interrupt count during disk i/o with vmstat; DMA mode will add an
extremely low number of interrupts, as compared to even multi-sector
PIO.
boot -v will give you a copious register dump of timing-related info
on Intel and VIAtech chipsets, as well as PIO/DMA mode information on
all hard drives. refer to your ATA and chipset documentation to
interpret these.
WHAT I'D LIKE FROM YOU and THINGS TO TEST:
reports. success reports, failure reports, any kind of reports. :)
send them to cgull+ide@smoke.marlboro.vt.us.
i'd also like to see the kernel messages from various BIOSes (boot -v;
dmesg), along with info on the motherboard and BIOS on that machine.
i'm especially interested in reports on how this code works on the
various Intel chipsets, and whether the register dump works
correctly. i'm also interested in hearing about other chipsets.
i'm especially interested in hearing success/failure reports for PCI
IDE controllers on cards, such as CMD's or Promise's new busmastering
IDE controllers.
UltraDMA-33 reports.
interoperation with ATAPI peripherals-- FreeBSD doesn't work with my
old Hitachi IDE CDROM, so i can't tell if I've broken anything. :)
i'd especially like to hear how the drive copes in DMA operation on
drives with bad sectors. i haven't been able to find any such yet.
success/failure reports on older IDE drives with early support for DMA
modes-- those introduced between 1.5 and 3 years ago, typically
ranging from perhaps 400MB to 1.6GB.
failure reports on operation with more than one drive would be
appreciated. the driver was developed with two drives on one
controller, the worst-case situation, and has been tested with one
drive on each controller, but you never know...
any reports of messages from the driver during normal operation,
especially "reverting to PIO mode", or "dmaverify odd vaddr or length"
(the DMA controller is strongly halfword oriented, and i'm curious to
know if any FreeBSD usage actually needs misaligned transfers).
performance reports. beware that bonnie's CPU usage reporting is
useless for IDE drives; the best test i've found has been to run a
program that runs a spin loop at an idle priority and reports how many
iterations it manages, and even that sometimes produces numbers i
don't believe. performance reports of multi-drive operation are
especially interesting; my system cannot sustain full throughput on
two drives on separate controllers, but that may just be a lame
motherboard.
THINGS I'M STILL MISSING CLUE ON:
* who's responsible for configuring DMA timing modes on IDE drives?
the BIOS or the driver?
* is there a spec for dealing with Ultra-DMA extensions?
* are there any chipsets or with bugs relating to DMA transfer that
should be blacklisted?
* are there any ATA interfaces that use some other kind of DMA
controller in conjunction with standard ATA protocol?
FINAL NOTE:
after having looked at the ATA-3 spec, all i can say is, "it's ugly".
*especially* electrically. the IDE bus is best modeled as an
unterminated transmission line, these days.
for maximum reliability, keep your IDE cables as short as possible and
as few as possible. from what i can tell, most current chipsets have
both IDE ports wired into a single buss, to a greater or lesser
degree. using two cables means you double the length of this bus.
SCSI may have its warts, but at least the basic analog design of the
bus is still somewhat reasonable. IDE passed beyond the veil two
years ago.
--John Hood, cgull@smoke.marlboro.vt.us
1997-07-29 12:57:25 +00:00
|
|
|
/* final cleanup on DMA */
|
|
|
|
|
if (((bp->b_flags & B_ERROR) == 0)
|
|
|
|
|
&& (du->dk_flags & DKFL_DMA)
|
|
|
|
|
&& wdtab[unit].b_active) {
|
|
|
|
|
int iosize;
|
|
|
|
|
|
|
|
|
|
iosize = du->dk_currentiosize * DEV_BSIZE;
|
|
|
|
|
|
|
|
|
|
du->dk_bc -= iosize;
|
|
|
|
|
|
|
|
|
|
if (du->dk_dkunit >= 0)
|
|
|
|
|
dk_wds[du->dk_dkunit] += iosize >> 6;
|
|
|
|
|
}
|
|
|
|
|
|
1994-01-04 20:05:26 +00:00
|
|
|
outt:
|
|
|
|
|
if (wdtab[unit].b_active) {
|
1993-06-12 14:58:17 +00:00
|
|
|
if ((bp->b_flags & B_ERROR) == 0) {
|
1995-03-22 05:23:01 +00:00
|
|
|
du->dk_skip += du->dk_currentiosize;/* add to successful sectors */
|
1994-01-04 20:05:26 +00:00
|
|
|
if (wdtab[unit].b_errcnt)
|
|
|
|
|
wderror(bp, du, "soft error");
|
|
|
|
|
wdtab[unit].b_errcnt = 0;
|
1993-06-12 14:58:17 +00:00
|
|
|
|
|
|
|
|
/* see if more to transfer */
|
|
|
|
|
if (du->dk_bc > 0 && (du->dk_flags & DKFL_ERROR) == 0) {
|
1995-03-22 05:23:01 +00:00
|
|
|
if( (du->dk_flags & DKFL_SINGLE) ||
|
|
|
|
|
((bp->b_flags & B_READ) == 0)) {
|
|
|
|
|
wdtab[unit].b_active = 0;
|
|
|
|
|
wdstart(unit);
|
|
|
|
|
} else {
|
|
|
|
|
du->dk_timeout = 1 + 3;
|
|
|
|
|
}
|
1994-02-01 05:55:21 +00:00
|
|
|
return; /* next chunk is started */
|
|
|
|
|
} else if ((du->dk_flags & (DKFL_SINGLE | DKFL_ERROR))
|
|
|
|
|
== DKFL_ERROR) {
|
1993-06-12 14:58:17 +00:00
|
|
|
du->dk_skip = 0;
|
|
|
|
|
du->dk_flags &= ~DKFL_ERROR;
|
1994-02-01 05:55:21 +00:00
|
|
|
du->dk_flags |= DKFL_SINGLE;
|
1994-01-04 20:05:26 +00:00
|
|
|
wdtab[unit].b_active = 0;
|
|
|
|
|
wdstart(unit);
|
1994-02-01 05:55:21 +00:00
|
|
|
return; /* redo xfer sector by sector */
|
1993-06-12 14:58:17 +00:00
|
|
|
}
|
|
|
|
|
}
|
1994-03-04 16:43:07 +00:00
|
|
|
|
1994-01-04 20:05:26 +00:00
|
|
|
done: ;
|
1993-06-12 14:58:17 +00:00
|
|
|
/* done with this transfer, with or without error */
|
Add support for busmaster DMA on some PCI IDE chipsets.
I changed a few bits here and there, mainly renaming wd82371.c
to ide_pci.c now that it's supposed to handle different chipsets.
It runs on my P6 natoma board with two Maxtor drives, and also
on a Fujitsu machine I have at work with an Opti chipset and
a Quantum drive.
Submitted by:cgull@smoke.marlboro.vt.us <John Hood>
Original readme:
*** WARNING ***
This code has so far been tested on exactly one motherboard with two
identical drives known for their good DMA support.
This code, in the right circumstances, could corrupt data subtly,
silently, and invisibly, in much the same way that older PCI IDE
controllers do. It's ALPHA-quality code; there's one or two major
gaps in my understanding of PCI IDE still. Don't use this code on any
system with data that you care about; it's only good for hack boxes.
Expect that any data may be silently and randomly corrupted at any
moment. It's a disk driver. It has bugs. Disk drivers with bugs
munch data. It's a fact of life.
I also *STRONGLY* recommend getting a copy of your chipset's manual
and the ATA-2 or ATA-3 spec and making sure that timing modes on your
disk drives and IDE controller are being setup correctly by the BIOS--
because the driver makes only the lamest of attempts to do this just
now.
*** END WARNING ***
that said, i happen to think the code is working pretty well...
WHAT IT DOES:
this code adds support to the wd driver for bus mastering PCI IDE
controllers that follow the SFF-8038 standard. (all the bus mastering
PCI IDE controllers i've seen so far do follow this standard.) it
should provide busmastering on nearly any current P5 or P6 chipset,
specifically including any Intel chipset using one of the PIIX south
bridges-- this includes the '430FX, '430VX, '430HX, '430TX, '440LX,
and (i think) the Orion '450GX chipsets. specific support is also
included for the VIA Apollo VP-1 chipset, as it appears in the
relabeled "HXPro" incarnation seen on cheap US$70 taiwanese
motherboards (that's what's in my development machine). it works out
of the box on controllers that do DMA mode2; if my understanding is
correct, it'll probably work on Ultra-DMA33 controllers as well.
it'll probably work on busmastering IDE controllers in PCI slots, too,
but this is an area i am less sure about.
it cuts CPU usage considerably and improves drive performance
slightly. usable numbers are difficult to come by with existing
benchmark tools, but experimentation on my K5-P90 system, with VIA
VP-1 chipset and Quantum Fireball 1080 drives, shows that disk i/o on
raw partitions imposes perhaps 5% cpu load. cpu load during
filesystem i/o drops a lot, from near 100% to anywhere between 30% and
70%. (the improvement may not be as large on an Intel chipset; from
what i can tell, the VIA VP-1 may not be very efficient with PCI I/O.)
disk performance improves by 5% or 10% with these drives.
real, visible, end-user performance improvement on a single user
machine is about nil. :) a kernel compile was sped up by a whole three
seconds. it *does* feel a bit better-behaved when the system is
swapping heavily, but a better disk driver is not the fix for *that*
problem.
THE CODE:
this code is a patch to wd.c and wd82371.c, and associated header
files. it should be considered alpha code; more work needs to be
done.
wd.c has fairly clean patches to add calls to busmaster code, as
implemented in wd82371.c and potentially elsewhere (one could imagine,
say, a Mac having a different DMA controller).
wd82371.c has been considerably reworked: the wddma interface that it
presents has been changed (expect more changes), many bugs have been
fixed, a new internal interface has been added for supporting
different chipsets, and the PCI probe has been considerably extended.
the interface between wd82371.c and wd.c is still fairly clean, but
i'm not sure it's in the right place. there's a mess of issues around
ATA/ATAPI that need to be sorted out, including ATAPI support, CD-ROM
support, tape support, LS-120/Zip support, SFF-8038i DMA, UltraDMA,
PCI IDE controllers, bus probes, buggy controllers, controller timing
setup, drive timing setup, world peace and kitchen sinks. whatever
happens with all this and however it gets partitioned, it is fairly
clear that wd.c needs some significant rework-- probably a complete
rewrite.
timing setup on disk controllers is something i've entirely punted on.
on my development machine, it appears that the BIOS does at least some
of the necessary timing setup. i chose to restrict operation to
drives that are already configured for Mode4 PIO and Mode2 multiword
DMA, since the timing is essentially the same and many if not most
chipsets use the same control registers for DMA and PIO timing.
does anybody *know* whether BIOSes are required to do timing setup for
DMA modes on drives under their care?
error recovery is probably weak. early on in development, i was
getting drive errors induced by bugs in the driver; i used these to
flush out the worst of the bugs in the driver's error handling, but
problems may remain. i haven't got a drive with bad sectors i can
watch the driver flail on.
complaints about how wd82371.c has been reindented will be ignored
until the FreeBSD project has a real style policy, there is a
mechanism for individual authors to match it (indent flags or an emacs
c-mode or whatever), and it is enforced. if i'm going to use a source
style i don't like, it would help if i could figure out what it *is*
(style(9) is about half of a policy), and a way to reasonably
duplicate it. i ended up wasting a while trying to figure out what
the right thing to do was before deciding reformatting the whole thing
was the worst possible thing to do, except for all the other
possibilities.
i have maintained wd.c's indentation; that was not too hard,
fortunately.
TO INSTALL:
my dev box is freebsd 2.2.2 release. fortunately, wd.c is a living
fossil, and has diverged very little recently. included in this
tarball is a patch file, 'otherdiffs', for all files except wd82371.c,
my edited wd82371.c, a patch file, 'wd82371.c-diff-exact', against the
2.2.2 dist of 82371.c, and another patch file,
'wd82371.c-diff-whitespace', generated with diff -b (ignore
whitespace). most of you not using 2.2.2 will probably have to use
this last patchfile with 'patch --ignore-whitespace'. apply from the
kernel source tree root. as far as i can tell, this should apply
cleanly on anything from -current back to 2.2.2 and probably back to
2.2.0. you, the kernel hacker, can figure out what to do from here.
if you need more specific directions, you probably should not be
experimenting with this code yet.
to enable DMA support, set flag 0x2000 for that drive in your config
file or in userconfig, as you would the 32-bit-PIO flag. the driver
will then turn on DMA support if your drive and controller pass its
tests. it's a bit picky, probably. on discovering DMA mode failures
or disk errors or transfers that the DMA controller can't deal with,
the driver will fall back to PIO, so it is wise to setup the flags as
if PIO were still important.
'controller wdc0 at isa? port "IO_WD1" bio irq 14 flags 0xa0ffa0ff
vector wdintr' should work with nearly any PCI IDE controller.
i would *strongly* suggest booting single-user at first, and thrashing
the drive a bit while it's still mounted read-only. this should be
fairly safe, even if the driver goes completely out to lunch. it
might save you a reinstall.
one way to tell whether the driver is really using DMA is to check the
interrupt count during disk i/o with vmstat; DMA mode will add an
extremely low number of interrupts, as compared to even multi-sector
PIO.
boot -v will give you a copious register dump of timing-related info
on Intel and VIAtech chipsets, as well as PIO/DMA mode information on
all hard drives. refer to your ATA and chipset documentation to
interpret these.
WHAT I'D LIKE FROM YOU and THINGS TO TEST:
reports. success reports, failure reports, any kind of reports. :)
send them to cgull+ide@smoke.marlboro.vt.us.
i'd also like to see the kernel messages from various BIOSes (boot -v;
dmesg), along with info on the motherboard and BIOS on that machine.
i'm especially interested in reports on how this code works on the
various Intel chipsets, and whether the register dump works
correctly. i'm also interested in hearing about other chipsets.
i'm especially interested in hearing success/failure reports for PCI
IDE controllers on cards, such as CMD's or Promise's new busmastering
IDE controllers.
UltraDMA-33 reports.
interoperation with ATAPI peripherals-- FreeBSD doesn't work with my
old Hitachi IDE CDROM, so i can't tell if I've broken anything. :)
i'd especially like to hear how the drive copes in DMA operation on
drives with bad sectors. i haven't been able to find any such yet.
success/failure reports on older IDE drives with early support for DMA
modes-- those introduced between 1.5 and 3 years ago, typically
ranging from perhaps 400MB to 1.6GB.
failure reports on operation with more than one drive would be
appreciated. the driver was developed with two drives on one
controller, the worst-case situation, and has been tested with one
drive on each controller, but you never know...
any reports of messages from the driver during normal operation,
especially "reverting to PIO mode", or "dmaverify odd vaddr or length"
(the DMA controller is strongly halfword oriented, and i'm curious to
know if any FreeBSD usage actually needs misaligned transfers).
performance reports. beware that bonnie's CPU usage reporting is
useless for IDE drives; the best test i've found has been to run a
program that runs a spin loop at an idle priority and reports how many
iterations it manages, and even that sometimes produces numbers i
don't believe. performance reports of multi-drive operation are
especially interesting; my system cannot sustain full throughput on
two drives on separate controllers, but that may just be a lame
motherboard.
THINGS I'M STILL MISSING CLUE ON:
* who's responsible for configuring DMA timing modes on IDE drives?
the BIOS or the driver?
* is there a spec for dealing with Ultra-DMA extensions?
* are there any chipsets or with bugs relating to DMA transfer that
should be blacklisted?
* are there any ATA interfaces that use some other kind of DMA
controller in conjunction with standard ATA protocol?
FINAL NOTE:
after having looked at the ATA-3 spec, all i can say is, "it's ugly".
*especially* electrically. the IDE bus is best modeled as an
unterminated transmission line, these days.
for maximum reliability, keep your IDE cables as short as possible and
as few as possible. from what i can tell, most current chipsets have
both IDE ports wired into a single buss, to a greater or lesser
degree. using two cables means you double the length of this bus.
SCSI may have its warts, but at least the basic analog design of the
bus is still somewhat reasonable. IDE passed beyond the veil two
years ago.
--John Hood, cgull@smoke.marlboro.vt.us
1997-07-29 12:57:25 +00:00
|
|
|
du->dk_flags &= ~(DKFL_SINGLE|DKFL_DMA);
|
1995-11-23 07:24:41 +00:00
|
|
|
TAILQ_REMOVE(&wdtab[unit].controller_queue, bp, b_act);
|
1994-01-04 20:05:26 +00:00
|
|
|
wdtab[unit].b_errcnt = 0;
|
1994-02-01 05:55:21 +00:00
|
|
|
bp->b_resid = bp->b_bcount - du->dk_skip * DEV_BSIZE;
|
1995-11-23 07:24:41 +00:00
|
|
|
wdutab[du->dk_lunit].b_active = 0;
|
|
|
|
|
wdutab[du->dk_lunit].b_errcnt = 0;
|
1994-05-25 09:21:21 +00:00
|
|
|
du->dk_skip = 0;
|
1993-06-12 14:58:17 +00:00
|
|
|
biodone(bp);
|
|
|
|
|
}
|
|
|
|
|
|
1994-10-16 03:50:36 +00:00
|
|
|
if(du->dk_dkunit >= 0) {
|
|
|
|
|
dk_busy &= ~(1 << du->dk_dkunit);
|
|
|
|
|
}
|
|
|
|
|
|
1993-06-12 14:58:17 +00:00
|
|
|
/* controller idle */
|
1994-01-04 20:05:26 +00:00
|
|
|
wdtab[unit].b_active = 0;
|
1993-06-12 14:58:17 +00:00
|
|
|
|
|
|
|
|
/* anything more on drive queue? */
|
1994-05-25 09:21:21 +00:00
|
|
|
wdustart(du);
|
1993-06-12 14:58:17 +00:00
|
|
|
/* anything more for controller to do? */
|
1995-08-18 11:26:35 +00:00
|
|
|
#ifndef ATAPI
|
|
|
|
|
/* This is not valid in ATAPI mode. */
|
1995-11-23 07:24:41 +00:00
|
|
|
if (wdtab[unit].controller_queue.tqh_first)
|
1995-08-18 11:26:35 +00:00
|
|
|
#endif
|
1994-01-04 20:05:26 +00:00
|
|
|
wdstart(unit);
|
1993-06-12 14:58:17 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Initialize a drive.
|
|
|
|
|
*/
|
|
|
|
|
int
|
|
|
|
|
wdopen(dev_t dev, int flags, int fmt, struct proc *p)
|
|
|
|
|
{
|
1994-01-04 20:05:26 +00:00
|
|
|
register unsigned int lunit;
|
1993-06-12 14:58:17 +00:00
|
|
|
register struct disk *du;
|
1995-04-14 22:31:58 +00:00
|
|
|
int error;
|
1993-06-12 14:58:17 +00:00
|
|
|
|
1995-04-14 22:31:58 +00:00
|
|
|
lunit = dkunit(dev);
|
|
|
|
|
if (lunit >= NWD || dktype(dev) != 0)
|
1994-02-01 05:55:21 +00:00
|
|
|
return (ENXIO);
|
1994-01-04 20:05:26 +00:00
|
|
|
du = wddrives[lunit];
|
1994-02-01 05:55:21 +00:00
|
|
|
if (du == NULL)
|
|
|
|
|
return (ENXIO);
|
|
|
|
|
|
|
|
|
|
/* Finish flushing IRQs left over from wdattach(). */
|
1997-03-11 23:17:28 +00:00
|
|
|
#ifdef CMD640
|
|
|
|
|
if (wdtab[du->dk_ctrlr_cmd640].b_active == 2)
|
|
|
|
|
wdtab[du->dk_ctrlr_cmd640].b_active = 0;
|
|
|
|
|
#else
|
1994-02-01 05:55:21 +00:00
|
|
|
if (wdtab[du->dk_ctrlr].b_active == 2)
|
|
|
|
|
wdtab[du->dk_ctrlr].b_active = 0;
|
1997-03-11 23:17:28 +00:00
|
|
|
#endif
|
1994-02-01 05:55:21 +00:00
|
|
|
|
1995-05-16 07:52:17 +00:00
|
|
|
du->dk_flags &= ~DKFL_BADSCAN;
|
|
|
|
|
|
1994-01-04 20:05:26 +00:00
|
|
|
while (du->dk_flags & DKFL_LABELLING)
|
|
|
|
|
tsleep((caddr_t)&du->dk_flags, PZERO - 1, "wdopen", 1);
|
1995-04-14 22:31:58 +00:00
|
|
|
#if 1
|
|
|
|
|
wdsleep(du->dk_ctrlr, "wdopn1");
|
|
|
|
|
du->dk_flags |= DKFL_LABELLING;
|
|
|
|
|
du->dk_state = WANTOPEN;
|
|
|
|
|
{
|
|
|
|
|
struct disklabel label;
|
|
|
|
|
|
|
|
|
|
bzero(&label, sizeof label);
|
|
|
|
|
label.d_secsize = du->dk_dd.d_secsize;
|
|
|
|
|
label.d_nsectors = du->dk_dd.d_nsectors;
|
|
|
|
|
label.d_ntracks = du->dk_dd.d_ntracks;
|
|
|
|
|
label.d_ncylinders = du->dk_dd.d_ncylinders;
|
|
|
|
|
label.d_secpercyl = du->dk_dd.d_secpercyl;
|
|
|
|
|
label.d_secperunit = du->dk_dd.d_secperunit;
|
|
|
|
|
error = dsopen("wd", dev, fmt, &du->dk_slices, &label, wdstrategy1,
|
1996-01-27 04:18:15 +00:00
|
|
|
(ds_setgeom_t *)NULL, &wd_bdevsw, &wd_cdevsw);
|
1995-04-14 22:31:58 +00:00
|
|
|
}
|
|
|
|
|
du->dk_flags &= ~DKFL_LABELLING;
|
|
|
|
|
wdsleep(du->dk_ctrlr, "wdopn2");
|
|
|
|
|
return (error);
|
|
|
|
|
#else
|
1993-06-12 14:58:17 +00:00
|
|
|
if ((du->dk_flags & DKFL_BSDLABEL) == 0) {
|
1993-09-05 13:46:17 +00:00
|
|
|
/*
|
1996-04-18 21:37:43 +00:00
|
|
|
* wdtab[ctrlr].b_active != 0 implies XXX applicable now ??
|
1996-05-03 14:57:27 +00:00
|
|
|
* drive_queue[lunit].b_act == NULL (?) XXX applicable now ??
|
1994-01-04 20:05:26 +00:00
|
|
|
* so the following guards most things (until the next i/o).
|
|
|
|
|
* It doesn't guard against a new i/o starting and being
|
|
|
|
|
* affected by the label being changed. Sigh.
|
1993-09-05 13:46:17 +00:00
|
|
|
*/
|
1994-01-04 20:05:26 +00:00
|
|
|
wdsleep(du->dk_ctrlr, "wdopn1");
|
|
|
|
|
|
1995-04-14 22:31:58 +00:00
|
|
|
du->dk_flags |= DKFL_LABELLING;
|
1993-09-07 02:08:51 +00:00
|
|
|
du->dk_state = WANTOPEN;
|
|
|
|
|
|
1995-04-14 22:31:58 +00:00
|
|
|
error = dsinit(dkmodpart(dev, RAW_PART), wdstrategy,
|
|
|
|
|
&du->dk_dd, &du->dk_slices);
|
|
|
|
|
if (error != 0) {
|
|
|
|
|
du->dk_flags &= ~DKFL_LABELLING;
|
|
|
|
|
return (error);
|
|
|
|
|
}
|
|
|
|
|
/* XXX check value returned by wdwsetctlr(). */
|
|
|
|
|
wdwsetctlr(du);
|
|
|
|
|
if (dkslice(dev) == WHOLE_DISK_SLICE) {
|
|
|
|
|
dsopen(dev, fmt, du->dk_slices);
|
|
|
|
|
return (0);
|
|
|
|
|
}
|
|
|
|
|
|
1994-01-04 20:05:26 +00:00
|
|
|
/*
|
1995-04-14 22:31:58 +00:00
|
|
|
* Read label using RAW_PART partition.
|
1994-01-04 20:05:26 +00:00
|
|
|
*
|
|
|
|
|
* If the drive has an MBR, then the current geometry (from
|
|
|
|
|
* wdgetctlr()) is used to read it; then the BIOS/DOS
|
|
|
|
|
* geometry is inferred and used to read the label off the
|
|
|
|
|
* 'c' partition. Otherwise the label is read using the
|
|
|
|
|
* current geometry. The label gives the final geometry.
|
|
|
|
|
* If bad sector handling is enabled, then this geometry
|
|
|
|
|
* is used to read the bad sector table. The geometry
|
|
|
|
|
* changes occur inside readdisklabel() and are propagated
|
|
|
|
|
* to the driver by resetting the state machine.
|
1995-04-14 22:31:58 +00:00
|
|
|
*
|
|
|
|
|
* XXX can now handle changes directly since dsinit() doesn't
|
|
|
|
|
* do too much.
|
1994-01-04 20:05:26 +00:00
|
|
|
*/
|
1995-04-14 22:31:58 +00:00
|
|
|
msg = correct_readdisklabel(dkmodpart(dev, RAW_PART), wdstrategy,
|
|
|
|
|
&du->dk_dd);
|
|
|
|
|
/* XXX check value returned by wdwsetctlr(). */
|
|
|
|
|
wdwsetctlr(du);
|
|
|
|
|
if (msg == NULL && du->dk_dd.d_flags & D_BADSECT)
|
|
|
|
|
msg = readbad144(dkmodpart(dev, RAW_PART), wdstrategy,
|
|
|
|
|
&du->dk_dd, &du->dk_bad);
|
1994-01-04 20:05:26 +00:00
|
|
|
du->dk_flags &= ~DKFL_LABELLING;
|
|
|
|
|
if (msg != NULL) {
|
1993-08-08 07:03:21 +00:00
|
|
|
log(LOG_WARNING, "wd%d: cannot find label (%s)\n",
|
1994-01-04 20:05:26 +00:00
|
|
|
lunit, msg);
|
1995-04-14 22:31:58 +00:00
|
|
|
if (part != RAW_PART)
|
1994-01-04 20:05:26 +00:00
|
|
|
return (EINVAL); /* XXX needs translation */
|
1995-04-14 22:31:58 +00:00
|
|
|
/*
|
|
|
|
|
* Soon return. This is how slices without labels
|
|
|
|
|
* are allowed. They only work on the raw partition.
|
|
|
|
|
*/
|
1993-06-12 14:58:17 +00:00
|
|
|
} else {
|
1994-02-01 05:55:21 +00:00
|
|
|
unsigned long newsize, offset, size;
|
1995-04-14 22:31:58 +00:00
|
|
|
#if 0
|
1994-02-01 05:55:21 +00:00
|
|
|
/*
|
1995-04-14 22:31:58 +00:00
|
|
|
* Force RAW_PART partition to be the whole disk.
|
1994-02-01 05:55:21 +00:00
|
|
|
*/
|
1995-04-14 22:31:58 +00:00
|
|
|
offset = du->dk_dd.d_partitions[RAW_PART].p_offset;
|
1994-02-01 05:55:21 +00:00
|
|
|
if (offset != 0) {
|
|
|
|
|
printf(
|
1994-08-30 14:26:13 +00:00
|
|
|
"wd%d: changing offset of '%c' partition from %lu to 0\n",
|
1995-04-14 22:31:58 +00:00
|
|
|
du->dk_lunit, 'a' + RAW_PART, offset);
|
|
|
|
|
du->dk_dd.d_partitions[RAW_PART].p_offset = 0;
|
1994-02-01 05:55:21 +00:00
|
|
|
}
|
1995-04-14 22:31:58 +00:00
|
|
|
size = du->dk_dd.d_partitions[RAW_PART].p_size;
|
1994-02-01 05:55:21 +00:00
|
|
|
newsize = du->dk_dd.d_secperunit; /* XXX */
|
|
|
|
|
if (size != newsize) {
|
|
|
|
|
printf(
|
1994-08-30 14:26:13 +00:00
|
|
|
"wd%d: changing size of '%c' partition from %lu to %lu\n",
|
1995-04-14 22:31:58 +00:00
|
|
|
du->dk_lunit, 'a' + RAW_PART, size,
|
|
|
|
|
newsize);
|
|
|
|
|
du->dk_dd.d_partitions[RAW_PART].p_size
|
|
|
|
|
= newsize;
|
1994-02-01 05:55:21 +00:00
|
|
|
}
|
1995-04-14 22:31:58 +00:00
|
|
|
#endif
|
1993-06-12 14:58:17 +00:00
|
|
|
}
|
|
|
|
|
|
1994-01-04 20:05:26 +00:00
|
|
|
/* Pick up changes made by readdisklabel(). */
|
|
|
|
|
wdsleep(du->dk_ctrlr, "wdopn2");
|
|
|
|
|
du->dk_state = WANTOPEN;
|
1993-09-07 02:08:51 +00:00
|
|
|
}
|
1994-01-04 20:05:26 +00:00
|
|
|
|
|
|
|
|
/*
|
1994-02-01 05:55:21 +00:00
|
|
|
* Warn if a partion is opened that overlaps another partition which
|
|
|
|
|
* is open unless one is the "raw" partition (whole disk).
|
1994-01-04 20:05:26 +00:00
|
|
|
*/
|
1995-04-14 22:31:58 +00:00
|
|
|
if ((du->dk_openpart & mask) == 0 && part != RAW_PART) {
|
1993-06-12 14:58:17 +00:00
|
|
|
int start, end;
|
|
|
|
|
|
1994-01-04 20:05:26 +00:00
|
|
|
pp = &du->dk_dd.d_partitions[part];
|
|
|
|
|
start = pp->p_offset;
|
|
|
|
|
end = pp->p_offset + pp->p_size;
|
|
|
|
|
for (pp = du->dk_dd.d_partitions;
|
|
|
|
|
pp < &du->dk_dd.d_partitions[du->dk_dd.d_npartitions];
|
|
|
|
|
pp++) {
|
|
|
|
|
if (pp->p_offset + pp->p_size <= start ||
|
1994-02-01 05:55:21 +00:00
|
|
|
pp->p_offset >= end)
|
1994-01-04 20:05:26 +00:00
|
|
|
continue;
|
1995-04-14 22:31:58 +00:00
|
|
|
if (pp - du->dk_dd.d_partitions == RAW_PART)
|
1994-01-04 20:05:26 +00:00
|
|
|
continue;
|
1994-02-01 05:55:21 +00:00
|
|
|
if (du->dk_openpart
|
|
|
|
|
& (1 << (pp - du->dk_dd.d_partitions)))
|
1994-01-04 20:05:26 +00:00
|
|
|
log(LOG_WARNING,
|
|
|
|
|
"wd%d%c: overlaps open partition (%c)\n",
|
|
|
|
|
lunit, part + 'a',
|
|
|
|
|
pp - du->dk_dd.d_partitions + 'a');
|
|
|
|
|
}
|
|
|
|
|
}
|
1995-04-14 22:31:58 +00:00
|
|
|
if (part >= du->dk_dd.d_npartitions && part != RAW_PART)
|
1994-01-04 20:05:26 +00:00
|
|
|
return (ENXIO);
|
1993-06-12 14:58:17 +00:00
|
|
|
|
1995-04-14 22:31:58 +00:00
|
|
|
dsopen(dev, fmt, du->dk_slices);
|
1994-02-01 05:55:21 +00:00
|
|
|
|
1993-06-12 14:58:17 +00:00
|
|
|
return (0);
|
1995-04-14 22:31:58 +00:00
|
|
|
#endif
|
1993-06-12 14:58:17 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Implement operations other than read/write.
|
|
|
|
|
* Called from wdstart or wdintr during opens and formats.
|
|
|
|
|
* Uses finite-state-machine to track progress of operation in progress.
|
1994-03-04 16:43:07 +00:00
|
|
|
* Returns 0 if operation still in progress, 1 if completed, 2 if error.
|
1993-06-12 14:58:17 +00:00
|
|
|
*/
|
|
|
|
|
static int
|
|
|
|
|
wdcontrol(register struct buf *bp)
|
|
|
|
|
{
|
|
|
|
|
register struct disk *du;
|
1994-02-01 05:55:21 +00:00
|
|
|
int ctrlr;
|
1993-06-12 14:58:17 +00:00
|
|
|
|
1995-04-14 22:31:58 +00:00
|
|
|
du = wddrives[dkunit(bp->b_dev)];
|
1997-03-11 23:17:28 +00:00
|
|
|
#ifdef CMD640
|
|
|
|
|
ctrlr = du->dk_ctrlr_cmd640;
|
|
|
|
|
#else
|
1994-01-04 20:05:26 +00:00
|
|
|
ctrlr = du->dk_ctrlr;
|
1997-03-11 23:17:28 +00:00
|
|
|
#endif
|
1993-09-07 02:08:51 +00:00
|
|
|
|
1994-01-04 20:05:26 +00:00
|
|
|
switch (du->dk_state) {
|
1994-02-01 05:55:21 +00:00
|
|
|
case WANTOPEN:
|
1994-01-04 20:05:26 +00:00
|
|
|
tryagainrecal:
|
|
|
|
|
wdtab[ctrlr].b_active = 1;
|
|
|
|
|
if (wdcommand(du, 0, 0, 0, 0, WDCC_RESTORE | WD_STEP) != 0) {
|
|
|
|
|
wderror(bp, du, "wdcontrol: wdcommand failed");
|
|
|
|
|
goto maybe_retry;
|
|
|
|
|
}
|
|
|
|
|
du->dk_state = RECAL;
|
1994-02-01 05:55:21 +00:00
|
|
|
return (0);
|
1993-06-12 14:58:17 +00:00
|
|
|
case RECAL:
|
1994-01-04 20:05:26 +00:00
|
|
|
if (du->dk_status & WDCS_ERR || wdsetctlr(du) != 0) {
|
|
|
|
|
wderror(bp, du, "wdcontrol: recal failed");
|
|
|
|
|
maybe_retry:
|
|
|
|
|
if (du->dk_status & WDCS_ERR)
|
|
|
|
|
wdunwedge(du);
|
1994-02-01 05:55:21 +00:00
|
|
|
du->dk_state = WANTOPEN;
|
|
|
|
|
if (++wdtab[ctrlr].b_errcnt < RETRIES)
|
1993-06-12 14:58:17 +00:00
|
|
|
goto tryagainrecal;
|
|
|
|
|
bp->b_error = ENXIO; /* XXX needs translation */
|
1994-01-04 20:05:26 +00:00
|
|
|
bp->b_flags |= B_ERROR;
|
1994-03-04 16:43:07 +00:00
|
|
|
return (2);
|
1993-06-12 14:58:17 +00:00
|
|
|
}
|
1994-01-04 20:05:26 +00:00
|
|
|
wdtab[ctrlr].b_errcnt = 0;
|
1993-06-12 14:58:17 +00:00
|
|
|
du->dk_state = OPEN;
|
|
|
|
|
/*
|
1994-02-01 05:55:21 +00:00
|
|
|
* The rest of the initialization can be done by normal
|
|
|
|
|
* means.
|
1993-06-12 14:58:17 +00:00
|
|
|
*/
|
1994-02-01 05:55:21 +00:00
|
|
|
return (1);
|
1993-06-12 14:58:17 +00:00
|
|
|
}
|
1994-01-04 20:05:26 +00:00
|
|
|
panic("wdcontrol");
|
1994-03-04 16:43:07 +00:00
|
|
|
return (2);
|
1993-06-12 14:58:17 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
1994-01-04 20:05:26 +00:00
|
|
|
* Wait uninterruptibly until controller is not busy, then send it a command.
|
|
|
|
|
* The wait usually terminates immediately because we waited for the previous
|
|
|
|
|
* command to terminate.
|
1993-06-12 14:58:17 +00:00
|
|
|
*/
|
|
|
|
|
static int
|
1994-01-04 20:05:26 +00:00
|
|
|
wdcommand(struct disk *du, u_int cylinder, u_int head, u_int sector,
|
|
|
|
|
u_int count, u_int command)
|
1993-11-22 23:25:46 +00:00
|
|
|
{
|
1994-02-01 05:55:21 +00:00
|
|
|
u_int wdc;
|
1993-06-12 14:58:17 +00:00
|
|
|
|
1995-04-24 05:12:29 +00:00
|
|
|
wdc = du->dk_port;
|
1997-04-03 09:43:50 +00:00
|
|
|
if (du->cfg_flags & WDOPT_SLEEPHACK) {
|
|
|
|
|
/* OK, so the APM bios has put the disk into SLEEP mode,
|
|
|
|
|
* how can we tell ? Uhm, we can't. There is no
|
|
|
|
|
* standardized way of finding out, and the only way to
|
|
|
|
|
* wake it up is to reset it. Bummer.
|
|
|
|
|
*
|
|
|
|
|
* All the many and varied versions of the IDE/ATA standard
|
|
|
|
|
* explicitly tells us not to look at these registers if
|
|
|
|
|
* the disk is in SLEEP mode. Well, too bad really, we
|
|
|
|
|
* have to find out if it's in sleep mode before we can
|
|
|
|
|
* avoid reading the registers.
|
|
|
|
|
*
|
|
|
|
|
* I have reason to belive that most disks will return
|
|
|
|
|
* either 0xff or 0x00 in all but the status register
|
|
|
|
|
* when in SLEEP mode, but I have yet to see one return
|
|
|
|
|
* 0x00, so we don't check for that yet.
|
|
|
|
|
*
|
|
|
|
|
* The check for WDCS_BUSY is for the case where the
|
|
|
|
|
* bios spins up the disk for us, but doesn't initialize
|
|
|
|
|
* it correctly /phk
|
|
|
|
|
*/
|
|
|
|
|
if(inb(wdc + wd_precomp) + inb(wdc + wd_cyl_lo) +
|
|
|
|
|
inb(wdc + wd_cyl_hi) + inb(wdc + wd_sdh) +
|
|
|
|
|
inb(wdc + wd_sector) + inb(wdc + wd_seccnt) == 6 * 0xff) {
|
|
|
|
|
if (bootverbose)
|
|
|
|
|
printf("wd(%d,%d): disk aSLEEP\n",
|
|
|
|
|
du->dk_ctrlr, du->dk_unit);
|
1995-04-24 05:12:29 +00:00
|
|
|
wdunwedge(du);
|
1997-04-03 09:43:50 +00:00
|
|
|
} else if(inb(wdc + wd_status) == WDCS_BUSY) {
|
|
|
|
|
if (bootverbose)
|
|
|
|
|
printf("wd(%d,%d): disk is BUSY\n",
|
|
|
|
|
du->dk_ctrlr, du->dk_unit);
|
|
|
|
|
wdunwedge(du);
|
|
|
|
|
}
|
|
|
|
|
}
|
1995-04-24 05:12:29 +00:00
|
|
|
|
1994-02-11 12:02:35 +00:00
|
|
|
if (wdwait(du, 0, TIMEOUT) < 0)
|
1994-01-04 20:05:26 +00:00
|
|
|
return (1);
|
1995-03-22 05:23:01 +00:00
|
|
|
if( command == WDCC_FEATURES) {
|
|
|
|
|
outb(wdc + wd_features, count);
|
|
|
|
|
} else {
|
|
|
|
|
outb(wdc + wd_precomp, du->dk_dd.d_precompcyl / 4);
|
|
|
|
|
outb(wdc + wd_cyl_lo, cylinder);
|
|
|
|
|
outb(wdc + wd_cyl_hi, cylinder >> 8);
|
|
|
|
|
outb(wdc + wd_sdh, WDSD_IBM | (du->dk_unit << 4) | head);
|
|
|
|
|
outb(wdc + wd_sector, sector + 1);
|
|
|
|
|
outb(wdc + wd_seccnt, count);
|
|
|
|
|
}
|
Add support for busmaster DMA on some PCI IDE chipsets.
I changed a few bits here and there, mainly renaming wd82371.c
to ide_pci.c now that it's supposed to handle different chipsets.
It runs on my P6 natoma board with two Maxtor drives, and also
on a Fujitsu machine I have at work with an Opti chipset and
a Quantum drive.
Submitted by:cgull@smoke.marlboro.vt.us <John Hood>
Original readme:
*** WARNING ***
This code has so far been tested on exactly one motherboard with two
identical drives known for their good DMA support.
This code, in the right circumstances, could corrupt data subtly,
silently, and invisibly, in much the same way that older PCI IDE
controllers do. It's ALPHA-quality code; there's one or two major
gaps in my understanding of PCI IDE still. Don't use this code on any
system with data that you care about; it's only good for hack boxes.
Expect that any data may be silently and randomly corrupted at any
moment. It's a disk driver. It has bugs. Disk drivers with bugs
munch data. It's a fact of life.
I also *STRONGLY* recommend getting a copy of your chipset's manual
and the ATA-2 or ATA-3 spec and making sure that timing modes on your
disk drives and IDE controller are being setup correctly by the BIOS--
because the driver makes only the lamest of attempts to do this just
now.
*** END WARNING ***
that said, i happen to think the code is working pretty well...
WHAT IT DOES:
this code adds support to the wd driver for bus mastering PCI IDE
controllers that follow the SFF-8038 standard. (all the bus mastering
PCI IDE controllers i've seen so far do follow this standard.) it
should provide busmastering on nearly any current P5 or P6 chipset,
specifically including any Intel chipset using one of the PIIX south
bridges-- this includes the '430FX, '430VX, '430HX, '430TX, '440LX,
and (i think) the Orion '450GX chipsets. specific support is also
included for the VIA Apollo VP-1 chipset, as it appears in the
relabeled "HXPro" incarnation seen on cheap US$70 taiwanese
motherboards (that's what's in my development machine). it works out
of the box on controllers that do DMA mode2; if my understanding is
correct, it'll probably work on Ultra-DMA33 controllers as well.
it'll probably work on busmastering IDE controllers in PCI slots, too,
but this is an area i am less sure about.
it cuts CPU usage considerably and improves drive performance
slightly. usable numbers are difficult to come by with existing
benchmark tools, but experimentation on my K5-P90 system, with VIA
VP-1 chipset and Quantum Fireball 1080 drives, shows that disk i/o on
raw partitions imposes perhaps 5% cpu load. cpu load during
filesystem i/o drops a lot, from near 100% to anywhere between 30% and
70%. (the improvement may not be as large on an Intel chipset; from
what i can tell, the VIA VP-1 may not be very efficient with PCI I/O.)
disk performance improves by 5% or 10% with these drives.
real, visible, end-user performance improvement on a single user
machine is about nil. :) a kernel compile was sped up by a whole three
seconds. it *does* feel a bit better-behaved when the system is
swapping heavily, but a better disk driver is not the fix for *that*
problem.
THE CODE:
this code is a patch to wd.c and wd82371.c, and associated header
files. it should be considered alpha code; more work needs to be
done.
wd.c has fairly clean patches to add calls to busmaster code, as
implemented in wd82371.c and potentially elsewhere (one could imagine,
say, a Mac having a different DMA controller).
wd82371.c has been considerably reworked: the wddma interface that it
presents has been changed (expect more changes), many bugs have been
fixed, a new internal interface has been added for supporting
different chipsets, and the PCI probe has been considerably extended.
the interface between wd82371.c and wd.c is still fairly clean, but
i'm not sure it's in the right place. there's a mess of issues around
ATA/ATAPI that need to be sorted out, including ATAPI support, CD-ROM
support, tape support, LS-120/Zip support, SFF-8038i DMA, UltraDMA,
PCI IDE controllers, bus probes, buggy controllers, controller timing
setup, drive timing setup, world peace and kitchen sinks. whatever
happens with all this and however it gets partitioned, it is fairly
clear that wd.c needs some significant rework-- probably a complete
rewrite.
timing setup on disk controllers is something i've entirely punted on.
on my development machine, it appears that the BIOS does at least some
of the necessary timing setup. i chose to restrict operation to
drives that are already configured for Mode4 PIO and Mode2 multiword
DMA, since the timing is essentially the same and many if not most
chipsets use the same control registers for DMA and PIO timing.
does anybody *know* whether BIOSes are required to do timing setup for
DMA modes on drives under their care?
error recovery is probably weak. early on in development, i was
getting drive errors induced by bugs in the driver; i used these to
flush out the worst of the bugs in the driver's error handling, but
problems may remain. i haven't got a drive with bad sectors i can
watch the driver flail on.
complaints about how wd82371.c has been reindented will be ignored
until the FreeBSD project has a real style policy, there is a
mechanism for individual authors to match it (indent flags or an emacs
c-mode or whatever), and it is enforced. if i'm going to use a source
style i don't like, it would help if i could figure out what it *is*
(style(9) is about half of a policy), and a way to reasonably
duplicate it. i ended up wasting a while trying to figure out what
the right thing to do was before deciding reformatting the whole thing
was the worst possible thing to do, except for all the other
possibilities.
i have maintained wd.c's indentation; that was not too hard,
fortunately.
TO INSTALL:
my dev box is freebsd 2.2.2 release. fortunately, wd.c is a living
fossil, and has diverged very little recently. included in this
tarball is a patch file, 'otherdiffs', for all files except wd82371.c,
my edited wd82371.c, a patch file, 'wd82371.c-diff-exact', against the
2.2.2 dist of 82371.c, and another patch file,
'wd82371.c-diff-whitespace', generated with diff -b (ignore
whitespace). most of you not using 2.2.2 will probably have to use
this last patchfile with 'patch --ignore-whitespace'. apply from the
kernel source tree root. as far as i can tell, this should apply
cleanly on anything from -current back to 2.2.2 and probably back to
2.2.0. you, the kernel hacker, can figure out what to do from here.
if you need more specific directions, you probably should not be
experimenting with this code yet.
to enable DMA support, set flag 0x2000 for that drive in your config
file or in userconfig, as you would the 32-bit-PIO flag. the driver
will then turn on DMA support if your drive and controller pass its
tests. it's a bit picky, probably. on discovering DMA mode failures
or disk errors or transfers that the DMA controller can't deal with,
the driver will fall back to PIO, so it is wise to setup the flags as
if PIO were still important.
'controller wdc0 at isa? port "IO_WD1" bio irq 14 flags 0xa0ffa0ff
vector wdintr' should work with nearly any PCI IDE controller.
i would *strongly* suggest booting single-user at first, and thrashing
the drive a bit while it's still mounted read-only. this should be
fairly safe, even if the driver goes completely out to lunch. it
might save you a reinstall.
one way to tell whether the driver is really using DMA is to check the
interrupt count during disk i/o with vmstat; DMA mode will add an
extremely low number of interrupts, as compared to even multi-sector
PIO.
boot -v will give you a copious register dump of timing-related info
on Intel and VIAtech chipsets, as well as PIO/DMA mode information on
all hard drives. refer to your ATA and chipset documentation to
interpret these.
WHAT I'D LIKE FROM YOU and THINGS TO TEST:
reports. success reports, failure reports, any kind of reports. :)
send them to cgull+ide@smoke.marlboro.vt.us.
i'd also like to see the kernel messages from various BIOSes (boot -v;
dmesg), along with info on the motherboard and BIOS on that machine.
i'm especially interested in reports on how this code works on the
various Intel chipsets, and whether the register dump works
correctly. i'm also interested in hearing about other chipsets.
i'm especially interested in hearing success/failure reports for PCI
IDE controllers on cards, such as CMD's or Promise's new busmastering
IDE controllers.
UltraDMA-33 reports.
interoperation with ATAPI peripherals-- FreeBSD doesn't work with my
old Hitachi IDE CDROM, so i can't tell if I've broken anything. :)
i'd especially like to hear how the drive copes in DMA operation on
drives with bad sectors. i haven't been able to find any such yet.
success/failure reports on older IDE drives with early support for DMA
modes-- those introduced between 1.5 and 3 years ago, typically
ranging from perhaps 400MB to 1.6GB.
failure reports on operation with more than one drive would be
appreciated. the driver was developed with two drives on one
controller, the worst-case situation, and has been tested with one
drive on each controller, but you never know...
any reports of messages from the driver during normal operation,
especially "reverting to PIO mode", or "dmaverify odd vaddr or length"
(the DMA controller is strongly halfword oriented, and i'm curious to
know if any FreeBSD usage actually needs misaligned transfers).
performance reports. beware that bonnie's CPU usage reporting is
useless for IDE drives; the best test i've found has been to run a
program that runs a spin loop at an idle priority and reports how many
iterations it manages, and even that sometimes produces numbers i
don't believe. performance reports of multi-drive operation are
especially interesting; my system cannot sustain full throughput on
two drives on separate controllers, but that may just be a lame
motherboard.
THINGS I'M STILL MISSING CLUE ON:
* who's responsible for configuring DMA timing modes on IDE drives?
the BIOS or the driver?
* is there a spec for dealing with Ultra-DMA extensions?
* are there any chipsets or with bugs relating to DMA transfer that
should be blacklisted?
* are there any ATA interfaces that use some other kind of DMA
controller in conjunction with standard ATA protocol?
FINAL NOTE:
after having looked at the ATA-3 spec, all i can say is, "it's ugly".
*especially* electrically. the IDE bus is best modeled as an
unterminated transmission line, these days.
for maximum reliability, keep your IDE cables as short as possible and
as few as possible. from what i can tell, most current chipsets have
both IDE ports wired into a single buss, to a greater or lesser
degree. using two cables means you double the length of this bus.
SCSI may have its warts, but at least the basic analog design of the
bus is still somewhat reasonable. IDE passed beyond the veil two
years ago.
--John Hood, cgull@smoke.marlboro.vt.us
1997-07-29 12:57:25 +00:00
|
|
|
if (wdwait(du, (command == WDCC_DIAGNOSE || command == WDCC_IDC)
|
1994-02-11 12:02:35 +00:00
|
|
|
? 0 : WDCS_READY, TIMEOUT) < 0)
|
1994-02-01 05:55:21 +00:00
|
|
|
return (1);
|
|
|
|
|
outb(wdc + wd_command, command);
|
1994-01-04 20:05:26 +00:00
|
|
|
return (0);
|
1993-06-12 14:58:17 +00:00
|
|
|
}
|
|
|
|
|
|
1996-08-23 02:52:44 +00:00
|
|
|
static void
|
|
|
|
|
wdsetmulti(struct disk *du)
|
|
|
|
|
{
|
|
|
|
|
/*
|
|
|
|
|
* The config option flags low 8 bits define the maximum multi-block
|
|
|
|
|
* transfer size. If the user wants the maximum that the drive
|
|
|
|
|
* is capable of, just set the low bits of the config option to
|
|
|
|
|
* 0x00ff.
|
|
|
|
|
*/
|
|
|
|
|
if ((du->cfg_flags & WDOPT_MULTIMASK) != 0 && (du->dk_multi > 1)) {
|
|
|
|
|
int configval = du->cfg_flags & WDOPT_MULTIMASK;
|
|
|
|
|
du->dk_multi = min(du->dk_multi, configval);
|
|
|
|
|
if (wdcommand(du, 0, 0, 0, du->dk_multi, WDCC_SET_MULTI)) {
|
|
|
|
|
du->dk_multi = 1;
|
|
|
|
|
} else {
|
|
|
|
|
if (wdwait(du, WDCS_READY, TIMEOUT) < 0) {
|
|
|
|
|
du->dk_multi = 1;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
} else {
|
|
|
|
|
du->dk_multi = 1;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
1993-06-12 14:58:17 +00:00
|
|
|
/*
|
|
|
|
|
* issue IDC to drive to tell it just what geometry it is to be.
|
|
|
|
|
*/
|
|
|
|
|
static int
|
1994-01-04 20:05:26 +00:00
|
|
|
wdsetctlr(struct disk *du)
|
|
|
|
|
{
|
1994-04-20 07:06:57 +00:00
|
|
|
int error = 0;
|
1994-02-01 05:55:21 +00:00
|
|
|
#ifdef WDDEBUG
|
|
|
|
|
printf("wd(%d,%d): wdsetctlr: C %lu H %lu S %lu\n",
|
|
|
|
|
du->dk_ctrlr, du->dk_unit,
|
|
|
|
|
du->dk_dd.d_ncylinders, du->dk_dd.d_ntracks,
|
|
|
|
|
du->dk_dd.d_nsectors);
|
1994-01-04 20:05:26 +00:00
|
|
|
#endif
|
1994-03-04 16:43:07 +00:00
|
|
|
if (du->dk_dd.d_ntracks == 0 || du->dk_dd.d_ntracks > 16) {
|
|
|
|
|
struct wdparams *wp;
|
|
|
|
|
|
|
|
|
|
printf("wd%d: can't handle %lu heads from partition table ",
|
1994-02-01 05:55:21 +00:00
|
|
|
du->dk_lunit, du->dk_dd.d_ntracks);
|
1994-03-04 16:43:07 +00:00
|
|
|
/* obtain parameters */
|
|
|
|
|
wp = &du->dk_params;
|
|
|
|
|
if (wp->wdp_heads > 0 && wp->wdp_heads <= 16) {
|
1995-05-09 12:26:00 +00:00
|
|
|
printf("(controller value %u restored)\n",
|
1994-03-04 16:43:07 +00:00
|
|
|
wp->wdp_heads);
|
|
|
|
|
du->dk_dd.d_ntracks = wp->wdp_heads;
|
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
printf("(truncating to 16)\n");
|
1994-04-20 07:06:57 +00:00
|
|
|
du->dk_dd.d_ntracks = 16;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (du->dk_dd.d_nsectors == 0 || du->dk_dd.d_nsectors > 255) {
|
|
|
|
|
printf("wd%d: cannot handle %lu sectors (max 255)\n",
|
|
|
|
|
du->dk_lunit, du->dk_dd.d_nsectors);
|
|
|
|
|
error = 1;
|
1994-02-01 05:55:21 +00:00
|
|
|
}
|
1994-04-20 07:06:57 +00:00
|
|
|
if (error) {
|
1997-03-11 23:17:28 +00:00
|
|
|
#ifdef CMD640
|
|
|
|
|
wdtab[du->dk_ctrlr_cmd640].b_errcnt += RETRIES;
|
|
|
|
|
#else
|
1994-04-20 07:06:57 +00:00
|
|
|
wdtab[du->dk_ctrlr].b_errcnt += RETRIES;
|
1997-03-11 23:17:28 +00:00
|
|
|
#endif
|
1994-04-20 07:06:57 +00:00
|
|
|
return (1);
|
1994-03-04 16:43:07 +00:00
|
|
|
}
|
1994-01-04 20:05:26 +00:00
|
|
|
if (wdcommand(du, du->dk_dd.d_ncylinders, du->dk_dd.d_ntracks - 1, 0,
|
|
|
|
|
du->dk_dd.d_nsectors, WDCC_IDC) != 0
|
1994-03-04 16:43:07 +00:00
|
|
|
|| wdwait(du, WDCS_READY, TIMEOUT) < 0) {
|
1994-01-04 20:05:26 +00:00
|
|
|
wderror((struct buf *)NULL, du, "wdsetctlr failed");
|
|
|
|
|
return (1);
|
|
|
|
|
}
|
1996-07-27 19:01:10 +00:00
|
|
|
|
1996-08-23 02:52:44 +00:00
|
|
|
wdsetmulti(du);
|
1996-07-27 19:01:10 +00:00
|
|
|
|
|
|
|
|
#ifdef NOTYET
|
|
|
|
|
/* set read caching and write caching */
|
|
|
|
|
wdcommand(du, 0, 0, 0, WDFEA_RCACHE, WDCC_FEATURES);
|
1996-08-23 02:52:44 +00:00
|
|
|
wdwait(du, WDCS_READY, TIMEOUT);
|
|
|
|
|
|
1996-07-27 19:01:10 +00:00
|
|
|
wdcommand(du, 0, 0, 0, WDFEA_WCACHE, WDCC_FEATURES);
|
1996-08-23 02:52:44 +00:00
|
|
|
wdwait(du, WDCS_READY, TIMEOUT);
|
1996-07-27 19:01:10 +00:00
|
|
|
#endif
|
|
|
|
|
|
1994-01-04 20:05:26 +00:00
|
|
|
return (0);
|
|
|
|
|
}
|
1993-06-12 14:58:17 +00:00
|
|
|
|
1996-06-12 05:11:41 +00:00
|
|
|
#if 0
|
1994-01-04 20:05:26 +00:00
|
|
|
/*
|
|
|
|
|
* Wait until driver is inactive, then set up controller.
|
|
|
|
|
*/
|
|
|
|
|
static int
|
|
|
|
|
wdwsetctlr(struct disk *du)
|
|
|
|
|
{
|
1994-02-01 05:55:21 +00:00
|
|
|
int stat;
|
|
|
|
|
int x;
|
1993-06-12 14:58:17 +00:00
|
|
|
|
1994-01-04 20:05:26 +00:00
|
|
|
wdsleep(du->dk_ctrlr, "wdwset");
|
1993-06-12 14:58:17 +00:00
|
|
|
x = splbio();
|
1994-01-04 20:05:26 +00:00
|
|
|
stat = wdsetctlr(du);
|
1994-02-01 05:55:21 +00:00
|
|
|
wdflushirq(du, x);
|
1993-06-12 14:58:17 +00:00
|
|
|
splx(x);
|
1994-01-04 20:05:26 +00:00
|
|
|
return (stat);
|
1993-06-12 14:58:17 +00:00
|
|
|
}
|
1996-06-12 05:11:41 +00:00
|
|
|
#endif
|
1993-06-12 14:58:17 +00:00
|
|
|
|
Add support for busmaster DMA on some PCI IDE chipsets.
I changed a few bits here and there, mainly renaming wd82371.c
to ide_pci.c now that it's supposed to handle different chipsets.
It runs on my P6 natoma board with two Maxtor drives, and also
on a Fujitsu machine I have at work with an Opti chipset and
a Quantum drive.
Submitted by:cgull@smoke.marlboro.vt.us <John Hood>
Original readme:
*** WARNING ***
This code has so far been tested on exactly one motherboard with two
identical drives known for their good DMA support.
This code, in the right circumstances, could corrupt data subtly,
silently, and invisibly, in much the same way that older PCI IDE
controllers do. It's ALPHA-quality code; there's one or two major
gaps in my understanding of PCI IDE still. Don't use this code on any
system with data that you care about; it's only good for hack boxes.
Expect that any data may be silently and randomly corrupted at any
moment. It's a disk driver. It has bugs. Disk drivers with bugs
munch data. It's a fact of life.
I also *STRONGLY* recommend getting a copy of your chipset's manual
and the ATA-2 or ATA-3 spec and making sure that timing modes on your
disk drives and IDE controller are being setup correctly by the BIOS--
because the driver makes only the lamest of attempts to do this just
now.
*** END WARNING ***
that said, i happen to think the code is working pretty well...
WHAT IT DOES:
this code adds support to the wd driver for bus mastering PCI IDE
controllers that follow the SFF-8038 standard. (all the bus mastering
PCI IDE controllers i've seen so far do follow this standard.) it
should provide busmastering on nearly any current P5 or P6 chipset,
specifically including any Intel chipset using one of the PIIX south
bridges-- this includes the '430FX, '430VX, '430HX, '430TX, '440LX,
and (i think) the Orion '450GX chipsets. specific support is also
included for the VIA Apollo VP-1 chipset, as it appears in the
relabeled "HXPro" incarnation seen on cheap US$70 taiwanese
motherboards (that's what's in my development machine). it works out
of the box on controllers that do DMA mode2; if my understanding is
correct, it'll probably work on Ultra-DMA33 controllers as well.
it'll probably work on busmastering IDE controllers in PCI slots, too,
but this is an area i am less sure about.
it cuts CPU usage considerably and improves drive performance
slightly. usable numbers are difficult to come by with existing
benchmark tools, but experimentation on my K5-P90 system, with VIA
VP-1 chipset and Quantum Fireball 1080 drives, shows that disk i/o on
raw partitions imposes perhaps 5% cpu load. cpu load during
filesystem i/o drops a lot, from near 100% to anywhere between 30% and
70%. (the improvement may not be as large on an Intel chipset; from
what i can tell, the VIA VP-1 may not be very efficient with PCI I/O.)
disk performance improves by 5% or 10% with these drives.
real, visible, end-user performance improvement on a single user
machine is about nil. :) a kernel compile was sped up by a whole three
seconds. it *does* feel a bit better-behaved when the system is
swapping heavily, but a better disk driver is not the fix for *that*
problem.
THE CODE:
this code is a patch to wd.c and wd82371.c, and associated header
files. it should be considered alpha code; more work needs to be
done.
wd.c has fairly clean patches to add calls to busmaster code, as
implemented in wd82371.c and potentially elsewhere (one could imagine,
say, a Mac having a different DMA controller).
wd82371.c has been considerably reworked: the wddma interface that it
presents has been changed (expect more changes), many bugs have been
fixed, a new internal interface has been added for supporting
different chipsets, and the PCI probe has been considerably extended.
the interface between wd82371.c and wd.c is still fairly clean, but
i'm not sure it's in the right place. there's a mess of issues around
ATA/ATAPI that need to be sorted out, including ATAPI support, CD-ROM
support, tape support, LS-120/Zip support, SFF-8038i DMA, UltraDMA,
PCI IDE controllers, bus probes, buggy controllers, controller timing
setup, drive timing setup, world peace and kitchen sinks. whatever
happens with all this and however it gets partitioned, it is fairly
clear that wd.c needs some significant rework-- probably a complete
rewrite.
timing setup on disk controllers is something i've entirely punted on.
on my development machine, it appears that the BIOS does at least some
of the necessary timing setup. i chose to restrict operation to
drives that are already configured for Mode4 PIO and Mode2 multiword
DMA, since the timing is essentially the same and many if not most
chipsets use the same control registers for DMA and PIO timing.
does anybody *know* whether BIOSes are required to do timing setup for
DMA modes on drives under their care?
error recovery is probably weak. early on in development, i was
getting drive errors induced by bugs in the driver; i used these to
flush out the worst of the bugs in the driver's error handling, but
problems may remain. i haven't got a drive with bad sectors i can
watch the driver flail on.
complaints about how wd82371.c has been reindented will be ignored
until the FreeBSD project has a real style policy, there is a
mechanism for individual authors to match it (indent flags or an emacs
c-mode or whatever), and it is enforced. if i'm going to use a source
style i don't like, it would help if i could figure out what it *is*
(style(9) is about half of a policy), and a way to reasonably
duplicate it. i ended up wasting a while trying to figure out what
the right thing to do was before deciding reformatting the whole thing
was the worst possible thing to do, except for all the other
possibilities.
i have maintained wd.c's indentation; that was not too hard,
fortunately.
TO INSTALL:
my dev box is freebsd 2.2.2 release. fortunately, wd.c is a living
fossil, and has diverged very little recently. included in this
tarball is a patch file, 'otherdiffs', for all files except wd82371.c,
my edited wd82371.c, a patch file, 'wd82371.c-diff-exact', against the
2.2.2 dist of 82371.c, and another patch file,
'wd82371.c-diff-whitespace', generated with diff -b (ignore
whitespace). most of you not using 2.2.2 will probably have to use
this last patchfile with 'patch --ignore-whitespace'. apply from the
kernel source tree root. as far as i can tell, this should apply
cleanly on anything from -current back to 2.2.2 and probably back to
2.2.0. you, the kernel hacker, can figure out what to do from here.
if you need more specific directions, you probably should not be
experimenting with this code yet.
to enable DMA support, set flag 0x2000 for that drive in your config
file or in userconfig, as you would the 32-bit-PIO flag. the driver
will then turn on DMA support if your drive and controller pass its
tests. it's a bit picky, probably. on discovering DMA mode failures
or disk errors or transfers that the DMA controller can't deal with,
the driver will fall back to PIO, so it is wise to setup the flags as
if PIO were still important.
'controller wdc0 at isa? port "IO_WD1" bio irq 14 flags 0xa0ffa0ff
vector wdintr' should work with nearly any PCI IDE controller.
i would *strongly* suggest booting single-user at first, and thrashing
the drive a bit while it's still mounted read-only. this should be
fairly safe, even if the driver goes completely out to lunch. it
might save you a reinstall.
one way to tell whether the driver is really using DMA is to check the
interrupt count during disk i/o with vmstat; DMA mode will add an
extremely low number of interrupts, as compared to even multi-sector
PIO.
boot -v will give you a copious register dump of timing-related info
on Intel and VIAtech chipsets, as well as PIO/DMA mode information on
all hard drives. refer to your ATA and chipset documentation to
interpret these.
WHAT I'D LIKE FROM YOU and THINGS TO TEST:
reports. success reports, failure reports, any kind of reports. :)
send them to cgull+ide@smoke.marlboro.vt.us.
i'd also like to see the kernel messages from various BIOSes (boot -v;
dmesg), along with info on the motherboard and BIOS on that machine.
i'm especially interested in reports on how this code works on the
various Intel chipsets, and whether the register dump works
correctly. i'm also interested in hearing about other chipsets.
i'm especially interested in hearing success/failure reports for PCI
IDE controllers on cards, such as CMD's or Promise's new busmastering
IDE controllers.
UltraDMA-33 reports.
interoperation with ATAPI peripherals-- FreeBSD doesn't work with my
old Hitachi IDE CDROM, so i can't tell if I've broken anything. :)
i'd especially like to hear how the drive copes in DMA operation on
drives with bad sectors. i haven't been able to find any such yet.
success/failure reports on older IDE drives with early support for DMA
modes-- those introduced between 1.5 and 3 years ago, typically
ranging from perhaps 400MB to 1.6GB.
failure reports on operation with more than one drive would be
appreciated. the driver was developed with two drives on one
controller, the worst-case situation, and has been tested with one
drive on each controller, but you never know...
any reports of messages from the driver during normal operation,
especially "reverting to PIO mode", or "dmaverify odd vaddr or length"
(the DMA controller is strongly halfword oriented, and i'm curious to
know if any FreeBSD usage actually needs misaligned transfers).
performance reports. beware that bonnie's CPU usage reporting is
useless for IDE drives; the best test i've found has been to run a
program that runs a spin loop at an idle priority and reports how many
iterations it manages, and even that sometimes produces numbers i
don't believe. performance reports of multi-drive operation are
especially interesting; my system cannot sustain full throughput on
two drives on separate controllers, but that may just be a lame
motherboard.
THINGS I'M STILL MISSING CLUE ON:
* who's responsible for configuring DMA timing modes on IDE drives?
the BIOS or the driver?
* is there a spec for dealing with Ultra-DMA extensions?
* are there any chipsets or with bugs relating to DMA transfer that
should be blacklisted?
* are there any ATA interfaces that use some other kind of DMA
controller in conjunction with standard ATA protocol?
FINAL NOTE:
after having looked at the ATA-3 spec, all i can say is, "it's ugly".
*especially* electrically. the IDE bus is best modeled as an
unterminated transmission line, these days.
for maximum reliability, keep your IDE cables as short as possible and
as few as possible. from what i can tell, most current chipsets have
both IDE ports wired into a single buss, to a greater or lesser
degree. using two cables means you double the length of this bus.
SCSI may have its warts, but at least the basic analog design of the
bus is still somewhat reasonable. IDE passed beyond the veil two
years ago.
--John Hood, cgull@smoke.marlboro.vt.us
1997-07-29 12:57:25 +00:00
|
|
|
/*
|
|
|
|
|
* gross little callback function for wdddma interface. returns 1 for
|
|
|
|
|
* success, 0 for failure.
|
|
|
|
|
*/
|
|
|
|
|
static int
|
|
|
|
|
wdsetmode(int mode, void *wdinfo)
|
|
|
|
|
{
|
|
|
|
|
int i;
|
|
|
|
|
struct disk *du;
|
|
|
|
|
|
|
|
|
|
du = wdinfo;
|
|
|
|
|
if (bootverbose)
|
|
|
|
|
printf("wdsetmode() setting transfer mode to %02x\n", mode);
|
|
|
|
|
i = wdcommand(du, 0, 0, mode, WDFEA_SETXFER,
|
|
|
|
|
WDCC_FEATURES) == 0 &&
|
|
|
|
|
wdwait(du, WDCS_READY, TIMEOUT) == 0;
|
|
|
|
|
return i;
|
|
|
|
|
}
|
|
|
|
|
|
1993-06-12 14:58:17 +00:00
|
|
|
/*
|
|
|
|
|
* issue READP to drive to ask it what it is.
|
|
|
|
|
*/
|
|
|
|
|
static int
|
1995-04-24 05:12:29 +00:00
|
|
|
wdgetctlr(struct disk *du)
|
1994-02-01 05:55:21 +00:00
|
|
|
{
|
|
|
|
|
int i;
|
1995-02-04 19:39:36 +00:00
|
|
|
char tb[DEV_BSIZE], tb2[DEV_BSIZE];
|
1995-03-22 05:23:01 +00:00
|
|
|
struct wdparams *wp = NULL;
|
1995-04-24 05:12:29 +00:00
|
|
|
u_long flags = du->cfg_flags;
|
1995-02-04 19:39:36 +00:00
|
|
|
again:
|
1994-01-04 20:05:26 +00:00
|
|
|
if (wdcommand(du, 0, 0, 0, 0, WDCC_READP) != 0
|
1994-03-04 16:43:07 +00:00
|
|
|
|| wdwait(du, WDCS_READY | WDCS_SEEKCMPLT | WDCS_DRQ, TIMEOUT) != 0) {
|
1995-03-22 05:23:01 +00:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* if we failed on the second try, assume non-32bit
|
|
|
|
|
*/
|
|
|
|
|
if( du->dk_flags & DKFL_32BIT)
|
|
|
|
|
goto failed;
|
1995-04-24 05:09:53 +00:00
|
|
|
|
1994-02-01 05:55:21 +00:00
|
|
|
/* XXX need to check error status after final transfer. */
|
1994-01-04 20:05:26 +00:00
|
|
|
/*
|
1994-02-01 05:55:21 +00:00
|
|
|
* Old drives don't support WDCC_READP. Try a seek to 0.
|
|
|
|
|
* Some IDE controllers return trash if there is no drive
|
|
|
|
|
* attached, so first test that the drive can be selected.
|
|
|
|
|
* This also avoids long waits for nonexistent drives.
|
1994-01-04 20:05:26 +00:00
|
|
|
*/
|
1994-02-11 12:02:35 +00:00
|
|
|
if (wdwait(du, 0, TIMEOUT) < 0)
|
1994-02-01 05:55:21 +00:00
|
|
|
return (1);
|
|
|
|
|
outb(du->dk_port + wd_sdh, WDSD_IBM | (du->dk_unit << 4));
|
|
|
|
|
DELAY(5000); /* usually unnecessary; drive select is fast */
|
1996-08-12 00:53:02 +00:00
|
|
|
/*
|
|
|
|
|
* Do this twice: may get a false WDCS_READY the first time.
|
|
|
|
|
*/
|
|
|
|
|
inb(du->dk_port + wd_status);
|
1994-02-01 05:55:21 +00:00
|
|
|
if ((inb(du->dk_port + wd_status) & (WDCS_BUSY | WDCS_READY))
|
|
|
|
|
!= WDCS_READY
|
|
|
|
|
|| wdcommand(du, 0, 0, 0, 0, WDCC_RESTORE | WD_STEP) != 0
|
1994-02-11 12:02:35 +00:00
|
|
|
|| wdwait(du, WDCS_READY | WDCS_SEEKCMPLT, TIMEOUT) != 0)
|
1994-01-04 20:05:26 +00:00
|
|
|
return (1);
|
|
|
|
|
|
1995-01-25 21:40:47 +00:00
|
|
|
if (du->dk_unit == bootinfo.bi_n_bios_used) {
|
1994-11-18 11:27:41 +00:00
|
|
|
du->dk_dd.d_secsize = DEV_BSIZE;
|
1995-04-24 05:09:53 +00:00
|
|
|
du->dk_dd.d_nsectors =
|
1995-01-25 21:40:47 +00:00
|
|
|
bootinfo.bi_bios_geom[du->dk_unit] & 0xff;
|
1995-04-24 05:09:53 +00:00
|
|
|
du->dk_dd.d_ntracks =
|
1995-01-25 21:40:47 +00:00
|
|
|
((bootinfo.bi_bios_geom[du->dk_unit] >> 8) & 0xff)
|
|
|
|
|
+ 1;
|
1994-11-18 11:27:41 +00:00
|
|
|
/* XXX Why 2 ? */
|
1995-04-24 05:09:53 +00:00
|
|
|
du->dk_dd.d_ncylinders =
|
1995-01-25 21:40:47 +00:00
|
|
|
(bootinfo.bi_bios_geom[du->dk_unit] >> 16) + 2;
|
1995-04-24 05:09:53 +00:00
|
|
|
du->dk_dd.d_secpercyl =
|
|
|
|
|
du->dk_dd.d_ntracks * du->dk_dd.d_nsectors;
|
|
|
|
|
du->dk_dd.d_secperunit =
|
|
|
|
|
du->dk_dd.d_secpercyl * du->dk_dd.d_ncylinders;
|
1995-04-14 22:31:58 +00:00
|
|
|
#if 0
|
1995-04-24 05:09:53 +00:00
|
|
|
du->dk_dd.d_partitions[WDRAW].p_size =
|
1994-11-18 11:27:41 +00:00
|
|
|
du->dk_dd.d_secperunit;
|
|
|
|
|
du->dk_dd.d_type = DTYPE_ST506;
|
|
|
|
|
du->dk_dd.d_subtype |= DSTYPE_GEOMETRY;
|
|
|
|
|
strncpy(du->dk_dd.d_typename, "Bios geometry",
|
|
|
|
|
sizeof du->dk_dd.d_typename);
|
|
|
|
|
strncpy(du->dk_params.wdp_model, "ST506",
|
|
|
|
|
sizeof du->dk_params.wdp_model);
|
1995-04-14 22:31:58 +00:00
|
|
|
#endif
|
1995-01-25 21:40:47 +00:00
|
|
|
bootinfo.bi_n_bios_used ++;
|
1994-11-18 11:27:41 +00:00
|
|
|
return 0;
|
|
|
|
|
}
|
1994-02-01 05:55:21 +00:00
|
|
|
/*
|
|
|
|
|
* Fake minimal drive geometry for reading the MBR.
|
|
|
|
|
* readdisklabel() may enlarge it to read the label and the
|
|
|
|
|
* bad sector table.
|
|
|
|
|
*/
|
1994-01-04 20:05:26 +00:00
|
|
|
du->dk_dd.d_secsize = DEV_BSIZE;
|
|
|
|
|
du->dk_dd.d_nsectors = 17;
|
|
|
|
|
du->dk_dd.d_ntracks = 1;
|
|
|
|
|
du->dk_dd.d_ncylinders = 1;
|
|
|
|
|
du->dk_dd.d_secpercyl = 17;
|
1994-02-01 05:55:21 +00:00
|
|
|
du->dk_dd.d_secperunit = 17;
|
|
|
|
|
|
1995-04-14 22:31:58 +00:00
|
|
|
#if 0
|
1994-02-01 05:55:21 +00:00
|
|
|
/*
|
|
|
|
|
* Fake maximal drive size for writing the label.
|
|
|
|
|
*/
|
1995-04-14 22:31:58 +00:00
|
|
|
du->dk_dd.d_partitions[RAW_PART].p_size = 64 * 16 * 1024;
|
1993-08-08 07:03:21 +00:00
|
|
|
|
1994-01-04 20:05:26 +00:00
|
|
|
/*
|
|
|
|
|
* Fake some more of the label for printing by disklabel(1)
|
|
|
|
|
* in case there is no real label.
|
|
|
|
|
*/
|
|
|
|
|
du->dk_dd.d_type = DTYPE_ST506;
|
|
|
|
|
du->dk_dd.d_subtype |= DSTYPE_GEOMETRY;
|
|
|
|
|
strncpy(du->dk_dd.d_typename, "Fake geometry",
|
1993-08-08 07:03:21 +00:00
|
|
|
sizeof du->dk_dd.d_typename);
|
1995-04-14 22:31:58 +00:00
|
|
|
#endif
|
1994-01-04 20:05:26 +00:00
|
|
|
|
|
|
|
|
/* Fake the model name for printing by wdattach(). */
|
1994-02-01 05:55:21 +00:00
|
|
|
strncpy(du->dk_params.wdp_model, "unknown",
|
1993-08-08 07:03:21 +00:00
|
|
|
sizeof du->dk_params.wdp_model);
|
1994-01-04 20:05:26 +00:00
|
|
|
|
|
|
|
|
return (0);
|
1993-06-12 14:58:17 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* obtain parameters */
|
|
|
|
|
wp = &du->dk_params;
|
1995-02-04 19:39:36 +00:00
|
|
|
if (du->dk_flags & DKFL_32BIT)
|
|
|
|
|
insl(du->dk_port + wd_data, tb, sizeof(tb) / sizeof(long));
|
|
|
|
|
else
|
|
|
|
|
insw(du->dk_port + wd_data, tb, sizeof(tb) / sizeof(short));
|
|
|
|
|
|
|
|
|
|
/* try 32-bit data path (VLB IDE controller) */
|
1995-04-24 04:32:31 +00:00
|
|
|
if (flags & WDOPT_32BIT) {
|
|
|
|
|
if (! (du->dk_flags & DKFL_32BIT)) {
|
|
|
|
|
bcopy(tb, tb2, sizeof(struct wdparams));
|
|
|
|
|
du->dk_flags |= DKFL_32BIT;
|
|
|
|
|
goto again;
|
|
|
|
|
}
|
1995-02-04 19:39:36 +00:00
|
|
|
|
1995-04-24 04:32:31 +00:00
|
|
|
/* check that we really have 32-bit controller */
|
|
|
|
|
if (bcmp (tb, tb2, sizeof(struct wdparams)) != 0) {
|
1995-03-22 05:23:01 +00:00
|
|
|
failed:
|
1995-04-24 04:32:31 +00:00
|
|
|
/* test failed, use 16-bit i/o mode */
|
|
|
|
|
bcopy(tb2, tb, sizeof(struct wdparams));
|
|
|
|
|
du->dk_flags &= ~DKFL_32BIT;
|
|
|
|
|
}
|
1995-02-04 19:39:36 +00:00
|
|
|
}
|
|
|
|
|
|
1993-06-12 14:58:17 +00:00
|
|
|
bcopy(tb, wp, sizeof(struct wdparams));
|
|
|
|
|
|
|
|
|
|
/* shuffle string byte order */
|
1994-02-01 05:55:21 +00:00
|
|
|
for (i = 0; i < sizeof(wp->wdp_model); i += 2) {
|
1993-06-12 14:58:17 +00:00
|
|
|
u_short *p;
|
1994-02-01 05:55:21 +00:00
|
|
|
|
1993-06-12 14:58:17 +00:00
|
|
|
p = (u_short *) (wp->wdp_model + i);
|
|
|
|
|
*p = ntohs(*p);
|
|
|
|
|
}
|
1994-02-22 22:13:37 +00:00
|
|
|
/*
|
|
|
|
|
* Clean up the wdp_model by converting nulls to spaces, and
|
|
|
|
|
* then removing the trailing spaces.
|
|
|
|
|
*/
|
|
|
|
|
for (i=0; i < sizeof(wp->wdp_model); i++) {
|
1994-02-22 18:51:27 +00:00
|
|
|
if (wp->wdp_model[i] == '\0') {
|
|
|
|
|
wp->wdp_model[i] = ' ';
|
|
|
|
|
}
|
|
|
|
|
}
|
1994-02-22 22:13:37 +00:00
|
|
|
for (i=sizeof(wp->wdp_model)-1; i>=0 && wp->wdp_model[i]==' '; i--) {
|
|
|
|
|
wp->wdp_model[i] = '\0';
|
|
|
|
|
}
|
1994-02-22 18:51:27 +00:00
|
|
|
|
1996-08-23 02:52:44 +00:00
|
|
|
/*
|
|
|
|
|
* find out the drives maximum multi-block transfer capability
|
|
|
|
|
*/
|
|
|
|
|
du->dk_multi = wp->wdp_nsecperint & 0xff;
|
|
|
|
|
wdsetmulti(du);
|
|
|
|
|
|
Add support for busmaster DMA on some PCI IDE chipsets.
I changed a few bits here and there, mainly renaming wd82371.c
to ide_pci.c now that it's supposed to handle different chipsets.
It runs on my P6 natoma board with two Maxtor drives, and also
on a Fujitsu machine I have at work with an Opti chipset and
a Quantum drive.
Submitted by:cgull@smoke.marlboro.vt.us <John Hood>
Original readme:
*** WARNING ***
This code has so far been tested on exactly one motherboard with two
identical drives known for their good DMA support.
This code, in the right circumstances, could corrupt data subtly,
silently, and invisibly, in much the same way that older PCI IDE
controllers do. It's ALPHA-quality code; there's one or two major
gaps in my understanding of PCI IDE still. Don't use this code on any
system with data that you care about; it's only good for hack boxes.
Expect that any data may be silently and randomly corrupted at any
moment. It's a disk driver. It has bugs. Disk drivers with bugs
munch data. It's a fact of life.
I also *STRONGLY* recommend getting a copy of your chipset's manual
and the ATA-2 or ATA-3 spec and making sure that timing modes on your
disk drives and IDE controller are being setup correctly by the BIOS--
because the driver makes only the lamest of attempts to do this just
now.
*** END WARNING ***
that said, i happen to think the code is working pretty well...
WHAT IT DOES:
this code adds support to the wd driver for bus mastering PCI IDE
controllers that follow the SFF-8038 standard. (all the bus mastering
PCI IDE controllers i've seen so far do follow this standard.) it
should provide busmastering on nearly any current P5 or P6 chipset,
specifically including any Intel chipset using one of the PIIX south
bridges-- this includes the '430FX, '430VX, '430HX, '430TX, '440LX,
and (i think) the Orion '450GX chipsets. specific support is also
included for the VIA Apollo VP-1 chipset, as it appears in the
relabeled "HXPro" incarnation seen on cheap US$70 taiwanese
motherboards (that's what's in my development machine). it works out
of the box on controllers that do DMA mode2; if my understanding is
correct, it'll probably work on Ultra-DMA33 controllers as well.
it'll probably work on busmastering IDE controllers in PCI slots, too,
but this is an area i am less sure about.
it cuts CPU usage considerably and improves drive performance
slightly. usable numbers are difficult to come by with existing
benchmark tools, but experimentation on my K5-P90 system, with VIA
VP-1 chipset and Quantum Fireball 1080 drives, shows that disk i/o on
raw partitions imposes perhaps 5% cpu load. cpu load during
filesystem i/o drops a lot, from near 100% to anywhere between 30% and
70%. (the improvement may not be as large on an Intel chipset; from
what i can tell, the VIA VP-1 may not be very efficient with PCI I/O.)
disk performance improves by 5% or 10% with these drives.
real, visible, end-user performance improvement on a single user
machine is about nil. :) a kernel compile was sped up by a whole three
seconds. it *does* feel a bit better-behaved when the system is
swapping heavily, but a better disk driver is not the fix for *that*
problem.
THE CODE:
this code is a patch to wd.c and wd82371.c, and associated header
files. it should be considered alpha code; more work needs to be
done.
wd.c has fairly clean patches to add calls to busmaster code, as
implemented in wd82371.c and potentially elsewhere (one could imagine,
say, a Mac having a different DMA controller).
wd82371.c has been considerably reworked: the wddma interface that it
presents has been changed (expect more changes), many bugs have been
fixed, a new internal interface has been added for supporting
different chipsets, and the PCI probe has been considerably extended.
the interface between wd82371.c and wd.c is still fairly clean, but
i'm not sure it's in the right place. there's a mess of issues around
ATA/ATAPI that need to be sorted out, including ATAPI support, CD-ROM
support, tape support, LS-120/Zip support, SFF-8038i DMA, UltraDMA,
PCI IDE controllers, bus probes, buggy controllers, controller timing
setup, drive timing setup, world peace and kitchen sinks. whatever
happens with all this and however it gets partitioned, it is fairly
clear that wd.c needs some significant rework-- probably a complete
rewrite.
timing setup on disk controllers is something i've entirely punted on.
on my development machine, it appears that the BIOS does at least some
of the necessary timing setup. i chose to restrict operation to
drives that are already configured for Mode4 PIO and Mode2 multiword
DMA, since the timing is essentially the same and many if not most
chipsets use the same control registers for DMA and PIO timing.
does anybody *know* whether BIOSes are required to do timing setup for
DMA modes on drives under their care?
error recovery is probably weak. early on in development, i was
getting drive errors induced by bugs in the driver; i used these to
flush out the worst of the bugs in the driver's error handling, but
problems may remain. i haven't got a drive with bad sectors i can
watch the driver flail on.
complaints about how wd82371.c has been reindented will be ignored
until the FreeBSD project has a real style policy, there is a
mechanism for individual authors to match it (indent flags or an emacs
c-mode or whatever), and it is enforced. if i'm going to use a source
style i don't like, it would help if i could figure out what it *is*
(style(9) is about half of a policy), and a way to reasonably
duplicate it. i ended up wasting a while trying to figure out what
the right thing to do was before deciding reformatting the whole thing
was the worst possible thing to do, except for all the other
possibilities.
i have maintained wd.c's indentation; that was not too hard,
fortunately.
TO INSTALL:
my dev box is freebsd 2.2.2 release. fortunately, wd.c is a living
fossil, and has diverged very little recently. included in this
tarball is a patch file, 'otherdiffs', for all files except wd82371.c,
my edited wd82371.c, a patch file, 'wd82371.c-diff-exact', against the
2.2.2 dist of 82371.c, and another patch file,
'wd82371.c-diff-whitespace', generated with diff -b (ignore
whitespace). most of you not using 2.2.2 will probably have to use
this last patchfile with 'patch --ignore-whitespace'. apply from the
kernel source tree root. as far as i can tell, this should apply
cleanly on anything from -current back to 2.2.2 and probably back to
2.2.0. you, the kernel hacker, can figure out what to do from here.
if you need more specific directions, you probably should not be
experimenting with this code yet.
to enable DMA support, set flag 0x2000 for that drive in your config
file or in userconfig, as you would the 32-bit-PIO flag. the driver
will then turn on DMA support if your drive and controller pass its
tests. it's a bit picky, probably. on discovering DMA mode failures
or disk errors or transfers that the DMA controller can't deal with,
the driver will fall back to PIO, so it is wise to setup the flags as
if PIO were still important.
'controller wdc0 at isa? port "IO_WD1" bio irq 14 flags 0xa0ffa0ff
vector wdintr' should work with nearly any PCI IDE controller.
i would *strongly* suggest booting single-user at first, and thrashing
the drive a bit while it's still mounted read-only. this should be
fairly safe, even if the driver goes completely out to lunch. it
might save you a reinstall.
one way to tell whether the driver is really using DMA is to check the
interrupt count during disk i/o with vmstat; DMA mode will add an
extremely low number of interrupts, as compared to even multi-sector
PIO.
boot -v will give you a copious register dump of timing-related info
on Intel and VIAtech chipsets, as well as PIO/DMA mode information on
all hard drives. refer to your ATA and chipset documentation to
interpret these.
WHAT I'D LIKE FROM YOU and THINGS TO TEST:
reports. success reports, failure reports, any kind of reports. :)
send them to cgull+ide@smoke.marlboro.vt.us.
i'd also like to see the kernel messages from various BIOSes (boot -v;
dmesg), along with info on the motherboard and BIOS on that machine.
i'm especially interested in reports on how this code works on the
various Intel chipsets, and whether the register dump works
correctly. i'm also interested in hearing about other chipsets.
i'm especially interested in hearing success/failure reports for PCI
IDE controllers on cards, such as CMD's or Promise's new busmastering
IDE controllers.
UltraDMA-33 reports.
interoperation with ATAPI peripherals-- FreeBSD doesn't work with my
old Hitachi IDE CDROM, so i can't tell if I've broken anything. :)
i'd especially like to hear how the drive copes in DMA operation on
drives with bad sectors. i haven't been able to find any such yet.
success/failure reports on older IDE drives with early support for DMA
modes-- those introduced between 1.5 and 3 years ago, typically
ranging from perhaps 400MB to 1.6GB.
failure reports on operation with more than one drive would be
appreciated. the driver was developed with two drives on one
controller, the worst-case situation, and has been tested with one
drive on each controller, but you never know...
any reports of messages from the driver during normal operation,
especially "reverting to PIO mode", or "dmaverify odd vaddr or length"
(the DMA controller is strongly halfword oriented, and i'm curious to
know if any FreeBSD usage actually needs misaligned transfers).
performance reports. beware that bonnie's CPU usage reporting is
useless for IDE drives; the best test i've found has been to run a
program that runs a spin loop at an idle priority and reports how many
iterations it manages, and even that sometimes produces numbers i
don't believe. performance reports of multi-drive operation are
especially interesting; my system cannot sustain full throughput on
two drives on separate controllers, but that may just be a lame
motherboard.
THINGS I'M STILL MISSING CLUE ON:
* who's responsible for configuring DMA timing modes on IDE drives?
the BIOS or the driver?
* is there a spec for dealing with Ultra-DMA extensions?
* are there any chipsets or with bugs relating to DMA transfer that
should be blacklisted?
* are there any ATA interfaces that use some other kind of DMA
controller in conjunction with standard ATA protocol?
FINAL NOTE:
after having looked at the ATA-3 spec, all i can say is, "it's ugly".
*especially* electrically. the IDE bus is best modeled as an
unterminated transmission line, these days.
for maximum reliability, keep your IDE cables as short as possible and
as few as possible. from what i can tell, most current chipsets have
both IDE ports wired into a single buss, to a greater or lesser
degree. using two cables means you double the length of this bus.
SCSI may have its warts, but at least the basic analog design of the
bus is still somewhat reasonable. IDE passed beyond the veil two
years ago.
--John Hood, cgull@smoke.marlboro.vt.us
1997-07-29 12:57:25 +00:00
|
|
|
du->dk_dmacookie = NULL;
|
|
|
|
|
/*
|
|
|
|
|
* check drive's DMA capability
|
|
|
|
|
*/
|
|
|
|
|
/* does user want this? */
|
|
|
|
|
if ((du->cfg_flags & WDOPT_DMA) &&
|
|
|
|
|
/* have we got a DMA controller? */
|
|
|
|
|
(wddma.wdd_candma &&
|
|
|
|
|
(du->dk_dmacookie = wddma.wdd_candma(du->dk_port,
|
|
|
|
|
du->dk_unit))) &&
|
|
|
|
|
/* can said drive do DMA? */
|
|
|
|
|
(wddma.wdd_dmainit(du->dk_dmacookie, wp, wdsetmode, du)))
|
|
|
|
|
|
|
|
|
|
du->dk_flags |= DKFL_USEDMA;
|
|
|
|
|
|
1994-02-01 05:55:21 +00:00
|
|
|
#ifdef WDDEBUG
|
1994-01-04 20:05:26 +00:00
|
|
|
printf(
|
1994-02-01 05:55:21 +00:00
|
|
|
"\nwd(%d,%d): wdgetctlr: gc %x cyl %d trk %d sec %d type %d sz %d model %s\n",
|
1996-06-08 10:03:38 +00:00
|
|
|
du->dk_ctrlr, du->dk_unit, wp->wdp_config, wp->wdp_cylinders,
|
|
|
|
|
wp->wdp_heads, wp->wdp_sectors, wp->wdp_buffertype,
|
|
|
|
|
wp->wdp_buffersize, wp->wdp_model);
|
1994-01-04 20:05:26 +00:00
|
|
|
#endif
|
1993-06-12 14:58:17 +00:00
|
|
|
|
|
|
|
|
/* update disklabel given drive information */
|
1994-01-04 20:05:26 +00:00
|
|
|
du->dk_dd.d_secsize = DEV_BSIZE;
|
1996-06-08 10:03:38 +00:00
|
|
|
du->dk_dd.d_ncylinders = wp->wdp_cylinders; /* +- 1 */
|
1993-06-12 14:58:17 +00:00
|
|
|
du->dk_dd.d_ntracks = wp->wdp_heads;
|
|
|
|
|
du->dk_dd.d_nsectors = wp->wdp_sectors;
|
|
|
|
|
du->dk_dd.d_secpercyl = du->dk_dd.d_ntracks * du->dk_dd.d_nsectors;
|
1995-04-14 22:31:58 +00:00
|
|
|
du->dk_dd.d_secperunit = du->dk_dd.d_secpercyl * du->dk_dd.d_ncylinders;
|
1996-07-21 09:28:50 +00:00
|
|
|
if (WDOPT_FORCEHD(du->cfg_flags)) {
|
|
|
|
|
du->dk_dd.d_ntracks = WDOPT_FORCEHD(du->cfg_flags);
|
|
|
|
|
du->dk_dd.d_secpercyl =
|
|
|
|
|
du->dk_dd.d_ntracks * du->dk_dd.d_nsectors;
|
|
|
|
|
du->dk_dd.d_ncylinders =
|
|
|
|
|
du->dk_dd.d_secperunit / du->dk_dd.d_secpercyl;
|
|
|
|
|
}
|
1995-04-14 22:31:58 +00:00
|
|
|
#if 0
|
|
|
|
|
du->dk_dd.d_partitions[RAW_PART].p_size = du->dk_dd.d_secperunit;
|
1993-06-12 14:58:17 +00:00
|
|
|
/* dubious ... */
|
|
|
|
|
bcopy("ESDI/IDE", du->dk_dd.d_typename, 9);
|
1994-02-01 05:55:21 +00:00
|
|
|
bcopy(wp->wdp_model + 20, du->dk_dd.d_packname, 14 - 1);
|
1993-06-12 14:58:17 +00:00
|
|
|
/* better ... */
|
|
|
|
|
du->dk_dd.d_type = DTYPE_ESDI;
|
|
|
|
|
du->dk_dd.d_subtype |= DSTYPE_GEOMETRY;
|
1995-04-14 22:31:58 +00:00
|
|
|
#endif
|
1994-02-01 05:55:21 +00:00
|
|
|
|
1993-06-12 14:58:17 +00:00
|
|
|
return (0);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
int
|
1995-02-26 01:15:30 +00:00
|
|
|
wdclose(dev_t dev, int flags, int fmt, struct proc *p)
|
1993-06-12 14:58:17 +00:00
|
|
|
{
|
1995-04-14 22:31:58 +00:00
|
|
|
dsclose(dev, fmt, wddrives[dkunit(dev)]->dk_slices);
|
1994-02-01 05:55:21 +00:00
|
|
|
return (0);
|
1993-06-12 14:58:17 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
int
|
1995-02-26 01:15:30 +00:00
|
|
|
wdioctl(dev_t dev, int cmd, caddr_t addr, int flags, struct proc *p)
|
1993-06-12 14:58:17 +00:00
|
|
|
{
|
1995-04-14 22:31:58 +00:00
|
|
|
int lunit = dkunit(dev);
|
1993-06-12 14:58:17 +00:00
|
|
|
register struct disk *du;
|
1995-04-14 22:31:58 +00:00
|
|
|
int error;
|
1994-01-04 20:05:26 +00:00
|
|
|
#ifdef notyet
|
1993-06-12 14:58:17 +00:00
|
|
|
struct uio auio;
|
|
|
|
|
struct iovec aiov;
|
1995-04-14 22:31:58 +00:00
|
|
|
struct format_op *fop;
|
1994-01-04 20:05:26 +00:00
|
|
|
#endif
|
1993-06-12 14:58:17 +00:00
|
|
|
|
1994-01-04 20:05:26 +00:00
|
|
|
du = wddrives[lunit];
|
1995-04-14 22:31:58 +00:00
|
|
|
wdsleep(du->dk_ctrlr, "wdioct");
|
1995-04-30 15:14:34 +00:00
|
|
|
error = dsioctl("wd", dev, cmd, addr, flags, &du->dk_slices,
|
|
|
|
|
wdstrategy1, (ds_setgeom_t *)NULL);
|
1995-04-14 22:31:58 +00:00
|
|
|
if (error != -1)
|
|
|
|
|
return (error);
|
1993-06-12 14:58:17 +00:00
|
|
|
|
|
|
|
|
switch (cmd) {
|
1995-05-16 07:52:17 +00:00
|
|
|
case DIOCSBADSCAN:
|
|
|
|
|
if (*(int *)addr)
|
|
|
|
|
du->dk_flags |= DKFL_BADSCAN;
|
|
|
|
|
else
|
|
|
|
|
du->dk_flags &= ~DKFL_BADSCAN;
|
|
|
|
|
return (0);
|
1993-06-12 14:58:17 +00:00
|
|
|
#ifdef notyet
|
|
|
|
|
case DIOCWFORMAT:
|
1995-04-14 22:31:58 +00:00
|
|
|
if (!(flag & FWRITE))
|
|
|
|
|
return (EBADF);
|
|
|
|
|
fop = (struct format_op *)addr;
|
|
|
|
|
aiov.iov_base = fop->df_buf;
|
|
|
|
|
aiov.iov_len = fop->df_count;
|
|
|
|
|
auio.uio_iov = &aiov;
|
|
|
|
|
auio.uio_iovcnt = 1;
|
|
|
|
|
auio.uio_resid = fop->df_count;
|
|
|
|
|
auio.uio_segflg = 0;
|
|
|
|
|
auio.uio_offset = fop->df_startblk * du->dk_dd.d_secsize;
|
1994-02-01 05:55:21 +00:00
|
|
|
#error /* XXX the 386BSD interface is different */
|
1995-04-14 22:31:58 +00:00
|
|
|
error = physio(wdformat, &rwdbuf[lunit], 0, dev, B_WRITE,
|
|
|
|
|
minphys, &auio);
|
|
|
|
|
fop->df_count -= auio.uio_resid;
|
|
|
|
|
fop->df_reg[0] = du->dk_status;
|
|
|
|
|
fop->df_reg[1] = du->dk_error;
|
|
|
|
|
return (error);
|
1993-06-12 14:58:17 +00:00
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
default:
|
1995-04-14 22:31:58 +00:00
|
|
|
return (ENOTTY);
|
1993-06-12 14:58:17 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
1994-02-01 05:55:21 +00:00
|
|
|
#ifdef B_FORMAT
|
1993-06-12 14:58:17 +00:00
|
|
|
int
|
|
|
|
|
wdformat(struct buf *bp)
|
|
|
|
|
{
|
|
|
|
|
|
|
|
|
|
bp->b_flags |= B_FORMAT;
|
1994-10-27 20:45:13 +00:00
|
|
|
wdstrategy(bp);
|
1995-04-24 05:09:53 +00:00
|
|
|
/*
|
1994-10-27 20:45:13 +00:00
|
|
|
* phk put this here, better that return(wdstrategy(bp));
|
|
|
|
|
* XXX
|
|
|
|
|
*/
|
|
|
|
|
return -1;
|
1993-06-12 14:58:17 +00:00
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
int
|
|
|
|
|
wdsize(dev_t dev)
|
|
|
|
|
{
|
|
|
|
|
struct disk *du;
|
1995-05-08 16:48:23 +00:00
|
|
|
int lunit;
|
1993-06-12 14:58:17 +00:00
|
|
|
|
1995-05-08 16:48:23 +00:00
|
|
|
lunit = dkunit(dev);
|
|
|
|
|
if (lunit >= NWD || dktype(dev) != 0)
|
1994-02-01 05:55:21 +00:00
|
|
|
return (-1);
|
1995-05-08 16:48:23 +00:00
|
|
|
du = wddrives[lunit];
|
|
|
|
|
if (du == NULL)
|
1993-06-12 14:58:17 +00:00
|
|
|
return (-1);
|
1995-05-08 16:48:23 +00:00
|
|
|
return (dssize(dev, &du->dk_slices, wdopen, wdclose));
|
1993-06-12 14:58:17 +00:00
|
|
|
}
|
|
|
|
|
|
1994-02-01 05:55:21 +00:00
|
|
|
/*
|
|
|
|
|
* Dump core after a system crash.
|
|
|
|
|
*/
|
1993-06-12 14:58:17 +00:00
|
|
|
int
|
1994-02-01 05:55:21 +00:00
|
|
|
wddump(dev_t dev)
|
1993-06-12 14:58:17 +00:00
|
|
|
{
|
1994-02-01 05:55:21 +00:00
|
|
|
register struct disk *du;
|
|
|
|
|
struct disklabel *lp;
|
|
|
|
|
long num; /* number of sectors to write */
|
|
|
|
|
int lunit, part;
|
1994-01-04 20:05:26 +00:00
|
|
|
long blkoff, blknum;
|
1994-02-01 05:55:21 +00:00
|
|
|
long blkchk, blkcnt, blknext;
|
1994-01-04 20:05:26 +00:00
|
|
|
long cylin, head, sector;
|
1994-02-01 05:55:21 +00:00
|
|
|
long secpertrk, secpercyl, nblocks;
|
1995-04-14 22:31:58 +00:00
|
|
|
u_long ds_offset;
|
1994-02-01 05:55:21 +00:00
|
|
|
char *addr;
|
|
|
|
|
static int wddoingadump = 0;
|
1993-06-12 14:58:17 +00:00
|
|
|
|
1994-02-01 05:55:21 +00:00
|
|
|
/* Toss any characters present prior to dump. */
|
1996-09-14 04:27:46 +00:00
|
|
|
while (cncheckc() != -1)
|
1993-06-12 14:58:17 +00:00
|
|
|
;
|
|
|
|
|
|
1994-02-01 05:55:21 +00:00
|
|
|
/* Check for acceptable device. */
|
|
|
|
|
/* XXX should reset to maybe allow du->dk_state < OPEN. */
|
1995-04-14 22:31:58 +00:00
|
|
|
lunit = dkunit(dev); /* eventually support floppies? */
|
|
|
|
|
part = dkpart(dev);
|
|
|
|
|
if (lunit >= NWD || (du = wddrives[lunit]) == NULL
|
|
|
|
|
|| du->dk_state < OPEN
|
|
|
|
|
|| (lp = dsgetlabel(dev, du->dk_slices)) == NULL)
|
1994-02-01 05:55:21 +00:00
|
|
|
return (ENXIO);
|
1993-06-12 14:58:17 +00:00
|
|
|
|
1994-02-01 05:55:21 +00:00
|
|
|
/* Size of memory to dump, in disk sectors. */
|
1996-05-02 10:43:17 +00:00
|
|
|
num = (u_long)Maxmem * PAGE_SIZE / du->dk_dd.d_secsize;
|
1993-06-12 14:58:17 +00:00
|
|
|
|
|
|
|
|
secpertrk = du->dk_dd.d_nsectors;
|
|
|
|
|
secpercyl = du->dk_dd.d_secpercyl;
|
1995-04-14 22:31:58 +00:00
|
|
|
nblocks = lp->d_partitions[part].p_size;
|
|
|
|
|
blkoff = lp->d_partitions[part].p_offset;
|
|
|
|
|
/* XXX */
|
|
|
|
|
ds_offset = du->dk_slices->dss_slices[dkslice(dev)].ds_offset;
|
|
|
|
|
blkoff += ds_offset;
|
1993-06-12 14:58:17 +00:00
|
|
|
|
1994-02-01 05:55:21 +00:00
|
|
|
#if 0
|
|
|
|
|
pg("part %x, nblocks %d, dumplo %d num %d\n",
|
|
|
|
|
part, nblocks, dumplo, num);
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
/* Check transfer bounds against partition size. */
|
|
|
|
|
if (dumplo < 0 || dumplo + num > nblocks)
|
|
|
|
|
return (EINVAL);
|
|
|
|
|
|
|
|
|
|
/* Check if we are being called recursively. */
|
|
|
|
|
if (wddoingadump)
|
|
|
|
|
return (EFAULT);
|
1993-06-12 14:58:17 +00:00
|
|
|
|
1994-01-04 20:05:26 +00:00
|
|
|
#if 0
|
1994-02-01 05:55:21 +00:00
|
|
|
/* Mark controller active for if we panic during the dump. */
|
|
|
|
|
wdtab[du->dk_ctrlr].b_active = 1;
|
1994-01-04 20:05:26 +00:00
|
|
|
#endif
|
1994-02-01 05:55:21 +00:00
|
|
|
wddoingadump = 1;
|
|
|
|
|
|
|
|
|
|
/* Recalibrate the drive. */
|
|
|
|
|
DELAY(5); /* ATA spec XXX NOT */
|
|
|
|
|
if (wdcommand(du, 0, 0, 0, 0, WDCC_RESTORE | WD_STEP) != 0
|
1994-02-11 12:02:35 +00:00
|
|
|
|| wdwait(du, WDCS_READY | WDCS_SEEKCMPLT, TIMEOUT) != 0
|
1994-02-01 05:55:21 +00:00
|
|
|
|| wdsetctlr(du) != 0) {
|
|
|
|
|
wderror((struct buf *)NULL, du, "wddump: recalibrate failed");
|
|
|
|
|
return (EIO);
|
|
|
|
|
}
|
1994-01-04 20:05:26 +00:00
|
|
|
|
1994-02-01 05:55:21 +00:00
|
|
|
du->dk_flags |= DKFL_SINGLE;
|
|
|
|
|
addr = (char *) 0;
|
1993-06-12 14:58:17 +00:00
|
|
|
blknum = dumplo + blkoff;
|
|
|
|
|
while (num > 0) {
|
1994-02-01 05:55:21 +00:00
|
|
|
blkcnt = num;
|
|
|
|
|
if (blkcnt > MAXTRANSFER)
|
|
|
|
|
blkcnt = MAXTRANSFER;
|
|
|
|
|
/* Keep transfer within current cylinder. */
|
1993-06-12 14:58:17 +00:00
|
|
|
if ((blknum + blkcnt - 1) / secpercyl != blknum / secpercyl)
|
|
|
|
|
blkcnt = secpercyl - (blknum % secpercyl);
|
1994-02-01 05:55:21 +00:00
|
|
|
blknext = blknum + blkcnt;
|
1993-06-12 14:58:17 +00:00
|
|
|
|
1995-04-24 05:09:53 +00:00
|
|
|
/*
|
1994-02-01 05:55:21 +00:00
|
|
|
* See if one of the sectors is in the bad sector list
|
|
|
|
|
* (if we have one). If the first sector is bad, then
|
|
|
|
|
* reduce the transfer to this one bad sector; if another
|
|
|
|
|
* sector is bad, then reduce reduce the transfer to
|
|
|
|
|
* avoid any bad sectors.
|
1993-06-12 14:58:17 +00:00
|
|
|
*/
|
1995-04-14 22:31:58 +00:00
|
|
|
if (du->dk_flags & DKFL_SINGLE
|
|
|
|
|
&& dsgetbad(dev, du->dk_slices) != NULL) {
|
1994-02-01 05:55:21 +00:00
|
|
|
for (blkchk = blknum; blkchk < blknum + blkcnt; blkchk++) {
|
1995-04-14 22:31:58 +00:00
|
|
|
daddr_t blknew;
|
|
|
|
|
blknew = transbad144(dsgetbad(dev, du->dk_slices),
|
|
|
|
|
blkchk - ds_offset) + ds_offset;
|
|
|
|
|
if (blknew != blkchk) {
|
1994-02-01 05:55:21 +00:00
|
|
|
/* Found bad block. */
|
|
|
|
|
blkcnt = blkchk - blknum;
|
|
|
|
|
if (blkcnt > 0) {
|
|
|
|
|
blknext = blknum + blkcnt;
|
|
|
|
|
goto out;
|
|
|
|
|
}
|
|
|
|
|
blkcnt = 1;
|
|
|
|
|
blknext = blknum + blkcnt;
|
1995-04-14 22:31:58 +00:00
|
|
|
#if 1 || defined(WDDEBUG)
|
|
|
|
|
printf("bad block %lu -> %lu\n",
|
|
|
|
|
blknum, blknew);
|
1994-02-01 05:55:21 +00:00
|
|
|
#endif
|
1993-06-12 14:58:17 +00:00
|
|
|
break;
|
|
|
|
|
}
|
1994-02-01 05:55:21 +00:00
|
|
|
}
|
1995-04-14 22:31:58 +00:00
|
|
|
}
|
1994-02-01 05:55:21 +00:00
|
|
|
out:
|
|
|
|
|
|
|
|
|
|
/* Compute disk address. */
|
|
|
|
|
cylin = blknum / secpercyl;
|
|
|
|
|
head = (blknum % secpercyl) / secpertrk;
|
|
|
|
|
sector = blknum % secpertrk;
|
1994-01-04 20:05:26 +00:00
|
|
|
|
1994-02-01 05:55:21 +00:00
|
|
|
#if 0
|
|
|
|
|
/* Let's just talk about this first... */
|
|
|
|
|
pg("cylin l%d head %ld sector %ld addr 0x%x count %ld",
|
|
|
|
|
cylin, head, sector, addr, blkcnt);
|
|
|
|
|
#endif
|
1993-06-12 14:58:17 +00:00
|
|
|
|
1994-02-01 05:55:21 +00:00
|
|
|
/* Do the write. */
|
|
|
|
|
if (wdcommand(du, cylin, head, sector, blkcnt, WDCC_WRITE)
|
|
|
|
|
!= 0) {
|
|
|
|
|
wderror((struct buf *)NULL, du,
|
|
|
|
|
"wddump: timeout waiting to to give command");
|
|
|
|
|
return (EIO);
|
|
|
|
|
}
|
|
|
|
|
while (blkcnt != 0) {
|
1994-05-25 09:21:21 +00:00
|
|
|
pmap_enter(kernel_pmap, (vm_offset_t)CADDR1, trunc_page(addr),
|
1994-02-01 05:55:21 +00:00
|
|
|
VM_PROT_READ, TRUE);
|
|
|
|
|
|
|
|
|
|
/* Ready to send data? */
|
|
|
|
|
DELAY(5); /* ATA spec */
|
1994-02-11 12:02:35 +00:00
|
|
|
if (wdwait(du, WDCS_READY | WDCS_SEEKCMPLT | WDCS_DRQ, TIMEOUT)
|
1994-02-01 05:55:21 +00:00
|
|
|
< 0) {
|
|
|
|
|
wderror((struct buf *)NULL, du,
|
|
|
|
|
"wddump: timeout waiting for DRQ");
|
|
|
|
|
return (EIO);
|
|
|
|
|
}
|
1995-02-04 19:39:36 +00:00
|
|
|
if (du->dk_flags & DKFL_32BIT)
|
|
|
|
|
outsl(du->dk_port + wd_data,
|
1996-05-02 10:43:17 +00:00
|
|
|
CADDR1 + ((int)addr & PAGE_MASK),
|
1995-02-04 19:39:36 +00:00
|
|
|
DEV_BSIZE / sizeof(long));
|
|
|
|
|
else
|
|
|
|
|
outsw(du->dk_port + wd_data,
|
1996-05-02 10:43:17 +00:00
|
|
|
CADDR1 + ((int)addr & PAGE_MASK),
|
1995-02-04 19:39:36 +00:00
|
|
|
DEV_BSIZE / sizeof(short));
|
1994-02-01 05:55:21 +00:00
|
|
|
addr += DEV_BSIZE;
|
1997-08-09 01:44:25 +00:00
|
|
|
/*
|
|
|
|
|
* If we are dumping core, it may take a while.
|
|
|
|
|
* So reassure the user and hold off any watchdogs.
|
|
|
|
|
*/
|
|
|
|
|
if ((unsigned)addr % (1024 * 1024) == 0) {
|
|
|
|
|
#ifdef HW_WDOG
|
|
|
|
|
if (wdog_tickler)
|
|
|
|
|
(*wdog_tickler)();
|
|
|
|
|
#endif /* HW_WDOG */
|
1994-02-01 05:55:21 +00:00
|
|
|
printf("%ld ", num / (1024 * 1024 / DEV_BSIZE));
|
1997-08-09 01:44:25 +00:00
|
|
|
}
|
1994-02-01 05:55:21 +00:00
|
|
|
num--;
|
|
|
|
|
blkcnt--;
|
|
|
|
|
}
|
1993-06-12 14:58:17 +00:00
|
|
|
|
1994-02-01 05:55:21 +00:00
|
|
|
/* Wait for completion. */
|
|
|
|
|
DELAY(5); /* ATA spec XXX NOT */
|
1994-02-11 12:02:35 +00:00
|
|
|
if (wdwait(du, WDCS_READY | WDCS_SEEKCMPLT, TIMEOUT) < 0) {
|
1994-02-01 05:55:21 +00:00
|
|
|
wderror((struct buf *)NULL, du,
|
|
|
|
|
"wddump: timeout waiting for status");
|
|
|
|
|
return (EIO);
|
|
|
|
|
}
|
1993-06-12 14:58:17 +00:00
|
|
|
|
1994-02-01 05:55:21 +00:00
|
|
|
/* Check final status. */
|
|
|
|
|
if (du->dk_status
|
|
|
|
|
& (WDCS_READY | WDCS_SEEKCMPLT | WDCS_DRQ | WDCS_ERR)
|
|
|
|
|
!= (WDCS_READY | WDCS_SEEKCMPLT)) {
|
|
|
|
|
wderror((struct buf *)NULL, du,
|
|
|
|
|
"wddump: extra DRQ, or error");
|
|
|
|
|
return (EIO);
|
1993-06-12 14:58:17 +00:00
|
|
|
}
|
1994-02-01 05:55:21 +00:00
|
|
|
|
|
|
|
|
/* Update block count. */
|
|
|
|
|
blknum = blknext;
|
|
|
|
|
|
|
|
|
|
/* Operator aborting dump? */
|
1996-09-14 04:27:46 +00:00
|
|
|
if (cncheckc() != -1)
|
1994-02-01 05:55:21 +00:00
|
|
|
return (EINTR);
|
1993-06-12 14:58:17 +00:00
|
|
|
}
|
1994-02-01 05:55:21 +00:00
|
|
|
return (0);
|
1993-06-12 14:58:17 +00:00
|
|
|
}
|
1994-01-04 20:05:26 +00:00
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
wderror(struct buf *bp, struct disk *du, char *mesg)
|
|
|
|
|
{
|
|
|
|
|
if (bp == NULL)
|
1994-02-21 12:32:33 +00:00
|
|
|
printf("wd%d: %s:\n", du->dk_lunit, mesg);
|
1994-01-04 20:05:26 +00:00
|
|
|
else
|
1995-04-14 22:31:58 +00:00
|
|
|
diskerr(bp, "wd", mesg, LOG_PRINTF, du->dk_skip,
|
|
|
|
|
dsgetlabel(bp->b_dev, du->dk_slices));
|
1994-02-21 12:32:33 +00:00
|
|
|
printf("wd%d: status %b error %b\n", du->dk_lunit,
|
1994-02-01 05:55:21 +00:00
|
|
|
du->dk_status, WDCS_BITS, du->dk_error, WDERR_BITS);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Discard any interrupts that were latched by the interrupt system while
|
|
|
|
|
* we were doing polled i/o.
|
|
|
|
|
*/
|
|
|
|
|
static void
|
|
|
|
|
wdflushirq(struct disk *du, int old_ipl)
|
|
|
|
|
{
|
1997-03-11 23:17:28 +00:00
|
|
|
#ifdef CMD640
|
|
|
|
|
wdtab[du->dk_ctrlr_cmd640].b_active = 2;
|
|
|
|
|
splx(old_ipl);
|
|
|
|
|
(void)splbio();
|
|
|
|
|
wdtab[du->dk_ctrlr_cmd640].b_active = 0;
|
|
|
|
|
#else
|
1994-02-01 05:55:21 +00:00
|
|
|
wdtab[du->dk_ctrlr].b_active = 2;
|
|
|
|
|
splx(old_ipl);
|
|
|
|
|
(void)splbio();
|
|
|
|
|
wdtab[du->dk_ctrlr].b_active = 0;
|
1997-03-11 23:17:28 +00:00
|
|
|
#endif
|
1994-01-04 20:05:26 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Reset the controller.
|
|
|
|
|
*/
|
|
|
|
|
static int
|
|
|
|
|
wdreset(struct disk *du)
|
|
|
|
|
{
|
1995-09-30 15:19:44 +00:00
|
|
|
int wdc, err = 0;
|
1994-01-04 20:05:26 +00:00
|
|
|
|
Add support for busmaster DMA on some PCI IDE chipsets.
I changed a few bits here and there, mainly renaming wd82371.c
to ide_pci.c now that it's supposed to handle different chipsets.
It runs on my P6 natoma board with two Maxtor drives, and also
on a Fujitsu machine I have at work with an Opti chipset and
a Quantum drive.
Submitted by:cgull@smoke.marlboro.vt.us <John Hood>
Original readme:
*** WARNING ***
This code has so far been tested on exactly one motherboard with two
identical drives known for their good DMA support.
This code, in the right circumstances, could corrupt data subtly,
silently, and invisibly, in much the same way that older PCI IDE
controllers do. It's ALPHA-quality code; there's one or two major
gaps in my understanding of PCI IDE still. Don't use this code on any
system with data that you care about; it's only good for hack boxes.
Expect that any data may be silently and randomly corrupted at any
moment. It's a disk driver. It has bugs. Disk drivers with bugs
munch data. It's a fact of life.
I also *STRONGLY* recommend getting a copy of your chipset's manual
and the ATA-2 or ATA-3 spec and making sure that timing modes on your
disk drives and IDE controller are being setup correctly by the BIOS--
because the driver makes only the lamest of attempts to do this just
now.
*** END WARNING ***
that said, i happen to think the code is working pretty well...
WHAT IT DOES:
this code adds support to the wd driver for bus mastering PCI IDE
controllers that follow the SFF-8038 standard. (all the bus mastering
PCI IDE controllers i've seen so far do follow this standard.) it
should provide busmastering on nearly any current P5 or P6 chipset,
specifically including any Intel chipset using one of the PIIX south
bridges-- this includes the '430FX, '430VX, '430HX, '430TX, '440LX,
and (i think) the Orion '450GX chipsets. specific support is also
included for the VIA Apollo VP-1 chipset, as it appears in the
relabeled "HXPro" incarnation seen on cheap US$70 taiwanese
motherboards (that's what's in my development machine). it works out
of the box on controllers that do DMA mode2; if my understanding is
correct, it'll probably work on Ultra-DMA33 controllers as well.
it'll probably work on busmastering IDE controllers in PCI slots, too,
but this is an area i am less sure about.
it cuts CPU usage considerably and improves drive performance
slightly. usable numbers are difficult to come by with existing
benchmark tools, but experimentation on my K5-P90 system, with VIA
VP-1 chipset and Quantum Fireball 1080 drives, shows that disk i/o on
raw partitions imposes perhaps 5% cpu load. cpu load during
filesystem i/o drops a lot, from near 100% to anywhere between 30% and
70%. (the improvement may not be as large on an Intel chipset; from
what i can tell, the VIA VP-1 may not be very efficient with PCI I/O.)
disk performance improves by 5% or 10% with these drives.
real, visible, end-user performance improvement on a single user
machine is about nil. :) a kernel compile was sped up by a whole three
seconds. it *does* feel a bit better-behaved when the system is
swapping heavily, but a better disk driver is not the fix for *that*
problem.
THE CODE:
this code is a patch to wd.c and wd82371.c, and associated header
files. it should be considered alpha code; more work needs to be
done.
wd.c has fairly clean patches to add calls to busmaster code, as
implemented in wd82371.c and potentially elsewhere (one could imagine,
say, a Mac having a different DMA controller).
wd82371.c has been considerably reworked: the wddma interface that it
presents has been changed (expect more changes), many bugs have been
fixed, a new internal interface has been added for supporting
different chipsets, and the PCI probe has been considerably extended.
the interface between wd82371.c and wd.c is still fairly clean, but
i'm not sure it's in the right place. there's a mess of issues around
ATA/ATAPI that need to be sorted out, including ATAPI support, CD-ROM
support, tape support, LS-120/Zip support, SFF-8038i DMA, UltraDMA,
PCI IDE controllers, bus probes, buggy controllers, controller timing
setup, drive timing setup, world peace and kitchen sinks. whatever
happens with all this and however it gets partitioned, it is fairly
clear that wd.c needs some significant rework-- probably a complete
rewrite.
timing setup on disk controllers is something i've entirely punted on.
on my development machine, it appears that the BIOS does at least some
of the necessary timing setup. i chose to restrict operation to
drives that are already configured for Mode4 PIO and Mode2 multiword
DMA, since the timing is essentially the same and many if not most
chipsets use the same control registers for DMA and PIO timing.
does anybody *know* whether BIOSes are required to do timing setup for
DMA modes on drives under their care?
error recovery is probably weak. early on in development, i was
getting drive errors induced by bugs in the driver; i used these to
flush out the worst of the bugs in the driver's error handling, but
problems may remain. i haven't got a drive with bad sectors i can
watch the driver flail on.
complaints about how wd82371.c has been reindented will be ignored
until the FreeBSD project has a real style policy, there is a
mechanism for individual authors to match it (indent flags or an emacs
c-mode or whatever), and it is enforced. if i'm going to use a source
style i don't like, it would help if i could figure out what it *is*
(style(9) is about half of a policy), and a way to reasonably
duplicate it. i ended up wasting a while trying to figure out what
the right thing to do was before deciding reformatting the whole thing
was the worst possible thing to do, except for all the other
possibilities.
i have maintained wd.c's indentation; that was not too hard,
fortunately.
TO INSTALL:
my dev box is freebsd 2.2.2 release. fortunately, wd.c is a living
fossil, and has diverged very little recently. included in this
tarball is a patch file, 'otherdiffs', for all files except wd82371.c,
my edited wd82371.c, a patch file, 'wd82371.c-diff-exact', against the
2.2.2 dist of 82371.c, and another patch file,
'wd82371.c-diff-whitespace', generated with diff -b (ignore
whitespace). most of you not using 2.2.2 will probably have to use
this last patchfile with 'patch --ignore-whitespace'. apply from the
kernel source tree root. as far as i can tell, this should apply
cleanly on anything from -current back to 2.2.2 and probably back to
2.2.0. you, the kernel hacker, can figure out what to do from here.
if you need more specific directions, you probably should not be
experimenting with this code yet.
to enable DMA support, set flag 0x2000 for that drive in your config
file or in userconfig, as you would the 32-bit-PIO flag. the driver
will then turn on DMA support if your drive and controller pass its
tests. it's a bit picky, probably. on discovering DMA mode failures
or disk errors or transfers that the DMA controller can't deal with,
the driver will fall back to PIO, so it is wise to setup the flags as
if PIO were still important.
'controller wdc0 at isa? port "IO_WD1" bio irq 14 flags 0xa0ffa0ff
vector wdintr' should work with nearly any PCI IDE controller.
i would *strongly* suggest booting single-user at first, and thrashing
the drive a bit while it's still mounted read-only. this should be
fairly safe, even if the driver goes completely out to lunch. it
might save you a reinstall.
one way to tell whether the driver is really using DMA is to check the
interrupt count during disk i/o with vmstat; DMA mode will add an
extremely low number of interrupts, as compared to even multi-sector
PIO.
boot -v will give you a copious register dump of timing-related info
on Intel and VIAtech chipsets, as well as PIO/DMA mode information on
all hard drives. refer to your ATA and chipset documentation to
interpret these.
WHAT I'D LIKE FROM YOU and THINGS TO TEST:
reports. success reports, failure reports, any kind of reports. :)
send them to cgull+ide@smoke.marlboro.vt.us.
i'd also like to see the kernel messages from various BIOSes (boot -v;
dmesg), along with info on the motherboard and BIOS on that machine.
i'm especially interested in reports on how this code works on the
various Intel chipsets, and whether the register dump works
correctly. i'm also interested in hearing about other chipsets.
i'm especially interested in hearing success/failure reports for PCI
IDE controllers on cards, such as CMD's or Promise's new busmastering
IDE controllers.
UltraDMA-33 reports.
interoperation with ATAPI peripherals-- FreeBSD doesn't work with my
old Hitachi IDE CDROM, so i can't tell if I've broken anything. :)
i'd especially like to hear how the drive copes in DMA operation on
drives with bad sectors. i haven't been able to find any such yet.
success/failure reports on older IDE drives with early support for DMA
modes-- those introduced between 1.5 and 3 years ago, typically
ranging from perhaps 400MB to 1.6GB.
failure reports on operation with more than one drive would be
appreciated. the driver was developed with two drives on one
controller, the worst-case situation, and has been tested with one
drive on each controller, but you never know...
any reports of messages from the driver during normal operation,
especially "reverting to PIO mode", or "dmaverify odd vaddr or length"
(the DMA controller is strongly halfword oriented, and i'm curious to
know if any FreeBSD usage actually needs misaligned transfers).
performance reports. beware that bonnie's CPU usage reporting is
useless for IDE drives; the best test i've found has been to run a
program that runs a spin loop at an idle priority and reports how many
iterations it manages, and even that sometimes produces numbers i
don't believe. performance reports of multi-drive operation are
especially interesting; my system cannot sustain full throughput on
two drives on separate controllers, but that may just be a lame
motherboard.
THINGS I'M STILL MISSING CLUE ON:
* who's responsible for configuring DMA timing modes on IDE drives?
the BIOS or the driver?
* is there a spec for dealing with Ultra-DMA extensions?
* are there any chipsets or with bugs relating to DMA transfer that
should be blacklisted?
* are there any ATA interfaces that use some other kind of DMA
controller in conjunction with standard ATA protocol?
FINAL NOTE:
after having looked at the ATA-3 spec, all i can say is, "it's ugly".
*especially* electrically. the IDE bus is best modeled as an
unterminated transmission line, these days.
for maximum reliability, keep your IDE cables as short as possible and
as few as possible. from what i can tell, most current chipsets have
both IDE ports wired into a single buss, to a greater or lesser
degree. using two cables means you double the length of this bus.
SCSI may have its warts, but at least the basic analog design of the
bus is still somewhat reasonable. IDE passed beyond the veil two
years ago.
--John Hood, cgull@smoke.marlboro.vt.us
1997-07-29 12:57:25 +00:00
|
|
|
if ((du->dk_flags & (DKFL_DMA|DKFL_USEDMA)) && du->dk_dmacookie)
|
|
|
|
|
wddma.wdd_dmadone(du->dk_dmacookie);
|
|
|
|
|
|
1994-01-04 20:05:26 +00:00
|
|
|
wdc = du->dk_port;
|
1994-02-11 12:02:35 +00:00
|
|
|
(void)wdwait(du, 0, TIMEOUT);
|
1994-01-04 20:05:26 +00:00
|
|
|
outb(wdc + wd_ctlr, WDCTL_IDS | WDCTL_RST);
|
|
|
|
|
DELAY(10 * 1000);
|
|
|
|
|
outb(wdc + wd_ctlr, WDCTL_IDS);
|
1995-09-30 15:19:44 +00:00
|
|
|
#ifdef ATAPI
|
1995-09-30 00:11:19 +00:00
|
|
|
if (wdwait(du, WDCS_READY | WDCS_SEEKCMPLT, TIMEOUT) != 0)
|
|
|
|
|
err = 1; /* no IDE drive found */
|
1995-08-18 11:26:35 +00:00
|
|
|
du->dk_error = inb(wdc + wd_error);
|
1995-09-30 00:11:19 +00:00
|
|
|
if (du->dk_error != 0x01)
|
|
|
|
|
err = 1; /* the drive is incompatible */
|
1995-09-30 15:19:44 +00:00
|
|
|
#else
|
|
|
|
|
if (wdwait(du, WDCS_READY | WDCS_SEEKCMPLT, TIMEOUT) != 0
|
|
|
|
|
|| (du->dk_error = inb(wdc + wd_error)) != 0x01)
|
|
|
|
|
return (1);
|
1995-09-30 00:11:19 +00:00
|
|
|
#endif
|
1994-01-04 20:05:26 +00:00
|
|
|
outb(wdc + wd_ctlr, WDCTL_4BIT);
|
1995-09-30 00:11:19 +00:00
|
|
|
return (err);
|
1994-01-04 20:05:26 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Sleep until driver is inactive.
|
|
|
|
|
* This is used only for avoiding rare race conditions, so it is unimportant
|
|
|
|
|
* that the sleep may be far too short or too long.
|
|
|
|
|
*/
|
|
|
|
|
static void
|
|
|
|
|
wdsleep(int ctrlr, char *wmesg)
|
|
|
|
|
{
|
1995-11-23 07:24:41 +00:00
|
|
|
int s = splbio();
|
1997-03-11 23:17:28 +00:00
|
|
|
#ifdef CMD640
|
|
|
|
|
if (eide_quirks & Q_CMD640B)
|
|
|
|
|
ctrlr = PRIMARY;
|
|
|
|
|
#endif
|
1994-01-04 20:05:26 +00:00
|
|
|
while (wdtab[ctrlr].b_active)
|
|
|
|
|
tsleep((caddr_t)&wdtab[ctrlr].b_active, PZERO - 1, wmesg, 1);
|
1995-11-23 07:24:41 +00:00
|
|
|
splx(s);
|
1994-01-04 20:05:26 +00:00
|
|
|
}
|
|
|
|
|
|
1994-02-06 17:03:17 +00:00
|
|
|
static void
|
1994-08-23 07:52:29 +00:00
|
|
|
wdtimeout(void *cdu)
|
1994-02-01 05:55:21 +00:00
|
|
|
{
|
|
|
|
|
struct disk *du;
|
|
|
|
|
int x;
|
1994-10-27 05:39:12 +00:00
|
|
|
static int timeouts;
|
1994-02-01 05:55:21 +00:00
|
|
|
|
|
|
|
|
du = (struct disk *)cdu;
|
|
|
|
|
x = splbio();
|
|
|
|
|
if (du->dk_timeout != 0 && --du->dk_timeout == 0) {
|
1994-10-27 05:39:12 +00:00
|
|
|
if(timeouts++ == 5)
|
|
|
|
|
wderror((struct buf *)NULL, du,
|
|
|
|
|
"Last time I say: interrupt timeout. Probably a portable PC.");
|
Add support for busmaster DMA on some PCI IDE chipsets.
I changed a few bits here and there, mainly renaming wd82371.c
to ide_pci.c now that it's supposed to handle different chipsets.
It runs on my P6 natoma board with two Maxtor drives, and also
on a Fujitsu machine I have at work with an Opti chipset and
a Quantum drive.
Submitted by:cgull@smoke.marlboro.vt.us <John Hood>
Original readme:
*** WARNING ***
This code has so far been tested on exactly one motherboard with two
identical drives known for their good DMA support.
This code, in the right circumstances, could corrupt data subtly,
silently, and invisibly, in much the same way that older PCI IDE
controllers do. It's ALPHA-quality code; there's one or two major
gaps in my understanding of PCI IDE still. Don't use this code on any
system with data that you care about; it's only good for hack boxes.
Expect that any data may be silently and randomly corrupted at any
moment. It's a disk driver. It has bugs. Disk drivers with bugs
munch data. It's a fact of life.
I also *STRONGLY* recommend getting a copy of your chipset's manual
and the ATA-2 or ATA-3 spec and making sure that timing modes on your
disk drives and IDE controller are being setup correctly by the BIOS--
because the driver makes only the lamest of attempts to do this just
now.
*** END WARNING ***
that said, i happen to think the code is working pretty well...
WHAT IT DOES:
this code adds support to the wd driver for bus mastering PCI IDE
controllers that follow the SFF-8038 standard. (all the bus mastering
PCI IDE controllers i've seen so far do follow this standard.) it
should provide busmastering on nearly any current P5 or P6 chipset,
specifically including any Intel chipset using one of the PIIX south
bridges-- this includes the '430FX, '430VX, '430HX, '430TX, '440LX,
and (i think) the Orion '450GX chipsets. specific support is also
included for the VIA Apollo VP-1 chipset, as it appears in the
relabeled "HXPro" incarnation seen on cheap US$70 taiwanese
motherboards (that's what's in my development machine). it works out
of the box on controllers that do DMA mode2; if my understanding is
correct, it'll probably work on Ultra-DMA33 controllers as well.
it'll probably work on busmastering IDE controllers in PCI slots, too,
but this is an area i am less sure about.
it cuts CPU usage considerably and improves drive performance
slightly. usable numbers are difficult to come by with existing
benchmark tools, but experimentation on my K5-P90 system, with VIA
VP-1 chipset and Quantum Fireball 1080 drives, shows that disk i/o on
raw partitions imposes perhaps 5% cpu load. cpu load during
filesystem i/o drops a lot, from near 100% to anywhere between 30% and
70%. (the improvement may not be as large on an Intel chipset; from
what i can tell, the VIA VP-1 may not be very efficient with PCI I/O.)
disk performance improves by 5% or 10% with these drives.
real, visible, end-user performance improvement on a single user
machine is about nil. :) a kernel compile was sped up by a whole three
seconds. it *does* feel a bit better-behaved when the system is
swapping heavily, but a better disk driver is not the fix for *that*
problem.
THE CODE:
this code is a patch to wd.c and wd82371.c, and associated header
files. it should be considered alpha code; more work needs to be
done.
wd.c has fairly clean patches to add calls to busmaster code, as
implemented in wd82371.c and potentially elsewhere (one could imagine,
say, a Mac having a different DMA controller).
wd82371.c has been considerably reworked: the wddma interface that it
presents has been changed (expect more changes), many bugs have been
fixed, a new internal interface has been added for supporting
different chipsets, and the PCI probe has been considerably extended.
the interface between wd82371.c and wd.c is still fairly clean, but
i'm not sure it's in the right place. there's a mess of issues around
ATA/ATAPI that need to be sorted out, including ATAPI support, CD-ROM
support, tape support, LS-120/Zip support, SFF-8038i DMA, UltraDMA,
PCI IDE controllers, bus probes, buggy controllers, controller timing
setup, drive timing setup, world peace and kitchen sinks. whatever
happens with all this and however it gets partitioned, it is fairly
clear that wd.c needs some significant rework-- probably a complete
rewrite.
timing setup on disk controllers is something i've entirely punted on.
on my development machine, it appears that the BIOS does at least some
of the necessary timing setup. i chose to restrict operation to
drives that are already configured for Mode4 PIO and Mode2 multiword
DMA, since the timing is essentially the same and many if not most
chipsets use the same control registers for DMA and PIO timing.
does anybody *know* whether BIOSes are required to do timing setup for
DMA modes on drives under their care?
error recovery is probably weak. early on in development, i was
getting drive errors induced by bugs in the driver; i used these to
flush out the worst of the bugs in the driver's error handling, but
problems may remain. i haven't got a drive with bad sectors i can
watch the driver flail on.
complaints about how wd82371.c has been reindented will be ignored
until the FreeBSD project has a real style policy, there is a
mechanism for individual authors to match it (indent flags or an emacs
c-mode or whatever), and it is enforced. if i'm going to use a source
style i don't like, it would help if i could figure out what it *is*
(style(9) is about half of a policy), and a way to reasonably
duplicate it. i ended up wasting a while trying to figure out what
the right thing to do was before deciding reformatting the whole thing
was the worst possible thing to do, except for all the other
possibilities.
i have maintained wd.c's indentation; that was not too hard,
fortunately.
TO INSTALL:
my dev box is freebsd 2.2.2 release. fortunately, wd.c is a living
fossil, and has diverged very little recently. included in this
tarball is a patch file, 'otherdiffs', for all files except wd82371.c,
my edited wd82371.c, a patch file, 'wd82371.c-diff-exact', against the
2.2.2 dist of 82371.c, and another patch file,
'wd82371.c-diff-whitespace', generated with diff -b (ignore
whitespace). most of you not using 2.2.2 will probably have to use
this last patchfile with 'patch --ignore-whitespace'. apply from the
kernel source tree root. as far as i can tell, this should apply
cleanly on anything from -current back to 2.2.2 and probably back to
2.2.0. you, the kernel hacker, can figure out what to do from here.
if you need more specific directions, you probably should not be
experimenting with this code yet.
to enable DMA support, set flag 0x2000 for that drive in your config
file or in userconfig, as you would the 32-bit-PIO flag. the driver
will then turn on DMA support if your drive and controller pass its
tests. it's a bit picky, probably. on discovering DMA mode failures
or disk errors or transfers that the DMA controller can't deal with,
the driver will fall back to PIO, so it is wise to setup the flags as
if PIO were still important.
'controller wdc0 at isa? port "IO_WD1" bio irq 14 flags 0xa0ffa0ff
vector wdintr' should work with nearly any PCI IDE controller.
i would *strongly* suggest booting single-user at first, and thrashing
the drive a bit while it's still mounted read-only. this should be
fairly safe, even if the driver goes completely out to lunch. it
might save you a reinstall.
one way to tell whether the driver is really using DMA is to check the
interrupt count during disk i/o with vmstat; DMA mode will add an
extremely low number of interrupts, as compared to even multi-sector
PIO.
boot -v will give you a copious register dump of timing-related info
on Intel and VIAtech chipsets, as well as PIO/DMA mode information on
all hard drives. refer to your ATA and chipset documentation to
interpret these.
WHAT I'D LIKE FROM YOU and THINGS TO TEST:
reports. success reports, failure reports, any kind of reports. :)
send them to cgull+ide@smoke.marlboro.vt.us.
i'd also like to see the kernel messages from various BIOSes (boot -v;
dmesg), along with info on the motherboard and BIOS on that machine.
i'm especially interested in reports on how this code works on the
various Intel chipsets, and whether the register dump works
correctly. i'm also interested in hearing about other chipsets.
i'm especially interested in hearing success/failure reports for PCI
IDE controllers on cards, such as CMD's or Promise's new busmastering
IDE controllers.
UltraDMA-33 reports.
interoperation with ATAPI peripherals-- FreeBSD doesn't work with my
old Hitachi IDE CDROM, so i can't tell if I've broken anything. :)
i'd especially like to hear how the drive copes in DMA operation on
drives with bad sectors. i haven't been able to find any such yet.
success/failure reports on older IDE drives with early support for DMA
modes-- those introduced between 1.5 and 3 years ago, typically
ranging from perhaps 400MB to 1.6GB.
failure reports on operation with more than one drive would be
appreciated. the driver was developed with two drives on one
controller, the worst-case situation, and has been tested with one
drive on each controller, but you never know...
any reports of messages from the driver during normal operation,
especially "reverting to PIO mode", or "dmaverify odd vaddr or length"
(the DMA controller is strongly halfword oriented, and i'm curious to
know if any FreeBSD usage actually needs misaligned transfers).
performance reports. beware that bonnie's CPU usage reporting is
useless for IDE drives; the best test i've found has been to run a
program that runs a spin loop at an idle priority and reports how many
iterations it manages, and even that sometimes produces numbers i
don't believe. performance reports of multi-drive operation are
especially interesting; my system cannot sustain full throughput on
two drives on separate controllers, but that may just be a lame
motherboard.
THINGS I'M STILL MISSING CLUE ON:
* who's responsible for configuring DMA timing modes on IDE drives?
the BIOS or the driver?
* is there a spec for dealing with Ultra-DMA extensions?
* are there any chipsets or with bugs relating to DMA transfer that
should be blacklisted?
* are there any ATA interfaces that use some other kind of DMA
controller in conjunction with standard ATA protocol?
FINAL NOTE:
after having looked at the ATA-3 spec, all i can say is, "it's ugly".
*especially* electrically. the IDE bus is best modeled as an
unterminated transmission line, these days.
for maximum reliability, keep your IDE cables as short as possible and
as few as possible. from what i can tell, most current chipsets have
both IDE ports wired into a single buss, to a greater or lesser
degree. using two cables means you double the length of this bus.
SCSI may have its warts, but at least the basic analog design of the
bus is still somewhat reasonable. IDE passed beyond the veil two
years ago.
--John Hood, cgull@smoke.marlboro.vt.us
1997-07-29 12:57:25 +00:00
|
|
|
else if(timeouts < 5)
|
1994-10-27 05:39:12 +00:00
|
|
|
wderror((struct buf *)NULL, du, "interrupt timeout");
|
1994-02-01 05:55:21 +00:00
|
|
|
wdunwedge(du);
|
|
|
|
|
wdflushirq(du, x);
|
|
|
|
|
du->dk_skip = 0;
|
|
|
|
|
du->dk_flags |= DKFL_SINGLE;
|
|
|
|
|
wdstart(du->dk_ctrlr);
|
|
|
|
|
}
|
1994-08-23 07:52:29 +00:00
|
|
|
timeout(wdtimeout, cdu, hz);
|
1994-02-01 05:55:21 +00:00
|
|
|
splx(x);
|
|
|
|
|
}
|
|
|
|
|
|
1994-01-04 20:05:26 +00:00
|
|
|
/*
|
|
|
|
|
* Reset the controller after it has become wedged. This is different from
|
|
|
|
|
* wdreset() so that wdreset() can be used in the probe and so that this
|
|
|
|
|
* can restore the geometry .
|
|
|
|
|
*/
|
|
|
|
|
static int
|
|
|
|
|
wdunwedge(struct disk *du)
|
|
|
|
|
{
|
|
|
|
|
struct disk *du1;
|
1994-02-01 05:55:21 +00:00
|
|
|
int lunit;
|
1994-01-04 20:05:26 +00:00
|
|
|
|
|
|
|
|
/* Schedule other drives for recalibration. */
|
|
|
|
|
for (lunit = 0; lunit < NWD; lunit++)
|
|
|
|
|
if ((du1 = wddrives[lunit]) != NULL && du1 != du
|
|
|
|
|
&& du1->dk_ctrlr == du->dk_ctrlr
|
|
|
|
|
&& du1->dk_state > WANTOPEN)
|
|
|
|
|
du1->dk_state = WANTOPEN;
|
|
|
|
|
|
|
|
|
|
DELAY(RECOVERYTIME);
|
|
|
|
|
if (wdreset(du) == 0) {
|
|
|
|
|
/*
|
|
|
|
|
* XXX - recalibrate current drive now because some callers
|
|
|
|
|
* aren't prepared to have its state change.
|
|
|
|
|
*/
|
|
|
|
|
if (wdcommand(du, 0, 0, 0, 0, WDCC_RESTORE | WD_STEP) == 0
|
1994-02-11 12:02:35 +00:00
|
|
|
&& wdwait(du, WDCS_READY | WDCS_SEEKCMPLT, TIMEOUT) == 0
|
1994-01-04 20:05:26 +00:00
|
|
|
&& wdsetctlr(du) == 0)
|
|
|
|
|
return (0);
|
|
|
|
|
}
|
|
|
|
|
wderror((struct buf *)NULL, du, "wdunwedge failed");
|
|
|
|
|
return (1);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Wait uninterruptibly until controller is not busy and either certain
|
|
|
|
|
* status bits are set or an error has occurred.
|
|
|
|
|
* The wait is usually short unless it is for the controller to process
|
|
|
|
|
* an entire critical command.
|
|
|
|
|
* Return 1 for (possibly stale) controller errors, -1 for timeout errors,
|
|
|
|
|
* or 0 for no errors.
|
|
|
|
|
* Return controller status in du->dk_status and, if there was a controller
|
|
|
|
|
* error, return the error code in du->dk_error.
|
|
|
|
|
*/
|
1994-02-01 05:55:21 +00:00
|
|
|
#ifdef WD_COUNT_RETRIES
|
1994-01-04 20:05:26 +00:00
|
|
|
static int min_retries[NWDC];
|
1994-02-01 05:55:21 +00:00
|
|
|
#endif
|
|
|
|
|
|
1994-01-04 20:05:26 +00:00
|
|
|
static int
|
1994-02-11 12:02:35 +00:00
|
|
|
wdwait(struct disk *du, u_char bits_wanted, int timeout)
|
1994-01-04 20:05:26 +00:00
|
|
|
{
|
1994-02-01 05:55:21 +00:00
|
|
|
int wdc;
|
|
|
|
|
u_char status;
|
|
|
|
|
|
1994-01-04 20:05:26 +00:00
|
|
|
#define POLLING 1000
|
|
|
|
|
|
|
|
|
|
wdc = du->dk_port;
|
1994-02-11 12:02:35 +00:00
|
|
|
timeout += POLLING;
|
1995-02-27 06:42:35 +00:00
|
|
|
|
1995-04-22 22:44:30 +00:00
|
|
|
/*
|
|
|
|
|
* This delay is really too long, but does not impact the performance
|
1995-04-24 04:32:31 +00:00
|
|
|
* as much when using the multi-sector option. Shorter delays have
|
1995-04-22 22:44:30 +00:00
|
|
|
* caused I/O errors on some drives and system configs. This should
|
|
|
|
|
* probably be fixed if we develop a better short term delay mechanism.
|
|
|
|
|
*/
|
|
|
|
|
DELAY(1);
|
1995-02-27 06:42:35 +00:00
|
|
|
|
1994-01-04 20:05:26 +00:00
|
|
|
do {
|
1994-02-01 05:55:21 +00:00
|
|
|
#ifdef WD_COUNT_RETRIES
|
1994-02-11 12:02:35 +00:00
|
|
|
if (min_retries[du->dk_ctrlr] > timeout
|
1994-02-01 05:55:21 +00:00
|
|
|
|| min_retries[du->dk_ctrlr] == 0)
|
1994-02-11 12:02:35 +00:00
|
|
|
min_retries[du->dk_ctrlr] = timeout;
|
1994-02-01 05:55:21 +00:00
|
|
|
#endif
|
1994-01-04 20:05:26 +00:00
|
|
|
du->dk_status = status = inb(wdc + wd_status);
|
Latest fixes from Serge:
I tried to solve the problem of IDE probing compatibility in this version.
When compiled without an ATAPI option, the wd driver is
fully backward compatible with 2.0.5. With ATAPI option,
the wdprobe becomes strictly weaker. That is, if wdprobe works
without ATAPI option, it will always work with it too.
Another problem was with the CD-ROM drive attached as a slave
in the IDE bus, where there is no master. All IDE CD-ROM
drives are shipped in slave configuration, and most users
just plug them in, never thinking about jumpers.
It works fine with ms-dos and ms-windows, and this
version of the driver supports it as well.
The eject op can now load disks. Just repeat it twice,
and the disk will be ejected and then loaded back.
The disc cannot be ejected if it is mounted.
Submitted by: Serge Vakulenko, <vak@cronyx.ru>
1995-10-14 15:41:10 +00:00
|
|
|
#ifdef ATAPI
|
|
|
|
|
/*
|
|
|
|
|
* Atapi drives have a very interesting feature, when attached
|
|
|
|
|
* as a slave on the IDE bus, and there is no master.
|
|
|
|
|
* They release the bus after getting the command.
|
|
|
|
|
* We should reselect the drive here to get the status.
|
|
|
|
|
*/
|
|
|
|
|
if (status == 0xff) {
|
|
|
|
|
outb(wdc + wd_sdh, WDSD_IBM | du->dk_unit << 4);
|
|
|
|
|
du->dk_status = status = inb(wdc + wd_status);
|
|
|
|
|
}
|
|
|
|
|
#endif
|
1994-01-04 20:05:26 +00:00
|
|
|
if (!(status & WDCS_BUSY)) {
|
|
|
|
|
if (status & WDCS_ERR) {
|
|
|
|
|
du->dk_error = inb(wdc + wd_error);
|
|
|
|
|
/*
|
|
|
|
|
* We once returned here. This is wrong
|
|
|
|
|
* because the error bit is apparently only
|
|
|
|
|
* valid after the controller has interrupted
|
|
|
|
|
* (e.g., the error bit is stale when we wait
|
|
|
|
|
* for DRQ for writes). So we can't depend
|
|
|
|
|
* on the error bit at all when polling for
|
|
|
|
|
* command completion.
|
|
|
|
|
*/
|
|
|
|
|
}
|
|
|
|
|
if ((status & bits_wanted) == bits_wanted)
|
|
|
|
|
return (status & WDCS_ERR);
|
|
|
|
|
}
|
1994-02-11 12:02:35 +00:00
|
|
|
if (timeout < TIMEOUT)
|
1994-01-04 20:05:26 +00:00
|
|
|
/*
|
|
|
|
|
* Switch to a polling rate of about 1 KHz so that
|
|
|
|
|
* the timeout is almost machine-independent. The
|
|
|
|
|
* controller is taking a long time to respond, so
|
|
|
|
|
* an extra msec won't matter.
|
|
|
|
|
*/
|
|
|
|
|
DELAY(1000);
|
1995-02-27 06:42:35 +00:00
|
|
|
else
|
|
|
|
|
DELAY(1);
|
1994-02-11 12:02:35 +00:00
|
|
|
} while (--timeout != 0);
|
1994-01-04 20:05:26 +00:00
|
|
|
return (-1);
|
|
|
|
|
}
|
|
|
|
|
|
the second set of changes in a move towards getting devices to be
totally dynamic.
this is only the devices in i386/isa
I'll do more tomorrow.
they're completely masked by #ifdef JREMOD at this stage...
the eventual aim is that every driver will do a SYSINIT
at startup BEFORE the probes, which will effectively
link it into the devsw tables etc.
If I'd thought about it more I'd have put that in in this set (damn)
The ioconf lines generated by config will also end up in the
device's own scope as well, so ioconf.c will eventually be gutted
the SYSINIT call to the driver will include a phase where the
driver links it's ioconf line into a chain of such. when this phase is done
then the user can modify them with the boot: -c
config menu if he wants, just like now..
config will put the config lines out in the .h file
(e.g. in aha.h will be the addresses for the aha driver to look.)
as I said this is a very small first step..
the aim of THIS set of edits is to not have to edit conf.c at all when
adding a new device.. the tabe will be a simple skeleton..
when this is done, it will allow other changes to be made,
all teh time still having a fully working kernel tree,
but the logical outcome is the complete REMOVAL of the devsw tables.
By the end of this, linked in drivers will be exactly the same as
run-time loaded drivers, except they JUST HAPPEN to already be linked
and present at startup..
the SYSINIT calls will be the equivalent of the "init" call
made to a newly loaded driver in every respect.
For this edit,
each of the files has the following code inserted into it:
obviously, tailored to suit..
----------------------somewhere at the top:
#ifdef JREMOD
#include <sys/conf.h>
#define CDEV_MAJOR 13
#define BDEV_MAJOR 4
static void sd_devsw_install();
#endif /*JREMOD */
---------------------somewhere that's run during bootup: EVENTUALLY a SYSINIT
#ifdef JREMOD
sd_devsw_install();
#endif /*JREMOD*/
-----------------------at the bottom:
#ifdef JREMOD
struct bdevsw sd_bdevsw =
{ sdopen, sdclose, sdstrategy, sdioctl, /*4*/
sddump, sdsize, 0 };
struct cdevsw sd_cdevsw =
{ sdopen, sdclose, rawread, rawwrite, /*13*/
sdioctl, nostop, nullreset, nodevtotty,/* sd */
seltrue, nommap, sdstrategy };
static sd_devsw_installed = 0;
static void sd_devsw_install()
{
dev_t descript;
if( ! sd_devsw_installed ) {
descript = makedev(CDEV_MAJOR,0);
cdevsw_add(&descript,&sd_cdevsw,NULL);
#if defined(BDEV_MAJOR)
descript = makedev(BDEV_MAJOR,0);
bdevsw_add(&descript,&sd_bdevsw,NULL);
#endif /*BDEV_MAJOR*/
sd_devsw_installed = 1;
}
}
#endif /* JREMOD */
1995-11-28 09:42:06 +00:00
|
|
|
static wd_devsw_installed = 0;
|
|
|
|
|
|
1995-11-29 10:49:16 +00:00
|
|
|
static void wd_drvinit(void *unused)
|
the second set of changes in a move towards getting devices to be
totally dynamic.
this is only the devices in i386/isa
I'll do more tomorrow.
they're completely masked by #ifdef JREMOD at this stage...
the eventual aim is that every driver will do a SYSINIT
at startup BEFORE the probes, which will effectively
link it into the devsw tables etc.
If I'd thought about it more I'd have put that in in this set (damn)
The ioconf lines generated by config will also end up in the
device's own scope as well, so ioconf.c will eventually be gutted
the SYSINIT call to the driver will include a phase where the
driver links it's ioconf line into a chain of such. when this phase is done
then the user can modify them with the boot: -c
config menu if he wants, just like now..
config will put the config lines out in the .h file
(e.g. in aha.h will be the addresses for the aha driver to look.)
as I said this is a very small first step..
the aim of THIS set of edits is to not have to edit conf.c at all when
adding a new device.. the tabe will be a simple skeleton..
when this is done, it will allow other changes to be made,
all teh time still having a fully working kernel tree,
but the logical outcome is the complete REMOVAL of the devsw tables.
By the end of this, linked in drivers will be exactly the same as
run-time loaded drivers, except they JUST HAPPEN to already be linked
and present at startup..
the SYSINIT calls will be the equivalent of the "init" call
made to a newly loaded driver in every respect.
For this edit,
each of the files has the following code inserted into it:
obviously, tailored to suit..
----------------------somewhere at the top:
#ifdef JREMOD
#include <sys/conf.h>
#define CDEV_MAJOR 13
#define BDEV_MAJOR 4
static void sd_devsw_install();
#endif /*JREMOD */
---------------------somewhere that's run during bootup: EVENTUALLY a SYSINIT
#ifdef JREMOD
sd_devsw_install();
#endif /*JREMOD*/
-----------------------at the bottom:
#ifdef JREMOD
struct bdevsw sd_bdevsw =
{ sdopen, sdclose, sdstrategy, sdioctl, /*4*/
sddump, sdsize, 0 };
struct cdevsw sd_cdevsw =
{ sdopen, sdclose, rawread, rawwrite, /*13*/
sdioctl, nostop, nullreset, nodevtotty,/* sd */
seltrue, nommap, sdstrategy };
static sd_devsw_installed = 0;
static void sd_devsw_install()
{
dev_t descript;
if( ! sd_devsw_installed ) {
descript = makedev(CDEV_MAJOR,0);
cdevsw_add(&descript,&sd_cdevsw,NULL);
#if defined(BDEV_MAJOR)
descript = makedev(BDEV_MAJOR,0);
bdevsw_add(&descript,&sd_bdevsw,NULL);
#endif /*BDEV_MAJOR*/
sd_devsw_installed = 1;
}
}
#endif /* JREMOD */
1995-11-28 09:42:06 +00:00
|
|
|
{
|
1995-11-29 10:49:16 +00:00
|
|
|
|
the second set of changes in a move towards getting devices to be
totally dynamic.
this is only the devices in i386/isa
I'll do more tomorrow.
they're completely masked by #ifdef JREMOD at this stage...
the eventual aim is that every driver will do a SYSINIT
at startup BEFORE the probes, which will effectively
link it into the devsw tables etc.
If I'd thought about it more I'd have put that in in this set (damn)
The ioconf lines generated by config will also end up in the
device's own scope as well, so ioconf.c will eventually be gutted
the SYSINIT call to the driver will include a phase where the
driver links it's ioconf line into a chain of such. when this phase is done
then the user can modify them with the boot: -c
config menu if he wants, just like now..
config will put the config lines out in the .h file
(e.g. in aha.h will be the addresses for the aha driver to look.)
as I said this is a very small first step..
the aim of THIS set of edits is to not have to edit conf.c at all when
adding a new device.. the tabe will be a simple skeleton..
when this is done, it will allow other changes to be made,
all teh time still having a fully working kernel tree,
but the logical outcome is the complete REMOVAL of the devsw tables.
By the end of this, linked in drivers will be exactly the same as
run-time loaded drivers, except they JUST HAPPEN to already be linked
and present at startup..
the SYSINIT calls will be the equivalent of the "init" call
made to a newly loaded driver in every respect.
For this edit,
each of the files has the following code inserted into it:
obviously, tailored to suit..
----------------------somewhere at the top:
#ifdef JREMOD
#include <sys/conf.h>
#define CDEV_MAJOR 13
#define BDEV_MAJOR 4
static void sd_devsw_install();
#endif /*JREMOD */
---------------------somewhere that's run during bootup: EVENTUALLY a SYSINIT
#ifdef JREMOD
sd_devsw_install();
#endif /*JREMOD*/
-----------------------at the bottom:
#ifdef JREMOD
struct bdevsw sd_bdevsw =
{ sdopen, sdclose, sdstrategy, sdioctl, /*4*/
sddump, sdsize, 0 };
struct cdevsw sd_cdevsw =
{ sdopen, sdclose, rawread, rawwrite, /*13*/
sdioctl, nostop, nullreset, nodevtotty,/* sd */
seltrue, nommap, sdstrategy };
static sd_devsw_installed = 0;
static void sd_devsw_install()
{
dev_t descript;
if( ! sd_devsw_installed ) {
descript = makedev(CDEV_MAJOR,0);
cdevsw_add(&descript,&sd_cdevsw,NULL);
#if defined(BDEV_MAJOR)
descript = makedev(BDEV_MAJOR,0);
bdevsw_add(&descript,&sd_bdevsw,NULL);
#endif /*BDEV_MAJOR*/
sd_devsw_installed = 1;
}
}
#endif /* JREMOD */
1995-11-28 09:42:06 +00:00
|
|
|
if( ! wd_devsw_installed ) {
|
1996-07-23 21:52:43 +00:00
|
|
|
bdevsw_add_generic(BDEV_MAJOR,CDEV_MAJOR, &wd_bdevsw);
|
the second set of changes in a move towards getting devices to be
totally dynamic.
this is only the devices in i386/isa
I'll do more tomorrow.
they're completely masked by #ifdef JREMOD at this stage...
the eventual aim is that every driver will do a SYSINIT
at startup BEFORE the probes, which will effectively
link it into the devsw tables etc.
If I'd thought about it more I'd have put that in in this set (damn)
The ioconf lines generated by config will also end up in the
device's own scope as well, so ioconf.c will eventually be gutted
the SYSINIT call to the driver will include a phase where the
driver links it's ioconf line into a chain of such. when this phase is done
then the user can modify them with the boot: -c
config menu if he wants, just like now..
config will put the config lines out in the .h file
(e.g. in aha.h will be the addresses for the aha driver to look.)
as I said this is a very small first step..
the aim of THIS set of edits is to not have to edit conf.c at all when
adding a new device.. the tabe will be a simple skeleton..
when this is done, it will allow other changes to be made,
all teh time still having a fully working kernel tree,
but the logical outcome is the complete REMOVAL of the devsw tables.
By the end of this, linked in drivers will be exactly the same as
run-time loaded drivers, except they JUST HAPPEN to already be linked
and present at startup..
the SYSINIT calls will be the equivalent of the "init" call
made to a newly loaded driver in every respect.
For this edit,
each of the files has the following code inserted into it:
obviously, tailored to suit..
----------------------somewhere at the top:
#ifdef JREMOD
#include <sys/conf.h>
#define CDEV_MAJOR 13
#define BDEV_MAJOR 4
static void sd_devsw_install();
#endif /*JREMOD */
---------------------somewhere that's run during bootup: EVENTUALLY a SYSINIT
#ifdef JREMOD
sd_devsw_install();
#endif /*JREMOD*/
-----------------------at the bottom:
#ifdef JREMOD
struct bdevsw sd_bdevsw =
{ sdopen, sdclose, sdstrategy, sdioctl, /*4*/
sddump, sdsize, 0 };
struct cdevsw sd_cdevsw =
{ sdopen, sdclose, rawread, rawwrite, /*13*/
sdioctl, nostop, nullreset, nodevtotty,/* sd */
seltrue, nommap, sdstrategy };
static sd_devsw_installed = 0;
static void sd_devsw_install()
{
dev_t descript;
if( ! sd_devsw_installed ) {
descript = makedev(CDEV_MAJOR,0);
cdevsw_add(&descript,&sd_cdevsw,NULL);
#if defined(BDEV_MAJOR)
descript = makedev(BDEV_MAJOR,0);
bdevsw_add(&descript,&sd_bdevsw,NULL);
#endif /*BDEV_MAJOR*/
sd_devsw_installed = 1;
}
}
#endif /* JREMOD */
1995-11-28 09:42:06 +00:00
|
|
|
wd_devsw_installed = 1;
|
1995-11-29 14:41:20 +00:00
|
|
|
}
|
the second set of changes in a move towards getting devices to be
totally dynamic.
this is only the devices in i386/isa
I'll do more tomorrow.
they're completely masked by #ifdef JREMOD at this stage...
the eventual aim is that every driver will do a SYSINIT
at startup BEFORE the probes, which will effectively
link it into the devsw tables etc.
If I'd thought about it more I'd have put that in in this set (damn)
The ioconf lines generated by config will also end up in the
device's own scope as well, so ioconf.c will eventually be gutted
the SYSINIT call to the driver will include a phase where the
driver links it's ioconf line into a chain of such. when this phase is done
then the user can modify them with the boot: -c
config menu if he wants, just like now..
config will put the config lines out in the .h file
(e.g. in aha.h will be the addresses for the aha driver to look.)
as I said this is a very small first step..
the aim of THIS set of edits is to not have to edit conf.c at all when
adding a new device.. the tabe will be a simple skeleton..
when this is done, it will allow other changes to be made,
all teh time still having a fully working kernel tree,
but the logical outcome is the complete REMOVAL of the devsw tables.
By the end of this, linked in drivers will be exactly the same as
run-time loaded drivers, except they JUST HAPPEN to already be linked
and present at startup..
the SYSINIT calls will be the equivalent of the "init" call
made to a newly loaded driver in every respect.
For this edit,
each of the files has the following code inserted into it:
obviously, tailored to suit..
----------------------somewhere at the top:
#ifdef JREMOD
#include <sys/conf.h>
#define CDEV_MAJOR 13
#define BDEV_MAJOR 4
static void sd_devsw_install();
#endif /*JREMOD */
---------------------somewhere that's run during bootup: EVENTUALLY a SYSINIT
#ifdef JREMOD
sd_devsw_install();
#endif /*JREMOD*/
-----------------------at the bottom:
#ifdef JREMOD
struct bdevsw sd_bdevsw =
{ sdopen, sdclose, sdstrategy, sdioctl, /*4*/
sddump, sdsize, 0 };
struct cdevsw sd_cdevsw =
{ sdopen, sdclose, rawread, rawwrite, /*13*/
sdioctl, nostop, nullreset, nodevtotty,/* sd */
seltrue, nommap, sdstrategy };
static sd_devsw_installed = 0;
static void sd_devsw_install()
{
dev_t descript;
if( ! sd_devsw_installed ) {
descript = makedev(CDEV_MAJOR,0);
cdevsw_add(&descript,&sd_cdevsw,NULL);
#if defined(BDEV_MAJOR)
descript = makedev(BDEV_MAJOR,0);
bdevsw_add(&descript,&sd_bdevsw,NULL);
#endif /*BDEV_MAJOR*/
sd_devsw_installed = 1;
}
}
#endif /* JREMOD */
1995-11-28 09:42:06 +00:00
|
|
|
}
|
1995-11-29 10:49:16 +00:00
|
|
|
|
|
|
|
|
SYSINIT(wddev,SI_SUB_DRIVERS,SI_ORDER_MIDDLE+CDEV_MAJOR,wd_drvinit,NULL)
|
|
|
|
|
|
|
|
|
|
|
1994-02-01 05:55:21 +00:00
|
|
|
#endif /* NWDC > 0 */
|
