From owner-cvs-all Thu Mar 22 7:45:41 2001 Delivered-To: cvs-all@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id A8CBA37B71E; Thu, 22 Mar 2001 07:45:34 -0800 (PST) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.1/8.11.1) with SMTP id f2MFjVh10664; Thu, 22 Mar 2001 10:45:31 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Thu, 22 Mar 2001 10:45:31 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Soren Schmidt Cc: Takahashi Yoshihiro , sos@FreeBSD.org, jkh@FreeBSD.org, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/etc MAKEDEV In-Reply-To: <200103221540.QAA67077@freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 22 Mar 2001, Soren Schmidt wrote: > It seems Robert Watson wrote: > > 1) It may be that we need a seperate "MAKEDEV all" for each architecture > > > > 2) Someone :-) needs to fix ATA to provide the support you need for PC98, > > as I keep being assured that WD is marching towards destruction. > > Well, not much I can do here due to lack of that platform, but I'll be > gald to help, however I havn't heard anything about this from the PC98 > gang... Ok, well, we need to get some communication going, and perhaps we can finally get rid of WD in 5.0-RELEASE :-). > > It's useful to note that the primary source of problems with AD that I > > have observed is overly agressive use of DMA instead of PIO for devices > > that don't support it. I wonder if that's something we could be doing > > better? > > This has been solved in -current, as the ata driver now check the > ata.ata_dma tunable for wether or not DMA should be used, ie it is > settable from the loader before the system boot, its then later settable > with atacontrol pr device. It would have benn so much easier if devices > told the real deal on wether they support DMA or not... I guess in my mind ata.ata_dma isn't a solution per se, it's a work around. From the sounds of it, there may not be a solution. Is it possible that some of the DMA-related failures are controller-related, and we could have a list of suspect controllers that cause ata.ata_dma to get appropriately tuned? I've experienced ATA problems on a number of machines, most notably my main file server, which prevented me from updating for a long time. Life got a lot better after appropriate tweaking of dma->pio, but still seem to get intermittent: ad0: WRITE command timeout tag=0 serv=0 - resetting ata0: resetting devices .. done ad0: timeout waiting for DRQ - resetting ata0: resetting devices .. done ad0: timeout waiting for DRQ - resetting ata0: resetting devices .. done ad0: timeout waiting for DRQ - resetting ata0: resetting devices .. done messages (very infrequently -- once every few days). My atamodes are: hw.atamodes: pio,dma,dma,pio, Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message