From owner-freebsd-stable@FreeBSD.ORG Fri Oct 22 16:43:28 2004 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 698BD16A4CE for ; Fri, 22 Oct 2004 16:43:28 +0000 (GMT) Received: from jane.prgmr.com (adsl-66-218-55-12.dslextreme.com [66.218.55.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1AE8943D2D for ; Fri, 22 Oct 2004 16:43:28 +0000 (GMT) (envelope-from lsc@jane.prgmr.com) Received: from lsc (helo=localhost) by jane.prgmr.com with local-esmtp (Exim 4.42 (FreeBSD)) id 1CL2WC-00023C-So; Fri, 22 Oct 2004 09:43:56 -0700 Date: Fri, 22 Oct 2004 09:43:56 -0700 (PDT) From: luke@prgmr.com X-X-Sender: lsc@prgmr.com To: Doug White In-Reply-To: <20041021184743.G41366@carver.gumbysoft.com> Message-ID: <20041022092517.T4440@prgmr.com> References: <20041020125520.P29221@prgmr.com> <20041021184743.G41366@carver.gumbysoft.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: User Lsc cc: stable@freebsd.org cc: luke@prgmr.com Subject: Re: FreeBSD 4.10 + PAE + SunFire v40z (Newisys 4100) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2004 16:43:28 -0000 On Thu, 21 Oct 2004, Doug White wrote: > On Wed, 20 Oct 2004 luke@prgmr.com wrote: > >> >> I have this SunFire v40z (as far as I can tell, it is a rebadged >> Newisys 4100. Sopposedly, sun manufactured it, but I can't find any ... > Why are you running this in i386 mode? Running an opteron in i386 mode + > PAE is a waste of a perfectly good 64 bit box :) Well, yes, but I can not run -STABLE in amd64 mode... I have to move to the 5.x branch for that. I do so at home, but for this application, I don't feel comfortable with anything less than -STABLE. Even so, the thing is faster than xeons, due to the superior memory archetecture, especially when using four processors. >> mpt0: port 0x2000-0x20ff mem \ >> 0xe5820000-0xe582fff f,0xe5830000-0xe583ffff irq 19 at device 4.0 on pci2 >> mpt0: error 16 creating per-cmd DMA maps >> mpt0: Could not allocate DMA memory > > 16 is EBUSY, whicih makes no sense whatsoever because it never sets error > to EBUSY. It would only ever set it to ENOMEM or succeed. I suspect nasty > bad memory corruption. Can the mpt device probe correctly if you drop it > below 4GB? Hmm... well, Luoqi Chen emailed me a bit ago with an answer that fixed my problem. I made the suggested changes, recompiled, and the thing seems to work ok now. I have pasted the relivant bits below: From: Luoqi Chen ... It's a bug in bus_dmamap_create() code, which has been fixed in -current. The fix is rather simple, in i386/i386/busdma_machdep.c, replace the line error = alloc_bounce_pages(dmat, pages); with if (alloc_bounce_pages(dmat, pages) < pages) error = ENOMEM; -lq