Bug 88275

Created attachment 112069 [details]
dmesg

Created attachment 112070 [details]
glxinfo

Created attachment 112071 [details]
Xorg.0.log

Looks like your X server isn't built with present support and the intel driver is requiring it.  This is either a problem with your build or an intel DDX bug.  In any case, it's not a mesa bug.

(In reply to Jason Ekstrand from comment #4)
> Looks like your X server isn't built with present support and the intel
> driver is requiring it.  This is either a problem with your build or an
> intel DDX bug.  In any case, it's not a mesa bug.

So what should I do to fix it ? Should I recreate this report on another component (DDX) or what ? I

(In reply to Jason Ekstrand from comment #4)
> Looks like your X server isn't built with present support and the intel
> driver is requiring it.  This is either a problem with your build or an
> intel DDX bug.  In any case, it's not a mesa bug.

Wrong, very wrong.

[  5295.161] (EE) AIGLX error: Calling driver entry point failed
[  5295.161] (EE) AIGLX: reverting to software rendering


__glXDRIscreenProbe()
  screen->driScreen =
        (*screen->dri2->createNewScreen) (pScreen->myNum,
                                          screen->fd,
                                          loader_extensions,
                                          &screen->driConfigs, screen);

    if (screen->driScreen == NULL) {
        LogMessage(X_ERROR, "AIGLX error: Calling driver entry point failed\n");
        goto handle_error;
    }

A mesa provided function (createNewScreen) is reporting a failure.

(In reply to Chris Wilson from comment #6)
> (In reply to Jason Ekstrand from comment #4)
> > Looks like your X server isn't built with present support and the intel
> > driver is requiring it.  This is either a problem with your build or an
> > intel DDX bug.  In any case, it's not a mesa bug.
> 
> Wrong, very wrong.
> 
> [  5295.161] (EE) AIGLX error: Calling driver entry point failed
> [  5295.161] (EE) AIGLX: reverting to software rendering

Sorry, I missed that.  I saw the first error and didn't notice the others.

> __glXDRIscreenProbe()
>   screen->driScreen =
>         (*screen->dri2->createNewScreen) (pScreen->myNum,
>                                           screen->fd,
>                                           loader_extensions,
>                                           &screen->driConfigs, screen);
> 
>     if (screen->driScreen == NULL) {
>         LogMessage(X_ERROR, "AIGLX error: Calling driver entry point
> failed\n");
>         goto handle_error;
>     }
> 
> A mesa provided function (createNewScreen) is reporting a failure.

That seems odd.

Eugene, Did this recently start happening?  Does it work with an older mesa?  Unfortunately, those logs aren't telling me much about what actually happened.

Also, what graphics chipset do you have?  From the Xorg.0.log, it looks like an 865G.  An lspci would be helpful

>Did this recently start happening?  Does it work with an older mesa?  Unfortunately, those logs aren't telling me much about what actually happened.

With older MESA I have described situation here: https://bugs.freedesktop.org/show_bug.cgi?id=86583

For any additional info, please ask.

full lspci:

lspci
00:00.0 Host bridge: Intel Corporation 82865G/PE/P DRAM Controller/Host-Hub Interface (rev 02)
00:02.0 VGA compatible controller: Intel Corporation 82865G Integrated Graphics Controller (rev 02)
00:06.0 System peripheral: Intel Corporation 82865G/PE/P Processor to I/O Memory Interface (rev 02)
00:1d.0 USB controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #1 (rev 02)
00:1d.1 USB controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #2 (rev 02)
00:1d.2 USB controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #3 (rev 02)
00:1d.3 USB controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #4 (rev 02)
00:1d.7 USB controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB2 EHCI Controller (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev c2)
00:1f.0 ISA bridge: Intel Corporation 82801EB/ER (ICH5/ICH5R) LPC Interface Bridge (rev 02)
00:1f.1 IDE interface: Intel Corporation 82801EB/ER (ICH5/ICH5R) IDE Controller (rev 02)
00:1f.2 IDE interface: Intel Corporation 82801EB (ICH5) SATA Controller (rev 02)
00:1f.3 SMBus: Intel Corporation 82801EB/ER (ICH5/ICH5R) SMBus Controller (rev 02)
00:1f.5 Multimedia audio controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) AC'97 Audio Controller (rev 02)
01:03.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8100/8101L/8139 PCI Fast Ethernet Adapter (rev 10)

Could you go back to the semi-working configuration you had before and get a glxinfo from it.  I can't tell what mesa driver is being called.  We have two different i915 drivers in mesa and knowing which would be useful.

Another thing that would be good to try is to set AccelMethod to "uxa" in your xorg.conf and see if that makes a difference.  I don't know that it will, but it would make a good datapoint.

(In reply to Jason Ekstrand from comment #11)
> Could you go back to the semi-working configuration you had before and get a
> glxinfo from it.  I can't tell what mesa driver is being called.  We have
> two different i915 drivers in mesa and knowing which would be useful.

i915_dri.so

(In reply to Jason Ekstrand from comment #11)
> Could you go back to the semi-working configuration you had before and get a
> glxinfo from it.  I can't tell what mesa driver is being called.  We have
> two different i915 drivers in mesa and knowing which would be useful.
Yes. But, please, specify what do you mean on "semi-working"? What kernel, what mesa version?


> Another thing that would be good to try is to set AccelMethod to "uxa" in
> your xorg.conf and see if that makes a difference.  I don't know that it
> will, but it would make a good datapoint.
Under "semi-working" configuration or under as it is now ?

Created attachment 112074 [details]
Xorg.0.log (UXA acceleration)

On current configuration.

I was able to fake my computer into thinking it was an i915 and the driver loads ok.  I'm guessing someone pushed something that broke indirect rendering.  I'll try to look at it next week.

(In reply to Jason Ekstrand from comment #15)
> I was able to fake my computer into thinking it was an i915 and the driver
> loads ok.  I'm guessing someone pushed something that broke indirect
> rendering.  I'll try to look at it next week.

Thanks.

Greetings. I just updated to latest Mesa git and drm-intel-nightly after which new backtrace and even GPU crash appeared again. Mouse pointer is late now for hand movements. Although it says acceleration is turning off I feel some performance acceleration and higher responsiveness in comparison to how it was before those backtrace and GPU crash appeared again.

Created attachment 112295 [details]
dmesg

Created attachment 112296 [details]
glxinfo

Created attachment 112297 [details]
Xorg.0.log with backtrace

Created attachment 112298 [details]
GPU crash dump from /sys/class/drm/card0/error

(In reply to Jason Ekstrand from comment #11)
> Could you go back to the semi-working configuration you had before and get a
> glxinfo from it.  I can't tell what mesa driver is being called.  We have
> two different i915 drivers in mesa and knowing which would be useful.

FWIW... only the "classic" driver supports GEN2 (i830, i845, and i865) chipsets.

Just a little update. Latest Mesa git and drm-intel-nightly #201501220251. Issue with mouse is gone and now it's ok. But OGL rendering still not starting:

$glxinfo | grep error
libGL error: failed to create dri screen
libGL error: failed to load driver: i915

Trying to logoff gives black screen. And the following in logs:

$grep -i error /var/log/syslog
[drm] GPU HANG: ecode -1:0x00000000, reason: Command parser error, iir 0x00008000, action: continue
[drm] GPU crash dump saved to /sys/class/drm/card0/error
i915: render error detected, EIR: 0x00000010
[drm:i915_report_and_clear_eir] *ERROR* EIR stuck: 0x00000010, masking
[drm] GPU HANG: ecode -1:0x00000000, reason: Command parser error, iir 0x00008000, action: continue
i915: render error detected, EIR: 0x00000010
[drm] GPU crash dump saved to /sys/class/drm/card0/error
[drm:i915_reset [i915]] *ERROR* Failed to reset chip: -19

Please, fix it.

What does it say when you run:

LIBGL_DEBUG=verbose glxinfo | grep direct

(In reply to Timothy Arceri from comment #24)
> What does it say when you run:
> 
> LIBGL_DEBUG=verbose glxinfo | grep direct

$ LIBGL_DEBUG=verbose glxinfo | grep direct
libGL: screen 0 does not appear to be DRI3 capable
libGL: pci id for fd 4: 8086:2572, driver i915
libGL: OpenDriver: trying /usr/lib/x86_64-linux-gnu/dri/tls/i915_dri.so
libGL: OpenDriver: trying /usr/lib/x86_64-linux-gnu/dri/i915_dri.so
libGL error: failed to create dri screen
libGL error: failed to load driver: i915
libGL: OpenDriver: trying /usr/lib/x86_64-linux-gnu/dri/tls/swrast_dri.so
libGL: OpenDriver: trying /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so
libGL: Can't open configuration file /home/teacher/.drirc: No such file or directory.
libGL: Can't open configuration file /home/teacher/.drirc: No such file or directory.
direct rendering: Yes

For any additional info/tests, lease ask.

I tried this on a pineview machine which is i915 not 865 but it works fine, so this doesn't look a generic driver change.

(In reply to Jason Ekstrand from comment #26)
> I tried this on a pineview machine which is i915 not 865 but it works fine,
> so this doesn't look a generic driver change.

So what could I/we do ? Any ideas ? May be some kind of any additional tests ?

(In reply to Jason Ekstrand from comment #26)
> I tried this on a pineview machine which is i915 not 865 but it works fine,
> so this doesn't look a generic driver change.

As I understood configuration you tried not the same that I have. So there are differences in them. But I can give you SSH access so you'll be able to determine the cause of the problem. Is this option suits you ?

I tried stable MESA 10.1.3 with kernels 3.13.0-45 and 3.18.5. It works without any problems. But installing latest MESA git immediately causes OpenGL not to start with following errors:

libGL error: failed to create dri screen
libGL error: failed to load driver: i915

So the problem is in MESA, after 10.3.1.

same here, it seems.

Created attachment 115461 [details]
dmesg |ag drm

Created attachment 115462 [details]
/sys/class/drm/card0/error

Created attachment 115463 [details]
glxinfo

glxgrear:
Running synchronized to the vertical refresh.  The framerate should be
approximately the same as the monitor refresh rate.
intel_do_flush_locked failed: Input/output error

compton:
intel_do_flush_locked failed: Input/output error

mpv:
[vo/opengl/x11] X11 error: GLXBadFBConfig
[vo/opengl] Could not create GL3 context. Retrying with legacy context.
AO: [pulse] 44100Hz stereo 2ch float
VO: [opengl] 1280x720 yuv420p
intel_do_flush_locked failed: Input/output error

Created attachment 115464 [details]
intel_reg_dumper

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/746.