Commit Graph

53 Commits

Author SHA1 Message Date
dyson
c2f779ce3a SMP Natoma motherboards cannot know if you are booting a UP or SMP OS. This
mod makes sure that the Natoma chipset is set into the correct mode.  In
the case of my P6DNF, when booting a UP kernel, I see a substantial improvement
in the latency of certain operations.   It appears that the cache hit
latency is curiously improved the most, per lat_mem_rd.
1997-08-16 07:18:51 +00:00
phk
3cd087ca46 Fix the VLSI chipset name from "Eagle" to "Eagle II". 1997-08-10 09:33:21 +00:00
phk
4ab3727023 Add ID's for 5 VLSI chips. They're not very friendly, so this info was
found by taking my HP800CT apart, perusing HPs (Very good!) service
manual and inference from a bad gif file I found in Finland.
Sigh...  But it's a nice machine :-)
1997-08-08 21:11:40 +00:00
bde
9195bd1ec7 Removed unused #includes. 1997-08-02 14:33:27 +00:00
sos
f827c62c94 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
se
ecd0abeac8 Assign correct chip set register dump functions to Triton II device IDs.
PR:		i386/4092
Submitted by:	Steve Bauer <sbauer@rock.sdsmt.edu>
1997-07-18 19:47:23 +00:00
se
854d44183b Add code to correctly probe all buses on the Intel XXPRESS motherboard.
Add a few Intel PCI chip-set names (VX) and fix Orion entries.
1997-05-30 21:01:47 +00:00
se
cfea775806 Completely replace the PCI bus driver code to make it better reflect
reality. There will be a new call interface, but for now the file
pci_compat.c (which is to be deleted, after all drivers are converted)
provides an emulation of the old PCI bus driver functions. The only
change that might be visible to drivers is, that the type pcici_t
(which had been meant to be just a handle, whose exact definition
should not be relied on), has been converted into a pcicfgregs* .

The Tekram AMD SCSI driver bogusly relied on the definition of pcici_t
and has been converted to just call the PCI drivers functions to access
configuration space register, instead of inventing its own ...

This code is by no means complete, but assumed to be fully operational,
and brings the official code base more in line with my development code.

A new generic device descriptor data type has to be agreed on. The PCI
code will then use that data type to provide new functionality:

1) userconfig support
2) "wired" PCI devices
3) conflicts checking against ISA/EISA
4) maps will depend on the command register enable bits
5) PCI to Anything bridges can be defined as devices,
   and are probed like any "standard" PCI device.

The following features are currently missing, but will be added back,
soon:

1) unknown device probe message
2) suppression of "mirrored" devices caused by ancient, broken chip-sets

This code relies on generic shared interrupt support just commited to
kern_intr.c (plus the modifications of isa.c and isa_device.h).
1997-05-26 15:08:43 +00:00
phk
e0c6c153a3 Don't break the nice symmetry of these messages with undue '>' chars. 1997-03-28 18:40:24 +00:00
se
505530044a Improve probe message for generic PCI->xxx bridge chips.
Submitted by:	phk
1997-03-25 19:03:04 +00:00
peter
94b6d72794 Back out part 1 of the MCFH that changed $Id$ to $FreeBSD$. We are not
ready for it yet.
1997-02-22 09:48:43 +00:00
jkh
808a36ef65 Make the long-awaited change from $Id$ to $FreeBSD$
This will make a number of things easier in the future, as well as (finally!)
avoiding the Id-smashing problem which has plagued developers for so long.

Boy, I'm glad we're not using sup anymore.  This update would have been
insane otherwise.
1997-01-14 07:20:47 +00:00
se
92f2d80d98 Add Intel VX chip set specific detection and register dump code.
Submitted by:	brianc@netrover.com (Brian Campbell)
1997-01-02 01:23:17 +00:00
rgrimes
7a685f7439 Re-enable conf82371fb2 now that I have verified that it works, even if
it only prints 2 bits out of hundreds.  (Minimizing the diff between
-head and 2.1.5.)
1996-09-16 08:56:39 +00:00
rgrimes
d9c5cf01e0 Remove the portion of revision 1.36 that added the #ifdef's for CPU
types as per discussions with Stefan Esser.
1996-09-09 06:09:45 +00:00
phk
bca885205d Remove devconf, it never grew up to be of any use. 1996-09-06 23:09:20 +00:00
rgrimes
efc66b15ae Partial merge of RELENG_2_1_0 -> HEAD (addition of Intel 82439HX chip text). 1996-09-06 09:21:48 +00:00
se
ee34d7e195 Fix Orion specific code by moving config_orion() to a place where it does
not depend on bootverbose being true.

