From owner-freebsd-x11@FreeBSD.ORG Tue Aug 26 14:41:23 2008 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6DB761065673 for ; Tue, 26 Aug 2008 14:41:23 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.232]) by mx1.freebsd.org (Postfix) with ESMTP id 527EF8FC24 for ; Tue, 26 Aug 2008 14:41:23 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so3271139rvf.43 for ; Tue, 26 Aug 2008 07:41:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=COxV+xntMpnv3UGRi7Cm46jiCKJ/rPhjZ3T3t8xXK4M=; b=CEobuwdGIUO8Uw455YpFzvIE7s9nbwcpPdNyD/leRC5TZjn1+tMeWpR5Ypt4kMB4/4 kocNXMsQ7ZTVE9gV1+iOStETLqXS0J6qcsUIOi8wWAaeaYBE2hEevQTJxQfPThVzqyNe wFOT6+X9gaLn1Fmu0qTbnITwxkjcXed12w1PA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=fH705VvHYXJ658OBlLLO1ObxxydXhaWuiixDYZoyDY+lDi+x4KANwiXPpuwRiu5yPB PM61npHguc7zzVps6DAb6SduQIpQlpOeiHsfeJgtMv0DXPJd8a9vqt6TlhOaQiA4FE1N jrTFtgI47FEXEbR+tfz0X6XodeBMrEp2pjvjI= Received: by 10.141.178.17 with SMTP id f17mr1875778rvp.104.1219761682415; Tue, 26 Aug 2008 07:41:22 -0700 (PDT) Received: by 10.141.86.19 with HTTP; Tue, 26 Aug 2008 07:41:22 -0700 (PDT) Message-ID: <3a142e750808260741p224bd68aw52711eab7e76aa59@mail.gmail.com> Date: Tue, 26 Aug 2008 16:41:22 +0200 From: "Paul B. Mahol" To: "Robert Noland" In-Reply-To: <3a142e750808250928n612761cch69a3bd2ebf374f92@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <48B1A590.2040701@gmail.com> <1219674352.53929.2.camel@squirrel.corp.cox.com> <3a142e750808250928n612761cch69a3bd2ebf374f92@mail.gmail.com> Cc: freebsd-x11 , jimmiejaz@gmail.com Subject: Re: [CFT] drm updates X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2008 14:41:23 -0000 On 8/25/08, Paul B. Mahol wrote: > On 8/25/08, Robert Noland wrote: >> On Sun, 2008-08-24 at 14:16 -0400, Jimmie James wrote: >>> Is this the type of lockup you're seeing? >>> >>> >>> Error in I830WaitLpRing(), timeout for 2 seconds >>> pgetbl_ctl: 0x3ffc0001getbl_err: 0x0 >>> ipeir: 0 iphdr: 7d000006 >>> LP ring tail: 1afa0 head: 1ad64 len: 1f001 start 0 >>> eir: 0 esr: 0 emr: ffff >>> instdone: fa41 instpm: 0 >>> memmode: 108 instps: 800f00c4 >>> hwstam: fffe ier: 2 imr: 8 iir: 80 >>> Ring at virtual 0x2884d000 head 0x1ad64 tail 0x1afa0 count 143 >>> >>> >>> >>> (WW) intel(0): PRB0_CTL (0x0001f001) indicates ring buffer enabled >>> (WW) intel(0): PRB0_HEAD (0x13e1ad64) and PRB0_TAIL (0x0001afa8) >>> indicate ring buffer not flushed >>> (WW) intel(0): Existing errors found in hardware state. >> >> Possibly, I haven't gotten this output though. Can you describe how you >> reached this state? >> >> robert. > > I dont have last 3 "(WW)" lines. > Actually I have, but with UP kernel: (WW) intel(0): PRB0_CTL (0x0001f001) indicates ring buffer enabled (WW) intel(0): PRB0_HEAD (0x0000afdc) and PRB0_TAIL (0x0000dd98) indicate ring buffer not flushed (WW) intel(0): Existing errors found in hardware state. And on UP kernel it is posible to kill Xorg via keyboard (ctrl+alt+backspace) but it fails to start again. Error in I830WaitLpRing(), timeout for 2 seconds pgetbl_ctl: 0x3ffc0001 getbl_err: 0x00000000 ipeir: 0x00000000 iphdr: 0x6db3ffff LP ring tail: 0x00001ee0 head: 0x0000afdc len: 0x0001f001 start 0x00000000 eir: 0x0000 esr: 0x0000 emr: 0xffff instdone: 0xffc1 instpm: 0x0000 memmode: 0x00000306 instps: 0x800f04d0 hwstam: 0xeffe ier: 0x0002 imr: 0x0000 iir: 0x1070 > It can be caused by any application that use direct rendering: 3D > games(OpenGL): > examples are zsnes, celestia, stellarium, etc. On UP kernel I tested blender. > I'm using SMP kernel. > > > Last fatal server error from recent Xorg.0.log.old had following last lines: > > (**) intel(0): Framebuffer compression enabled > (**) intel(0): Tiling enabled > (==) intel(0): Write-combining range (0xf4400000,0x80000) was already clear > (==) intel(0): Write-combining range (0xf4480000,0x40000) was already clear > (==) intel(0): VideoRam: 7932 KB > (II) intel(0): Attempting memory allocation with tiled buffers. > (EE) intel(0): Failed to allocate framebuffer. Is your VideoRAM set too low? > (II) intel(0): Tiled allocation failed. > (WW) intel(0): Couldn't allocate tiled memory, fb compression disabled > (II) intel(0): Attempting memory allocation with untiled buffers. > (WW) intel(0): Failed to allocate EXA offscreen memory. > (II) intel(0): Untiled allocation failed. > (II) intel(0): Couldn't allocate 3D memory, disabling DRI. > ^^^^^^^^^^^^^^^^^^^^^^^^ > (II) intel(0): Attempting memory allocation with untiled buffers. > (WW) intel(0): Failed to allocate EXA offscreen memory. > (II) intel(0): Untiled allocation failed. > (EE) intel(0): Couldn't allocate video memory > > Fatal server error: > AddScreen/ScreenInit failed for driver 0 > > > Note that I'm unable to switch vty to console (atkbd0), but killing > Xorg from network > is possible. > > Note that panic/hardlock with unloading loaded modules from kernel > (with/out Xorg session) > is regression from previous drm state in CURRENT. Could backtrace somehow > help? > >> >>> >>> vgapci0@pci0:0:2:0: class=0x030000 card=0x25821043 chip=0x25828086 >>> rev=0x04 hdr=0x00 >>> vendor = 'Intel Corporation' >>> device = '82915G/GV/GL, 82910GL Integrated Graphics Device' >>> class = display >>> subclass = VGA >>> vgapci1@pci0:0:2:1: class=0x038000 card=0x25821043 chip=0x27828086 >>> rev=0x04 hdr=0x00 >>> vendor = 'Intel Corporation' >>> device = '82915G Graphics device: 82915G/GV/910GL Express >>> Chipset Family' >>> class = display >>> >>> >On Sun, 2008-08-24 at 12:29 +0200, Paul B. Mahol wrote: >>> > On 8/24/08, Robert Noland wrote: >>> > > I've uploaded a final patch set to: >>> > > >>> > > http://people.freebsd.org/~rnoland >>> > > >>> > > I have committed this version to -CURRENT, but patches are available >>> > > fo= >>> r >>> > > RELENG_7 as well. >>> > > >>> > > This version mostly just fixes a long standing memory leak. >>> > > >>> > > All of the reports for radeon have been good. I'm still seeing a few >>> > > odd things with Intel though. The most severe issue is on my 965gm. >>> > > After restarting X, it will hang in a way that I have never seen >>> > > before... The small amount of evidence that I have been able to >>> > > collec= >>> t >>> > > suggests that this may be due to mesa trashing the hardware. I've >>> > > spen= >>> t >>> > > a couple of days trying to figure out exactly what could be wrong. >>> > > Thi= >>> s >>> > > morning I rebuilt my kernel with a stock drm from src and I got >>> > > exactly >>> > > the same hang. Since this update does help lots of people and >>> > > doesn't >>> > > seem to make things worse than they were to begin with, I went ahead >>> > > an= >>> d >>> > > committed it. >>> > > >>> > > I was incorrect about the patch to libdrm... It isn't needed in 2.3.1 >>> > > and it is already committed upstream. I'll commit that update to >>> > > ports >>> > > soon also. It, along with a recent xf86-video-* are needed to enable >>> > > the new vblank behavior, which will disable vblank interrupts if >>> > > there >>> > > are no active consumers. >>> > > >>> > > robert. >>> > > >>> >=20 >>> > Do I need to update some ports? because with kernel from HEAD I have >>> > encountered problems when drm is loaded (agp + drm + i915) >>> > astro/stellarium caused deadlock, only mouse pointer could move, if I >>> > did= >>> not >>> > started it, system will panic anyway after some time. I did not yet >>> > teste= >>> d >>> > vty switching,.... >>> >> >