Date: Thu, 22 Mar 2001 17:51:14 +0100 (CET) From: Soren Schmidt <sos@freebsd.dk> To: rwatson@FreeBSD.org (Robert Watson) Cc: nyan@FreeBSD.org (Takahashi Yoshihiro), sos@FreeBSD.org, jkh@FreeBSD.org, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/etc MAKEDEV Message-ID: <200103221651.RAA84705@freebsd.dk> In-Reply-To: <Pine.NEB.3.96L.1010322104159.10372D-100000@fledge.watson.org> from Robert Watson at "Mar 22, 2001 10:45:31 am"
next in thread | previous in thread | raw e-mail | index | archive | help
It seems Robert Watson wrote: > > 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 :-). I'm all ears :) > > 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: Well, the problem is _not_ the controllers (those that we know can't do DMA are not even tried), its a disk problem. Some vendors (you know who you are) has produced ALOT of drives that fail in interesting ways but that claim to do DMA. This could be dealt with via a black list but it would be endless and impossible to maintain, a whitelist might be easier if not shorter, but its stil only 90% solutions. > 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, What type of drive is that ? -Søren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200103221651.RAA84705>