Include only register specifications for those chip sets that apply to
a cpu that might boot this a particular kernel (ie. make the Saturn code
depend on I486_CPU being defined, the Pentium chip sets on I586_CPU ...)
1996-09-05 21:34:12 +00:00
se
4f76890c16 Correct previous Orion specific fix: The configuration register
access function always returns a DWORD aligned DWORD ...
1996-09-02 21:33:41 +00:00
se
d6fd1776b0 Add preliminary support for the Orion PCI chip set. It is special in the
way it attaches multiple PCI buses directly to the CPU, instead of having
them hanging off from PCI to PCI bridges. This code is a hack, and will
be obsoleted by the planned rework of the PCI code, which will change the
dealing with PCI to PCI bridges and other special devices significantly.

The patch also adds a kern_devconf entry for PCI bus 0 which is assumed
to be a child of cpu0. The new PCI code will make it possible to hand out
the kern_devconf structure to a pci device being attached, since this is
(regretably, IMHO) required by a few ISA devices.

Finally there are new PCI ids for some Intel chip set devices, which had
already been known to 2.1.5R, but did not make it into -current. This closes
"kern/1558: PCI probe seems to have lost a device in -current".
1996-09-02 21:23:06 +00:00
bde
cfdfb3c281 Removed now-unused #includes of <machine/cpu.h>. They were for bootverbose
being declared in the wrong place.
1996-04-07 17:32:42 +00:00
se
139a5ed52c Add generic PCI to PCI bridge support.
Improve verbose boot messages for unidentified chips.
1996-02-17 23:57:04 +00:00
wollman
c02be74f05 Implement a prototype interface to bus-master IDE DMA on the Triton
chipset.  This does not attempt to do anything special with the timing
on the hope that the BIOS will have done the right thing already.  The
actual interface from the wd driver to the new facility is not
implemented yet (this commit being an attempt at prodding someone else
to do it because looking at the wd driver always confuses the h*** out of me).
1996-01-28 22:16:20 +00:00
wollman
3ebe21e07b Decode configuration for the IDE part of the Triton chipset. This
includes a hack in the probe code: the 82371FB is a multifuction
device, but doesn't properly set the configuration bit which
indicates this.  So, we just hard-wire all 82371FBs as multifunction
devices.

This does not actually make the bus-master IDE stuff work, although
if anyone wants to work on that, I have the databooks that tell
how to use it.
1996-01-27 20:14:32 +00:00
wollman
6fd0c86ccc Correctly identify the various parts of the Triton chipset. 1996-01-25 20:38:31 +00:00
wollman
1d9e7dac5c Spelling error: Busting -> Bursting. 1996-01-23 21:31:51 +00:00
wollman
7b8816e057 Got the sense of the L1 cache enabled test wrong; fixed. 1996-01-23 20:36:49 +00:00
wollman
5de35f4d42 Add support for dumping the configuration of the Intel
82371FB PCI ISA IDE Xcellerator (sic) chip.  The IDE function
will not be done until Stefan tells me how to access it.
1996-01-23 20:21:24 +00:00
wollman
6ae0d73e93 Add register definitions for Intel 82437FX (Triton System Controller) 1996-01-22 22:43:48 +00:00
phk
9cb413a93c Another mega commit to staticize things. 1995-12-14 09:55:16 +00:00
bde
9d43933c59 Renamed TRUE (which has value 2) to M_TR to avoid a clash with the
the boolean TRUE.
1995-12-05 20:40:10 +00:00
se
966d73112d Remove '#ifdef undef' that was only supposed to be in my local test version. 1995-09-14 17:26:24 +00:00
se
1104c373a3 Do not include the verbose boot messages, if PCI_QUIET is defined. 1995-09-14 13:13:33 +00:00
se
39322cdbf1 Remove support for PCI bridge classes, since this
dealt with by code in pci.c now.
1995-09-07 15:40:51 +00:00
se
c574ff1709 Add description of Intel 82425EX PCI system controller chip (Aries ?).
Submitted by:	Danny J. Zerkel <dzerkel@feephi.phofarm.com>
1995-09-07 14:17:46 +00:00
se
bd57cefcd4 Add more chip set register decodings:
ISA GAT mode and hidden refresh seem to cause reliability problems
on Saturn based systems and are now reported when booting with '-v'.

