From owner-freebsd-stable@FreeBSD.ORG Thu Feb 11 12:07:23 2010 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2387E1065679; Thu, 11 Feb 2010 12:07:23 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id ECA2A8FC08; Thu, 11 Feb 2010 12:07:22 +0000 (UTC) Received: from [192.168.1.4] (adsl-19-244-133.bna.bellsouth.net [68.19.244.133]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id o1BC7Khb011703 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 11 Feb 2010 07:07:20 -0500 (EST) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Ulrich =?ISO-8859-1?Q?Sp=F6rlein?= In-Reply-To: <20100211074933.GJ9748@acme.spoerlein.net> References: <6101e8c41002091524q25a7e026u585e575eb4f1589c@mail.gmail.com> <4B728A7A.60706@gmail.com> <1265814670.8609.58.camel@balrog.2hip.net> <20100210180042.GF9748@acme.spoerlein.net> <1265825292.8609.81.camel@balrog.2hip.net> <20100211074933.GJ9748@acme.spoerlein.net> Content-Type: text/plain; charset="ISO-8859-1" Organization: FreeBSD Date: Thu, 11 Feb 2010 06:07:14 -0600 Message-Id: <1265890034.8609.147.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00, FH_DATE_PAST_20XX, RDNS_DYNAMIC, SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: stable@FreeBSD.org Subject: Re: freebsd7 (and 8), radeon, xorg-server -> deadlock or so X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 12:07:23 -0000 On Thu, 2010-02-11 at 08:49 +0100, Ulrich Spörlein wrote: > On Wed, 10.02.2010 at 12:08:12 -0600, Robert Noland wrote: > > On Wed, 2010-02-10 at 19:00 +0100, Ulrich Spörlein wrote: > > > On Wed, 10.02.2010 at 09:11:10 -0600, Robert Noland wrote: > > > > I have a strong suspicion that the issue is with bus_dma. If this is a > > > > pci based card, then it is trying to allocate 32MB of contiguous > > > > physical ram when the drm device is opened. This usually succeeds the > > > > first time that the driver opens the device, but later, after memory has > > > > become fragmented, this can become an issue. As I have mentioned, I > > > > have code that reworks this whole process and I'll try and make a patch > > > > available soon, but my I don't have a lot of time now, so it might be > > > > the weekend before I can rebase the code and get a clean patch. > > > > > > No deadlocks for me, but I've been hit by the 32MB issue. On 8-STABLE without > > > the recent Xorg update (haven't done that yet) I usually startx right after > > > boot, and this usually works fine. > > > > > > One time I had massive ZFS/git jobs running headless first and wanted to > > > startx afterwards. X11 took quite some time to come up and although > > > window "switching" was snappy, *moving* windows around was slow as hell, > > > window contents were re-drawing at ~1FPS. > > > > > > This also seems to always happen if I stop X11 and startx it again. > > > So I made a diff from a regular Xorg startup against the slow one: > > > > > > --- Xorg.0.log 2010-02-09 20:59:16.000000000 +0100 > > > +++ Xorg.slow.log 2010-01-31 11:04:08.000000000 +0100 > > > ... > > > @@ -599,49 +599,22 @@ > > > (II) RADEON(0): [drm] added 1 reserved context for kernel > > > (II) RADEON(0): X context handle = 0x1 > > > (II) RADEON(0): [drm] installed DRM signal handler > > > -(II) RADEON(0): [pci] 32768 kB allocated with handle 0xed1a5000 > > > -(II) RADEON(0): [pci] ring handle = 0xed1a5000 > > > -(II) RADEON(0): [pci] Ring mapped at 0x802aa0000 > > > -(II) RADEON(0): [pci] Ring contents 0x00000000 > > > -(II) RADEON(0): [pci] ring read ptr handle = 0xed2a6000 > > > -(II) RADEON(0): [pci] Ring read ptr mapped at 0x8006d6000 > > > -(II) RADEON(0): [pci] Ring read ptr contents 0x00000000 > > > -(II) RADEON(0): [pci] vertex/indirect buffers handle = 0xed2a7000 > > > -(II) RADEON(0): [pci] Vertex/indirect buffers mapped at 0x812c00000 > > > -(II) RADEON(0): [pci] Vertex/indirect buffers contents 0x00000000 > > > -(II) RADEON(0): [pci] GART texture map handle = 0xed4a7000 > > > -(II) RADEON(0): [pci] GART Texture map mapped at 0x812ea7000 > > > -(II) RADEON(0): [drm] register handle = 0xfe8e0000 > > > -(II) RADEON(0): [dri] Visual configs initialized > > > +(EE) RADEON(0): [pci] Out of memory (-12) > > > > Yes, drm failed to allocate the 32MB to back the GART, so drm was > > disabled. Hopefully, the new allocation strategy will resolve this > > since it will just require 32MB of physical ram below 4GB without > > needing it to be contiguous. > > Hmm, given that today, 32MB isn't really that much, wouldn't it make > more sense to have radeon(4) reserve those 32MB on load and never let > go? I have radeon_load=YES set in loader.conf so it has a fair chance to > always get it's 32MB contig. memory during startup. Given ZFS' memory > hunger, there may not be enough free physical RAM below 4GB ... While that would make sense... And it might work more like that once I implement TTM/KMS (actually the whole memory requirements will change as pages will then get mapped in and out of the gart), but currently, the allocation of scatter gather memory to populate the gart is driven by userland. The only memory that is pre-allocated by the driver is the sarea, and the register maps are pre-allocated, but that is just address mapping. For everything else, userland tells us when and how much memory to allocate. On radeon (and Intel for that matter) most if not all cards can reference anything that the cpu can, (up to at least 36 bits, iirc, or maybe 40) so I might drop the 4GB limit. However, since all of this is done in the generic drm code, I don't actually know what card I'm allocating memory for when I do it, so I won't change that part until I need to. I'll try and get a cleaned up patch of the scatter gather rework out this weekend. I've abandoned the use of bus_dma entirely for allocating SG pages and interact with the VM directly, thus avoiding the contiguous requirements of bus_dma. robert. > But it's your call, you obviously know more about this than me anyway :) > > Bye, > Uli -- Robert Noland FreeBSD