From owner-freebsd-current@FreeBSD.ORG Mon Dec 10 07:26:02 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D720116A418 for ; Mon, 10 Dec 2007 07:26:02 +0000 (UTC) (envelope-from sos@deepcore.dk) Received: from spider.deepcore.dk (cpe.atm2-0-70484.0x50a6c9a6.abnxx16.customer.tele.dk [80.166.201.166]) by mx1.freebsd.org (Postfix) with ESMTP id 5B46513C4D1 for ; Mon, 10 Dec 2007 07:26:02 +0000 (UTC) (envelope-from sos@deepcore.dk) Received: from ws.local (ws.deepcore.dk [194.192.25.137]) by spider.deepcore.dk (8.13.8/8.13.8) with ESMTP id lBA7PxRJ085847; Mon, 10 Dec 2007 08:26:00 +0100 (CET) (envelope-from sos@deepcore.dk) Message-ID: <475CEA07.1050500@deepcore.dk> Date: Mon, 10 Dec 2007 08:25:59 +0100 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Travis Mikalson References: <73807.10710.qm@web63912.mail.re1.yahoo.com> <200711280842.09340.jhb@freebsd.org> <474D726A.8080807@deepcore.dk> <200711280938.38545.jhb@freebsd.org> <474E5B69.7070406@yandex.ru> <474E65D6.4040403@deepcore.dk> <474E69AE.7000105@yandex.ru> <475978E1.2090507@deepcore.dk> <475C6C3E.6070004@deepcore.dk> <475CC426.3060808@terranova.net> <475CCAA0.5040900@terranova.net> In-Reply-To: <475CCAA0.5040900@terranova.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: Any successful installs on a Broadcom HT1000 chipset? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2007 07:26:02 -0000 Travis Mikalson wrote: > Travis Mikalson wrote: >> So this is a successful workaround for the HT1000 on-board SATA, and=20 >> it looks like this additional workaround you just posted is pretty=20 >> universal and would also limit a Marvell PCI-X SATA controller's DMA=20 >> size. > > Er, scratch that, I see the max_iosize you set is in=20 > ata_serverworks_allocate() so this fix wouldn't help with a Marvell=20 > SATA controller plugged into the HT1000 system's PCI-X slot. Yep, I'm not convinced there are "generic" DMA problems with that=20 chipset, but the ATA part definitively has trouble, I'm (slowly) working = my way through the different results here to try pinpoint the problem=20 more precisely. I'm also going to try a Marvell ctlr later today, more news later... > > I also see this isn't first and only chipset to have the exact same=20 > dma max_iosize limit imposed :) Right, the usual need for this limit is that the 64K size means that the = count reg is set to zero, and some HW designers just didn't get that righ= t. In this case its different as it does not always fail, but I havn't=20 found the combo that makes it fail yet. However the workaround seems to=20 be quite solid, but there might be a better / more correct way to solve=20 it still. -S=F8ren