From owner-freebsd-alpha@FreeBSD.ORG Wed Dec 22 17:30:19 2004 Return-Path: Delivered-To: freebsd-alpha@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E6F1A16A4CE for ; Wed, 22 Dec 2004 17:30:19 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id B491943D4C for ; Wed, 22 Dec 2004 17:30:19 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id iBMHUJe2097822 for ; Wed, 22 Dec 2004 17:30:19 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id iBMHUJC6097807; Wed, 22 Dec 2004 17:30:19 GMT (envelope-from gnats) Date: Wed, 22 Dec 2004 17:30:19 GMT Message-Id: <200412221730.iBMHUJC6097807@freefall.freebsd.org> To: freebsd-alpha@FreeBSD.org From: Sven Petai Subject: Re: alpha/75317: ATA DMA broken on PCalpha X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Sven Petai List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2004 17:30:20 -0000 The following reply was made to PR alpha/75317; it has been noted by GNATS. From: Sven Petai To: freebsd-gnats-submit@freebsd.org Cc: Subject: Re: alpha/75317: ATA DMA broken on PCalpha Date: Wed, 22 Dec 2004 19:24:16 +0200 I managed to put a wrong link in the original bugreport. The correct dmesg -v output is located at http://bsd.ee/~hadara/debug/pcalpha/pcalpha_panic_08.11.2004.txt I think I now understand what causes this bug, First of all there seems to be a slight bug in Alphas bus_dmamap_load(), which could be fixed with following patch: --- sys/alpha/alpha/busdma_machdep.c.orig Wed Dec 22 17:11:27 2004 +++ sys/alpha/alpha/busdma_machdep.c Wed Dec 22 17:13:57 2004 @@ -581,7 +581,8 @@ if (sg->ds_len == 0) { sg->ds_addr = paddr + alpha_XXX_dmamap_or; sg->ds_len = size; - } else if (paddr == nextpaddr) { + } else if (paddr == nextpaddr && + (sg->ds_len + size) <= dmat->maxsegsz) { sg->ds_len += size; } else { /* Go to the next segment */ without that we really could return larger chunks than specified by maxsegsz to bus_dma_tag_create function. anyway this still doesn't make things work correctly for me, because the real problem seems to be the Pyxis page crossing bug. Basically it comes down to corrupting DMA transfers larger than 8k. It didn't cause problems before, since we never did larger than PAGE_SIZE transfers before the ATA dma change mentioned in the original report. There's a detection code for the buggy chip @ src/sys/alpha/pci/cia.c but it's little too naive, since it assumes only DEC_ST550 can have it, in reality it seems to be used in some very early revisions of 164LX(SX too?). But there doesn't seem to be a reliable way to detect if we have the faulty chip since it was worked around in later revisions by doing some changes elsewhere. One of the possible easy solutions would be to hack ata_dmaalloc() to use PAGE_SIZE as max segment size argument to the bus_dma_tag_create function if machine has Pyxis chip at all, no matter if it's faulty or not. Would that be acceptable and if so what is the best way to propagate knowledge about existence of this chip from cia driver to ATA ?