From owner-cvs-all Thu Jul 22 18:30:53 1999 Delivered-To: cvs-all@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id C442115641; Thu, 22 Jul 1999 18:30:40 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id KAA29673; Fri, 23 Jul 1999 10:59:41 +0930 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id KAA33651; Fri, 23 Jul 1999 10:59:41 +0930 (CST) Date: Fri, 23 Jul 1999 10:59:41 +0930 From: Greg Lehey To: Julian Elischer Cc: Dag-Erling Smorgrav , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/pci ide_pci.c Message-ID: <19990723105940.D84734@freebie.lemis.com> References: <199907221134.EAA03813@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: ; from Julian Elischer on Thu, Jul 22, 1999 at 12:41:43PM -0700 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk On Thursday, 22 July 1999 at 12:41:43 -0700, Julian Elischer wrote: > On Thu, 22 Jul 1999, Dag-Erling Smorgrav wrote: > >> des 1999/07/22 04:34:13 PDT >> >> Modified files: (Branch: RELENG_3) >> sys/pci ide_pci.c >> Log: >> Back out previous commit so IDE works again. >> Whatever happened to testing before MFC? >> >> Revision Changes Path >> 1.28.2.2 +99 -124 src/sys/pci/ide_pci.c > > ERK! > I found it.. > - firstpage = DMA_PG_SZ - ((uintptr_t)vaddr & (DMA_PG_SZ)); > + firstpage = DMA_PG_SZ - ((uintptr_t)vaddr & (DMA_PG_SZ - 1)); > > gives the same result for page alligned transfers, but is definitly wrong > for unalligned transfers.. > we must be doing all alligned transfers! > > (I have a rack of 4 machines doing load testing with the bad code and all > working fine!) at a guess, the failure must have been on an access to the > raw device. and.... AHA! the Cx5530 can not do accesses not alligned to > 16 byte boundaries, so we are not testing them.. they get done by PIO, and > not this code. this explains why we can do heavy testing on it and not > see this bug Was this the thing that caused UDMA to fall into a heap on the ground? Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message