Submitted by:	Danny J. Zerkel <dzerkel@feephi.phofarm.com>
1995-08-15 09:43:42 +00:00
se
0d80d6cf0d Add a few chip set IDs. 1995-07-27 22:14:25 +00:00
se
48d4f5cf6b Add config messages for the Intel 82378 chip.
Submitted by:   Danny J. Zerkel <dzerkel@feephi.phofarm.com>
1995-07-27 22:04:57 +00:00
se
2b44d2ccf2 Give more detailed information about the type of bridge devices
found when probing the PCI bus.
1995-06-28 16:02:05 +00:00
se
2a67a27d9b Corrections and additions to the PCI chip set configurations log.
Submitted by:	"Danny J. Zerkel" <dzerkel@feephi.phofarm.com>
1995-06-28 11:28:43 +00:00
se
6e667246cd Completely new PCI code:
1) Supports PCI to PCI bridge devices (and tries to initialise them,
   even if the BIOS is brain dead).
2) Supports shared PCI interrupts. Interrupt handlers now MUST return
   '0' if they found nothing to do, '1' otherwise.

New features tested with i486 systems based on the Intel Saturn and
a DEC 4channel Ethernet card only, but expected to work on most systems.

The option PCI_REMAP has been removed !

Submitted by:	Wolfgang Stanglmeier <wolf@kintaro.cologne.de>
1995-03-21 23:01:06 +00:00
dg
b553215b12 Added a new field to the pci_device struct called pd_shutdown to specify
a device specific shutdown routine for devconf. Assign the value of this
to the kern_devconf struct. Implement a device shutdown routine for if_de
that disables the device. This will stop the device from corrupting memory
after a reboot.
1995-03-17 04:27:21 +00:00
se
84213d5699 Disable vga_attach() code, as it always should have been. 1995-03-02 23:29:44 +00:00
se
45a93efd7d Add code to deal with PCI-PCI bridge chips, especially the DEC 21050.
Try to deduce maximum number of PCI buses in system (working around
chip set bugs).
Better check for devices at multiple addresses (aliases).

Reviewed by:	se
Submitted by:	<wolf@kintaro.cologne.de> Wolfgang Stanglmeier
1995-02-27 17:22:09 +00:00
wollman
293acf9294 Make capitalization consistent with other devices registered in
the database.  Also, distinguish between VGA-like display devices
and everything else.
1995-02-14 03:19:27 +00:00
dg
57e383cd4c Reapplied all of Stefan's changes. What a mess - the files were modified
and moved at the same time. This made it *very* difficult to fix the
revision log lossage that happend when the files were moved. SIGH.
1995-02-02 13:12:18 +00:00
dg
1cfe037240 Fixed up include paths after copying these in the repository. 1995-02-02 12:36:19 +00:00
se
c01314f53a Add support for -v option passed to boot loader (bootverbose).
Reviewed by:
Submitted by:
Obtained from:
1994-12-22 21:20:39 +00:00
se
04ad970a93 Added decoding of chipset registers for Pentium 90/100 CPUs. 1994-10-25 18:45:19 +00:00
phk
93841a2173 #ifdef'ed the verbose probe messages. Only until I find a good way of
making it run-time selectable, then it will be back (at will).
1994-10-17 21:11:31 +00:00