[CFT] drm updates

Tue Aug 26 14:41:23 UTC 2008

On 8/25/08, Paul B. Mahol <onemda at gmail.com> wrote:
> On 8/25/08, Robert Noland <rnoland at 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 at 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 at 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 at 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,....
>>>
>>
>