Date: Wed, 10 Feb 2010 12:08:12 -0600 From: Robert Noland <rnoland@FreeBSD.org> To: Ulrich =?ISO-8859-1?Q?Sp=F6rlein?= <uqs@FreeBSD.org> Cc: stable@FreeBSD.org, Vitaly Magerya <vmagerya@gmail.com>, Oliver Pinter <oliver.pntr@gmail.com> Subject: Re: freebsd7 (and 8), radeon, xorg-server -> deadlock or so Message-ID: <1265825292.8609.81.camel@balrog.2hip.net> In-Reply-To: <20100210180042.GF9748@acme.spoerlein.net> References: <6101e8c41002091524q25a7e026u585e575eb4f1589c@mail.gmail.com> <4B728A7A.60706@gmail.com> <1265814670.8609.58.camel@balrog.2hip.net> <20100210180042.GF9748@acme.spoerlein.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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. robert. > +(EE) RADEON(0): [pci] PCI failed to initialize. Disabling the DRI. > +(II) RADEON(0): [drm] removed 1 reserved context for kernel > +(II) RADEON(0): [drm] unmapping 8192 bytes of SAREA 0xffffff8014a6d000 at 0x8006d4000 > +(II) RADEON(0): [drm] Closed DRM master. > (II) RADEON(0): RADEONRestoreMemMapRegisters() : > (II) RADEON(0): MC_FB_LOCATION : 0x00ef00d0 0x001f0000 > (II) RADEON(0): MC_AGP_LOCATION : 0x003f0000 > (==) RADEON(0): Backing store disabled > -(II) RADEON(0): [DRI] installation complete > -(II) RADEON(0): [drm] Added 32 65536 byte vertex/indirect buffers > -(II) RADEON(0): [drm] Mapped 32 vertex/indirect buffers > -(II) RADEON(0): [drm] dma control initialized, using IRQ 256 > -(II) RADEON(0): [drm] Initialized kernel GART heap manager, 29884416 > -(WW) RADEON(0): DRI init changed memory map, adjusting ... > -(WW) RADEON(0): MC_FB_LOCATION was: 0x00ef00d0 is: 0x00ef00d0 > -(WW) RADEON(0): MC_AGP_LOCATION was: 0x003f0000 is: 0x00030000 > -(II) RADEON(0): RADEONRestoreMemMapRegisters() : > -(II) RADEON(0): MC_FB_LOCATION : 0x00ef00d0 0x00ef00d0 > -(II) RADEON(0): MC_AGP_LOCATION : 0x00030000 > -(II) RADEON(0): Direct rendering enabled > -(II) RADEON(0): Setting EXA maxPitchBytes > -(II) EXA(0): Offscreen pixmap area of 111050752 bytes > -(II) EXA(0): Driver registered support for the following operations: > -(II) Solid > -(II) Copy > -(II) Composite (RENDER acceleration) > -(II) UploadToScreen > -(II) DownloadFromScreen > -(II) RADEON(0): Acceleration enabled > +(WW) RADEON(0): Direct rendering disabled > +(EE) RADEON(0): Acceleration initialization failed > +(II) RADEON(0): Acceleration disabled > (**) Option "dpms" > (**) RADEON(0): DPMS enabled > (==) RADEON(0): Silken mouse enabled > -(II) RADEON(0): Set up textured video > +(II) RADEON(0): Textured video requires CP on R5xx/R6xx/R7xx/IGP > Output CRT2 disable success > (II) RADEON(0): UNIPHY1 transmitter: Coherent Mode enabled > Output UNIPHY1 transmitter setup success > @@ -661,7 +634,7 @@ > Mode 1920x1200 - 2080 1235 9 > (II) RADEON(0): RADEONRestoreMemMapRegisters() : > (II) RADEON(0): MC_FB_LOCATION : 0x00ef00d0 0x00ef00d0 > -(II) RADEON(0): MC_AGP_LOCATION : 0x00030000 > +(II) RADEON(0): MC_AGP_LOCATION : 0x003f0000 > freq: 154000000 > best_freq: 153900000 > best_feedback_div: 57 > > > Pretty obvious what went wrong... > > Bye, > Uli > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- Robert Noland <rnoland@FreeBSD.org> FreeBSD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1265825292.8609.81.camel>