Hi,
I am using 2.6.35.9-64.fc14.x86_64 running 1.3.9-1.fc14.x86_64
and am having my 945gma lock up in texture decompress according
to intel_gpu_top utility, when trying to play Myst 5.
Any fixes on the horizon?
--
"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety." (Ben Franklin)
"The course of history shows that as a government grows, liberty
decreases." (Thomas Jefferson)
On 12/18/2010 03:09 PM, Stephen Clark wrote:
> Hi,
>
> I am using 2.6.35.9-64.fc14.x86_64 running 1.3.9-1.fc14.x86_64
> and am having my 945gma lock up in texture decompress according
> to intel_gpu_top utility, when trying to play Myst 5.
>
> Any fixes on the horizon?
>
Additional data point with 2.6.37-0.rc6.git0.1.fc15.x86_64 from rawhide
I get:
[ 307.256028] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer
elapsed... GPU hung
[ 307.258118] [drm:i915_do_wait_request] *ERROR* i915_do_wait_request
returns -11 (awaiting 27197 at 27195, next 27199)
[ 307.258975] [drm:i915_reset] *ERROR* Failed to reset chip.
and my X screen goes weird - have to switch to vty console.
--
"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety." (Ben Franklin)
"The course of history shows that as a government grows, liberty
decreases." (Thomas Jefferson)
On Sat, 18 Dec 2010 15:30:55 -0500, Stephen Clark <[email protected]> wrote:
> On 12/18/2010 03:09 PM, Stephen Clark wrote:
> > Hi,
> >
> > I am using 2.6.35.9-64.fc14.x86_64 running 1.3.9-1.fc14.x86_64
> > and am having my 945gma lock up in texture decompress according
> > to intel_gpu_top utility, when trying to play Myst 5.
> >
> > Any fixes on the horizon?
> >
> Additional data point with 2.6.37-0.rc6.git0.1.fc15.x86_64 from rawhide
> I get:
> [ 307.256028] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer
> elapsed... GPU hung
> [ 307.258118] [drm:i915_do_wait_request] *ERROR* i915_do_wait_request
> returns -11 (awaiting 27197 at 27195, next 27199)
> [ 307.258975] [drm:i915_reset] *ERROR* Failed to reset chip.
>
> and my X screen goes weird - have to switch to vty console.
Judging by your description, you've hit a bug in Mesa. Please verify the
bug with the current stable release (of Mesa) and file a bug report, and
be sure to include /sys/kernel/debug/dri/0/i915_error_state for the hang.
Thanks,
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On 12/18/2010 04:40 PM, Chris Wilson wrote:
> On Sat, 18 Dec 2010 15:30:55 -0500, Stephen Clark<[email protected]> wrote:
>
>> On 12/18/2010 03:09 PM, Stephen Clark wrote:
>>
>>> Hi,
>>>
>>> I am using 2.6.35.9-64.fc14.x86_64 running 1.3.9-1.fc14.x86_64
>>> and am having my 945gma lock up in texture decompress according
>>> to intel_gpu_top utility, when trying to play Myst 5.
>>>
>>> Any fixes on the horizon?
>>>
>>>
>> Additional data point with 2.6.37-0.rc6.git0.1.fc15.x86_64 from rawhide
>> I get:
>> [ 307.256028] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer
>> elapsed... GPU hung
>> [ 307.258118] [drm:i915_do_wait_request] *ERROR* i915_do_wait_request
>> returns -11 (awaiting 27197 at 27195, next 27199)
>> [ 307.258975] [drm:i915_reset] *ERROR* Failed to reset chip.
>>
>> and my X screen goes weird - have to switch to vty console.
>>
> Judging by your description, you've hit a bug in Mesa. Please verify the
> bug with the current stable release (of Mesa) and file a bug report, and
> be sure to include /sys/kernel/debug/dri/0/i915_error_state for the hang.
>
> Thanks,
> -Chris
>
>
I had been using mesa-7.9.
I loaded mesa-7.10 similar results. There is no
/sys/kernel/debug/dri/0/i915_error_state
In fact there is nothing in the /sys/kernel/debug directory. Do I have
to enable
something.
With the later kernel - things are worse X becomes totally useless it looks
like my lcd panel lost horizontal sync. With the 2.6.25 kernel X is
still usable
this makes me think at least some of the problem is kernel related.
With 2.6.37-rc6 and mesa 7.10 with hardware acceleration turned off in wine-
Dec 18 18:01:50 joker4 yum[5244]: Updated: mesa-libGL-7.10-0.17.fc15.x86_64
Dec 18 18:01:52 joker4 yum[5244]: Updated: mesa-libGL-7.10-0.17.fc15.i686
Dec 18 18:01:54 joker4 yum[5244]: Updated: mesa-libGLU-7.10-0.17.fc15.x86_64
Dec 18 18:02:02 joker4 yum[5244]: Updated: mesa-dri-drivers-7.10-0.17.fc15.x86_6
4
Dec 18 18:02:03 joker4 yum[5244]: Updated: mesa-libGLU-7.10-0.17.fc15.i686
Dec 18 18:02:11 joker4 yum[5244]: Updated: mesa-dri-drivers-7.10-0.17.fc15.i686
Dec 18 18:04:18 joker4 kernel: [ 9603.588113] [drm:i915_hangcheck_elapsed] *ERRO
R* Hangcheck timer elapsed... GPU hung
Dec 18 18:04:18 joker4 kernel: [ 9603.588313] [drm:i915_do_wait_request] *ERROR*
i915_do_wait_request returns -5 (awaiting 379738 at 379735)
--
"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety." (Ben Franklin)
"The course of history shows that as a government grows, liberty
decreases." (Thomas Jefferson)
On Sat, 18 Dec 2010 18:32:49 -0500, Stephen Clark <[email protected]> wrote:
> I had been using mesa-7.9.
> I loaded mesa-7.10 similar results. There is no
>
> /sys/kernel/debug/dri/0/i915_error_state
>
> In fact there is nothing in the /sys/kernel/debug directory. Do I have
> to enable
> something.
You need to "mount -tdebugfs debug /sys/kernel/debug".
> With the later kernel - things are worse X becomes totally useless it looks
> like my lcd panel lost horizontal sync. With the 2.6.25 kernel X is
> still usable
> this makes me think at least some of the problem is kernel related.
2.6.25 to present marks the transition between UMS and KMS, i.e. moving
of the userspace modesetting code into the kernel. And that should not
have regressed. Can you please, grab an intel_reg_dumper of the working
setup and the lost-sync setup, and include a drm.debug=0xe dmesg (i.e. add
drm.debug=0xe to your boot commandline)?
> With 2.6.37-rc6 and mesa 7.10 with hardware acceleration turned off in wine-
>
> Dec 18 18:01:50 joker4 yum[5244]: Updated: mesa-libGL-7.10-0.17.fc15.x86_64
> Dec 18 18:01:52 joker4 yum[5244]: Updated: mesa-libGL-7.10-0.17.fc15.i686
> Dec 18 18:01:54 joker4 yum[5244]: Updated: mesa-libGLU-7.10-0.17.fc15.x86_64
> Dec 18 18:02:02 joker4 yum[5244]: Updated: mesa-dri-drivers-7.10-0.17.fc15.x86_6
> 4
> Dec 18 18:02:03 joker4 yum[5244]: Updated: mesa-libGLU-7.10-0.17.fc15.i686
> Dec 18 18:02:11 joker4 yum[5244]: Updated: mesa-dri-drivers-7.10-0.17.fc15.i686
Good, those drivers are recent enough that I should be able to use the
error state to find the broken code.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On 12/19/2010 06:02 AM, Chris Wilson wrote:
> On Sat, 18 Dec 2010 18:32:49 -0500, Stephen Clark<[email protected]> wrote:
>
>> I had been using mesa-7.9.
>> I loaded mesa-7.10 similar results. There is no
>>
>> /sys/kernel/debug/dri/0/i915_error_state
>>
>> In fact there is nothing in the /sys/kernel/debug directory. Do I have
>> to enable
>> something.
>>
> You need to "mount -tdebugfs debug /sys/kernel/debug".
>
>
>> With the later kernel - things are worse X becomes totally useless it looks
>> like my lcd panel lost horizontal sync. With the 2.6.25 kernel X is
>> still usable
>> this makes me think at least some of the problem is kernel related.
>>
> 2.6.25 to present marks the transition between UMS and KMS, i.e. moving
> of the userspace modesetting code into the kernel. And that should not
> have regressed. Can you please, grab an intel_reg_dumper of the working
> setup and the lost-sync setup, and include a drm.debug=0xe dmesg (i.e. add
> drm.debug=0xe to your boot commandline)?
>
>
>> With 2.6.37-rc6 and mesa 7.10 with hardware acceleration turned off in wine-
>>
>> Dec 18 18:01:50 joker4 yum[5244]: Updated: mesa-libGL-7.10-0.17.fc15.x86_64
>> Dec 18 18:01:52 joker4 yum[5244]: Updated: mesa-libGL-7.10-0.17.fc15.i686
>> Dec 18 18:01:54 joker4 yum[5244]: Updated: mesa-libGLU-7.10-0.17.fc15.x86_64
>> Dec 18 18:02:02 joker4 yum[5244]: Updated: mesa-dri-drivers-7.10-0.17.fc15.x86_6
>> 4
>> Dec 18 18:02:03 joker4 yum[5244]: Updated: mesa-libGLU-7.10-0.17.fc15.i686
>> Dec 18 18:02:11 joker4 yum[5244]: Updated: mesa-dri-drivers-7.10-0.17.fc15.i686
>>
> Good, those drivers are recent enough that I should be able to use the
> error state to find the broken code.
> -Chris
>
>
Hi Chris,
I emailed the information you requested, it was quite large, and haven't
seen it show up on
LKML yet. Don't know if it is being blocked by the ML or not.
Regards,
Steve
--
"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety." (Ben Franklin)
"The course of history shows that as a government grows, liberty
decreases." (Thomas Jefferson)
On 12/19/2010 04:46 PM, Stephen Clark wrote:
> On 12/19/2010 06:02 AM, Chris Wilson wrote:
>> On Sat, 18 Dec 2010 18:32:49 -0500, Stephen
>> Clark<[email protected]> wrote:
>>> I had been using mesa-7.9.
>>> I loaded mesa-7.10 similar results. There is no
>>>
>>> /sys/kernel/debug/dri/0/i915_error_state
>>>
>>> In fact there is nothing in the /sys/kernel/debug directory. Do I have
>>> to enable
>>> something.
>> You need to "mount -tdebugfs debug /sys/kernel/debug".
>>
>>> With the later kernel - things are worse X becomes totally useless
>>> it looks
>>> like my lcd panel lost horizontal sync. With the 2.6.25 kernel X is
>>> still usable
>>> this makes me think at least some of the problem is kernel related.
>> 2.6.25 to present marks the transition between UMS and KMS, i.e. moving
>> of the userspace modesetting code into the kernel. And that should not
>> have regressed. Can you please, grab an intel_reg_dumper of the working
>> setup and the lost-sync setup, and include a drm.debug=0xe dmesg
>> (i.e. add
>> drm.debug=0xe to your boot commandline)?
>>
>>> With 2.6.37-rc6 and mesa 7.10 with hardware acceleration turned off
>>> in wine-
>>>
>>> Dec 18 18:01:50 joker4 yum[5244]: Updated:
>>> mesa-libGL-7.10-0.17.fc15.x86_64
>>> Dec 18 18:01:52 joker4 yum[5244]: Updated:
>>> mesa-libGL-7.10-0.17.fc15.i686
>>> Dec 18 18:01:54 joker4 yum[5244]: Updated:
>>> mesa-libGLU-7.10-0.17.fc15.x86_64
>>> Dec 18 18:02:02 joker4 yum[5244]: Updated:
>>> mesa-dri-drivers-7.10-0.17.fc15.x86_6
>>> 4
>>> Dec 18 18:02:03 joker4 yum[5244]: Updated:
>>> mesa-libGLU-7.10-0.17.fc15.i686
>>> Dec 18 18:02:11 joker4 yum[5244]: Updated:
>>> mesa-dri-drivers-7.10-0.17.fc15.i686
>> Good, those drivers are recent enough that I should be able to use the
>> error state to find the broken code.
>> -Chris
>>
> Hi Chris,
>
> I emailed the information you requested, it was quite large, and
> haven't seen it show up on
> LKML yet. Don't know if it is being blocked by the ML or not.
>
> Regards,
> Steve
>
Hi Chris,
Just wondering if you received what you needed from me. I still have the
info
for the 2.6.37rc6 kernel that I haven't sent awaiting some kind of
acknowledgment that
you received the initial info I send for the 2.6.35 kernel.
Steve
--
"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety." (Ben Franklin)
"The course of history shows that as a government grows, liberty
decreases." (Thomas Jefferson)
On 12/21/2010 11:16 AM, Stephen Clark wrote:
> On 12/19/2010 04:46 PM, Stephen Clark wrote:
>> On 12/19/2010 06:02 AM, Chris Wilson wrote:
>>> On Sat, 18 Dec 2010 18:32:49 -0500, Stephen
>>> Clark<[email protected]> wrote:
>>>> I had been using mesa-7.9.
>>>> I loaded mesa-7.10 similar results. There is no
>>>>
>>>> /sys/kernel/debug/dri/0/i915_error_state
>>>>
>>>> In fact there is nothing in the /sys/kernel/debug directory. Do I have
>>>> to enable
>>>> something.
>>> You need to "mount -tdebugfs debug /sys/kernel/debug".
>>>
>>>> With the later kernel - things are worse X becomes totally useless
>>>> it looks
>>>> like my lcd panel lost horizontal sync. With the 2.6.25 kernel X is
>>>> still usable
>>>> this makes me think at least some of the problem is kernel related.
>>> 2.6.25 to present marks the transition between UMS and KMS, i.e. moving
>>> of the userspace modesetting code into the kernel. And that should not
>>> have regressed. Can you please, grab an intel_reg_dumper of the working
>>> setup and the lost-sync setup, and include a drm.debug=0xe dmesg
>>> (i.e. add
>>> drm.debug=0xe to your boot commandline)?
>>>
>>>> With 2.6.37-rc6 and mesa 7.10 with hardware acceleration turned off
>>>> in wine-
>>>>
>>>> Dec 18 18:01:50 joker4 yum[5244]: Updated:
>>>> mesa-libGL-7.10-0.17.fc15.x86_64
>>>> Dec 18 18:01:52 joker4 yum[5244]: Updated:
>>>> mesa-libGL-7.10-0.17.fc15.i686
>>>> Dec 18 18:01:54 joker4 yum[5244]: Updated:
>>>> mesa-libGLU-7.10-0.17.fc15.x86_64
>>>> Dec 18 18:02:02 joker4 yum[5244]: Updated:
>>>> mesa-dri-drivers-7.10-0.17.fc15.x86_6
>>>> 4
>>>> Dec 18 18:02:03 joker4 yum[5244]: Updated:
>>>> mesa-libGLU-7.10-0.17.fc15.i686
>>>> Dec 18 18:02:11 joker4 yum[5244]: Updated:
>>>> mesa-dri-drivers-7.10-0.17.fc15.i686
>>> Good, those drivers are recent enough that I should be able to use the
>>> error state to find the broken code.
>>> -Chris
>>>
>> Hi Chris,
>>
>> I emailed the information you requested, it was quite large, and
>> haven't seen it show up on
>> LKML yet. Don't know if it is being blocked by the ML or not.
>>
>> Regards,
>> Steve
>>
> Hi Chris,
>
> Just wondering if you received what you needed from me. I still have
> the info
> for the 2.6.37rc6 kernel that I haven't sent awaiting some kind of
> acknowledgment that
> you received the initial info I send for the 2.6.35 kernel.
>
> Steve
>
Hi Chris,
Just wanted to say I downloaded the latest drm_fixes from Dave Airlie
and tried them
on 2.6.37rc7 and got the same gpu hang with the screen tearing
horizontally. I have
the the intel gpu dump and a cat of the i915_error_state. Together they
are over
2 megabytes. Should I send them to you directly since they seem to big
for the mailing
list.
Regards,
Steve
--
"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety." (Ben Franklin)
"The course of history shows that as a government grows, liberty
decreases." (Thomas Jefferson)
On Wed, 22 Dec 2010 14:40:32 -0500, Stephen Clark <[email protected]> wrote:
> Hi Chris,
>
> Just wanted to say I downloaded the latest drm_fixes from Dave Airlie
> and tried them
> on 2.6.37rc7 and got the same gpu hang with the screen tearing
> horizontally. I have
> the the intel gpu dump and a cat of the i915_error_state. Together they
> are over
> 2 megabytes. Should I send them to you directly since they seem to big
> for the mailing
> list.
Please do, or open a bug on bugs.freedesktop.org so that the error state
doesn't get lost. The intel_gpu_dump should be redundant, as the same
information, and more, is captured in the i915_error_state.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre