d/freebsd-nq
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
8cd077a7fd
freebsd-nq/sys/pci/ide_pci.c

1430 lines
35 KiB
C
Raw Normal View History

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
/*
* Copyright 1996 Massachusetts Institute of Technology
*
* Permission to use, copy, modify, and distribute this software and
* its documentation for any purpose and without fee is hereby
* granted, provided that both the above copyright notice and this
* permission notice appear in all copies, that both the above
* copyright notice and this permission notice appear in all
* supporting documentation, and that the name of M.I.T. not be used
* in advertising or publicity pertaining to distribution of the
* software without specific, written prior permission. M.I.T. makes
* no representations about the suitability of this software for any
* purpose. It is provided "as is" without express or implied
* warranty.
*
* THIS SOFTWARE IS PROVIDED BY M.I.T. ``AS IS''. M.I.T. DISCLAIMS
* ALL EXPRESS OR IMPLIED WARRANTIES WITH REGARD TO THIS SOFTWARE,
* INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
* MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT
* SHALL M.I.T. 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.
*
Remove a bunch of variables which were unused both in GENERIC and LINT. Found by: -Wunused
1997-11-07 08:53:44 +00:00
* $Id: ide_pci.c,v 1.4 1997/09/20 07:41:55 dyson Exp $
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
*/
#include "pci.h"
#if NPCI > 0
Upgrade of EIDE DMA support, Johns comments: * lots of fixes to error handling-- mostly works now * improve DMA timing config for Triton chipsets-- PIIX4 and UDMA drive still untested * generally improve DMA config in many ways-- mostly cleanup * clean up boot-time messages * rewrite PRD generation algorithm * first wd timeout is now longer, to handle drive spinup Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-04 18:49:53 +00:00
#include "opt_wd.h"
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
#include "wd.h"
#if NWDC > 0
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
#include <sys/param.h>
#include <sys/systm.h>
#include <sys/buf.h>
#include <sys/malloc.h>
#include <sys/kernel.h>
#include <vm/vm.h>
#include <vm/pmap.h>
#include <i386/isa/wdreg.h>
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
#include <i386/isa/isa.h>
#include <i386/isa/isa_device.h>
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
#include <pci/pcivar.h>
#include <pci/pcireg.h>
#include <pci/ide_pcireg.h>
Upgrade of EIDE DMA support, Johns comments: * lots of fixes to error handling-- mostly works now * improve DMA timing config for Triton chipsets-- PIIX4 and UDMA drive still untested * generally improve DMA config in many ways-- mostly cleanup * clean up boot-time messages * rewrite PRD generation algorithm * first wd timeout is now longer, to handle drive spinup Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-04 18:49:53 +00:00
#ifndef MIN
#define MIN(a,b) (((a)<(b))?(a):(b))
#endif
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
#define PROMISE_ULTRA33 0x4d33105a
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 ide_pci_cookie; /* structs vendor_fns, ide_pci_cookie are recursive */
struct vendor_fns {
int (*vendor_dmainit) /* initialize DMA controller and drive */
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
(struct ide_pci_cookie *cookie,
struct wdparams *wp,
int (*wdcmd)(int, void *),
void *);
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
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
void (*vendor_status) /* prints off DMA timing info */
(struct ide_pci_cookie *cookie);
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
};
/*
* XXX the fact that this list keeps all kinds of info on PCI controllers
* is pretty grotty-- much of this should be replaced by a proper integration
* of PCI probes into the wd driver.
* XXX if we're going to support native-PCI controllers, we also need to
* keep the address of the IDE control block register, which is something wd.c
* needs to know, which is why this info is in the wrong place.
*/
struct ide_pci_cookie {
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
LIST_ENTRY(ide_pci_cookie) le;
int iobase_wd;
int ctlr; /* controller 0/1 on PCI IDE interface */
int unit;
int iobase_bm; /* SFF-8038 control registers */
int altiobase_wd;
pcici_t tag;
pcidi_t type;
struct ide_pci_prd *prd;
struct vendor_fns vs;
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 ide_pci_softc {
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
LIST_HEAD(, ide_pci_cookie) cookies;
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
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
generic_dmainit(struct ide_pci_cookie *cookie,
struct wdparams *wp,
int (*wdcmd)(int, void *),
void *wdinfo);
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 void
Upgrade of EIDE DMA support, Johns comments: * lots of fixes to error handling-- mostly works now * improve DMA timing config for Triton chipsets-- PIIX4 and UDMA drive still untested * generally improve DMA config in many ways-- mostly cleanup * clean up boot-time messages * rewrite PRD generation algorithm * first wd timeout is now longer, to handle drive spinup Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-04 18:49:53 +00:00
generic_status(struct ide_pci_cookie *cookie);
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 void
Upgrade of EIDE DMA support, Johns comments: * lots of fixes to error handling-- mostly works now * improve DMA timing config for Triton chipsets-- PIIX4 and UDMA drive still untested * generally improve DMA config in many ways-- mostly cleanup * clean up boot-time messages * rewrite PRD generation algorithm * first wd timeout is now longer, to handle drive spinup Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-04 18:49:53 +00:00
via_571_status(struct ide_pci_cookie *cookie);
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
static int
via_571_dmainit(struct ide_pci_cookie *cookie,
struct wdparams *wp,
int (*wdcmd)(int, void *),
void *wdinfo);
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 void
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
intel_piix_dump_drive(char *ctlr,
int sitre,
int is_piix4,
int word40,
int word44,
int word48,
int word4a,
int drive);
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 void
Upgrade of EIDE DMA support, Johns comments: * lots of fixes to error handling-- mostly works now * improve DMA timing config for Triton chipsets-- PIIX4 and UDMA drive still untested * generally improve DMA config in many ways-- mostly cleanup * clean up boot-time messages * rewrite PRD generation algorithm * first wd timeout is now longer, to handle drive spinup Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-04 18:49:53 +00:00
intel_piix_status(struct ide_pci_cookie *cookie);
static int
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
intel_piix_dmainit(struct ide_pci_cookie *cookie,
struct wdparams *wp,
int (*wdcmd)(int, void *),
void *wdinfo);
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 struct ide_pci_cookie *
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
mkcookie(int iobase_wd,
int ctlr,
int unit,
int iobase_bm,
pcici_t tag,
pcidi_t type,
struct vendor_fns *vp,
int altiobase_wd);
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 void ide_pci_attach(pcici_t tag, int unit);
static void *ide_pci_candma(int, int);
static int ide_pci_dmainit(void *,
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
struct wdparams *,
int (*)(int, void *),
void *);
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 ide_pci_dmaverify(void *, char *, u_long, int);
static int ide_pci_dmasetup(void *, char *, u_long, int);
static void ide_pci_dmastart(void *);
static int ide_pci_dmadone(void *);
static int ide_pci_status(void *);
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
static int ide_pci_iobase(void *xcp);
static int ide_pci_altiobase(void *xcp);
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 struct ide_pci_softc softc;
static int ide_pci_softc_cookies_initted = 0;
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
extern void wdintr(void *);
extern struct isa_driver wdcdriver;
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
/*
* PRD_ALLOC_SIZE should be something that will not be allocated across a 64k
* boundary.
* PRD_MAX_SEGS is defined to be the maximum number of segments required for
* a transfer on an IDE drive, for an xfer that is linear in virtual memory.
* PRD_BUF_SIZE is the size of the buffer needed for a PRD table.
*/
#define PRD_ALLOC_SIZE PAGE_SIZE
#define PRD_MAX_SEGS ((256 * 512 / PAGE_SIZE) + 1)
#define PRD_BUF_SIZE PRD_MAX_SEGS * 8
static void *prdbuf = 0;
static void *prdbuf_next = 0;
/*
* Hardware specific IDE controller code. All vendor-specific code
* for handling IDE timing and other chipset peculiarities should be
* encapsulated here.
*/
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
/* helper funcs */
/*
* nnn_mode() return the highest valid mode, or -1 if the mode class is
* not supported
*/
static inline int
pio_mode(struct wdparams *wp)
{
if ((wp->wdp_atavalid & 2) == 2) {
if ((wp->wdp_eidepiomodes & 2) == 2) return 4;
if ((wp->wdp_eidepiomodes & 1) == 1) return 3;
}
return -1;
}
#if 0
static inline int
dma_mode(struct wdparams *wp)
{
/* XXX not quite sure how to verify validity on this field */
}
#endif
static inline int
mwdma_mode(struct wdparams *wp)
{
/*
* XXX technically, using wdp_atavalid to test for validity of
* this field is not quite correct
*/
if ((wp->wdp_atavalid & 2) == 2) {
if ((wp->wdp_dmamword & 4) == 4) return 2;
if ((wp->wdp_dmamword & 2) == 2) return 1;
if ((wp->wdp_dmamword & 1) == 1) return 0;
}
return -1;
}
static inline int
udma_mode(struct wdparams *wp)
{
if ((wp->wdp_atavalid & 4) == 4) {
if ((wp->wdp_udmamode & 4) == 4) return 2;
if ((wp->wdp_udmamode & 2) == 2) return 1;
if ((wp->wdp_udmamode & 1) == 1) return 0;
}
return -1;
}
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
/* Generic busmastering PCI-IDE */
static int
generic_dmainit(struct ide_pci_cookie *cookie,
struct wdparams *wp,
int(*wdcmd)(int, void *),
void *wdinfo)
{
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
/*
* punt on the whole timing issue by looking for either a
* drive programmed for both PIO4 and mDMA2 (which use similar
* timing) or a drive in an UltraDMA mode (hopefully all
* controllers have separate timing for UDMA). one hopes that if
* the drive's DMA mode has been configured by the BIOS, the
* controller's has also.
*
* XXX there are examples where this approach is now known to be
* broken, at least on systems based on Intel chipsets.
*/
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
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
if ((pio_mode(wp) >= 4 && mwdma_mode(wp) >= 2) ||
(udma_mode(wp) >= 2)) {
printf("ide_pci: generic_dmainit %04x:%d: warning, IDE controller timing not set\n",
cookie->iobase_wd,
cookie->unit);
return 1;
}
#ifdef IDE_PCI_DEBUG
printf("pio_mode: %d, mwdma_mode(wp): %d, udma_mode(wp): %d\n",
pio_mode(wp), mwdma_mode(wp), udma_mode(wp));
#endif
return 0;
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 void
Upgrade of EIDE DMA support, Johns comments: * lots of fixes to error handling-- mostly works now * improve DMA timing config for Triton chipsets-- PIIX4 and UDMA drive still untested * generally improve DMA config in many ways-- mostly cleanup * clean up boot-time messages * rewrite PRD generation algorithm * first wd timeout is now longer, to handle drive spinup Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-04 18:49:53 +00:00
generic_status(struct ide_pci_cookie *cookie)
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
{
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
printf("generic_status: no PCI IDE timing info available\n");
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 struct vendor_fns vs_generic =
{
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
generic_dmainit,
generic_status
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
};
/* VIA Technologies "82C571" PCI-IDE controller core */
static void
Upgrade of EIDE DMA support, Johns comments: * lots of fixes to error handling-- mostly works now * improve DMA timing config for Triton chipsets-- PIIX4 and UDMA drive still untested * generally improve DMA config in many ways-- mostly cleanup * clean up boot-time messages * rewrite PRD generation algorithm * first wd timeout is now longer, to handle drive spinup Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-04 18:49:53 +00:00
via_571_status(struct ide_pci_cookie *cookie)
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
{
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
int iobase_wd;
int ctlr, unit;
int iobase_bm;
pcici_t tag;
pcidi_t type;
u_long word40[5];
int i, unitno;
iobase_wd = cookie->iobase_wd;
unit = cookie->unit;
ctlr = cookie->ctlr;
iobase_bm = cookie->iobase_bm;
tag = cookie->tag;
type = cookie->type;
unitno = ctlr * 2 + unit;
for (i=0; i<5; i++) {
word40[i] = pci_conf_read(tag, i * 4 + 0x40);
}
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
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
if (ctlr == 0)
printf("via_571_status: Primary IDE prefetch/postwrite %s/%s\n",
word40[0] & 0x8000 ? "enabled" : "disabled",
word40[0] & 0x4000 ? "enabled" : "disabled");
else
printf("via_571_status: Secondary IDE prefetch/postwrite %s/%s\n",
word40[0] & 0x2000 ? "enabled" : "disabled",
word40[0] & 0x1000 ? "enabled" : "disabled");
Upgrade of EIDE DMA support, Johns comments: * lots of fixes to error handling-- mostly works now * improve DMA timing config for Triton chipsets-- PIIX4 and UDMA drive still untested * generally improve DMA config in many ways-- mostly cleanup * clean up boot-time messages * rewrite PRD generation algorithm * first wd timeout is now longer, to handle drive spinup Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-04 18:49:53 +00:00
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
printf("via_571_status: busmaster status read retry %s\n",
(word40[1] & 0x08) ? "enabled" : "disabled");
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
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
printf("via_571_status: %s drive %d data setup=%d active=%d recovery=%d\n",
unitno < 2 ? "primary" : "secondary",
unitno & 1,
((word40[3] >> ((3 - unitno) * 2)) & 3) + 1,
((word40[2] >> (((3 - unitno) * 8) + 4)) & 0x0f) + 1,
((word40[2] >> ((3 - unitno) * 8)) & 0x0f) + 1);
if (ctlr == 0)
printf("via_571_status: primary ctrl active=%d recovery=%d\n",
((word40[3] >> 28) & 0x0f) + 1,
((word40[2] >> 24) & 0x0f) + 1);
else
printf("via_571_status: secondary ctrl active=%d recovery=%d\n",
((word40[3] >> 20) & 0x0f) + 1,
((word40[2] >> 16) & 0x0f) + 1);
/* UltraDMA dump */
{
int foo;
foo = word40[4] >> ((3 - unitno) * 8);
printf("via_571_status: %s drive %d udma method=%d enable=%d PIOmode=%d cycle=%d\n",
i < 2 ? "primary" : "secondary",
i & 1,
(foo >> 7) & 1,
(foo >> 6) & 1,
(foo >> 5) & 1,
(foo & 3) + 2);
}
}
/*
* XXX timing values set here are only good for 30/33MHz buses; should deal
* with slower ones too (BTW: you overclock-- you lose)
*/
static int
via_571_dmainit(struct ide_pci_cookie *cookie,
struct wdparams *wp,
int(*wdcmd)(int, void *),
void *wdinfo)
{
int r;
u_long pci_revision;
int unitno;
pci_revision = pci_conf_read(cookie->tag, PCI_CLASS_REG) &
PCI_REVISION_MASK;
unitno = cookie->ctlr * 2 + cookie->unit;
/* If it's a UDMA drive on a '590, set it up */
/*
* XXX the revision number we check for is of dubious validity.
* it's extracted from the AMD 645 datasheet.
*/
if (pci_revision >= 1 && udma_mode(wp) >= 2) {
unsigned int word50, mask, new;
word50 = pci_conf_read(cookie->tag, 0x50);
/* UDMA enable by SET FEATURES, DMA cycles, cycle time 2T */
mask = 0xe3000000 >> (unitno * 8);
new = 0x80000000 >> (unitno * 8);
word50 &= ~mask;
word50 |= new;
pci_conf_write(cookie->tag, 0x50, word50);
/*
* With the '590, drive configuration should come *after* the
* controller configuration, to make sure the controller sees
* the SET FEATURES command and does the right thing.
*/
/* Set UDMA mode 2 on drive */
if (bootverbose)
printf("intel_piix_dmainit: setting ultra DMA mode 2\n");
r = wdcmd(WDDMA_UDMA2, wdinfo);
if (!r) {
printf("intel_piix_dmainit: setting DMA mode failed\n");
return 0;
}
if (bootverbose)
via_571_status(cookie);
return 1;
}
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
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
/* otherwise, try and program it for MW DMA mode 2 */
else if (mwdma_mode(wp) >= 2 && pio_mode(wp) >= 4) {
u_long workword;
/* Set multiword DMA mode 2 on drive */
if (bootverbose)
printf("intel_piix_dmainit: setting multiword DMA mode 2\n");
r = wdcmd(WDDMA_MDMA2, wdinfo);
if (!r) {
printf("intel_piix_dmainit: setting DMA mode failed\n");
return 0;
}
/* Configure the controller appropriately for MWDMA mode 2 */
workword = pci_conf_read(cookie->tag, 0x40);
/*
* enable prefetch/postwrite-- XXX may cause problems
* with CD-ROMs?
*/
workword &= ~(3 << (cookie->ctlr * 2 + 12));
workword |= 3 << (cookie->ctlr * 2 + 12);
/* FIFO configurations-- equal split, threshold 1/2 */
workword &= 0x90ffffff;
workword |= 0x2a000000;
pci_conf_write(cookie->tag, 0x40, workword);
workword = pci_conf_read(cookie->tag, 0x44);
/* enable status read retry */
workword |= 8;
/* enable FIFO flush on interrupt and end of sector */
workword &= 0xff0cffff;
workword |= 0x00f00000;
pci_conf_write(cookie->tag, 0x44, workword);
workword = pci_conf_read(cookie->tag, 0x48);
/* set Mode2 timing */
workword &= ~(0xff000000 >> (unitno * 8));
workword |= 0x31000000 >> (unitno * 8);
pci_conf_write(cookie->tag, 0x48, workword);
/* set sector size */
pci_conf_write(cookie->tag, cookie->ctlr ? 0x68 : 0x60, 0x200);
if (bootverbose)
via_571_status(cookie);
return 1;
}
return 0;
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
}
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41: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
static struct vendor_fns vs_via_571 =
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
{
via_571_dmainit,
via_571_status
};
static void
promise_status(struct ide_pci_cookie *cookie)
{
pcici_t tag;
Remove a bunch of variables which were unused both in GENERIC and LINT. Found by: -Wunused
1997-11-07 08:53:44 +00:00
int i;
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
u_int32_t port0_command, port0_altstatus;
u_int32_t port1_command, port1_altstatus;
u_int32_t dma_block;
u_int32_t lat_and_interrupt;
u_int32_t drivetiming;
int pa, pb, mb, mc;
tag = cookie->tag;
port0_command = pci_conf_read(tag, 0x10);
port0_altstatus = pci_conf_read(tag, 0x14);
port1_command = pci_conf_read(tag, 0x18);
port1_altstatus = pci_conf_read(tag, 0x1c);
dma_block = pci_conf_read(tag, 0x20);
lat_and_interrupt = pci_conf_read(tag, 0x3c);
printf("promise_status: port0: 0x%lx, port0_alt: 0x%lx, port1: 0x%lx, port1_alt: 0x%lx\n",
port0_command, port0_altstatus, port1_command, port1_altstatus);
printf("promise_status: dma control blk address: 0x%lx, int: %d, irq: %d\n",
dma_block, (lat_and_interrupt >> 8) & 0xff, lat_and_interrupt & 0xff);
for(i=0;i<4;i+=2) {
drivetiming = pci_conf_read(tag, 0x60 + i * 4);
printf("drivebits%d-%d: %b\n", i, i+1, drivetiming,
"\020\05Prefetch\06Iordy\07Errdy\010Sync\025DmaW\026DmaR");
pa = drivetiming & 0xf;
pb = (drivetiming >> 8) & 0x1f;
mb = (drivetiming >> 13) & 0x7;
mc = (drivetiming >> 16) & 0xf;
printf("drivetiming%d: pa: 0x%x, pb: 0x%x, mb: 0x%x, mc: 0x%x\n",
i, pa, pb, mb, mc);
drivetiming = pci_conf_read(tag, 0x60 + (i + 1) * 4);
pa = drivetiming & 0xf;
pb = (drivetiming >> 8) & 0x1f;
mb = (drivetiming >> 13) & 0x7;
mc = (drivetiming >> 16) & 0xf;
printf("drivetiming%d: pa: 0x%x, pb: 0x%x, mb: 0x%x, mc: 0x%x\n",
i + 1, pa, pb, mb, mc);
}
}
static struct vendor_fns vs_promise =
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
{
generic_dmainit,
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
promise_status
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
};
/* Intel PIIX, PIIX3, and PIIX4 IDE controller subfunctions */
static void
intel_piix_dump_drive(char *ctlr,
int sitre,
Upgrade of EIDE DMA support, Johns comments: * lots of fixes to error handling-- mostly works now * improve DMA timing config for Triton chipsets-- PIIX4 and UDMA drive still untested * generally improve DMA config in many ways-- mostly cleanup * clean up boot-time messages * rewrite PRD generation algorithm * first wd timeout is now longer, to handle drive spinup Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-04 18:49:53 +00:00
int is_piix4,
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
int word40,
int word44,
Upgrade of EIDE DMA support, Johns comments: * lots of fixes to error handling-- mostly works now * improve DMA timing config for Triton chipsets-- PIIX4 and UDMA drive still untested * generally improve DMA config in many ways-- mostly cleanup * clean up boot-time messages * rewrite PRD generation algorithm * first wd timeout is now longer, to handle drive spinup Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-04 18:49:53 +00:00
int word48,
int word4a,
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
int drive)
{
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
char *ms;
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
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
if (!sitre)
ms = "master/slave";
else if (drive == 0)
ms = "master";
else
ms = "slave";
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
printf("intel_piix_status: %s %s sample = %d, %s recovery = %d\n",
ctlr,
ms,
5 - ((sitre && drive) ?
((word44 >> 2) & 3) :
((word40 >> 12) & 3)),
ms,
4 - ((sitre && drive) ?
((word44 >> 0) & 3) :
((word40 >> 8) & 3)));
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
word40 >>= (drive * 4);
printf("intel_piix_status: %s %s fastDMAonly %s, pre/post %s,\n\
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
intel_piix_status: IORDY sampling %s,\n\
intel_piix_status: fast PIO %s%s\n",
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
ctlr,
(drive == 0) ? "master" : "slave",
(word40 & 8) ? "enabled" : "disabled",
(word40 & 4) ? "enabled" : "disabled",
(word40 & 2) ? "enabled" : "disabled",
(word40 & 1) ? "enabled" : "disabled",
((word40 & 9) == 9) ? " (overridden by fastDMAonly)" : "" );
if (is_piix4)
printf("intel_piix_status: UltraDMA %s, CT/RP = %d/%d\n",
word48 ? "enabled": "disabled",
4 - (word4a & 3),
6 - (word4a & 3));
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 void
Upgrade of EIDE DMA support, Johns comments: * lots of fixes to error handling-- mostly works now * improve DMA timing config for Triton chipsets-- PIIX4 and UDMA drive still untested * generally improve DMA config in many ways-- mostly cleanup * clean up boot-time messages * rewrite PRD generation algorithm * first wd timeout is now longer, to handle drive spinup Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-04 18:49:53 +00:00
intel_piix_status(struct ide_pci_cookie *cookie)
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
{
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
int iobase_wd;
int unit;
int iobase_bm;
pcici_t tag;
pcidi_t type;
int ctlr;
u_long word40, word44, word48;
int sitre, is_piix4;
iobase_wd = cookie->iobase_wd;
unit = cookie->unit;
iobase_bm = cookie->iobase_bm;
tag = cookie->tag;
type = cookie->type;
ctlr = cookie->ctlr;
word40 = pci_conf_read(tag, 0x40);
word44 = pci_conf_read(tag, 0x44);
word48 = pci_conf_read(tag, 0x48);
/*
* XXX will not be right for the *next* generation of upward-compatible
* intel IDE controllers...
*/
is_piix4 = pci_conf_read(tag, PCI_CLASS_REG) == 0x71118086;
sitre = word40 & 0x4000;
switch (ctlr * 2 + unit) {
case 0:
intel_piix_dump_drive("primary",
sitre,
is_piix4,
word40 & 0xffff,
word44 & 0x0f,
word48,
word48 >> 16,
0);
break;
case 1:
intel_piix_dump_drive("primary",
sitre,
is_piix4,
word40 & 0xffff,
word44 & 0x0f,
word48 >> 1,
word48 >> 20,
1);
break;
case 2:
intel_piix_dump_drive("secondary",
sitre,
is_piix4,
(word40 >> 16) & 0xffff,
(word44 >> 4) & 0x0f,
word48 >> 2,
word48 >> 24,
0);
break;
case 3:
intel_piix_dump_drive("secondary",
sitre,
is_piix4,
(word40 >> 16) & 0xffff,
(word44 >> 4) & 0x0f,
word48 >> 3,
word48 >> 28,
1);
break;
default:
printf("intel_piix_status: bad drive or controller number\n");
}
Upgrade of EIDE DMA support, Johns comments: * lots of fixes to error handling-- mostly works now * improve DMA timing config for Triton chipsets-- PIIX4 and UDMA drive still untested * generally improve DMA config in many ways-- mostly cleanup * clean up boot-time messages * rewrite PRD generation algorithm * first wd timeout is now longer, to handle drive spinup Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-04 18:49:53 +00:00
}
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
/*
* XXX timing values set hereare only good for 30/33MHz buses; should deal
* with slower ones too (BTW: you overclock-- you lose)
*/
Upgrade of EIDE DMA support, Johns comments: * lots of fixes to error handling-- mostly works now * improve DMA timing config for Triton chipsets-- PIIX4 and UDMA drive still untested * generally improve DMA config in many ways-- mostly cleanup * clean up boot-time messages * rewrite PRD generation algorithm * first wd timeout is now longer, to handle drive spinup Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-04 18:49:53 +00:00
static int
intel_piix_dmainit(struct ide_pci_cookie *cookie,
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
struct wdparams *wp,
int(*wdcmd)(int, void *),
void *wdinfo)
Upgrade of EIDE DMA support, Johns comments: * lots of fixes to error handling-- mostly works now * improve DMA timing config for Triton chipsets-- PIIX4 and UDMA drive still untested * generally improve DMA config in many ways-- mostly cleanup * clean up boot-time messages * rewrite PRD generation algorithm * first wd timeout is now longer, to handle drive spinup Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-04 18:49:53 +00:00
{
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
int r;
Upgrade of EIDE DMA support, Johns comments: * lots of fixes to error handling-- mostly works now * improve DMA timing config for Triton chipsets-- PIIX4 and UDMA drive still untested * generally improve DMA config in many ways-- mostly cleanup * clean up boot-time messages * rewrite PRD generation algorithm * first wd timeout is now longer, to handle drive spinup Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-04 18:49:53 +00:00
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
/* If it's a UDMA drive and a PIIX4, set it up */
if (cookie->type == 0x71118086 && udma_mode(wp) >= 2) {
/* Set UDMA mode 2 on controller */
int unitno, mask, new;
Upgrade of EIDE DMA support, Johns comments: * lots of fixes to error handling-- mostly works now * improve DMA timing config for Triton chipsets-- PIIX4 and UDMA drive still untested * generally improve DMA config in many ways-- mostly cleanup * clean up boot-time messages * rewrite PRD generation algorithm * first wd timeout is now longer, to handle drive spinup Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-04 18:49:53 +00:00
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
if (bootverbose)
printf("intel_piix_dmainit: setting ultra DMA mode 2\n");
Upgrade of EIDE DMA support, Johns comments: * lots of fixes to error handling-- mostly works now * improve DMA timing config for Triton chipsets-- PIIX4 and UDMA drive still untested * generally improve DMA config in many ways-- mostly cleanup * clean up boot-time messages * rewrite PRD generation algorithm * first wd timeout is now longer, to handle drive spinup Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-04 18:49:53 +00:00
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
r = wdcmd(WDDMA_UDMA2, wdinfo);
if (!r) {
printf("intel_piix_dmainit: setting DMA mode failed\n");
return 0;
}
unitno = cookie->ctlr * 2 + cookie->unit;
Upgrade of EIDE DMA support, Johns comments: * lots of fixes to error handling-- mostly works now * improve DMA timing config for Triton chipsets-- PIIX4 and UDMA drive still untested * generally improve DMA config in many ways-- mostly cleanup * clean up boot-time messages * rewrite PRD generation algorithm * first wd timeout is now longer, to handle drive spinup Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-04 18:49:53 +00:00
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
mask = 1 << unitno + 3 << (16 + unitno * 4);
new = 1 << unitno + 2 << (16 + unitno * 4);
pci_conf_write(cookie->tag, 0x48,
(pci_conf_read(cookie->tag, 0x48) & ~mask) | new);
if (bootverbose)
intel_piix_status(cookie);
return 1;
}
Upgrade of EIDE DMA support, Johns comments: * lots of fixes to error handling-- mostly works now * improve DMA timing config for Triton chipsets-- PIIX4 and UDMA drive still untested * generally improve DMA config in many ways-- mostly cleanup * clean up boot-time messages * rewrite PRD generation algorithm * first wd timeout is now longer, to handle drive spinup Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-04 18:49:53 +00:00
/*
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
* if it's an 82371FB, which can't do independent programming of
* drive timing, we punt; we're not going to fuss with trying to
* coordinate timing modes between drives. if this is you, get a
* new motherboard. or contribute patches :)
*
* we do now at least see if the modes set are OK to use. this should
* satisfy the majority of people, with mwdma mode2 drives.
Upgrade of EIDE DMA support, Johns comments: * lots of fixes to error handling-- mostly works now * improve DMA timing config for Triton chipsets-- PIIX4 and UDMA drive still untested * generally improve DMA config in many ways-- mostly cleanup * clean up boot-time messages * rewrite PRD generation algorithm * first wd timeout is now longer, to handle drive spinup Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-04 18:49:53 +00:00
*/
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
else if (cookie->type == 0x12308086)
{
u_long word40;
/* can drive do PIO 4 and MW DMA 2? */
if (!(mwdma_mode(wp) >= 4 && pio_mode(wp) >= 4))
return 0;
word40 = pci_conf_read(cookie->tag, 0x40);
word40 >>= cookie->ctlr * 16;
/* Check for timing config usable for DMA on controller */
if (!((word40 & 0x3300) == 0x2300 &&
((word40 >> (cookie->unit * 4)) & 1) == 1))
return 0;
/* Set multiword DMA mode 2 on drive */
if (bootverbose)
printf("intel_piix_dmainit: setting multiword DMA mode 2\n");
r = wdcmd(WDDMA_MDMA2, wdinfo);
if (!r) {
printf("intel_piix_dmainit: setting DMA mode failed\n");
return 0;
}
return 1;
Upgrade of EIDE DMA support, Johns comments: * lots of fixes to error handling-- mostly works now * improve DMA timing config for Triton chipsets-- PIIX4 and UDMA drive still untested * generally improve DMA config in many ways-- mostly cleanup * clean up boot-time messages * rewrite PRD generation algorithm * first wd timeout is now longer, to handle drive spinup Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-04 18:49:53 +00:00
}
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
/* otherwise, treat it as a PIIX3 and program it for MW DMA mode 2 */
else if (mwdma_mode(wp) >= 2 && pio_mode(wp) >= 4) {
u_long mask40, mask44, new40, new44;
/*
* If SITRE is not set, set it and copy the
* appropriate bits into the secondary registers. Do
* both controllers at once.
*/
if (((pci_conf_read(cookie->tag, 0x40) >> (16 * cookie->ctlr))
& 0x4000) == 0) {
unsigned int word40, word44;
word40 = pci_conf_read(cookie->tag, 0x40);
/* copy bits to secondary register */
word44 = pci_conf_read(cookie->tag, 0x44);
/*
* I've got a Biostar motherboard with Award
* BIOS that sets SITRE and secondary timing
* on one controller but not the other.
* Bizarre.
*/
if ((word40 & 0x4000) == 0) {
word44 &= ~0xf;
word44 |= ((word40 & 0x3000) >> 10) |
((word40 & 0x0300) >> 8);
}
if ((word40 & 0x40000000) == 0) {
word44 &= ~0xf0;
word44 |= ((word40 & 0x30000000) >> 22) |
((word40 & 0x03000000) >> 20);
}
/* set SITRE */
word40 |= 0x40004000;
pci_conf_write(cookie->tag, 0x40, word40);
pci_conf_write(cookie->tag, 0x44, word44);
}
/* Set multiword DMA mode 2 on drive */
if (bootverbose)
printf("intel_piix_dmainit: setting multiword DMA mode 2\n");
r = wdcmd(WDDMA_MDMA2, wdinfo);
if (!r) {
printf("intel_piix_dmainit: setting DMA mode failed\n");
return 0;
}
/*
* backward compatible hardware leaves us with such
* twisted masses of software (aka twiddle the
* extremely weird register layout on a PIIX3, setting
* PIO mode 4 and MWDMA mode 2)
*/
if (cookie->unit == 0) {
mask40 = 0x330f;
new40 = 0x2307;
mask44 = 0;
new44 = 0;
} else {
mask40 = 0x00f0;
new40 = 0x0070;
mask44 = 0x000f;
new44 = 0x000b;
}
if (cookie->ctlr) {
mask40 <<= 16;
new40 <<= 16;
mask44 <<= 4;
new44 <<= 4;
}
pci_conf_write(cookie->tag, 0x40,
(pci_conf_read(cookie->tag, 0x40) & ~mask40) | new40);
pci_conf_write(cookie->tag, 0x44,
(pci_conf_read(cookie->tag, 0x44) & ~mask44) | new44);
if (bootverbose)
intel_piix_status(cookie);
return 1;
Upgrade of EIDE DMA support, Johns comments: * lots of fixes to error handling-- mostly works now * improve DMA timing config for Triton chipsets-- PIIX4 and UDMA drive still untested * generally improve DMA config in many ways-- mostly cleanup * clean up boot-time messages * rewrite PRD generation algorithm * first wd timeout is now longer, to handle drive spinup Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-04 18:49:53 +00:00
}
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
return 0;
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 struct vendor_fns vs_intel_piix =
{
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
intel_piix_dmainit,
intel_piix_status
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
};
/* Generic SFF-8038i code-- all code below here, except for PCI probes,
* more or less conforms to the SFF-8038i spec as extended for PCI.
* There should be no code that goes beyond that feature set below.
*/
/* XXX mkcookie is overloaded with too many parameters */
static struct ide_pci_cookie *
mkcookie(int iobase_wd,
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
int ctlr,
int unit,
int iobase_bm,
pcici_t tag,
pcidi_t type,
struct vendor_fns *vp,
int altiobase_wd)
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
{
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
struct ide_pci_cookie *cp;
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
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
cp = malloc(sizeof *cp, M_DEVBUF, M_NOWAIT);
if (!cp) return 0;
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
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
cp->iobase_wd = iobase_wd;
cp->ctlr = ctlr;
cp->unit = unit;
cp->tag = tag;
cp->type = type;
cp->iobase_bm = iobase_bm;
cp->altiobase_wd = altiobase_wd;
bcopy(vp, &cp->vs, sizeof(struct vendor_fns));
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 (!prdbuf) {
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
prdbuf = malloc(PRD_ALLOC_SIZE, M_DEVBUF, M_NOWAIT);
if (!prdbuf) {
FREE(cp, M_DEVBUF);
return 0;
}
if (((int)prdbuf >> PAGE_SHIFT) ^
(((int)prdbuf + PRD_ALLOC_SIZE - 1) >> PAGE_SHIFT)) {
printf("ide_pci: prdbuf straddles page boundary, no DMA\n");
FREE(cp, M_DEVBUF);
FREE(prdbuf, M_DEVBUF);
return 0;
}
prdbuf_next = prdbuf;
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
}
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
if (((char *)prdbuf_next + PRD_BUF_SIZE) >
((char *)prdbuf + PRD_ALLOC_SIZE)) {
printf("ide_pci: mkcookie %04x:%d: no more space for PRDs, no DMA\n",
iobase_wd, unit);
FREE(cp, M_DEVBUF);
return 0;
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
}
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
cp->prd = prdbuf_next;
(char *)prdbuf_next += PRD_BUF_SIZE;
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
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
LIST_INSERT_HEAD(&softc.cookies, cp, le);
return cp;
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 char *
ide_pci_probe(pcici_t tag, pcidi_t type)
{
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
u_long data;
data = pci_conf_read(tag, PCI_CLASS_REG);
if ((data & PCI_CLASS_MASK) == PCI_CLASS_MASS_STORAGE &&
((data & PCI_SUBCLASS_MASK) == 0x00010000 ||
((data & PCI_SUBCLASS_MASK) == 0x00040000))) {
if (type == 0x71118086)
return ("Intel PIIX4 Bus-master IDE controller");
if (type == 0x70108086)
return ("Intel PIIX3 Bus-master IDE controller");
if (type == 0x12308086)
return ("Intel PIIX Bus-master IDE controller");
if (type == PROMISE_ULTRA33)
return ("Promise Ultra/33 IDE controller");
if (type == 0x05711106)
return ("VIA 82C586x (Apollo) Bus-master IDE controller");
if (data & 0x8000)
return ("PCI IDE controller (busmaster capable)");
Upgrade of EIDE DMA support, Johns comments: * lots of fixes to error handling-- mostly works now * improve DMA timing config for Triton chipsets-- PIIX4 and UDMA drive still untested * generally improve DMA config in many ways-- mostly cleanup * clean up boot-time messages * rewrite PRD generation algorithm * first wd timeout is now longer, to handle drive spinup Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-04 18:49:53 +00:00
#ifndef CMD640
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
/*
* XXX the CMD640B hack should be better integrated, or
* something.
*/
else
return ("PCI IDE controller (not busmaster capable)");
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
#endif
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
};
return ((char*)0);
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 void
ide_pci_attach(pcici_t tag, int unit)
{
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
u_long class, cmd;
int bmista_1, bmista_2;
int iobase_wd_1, iobase_wd_2, iobase_bm_1, iobase_bm_2;
int altiobase_wd_1, altiobase_wd_2;
struct vendor_fns *vp;
pcidi_t type;
struct ide_pci_cookie *cookie;
int ctlridx;
ctlridx = unit * 2;
/* set up vendor-specific stuff */
type = pci_conf_read(tag, PCI_ID_REG);
if (type != PROMISE_ULTRA33) {
/* is it busmaster capable? bail if not */
class = pci_conf_read(tag, PCI_CLASS_REG);
if (!(class & 0x8000)) {
return;
}
/* is it enabled and is busmastering turned on? */
cmd = pci_conf_read(tag, PCI_COMMAND_STATUS_REG);
if ((cmd & 5) != 5) {
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
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
switch (type) {
case 0x71118086:
case 0x70108086:
case 0x12308086:
/* Intel PIIX, PIIX3, PIIX4 */
vp = &vs_intel_piix;
break;
case 0x5711106:
/* VIA Apollo chipset family */
vp = &vs_via_571;
break;
case PROMISE_ULTRA33:
/* Promise controllers */
vp = &vs_promise;
break;
default:
/* everybody else */
vp = &vs_generic;
break;
}
Upgrade of EIDE DMA support, Johns comments: * lots of fixes to error handling-- mostly works now * improve DMA timing config for Triton chipsets-- PIIX4 and UDMA drive still untested * generally improve DMA config in many ways-- mostly cleanup * clean up boot-time messages * rewrite PRD generation algorithm * first wd timeout is now longer, to handle drive spinup Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-04 18:49:53 +00:00
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
if (type != PROMISE_ULTRA33) {
if ((class & 0x100) == 0) {
iobase_wd_1 = IO_WD1;
altiobase_wd_1 = iobase_wd_1 + wd_altsts;
} else {
iobase_wd_1 = pci_conf_read(tag, 0x10) & 0xfffc;
altiobase_wd_1 = pci_conf_read(tag, 0x14) & 0xfffc;
}
if ((class & 0x400) == 0) {
iobase_wd_2 = IO_WD2;
altiobase_wd_2 = iobase_wd_2 + wd_altsts;
} else {
iobase_wd_2 = pci_conf_read(tag, 0x18) & 0xfffc;
altiobase_wd_2 = pci_conf_read(tag, 0x1c) & 0xfffc;
}
} else {
iobase_wd_1 = pci_conf_read(tag, 0x10) & 0xfffc;
altiobase_wd_1 = pci_conf_read(tag, 0x14) & 0xfffc;
iobase_wd_2 = pci_conf_read(tag, 0x18) & 0xfffc;
altiobase_wd_2 = pci_conf_read(tag, 0x1c) & 0xfffc;
}
Upgrade of EIDE DMA support, Johns comments: * lots of fixes to error handling-- mostly works now * improve DMA timing config for Triton chipsets-- PIIX4 and UDMA drive still untested * generally improve DMA config in many ways-- mostly cleanup * clean up boot-time messages * rewrite PRD generation algorithm * first wd timeout is now longer, to handle drive spinup Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-04 18:49:53 +00:00
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
iobase_bm_1 = pci_conf_read(tag, 0x20) & 0xfffc;
iobase_bm_2 = iobase_bm_1 + SFF8038_CTLR_1;
if (iobase_bm_1 == 0) {
printf("ide_pci: BIOS has not configured busmaster I/O address,\n\
ide_pci: giving up\n");
return;
}
Upgrade of EIDE DMA support, Johns comments: * lots of fixes to error handling-- mostly works now * improve DMA timing config for Triton chipsets-- PIIX4 and UDMA drive still untested * generally improve DMA config in many ways-- mostly cleanup * clean up boot-time messages * rewrite PRD generation algorithm * first wd timeout is now longer, to handle drive spinup Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-04 18:49:53 +00:00
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
wddma[unit].wdd_candma = ide_pci_candma;
wddma[unit].wdd_dmainit = ide_pci_dmainit;
wddma[unit].wdd_dmaverify = ide_pci_dmaverify;
wddma[unit].wdd_dmaprep = ide_pci_dmasetup;
wddma[unit].wdd_dmastart = ide_pci_dmastart;
wddma[unit].wdd_dmadone = ide_pci_dmadone;
wddma[unit].wdd_dmastatus = ide_pci_status;
wddma[unit].wdd_iobase = ide_pci_iobase;
wddma[unit].wdd_altiobase = ide_pci_altiobase;
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
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
/*
* This code below is mighty bogus. The config entries for the
* isa_devtab_bio are plugged in before the standard ISA bios scan.
* This is our "hack" way to simulate a dynamic assignment of I/O
* addresses, from a PCI device to an ISA probe. Sorry :-).
*/
if (iobase_wd_1 != IO_WD1) {
Remove a bunch of variables which were unused both in GENERIC and LINT. Found by: -Wunused
1997-11-07 08:53:44 +00:00
struct isa_device *dvp, *dvp1, *dvup;
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
for( dvp = isa_devtab_bio;
dvp->id_id != 0;
dvp++) {
if ((dvp->id_driver == &wdcdriver) && (dvp->id_iobase == 0)) {
int biotabunit;
biotabunit = dvp->id_unit * 2;
dvp->id_iobase = iobase_wd_1;
dvp1 = dvp + 1;
dvp1->id_iobase = iobase_wd_2;
printf("ide_pci%d: adding drives to controller %d:",
unit, biotabunit);
for(dvup = isa_biotab_wdc;
dvup->id_id != 0;
dvup++) {
if (dvup->id_driver != &wdcdriver)
continue;
if (dvup->id_unit != biotabunit)
continue;
dvup->id_iobase = dvp->id_iobase;
printf(" %d", dvup->id_unit);
dvup++;
pci_map_int(tag, wdintr, (void *) dvp->id_unit, &bio_imask);
if (dvup->id_id == 0)
break;
if (dvup->id_unit == biotabunit + 1) {
dvup->id_iobase = dvp->id_iobase;
printf(" %d", dvup->id_unit);
dvup++;
if (dvup->id_id == 0) {
iobase_wd_2 = 0;
break;
}
}
if (dvup->id_unit == biotabunit + 2) {
pci_map_int(tag, wdintr, (void *) ((int) dvp->id_unit + 1), &bio_imask);
dvup->id_iobase = dvp1->id_iobase;
printf(" %d", dvup->id_unit);
dvup++;
if (dvup->id_id == 0) {
break;
}
}
if (dvup->id_unit == biotabunit + 3) {
pci_map_int(tag, wdintr, (void *) ((int) dvp->id_unit + 1), &bio_imask);
dvup->id_iobase = dvp1->id_iobase;
printf(" %d", dvup->id_unit);
}
break;
}
printf("\n");
break;
}
}
}
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
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
bmista_1 = inb(iobase_bm_1 + BMISTA_PORT);
bmista_2 = inb(iobase_bm_2 + BMISTA_PORT);
if (!ide_pci_softc_cookies_initted) {
LIST_INIT(&softc.cookies);
ide_pci_softc_cookies_initted = 1;
}
if (iobase_wd_1 != 0) {
cookie = mkcookie(iobase_wd_1,
ctlridx,
0,
iobase_bm_1,
tag,
type,
vp,
altiobase_wd_1);
if (bootverbose)
vp->vendor_status(cookie);
cookie = mkcookie(iobase_wd_1,
ctlridx,
1,
iobase_bm_1,
tag,
type,
vp,
altiobase_wd_1);
if (bootverbose) {
vp->vendor_status(cookie);
printf("ide_pci: busmaster 0 status: %02x from port: %08x\n",
bmista_1, iobase_bm_1+BMISTA_PORT);
if (bmista_1 & BMISTA_DMA0CAP)
printf("ide_pci: ide0:0 has been configured for DMA by BIOS\n");
if (bmista_1 & BMISTA_DMA1CAP)
printf("ide_pci: ide0:1 has been configured for DMA by BIOS\n");
}
}
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
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
if (bmista_1 & BMISTA_SIMPLEX || bmista_2 & BMISTA_SIMPLEX) {
printf("ide_pci: controller is simplex, no DMA on secondary channel\n");
} else if (iobase_wd_2 != 0) {
cookie = mkcookie(iobase_wd_2,
ctlridx + 1,
0,
iobase_bm_2,
tag,
type,
vp,
altiobase_wd_2);
if (bootverbose)
vp->vendor_status(cookie);
cookie = mkcookie(iobase_wd_2,
ctlridx + 1,
1,
iobase_bm_2,
tag,
type,
vp,
altiobase_wd_2);
if (bootverbose) {
vp->vendor_status(cookie);
printf("ide_pci: busmaster 1 status: %02x from port: %08x\n",
bmista_2, iobase_bm_2+BMISTA_PORT);
if (bmista_2 & BMISTA_DMA0CAP)
printf("ide_pci: ide1:0 has been configured for DMA by BIOS\n");
if (bmista_2 & BMISTA_DMA1CAP)
printf("ide_pci: ide1:1 has been configured for DMA by BIOS\n");
}
}
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 u_long ide_pci_count;
static struct pci_device ide_pci_device = {
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
"ide_pci",
ide_pci_probe,
ide_pci_attach,
&ide_pci_count,
0
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
};
DATA_SET(pcidevice_set, ide_pci_device);
/*
* Return a cookie if we can do DMA on the specified (iobase_wd, unit).
*/
static void *
ide_pci_candma(int iobase_wd, int unit)
{
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
struct ide_pci_cookie *cp;
cp = softc.cookies.lh_first;
while(cp) {
if (cp->ctlr == unit &&
((iobase_wd == 0) || (cp->iobase_wd == iobase_wd)))
break;
cp = cp->le.le_next;
}
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
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
return cp;
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
}
/*
* Initialize controller and drive for DMA operation, including timing modes.
* Uses data passed from the wd driver and a callback function to initialize
* timing modes on the drive.
*/
static int
ide_pci_dmainit(void *cookie,
struct wdparams *wp,
int(*wdcmd)(int, void *),
void *wdinfo)
{
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
struct ide_pci_cookie *cp = cookie;
/*
* If the controller status indicates that DMA is configured already,
* we flounce happily away
*/
if (inb(cp->iobase_bm + BMISTA_PORT) &
Upgrade of EIDE DMA support, Johns comments: * lots of fixes to error handling-- mostly works now * improve DMA timing config for Triton chipsets-- PIIX4 and UDMA drive still untested * generally improve DMA config in many ways-- mostly cleanup * clean up boot-time messages * rewrite PRD generation algorithm * first wd timeout is now longer, to handle drive spinup Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-04 18:49:53 +00:00
((cp->unit == 0) ? BMISTA_DMA0CAP : BMISTA_DMA1CAP))
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
return 1;
Upgrade of EIDE DMA support, Johns comments: * lots of fixes to error handling-- mostly works now * improve DMA timing config for Triton chipsets-- PIIX4 and UDMA drive still untested * generally improve DMA config in many ways-- mostly cleanup * clean up boot-time messages * rewrite PRD generation algorithm * first wd timeout is now longer, to handle drive spinup Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-04 18:49:53 +00:00
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
/* We take a stab at it with device-dependent code */
return(cp->vs.vendor_dmainit(cp, wp, wdcmd, wdinfo));
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
}
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41: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
/*
* Verify that controller can handle a dma request for cp. Should
* not affect any hardware or driver state.
*/
static int
ide_pci_dmaverify(void *xcp, char *vaddr, u_long count, int dir)
{
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
int badfu;
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
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
/*
* check for nonaligned or odd-length Stuff
*/
badfu = ((unsigned int)vaddr & 1) || (count & 1);
Upgrade of EIDE DMA support, Johns comments: * lots of fixes to error handling-- mostly works now * improve DMA timing config for Triton chipsets-- PIIX4 and UDMA drive still untested * generally improve DMA config in many ways-- mostly cleanup * clean up boot-time messages * rewrite PRD generation algorithm * first wd timeout is now longer, to handle drive spinup Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-04 18:49:53 +00:00
#ifdef DIAGNOSTIC
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
if (badfu) {
printf("ide_pci: dmaverify odd vaddr or length, ");
printf("vaddr = %08x length = %08x\n", (int)vaddr, 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
#endif
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
return (!badfu);
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
}
/*
* Set up DMA for cp. It is the responsibility of the caller
* to ensure that the controller is idle before this routine
* is called.
*/
static int
Upgrade of EIDE DMA support, Johns comments: * lots of fixes to error handling-- mostly works now * improve DMA timing config for Triton chipsets-- PIIX4 and UDMA drive still untested * generally improve DMA config in many ways-- mostly cleanup * clean up boot-time messages * rewrite PRD generation algorithm * first wd timeout is now longer, to handle drive spinup Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-04 18:49:53 +00:00
ide_pci_dmasetup(void *xcp, char *vaddr, u_long vcount, int dir)
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
{
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
struct ide_pci_cookie *cp = xcp;
struct ide_pci_prd *prd;
int i;
u_long firstpage;
u_long prd_base, prd_count;
u_long nbase, ncount, nend;
int iobase_bm;
u_long count, checkcount;
Upgrade of EIDE DMA support, Johns comments: * lots of fixes to error handling-- mostly works now * improve DMA timing config for Triton chipsets-- PIIX4 and UDMA drive still untested * generally improve DMA config in many ways-- mostly cleanup * clean up boot-time messages * rewrite PRD generation algorithm * first wd timeout is now longer, to handle drive spinup Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-04 18:49:53 +00:00
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
prd = cp->prd;
Upgrade of EIDE DMA support, Johns comments: * lots of fixes to error handling-- mostly works now * improve DMA timing config for Triton chipsets-- PIIX4 and UDMA drive still untested * generally improve DMA config in many ways-- mostly cleanup * clean up boot-time messages * rewrite PRD generation algorithm * first wd timeout is now longer, to handle drive spinup Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-04 18:49:53 +00:00
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
count = vcount;
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
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
i = 0;
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
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
iobase_bm = cp->iobase_bm;
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
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
if (count == 0) {
printf("ide_pci: dmasetup 0-length transfer, ");
printf("vaddr = %08x length = %08x\n", (int)vaddr, count);
Upgrade of EIDE DMA support, Johns comments: * lots of fixes to error handling-- mostly works now * improve DMA timing config for Triton chipsets-- PIIX4 and UDMA drive still untested * generally improve DMA config in many ways-- mostly cleanup * clean up boot-time messages * rewrite PRD generation algorithm * first wd timeout is now longer, to handle drive spinup Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-04 18:49:53 +00:00
return 1;
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
}
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
/* Generate first PRD entry, which may be non-aligned. */
firstpage = PAGE_SIZE - ((u_long)vaddr & PAGE_MASK);
prd_base = vtophys(vaddr);
prd_count = MIN(count, firstpage);
vaddr += prd_count;
count -= prd_count;
/* Step through virtual pages, coalescing as needed. */
while (count) {
nbase = vtophys(vaddr);
ncount = MIN(count, PAGE_SIZE);
nend = nbase + ncount;
/*
* Coalesce if physically contiguous and not crossing
* 64k boundary.
*/
if ((prd_base + prd_count == nbase) &&
((((nend - 1) ^ prd_base) & ~0xffff) == 0)) {
prd_count += ncount;
} else {
prd[i].prd_base = prd_base;
prd[i].prd_count = (prd_count & 0xffff);
i++;
if (i >= PRD_MAX_SEGS) {
printf("wd82371: too many segments in PRD table\n");
return 1;
}
prd_base = nbase;
prd_count = ncount;
}
vaddr += ncount;
count -= ncount;
}
/* Write last PRD entry. */
prd[i].prd_base = prd_base;
prd[i].prd_count = (prd_count & 0xffff) | PRD_EOT_BIT;
Upgrade of EIDE DMA support, Johns comments: * lots of fixes to error handling-- mostly works now * improve DMA timing config for Triton chipsets-- PIIX4 and UDMA drive still untested * generally improve DMA config in many ways-- mostly cleanup * clean up boot-time messages * rewrite PRD generation algorithm * first wd timeout is now longer, to handle drive spinup Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-04 18:49:53 +00:00
#ifdef DIAGNOSTIC
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
/* sanity check the transfer for length and page-alignment, at least */
checkcount = 0;
for (i = 0;; i++) {
unsigned int modcount;
modcount = prd[i].prd_count & 0xffffe;
if (modcount == 0) modcount = 0x10000;
checkcount += modcount;
if (i != 0 && ((prd[i].prd_base & PAGE_MASK) != 0)) {
printf("ide_pci: dmasetup() diagnostic fails-- unaligned page\n");
return 1;
}
if (prd[i].prd_count & PRD_EOT_BIT)
break;
Upgrade of EIDE DMA support, Johns comments: * lots of fixes to error handling-- mostly works now * improve DMA timing config for Triton chipsets-- PIIX4 and UDMA drive still untested * generally improve DMA config in many ways-- mostly cleanup * clean up boot-time messages * rewrite PRD generation algorithm * first wd timeout is now longer, to handle drive spinup Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-04 18:49:53 +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
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
if (checkcount != vcount) {
printf("ide_pci: dmasetup() diagnostic fails-- bad length\n");
return 1;
}
Upgrade of EIDE DMA support, Johns comments: * lots of fixes to error handling-- mostly works now * improve DMA timing config for Triton chipsets-- PIIX4 and UDMA drive still untested * generally improve DMA config in many ways-- mostly cleanup * clean up boot-time messages * rewrite PRD generation algorithm * first wd timeout is now longer, to handle drive spinup Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-04 18:49:53 +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
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
/* Set up PRD base register */
outl(iobase_bm + BMIDTP_PORT, vtophys(prd));
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
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
/* Set direction of transfer */
outb(iobase_bm + BMICOM_PORT, (dir == B_READ) ? BMICOM_READ_WRITE : 0);
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
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
/* Clear interrupt and error bits */
outb(iobase_bm + BMISTA_PORT,
(inb(iobase_bm + BMISTA_PORT)
| (BMISTA_INTERRUPT | BMISTA_DMA_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
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
return 0;
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 void
ide_pci_dmastart(void *xcp)
{
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
struct ide_pci_cookie *cp = xcp;
int iobase_bm;
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
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
iobase_bm = cp->iobase_bm;
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
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
outb(iobase_bm + BMICOM_PORT,
inb(iobase_bm + BMICOM_PORT) | BMICOM_STOP_START);
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
ide_pci_dmadone(void *xcp)
{
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
struct ide_pci_cookie *cp = xcp;
int iobase_bm, status;
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
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
status = ide_pci_status(xcp);
iobase_bm = cp->iobase_bm;
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
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
outb(iobase_bm + BMICOM_PORT,
inb(iobase_bm + BMICOM_PORT) & ~BMICOM_STOP_START);
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
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
return status;
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
ide_pci_status(void *xcp)
{
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
struct ide_pci_cookie *cp = xcp;
int iobase_bm, status, bmista;
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
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
status = 0;
iobase_bm = cp->iobase_bm;
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
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
bmista = inb(iobase_bm + BMISTA_PORT);
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
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
if (bmista & BMISTA_INTERRUPT)
status |= WDDS_INTERRUPT;
if (bmista & BMISTA_DMA_ERROR)
status |= WDDS_ERROR;
if (bmista & BMISTA_DMA_ACTIVE)
status |= WDDS_ACTIVE;
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
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
return status;
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
}
Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
1997-09-20 07:41:58 +00:00
static int
ide_pci_altiobase(void *xcp)
{
struct ide_pci_cookie *cp = xcp;
if (cp == 0) {
return 0;
} else {
return cp->altiobase_wd;
}
}
static int
ide_pci_iobase(void *xcp)
{
struct ide_pci_cookie *cp = xcp;
if (cp == 0) {
return 0;
} else {
return cp->iobase_wd;
}
}
#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
#endif /* NPCI > 0 */
Reference in New Issue Copy Permalink