>Number:         24273
>Category:       kern
>Synopsis:       nVidia nForce3 IDE has no driver support for DMA
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Thu Jan 29 22:47:00 UTC 2004
>Closed-Date:
>Last-Modified:
>Originator:     Richard Rauch
>Release:        NetBSD/amd64-current (20040127)
>Organization:
  "I probably don't know what I'm talking about."  http://www.olib.org/~rkr/
>Environment:
NetBSD socrates 1.6ZI NetBSD 1.6ZI (socrates) #2: Tue Jan 27 18:29:23 CST 2004  root@socrates:/usr/netbsd/current/src/sys/arch/amd64/compile/obj.amd64/socrates amd64
>Description:
	I have the followin in dmesg:

	pciide0 at pci0 dev 8 function 0
	pciide0: Nvidia Corporation nForce3 ATA133 IDE (rev. 0xa5)
	pciide0: bus-master DMA support present, but unused (no driver support)
	atabus0 at pciide0 channel 0
	 [...]
	wd0 at atabus0 drive 0wskbd1: connecting to wsdisplay0
	uhidev2 at uhub2 port 5 configuration 1 interface 1: <WDC WD400BB-75DKA0>
	wd0: drive supports 16-sector PIO transfers, LBA48 addressing
	wd0: 38146 MB, 77504 cyl, 16 head, 63 sec, 512 bytes/sect x 78125000 sectors
	wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 5 (Ultra/100)
	 [...]

	Hm...I just noticed the mangled dmesg lines.  That probably explains
	the occasional blank line that I have recently noticed in dmesg.
	I assume that someone is threading the autoconfig stuff---probably
	a good idea, but the kernel print routines should probably be
	writing whole lines at a time.  (Writing to buffers is another
	idea, then flush the thread's buffer when it completes some
	major chunk.  Perhaps when a \n is encountered?  Should I file
	a separate PR for that, or is it already a known issue?)

	(Blocking the output from each device configure until the device
	 is "done" is obviously a bad idea, since, in the unlikely event
	 of a system lockup during a device probe, one wouldn't have any
	 useful information about what code was running when the system
	 crashed.  Collecting a line at a time probably isn't too bad.)


	Anyway.  For lack of DMA support, the drive chews up a huge amount
	of CPU in order to turn in ~7MB/s in bonnie++.  A nearly identical
	drive (1 year older; same make/manufacturer/size) turns in about
	3x that speed on a slower system, with much less CPU drain.

>How-To-Repeat:
	Boot an nForce3 motherboard with the native IDE controller.

>Fix:
	No patches offered at this point.  But some workaround commentary
	(see the last for what may be a clue to making this work well and
	with little effort):

	The simplest workaround is to live with it.  PIO works.

	Offloading to a better NFS server will maintain about the same
	speed as PIO and hit ~0 local CPU usage.  This is good in numerous
	ways.  (I do this not only for sources, but also for objdirs.  I
	only keep installed binaries local.)

	Buying an IDE controller to drop into the machine is also an option,
	but shouldn't be necessary when you've got what should be a fine
	IDE controller on the motherboard.  It also depends upon having
	an open PCI slot...

	I notice that the GNU/LINUX people treat this controller as an
	alias for one of the AMD 7xx chipset controllers.  (I don't have
	the sources in front of me at the moment, so I'm not sure which
	one.)  From what I can tell, they don't provide any special support
	for the nVidia IDE controller beyond identifying it as being like
	the AMD chipset.


	I'm not sure how the "quirk" system works, but can re-grab the
	GNU/LINUX kernel sources to double-check which IDE controller
	they use as a double for the nVidia controller, then see about
	hacking something into my local kernel and trying a "bonnie++"
	run.  Assuming that it works.  (^&
>Release-Note:
>Audit-Trail:
>Unformatted: