Date: Tue, 26 Aug 2008 16:41:22 +0200 From: "Paul B. Mahol" <onemda@gmail.com> To: "Robert Noland" <rnoland@freebsd.org> Cc: freebsd-x11 <freebsd-x11@freebsd.org>, jimmiejaz@gmail.com Subject: Re: [CFT] drm updates Message-ID: <3a142e750808260741p224bd68aw52711eab7e76aa59@mail.gmail.com> In-Reply-To: <3a142e750808250928n612761cch69a3bd2ebf374f92@mail.gmail.com> References: <48B1A590.2040701@gmail.com> <1219674352.53929.2.camel@squirrel.corp.cox.com> <3a142e750808250928n612761cch69a3bd2ebf374f92@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 8/25/08, Paul B. Mahol <onemda@gmail.com> wrote: > On 8/25/08, Robert Noland <rnoland@freebsd.org> 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 <rnoland@freebsd.org> 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,.... >>> >> >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3a142e750808260741p224bd68aw52711eab7e76aa59>