Date: Mon, 25 Aug 2008 18:28:09 +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: <3a142e750808250928n612761cch69a3bd2ebf374f92@mail.gmail.com> In-Reply-To: <1219674352.53929.2.camel@squirrel.corp.cox.com> References: <48B1A590.2040701@gmail.com> <1219674352.53929.2.camel@squirrel.corp.cox.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
It can be caused by any application that use direct rendering: 3D games(OpenGL):
examples are zsnes, celestia, stellarium, etc.
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?3a142e750808250928n612761cch69a3bd2ebf374f92>