[Bug 93765] Complete system freeze on resume wake up from suspend -- BUG: unable to handle kernel paging request at ffffc90402435ffc

https://bugs.freedesktop.org/show_bug.cgi?id=93765 --- Comment #7 from Chris --- Created attachment 121168 --> https://bugs.freedesktop.org/attachment.cgi?id=121168=edit Complete crash dump Ubuntu 14.04 I purged the fglrx drivers from my Ubuntu 14.04.3 (kernel

Re: [PATCH 2/2] release.sh: Don't quit on dry runs if tarball already uploaded

On Wed, Jan 20, 2016 at 02:46:39PM -0800, Bryce Harrington wrote: > From: Bryce Harrington > > When doing practice runs of the script, we aren't going to be uploading > anything, so don't treat it as a fatal error if the tarball is already > uploaded, as this may hide

Re: Diagnosing first vs subsequent performance

It's true. A glxinfo first, is enough to get things working, so that's a workaround. Not ideal, but something. As far as dmesg, the only new output after a slow-instance of glxgears, is a line like this: > vgaarb: this pci device is not a vga device But since the tesla is not a VGA device,

Re: [PATCH] glx: don't force version == 2.0 for ES2 GLX context creation

On Tue, 2016-01-19 at 10:06 -0500, Ilia Mirkin wrote: > dEQP tests request a specific version. The EXT spec has been updated to > allow other versions, so allow anything >= 2.0 to be requested. (Comic book guy voice) Actually... >  case GLX_CONTEXT_ES2_PROFILE_BIT_EXT: The spec says: >

Re: Diagnosing first vs subsequent performance

On Tue, Jan 19, 2016 at 12:54:15PM -0700, Lloyd Brown wrote: > Sure. I've generated them using something like this: > > > $ for i in {0..3}; do echo "Testing display $i"; for j in {1..2}; do > > echo "Instance $j"; DISPLAY=:${i}.0 glxinfo > > > /tmp/glxinfo.display${i}.instance${j}; echo

Re: Diagnosing first vs subsequent performance

Check dmesg, notably for NVRM, right after the failed gl call. I assume any initial gl call will do, ie. running glxinfo will lead to a first instance glxgears on the GPU? Cheers, Thomas ___ xorg@lists.x.org: X.Org support Archives:

Re: Diagnosing first vs subsequent performance

Something else very odd, as well: I was just running glxgears (good performance) on one display, and then when I ran glxinfo on a second display, the glxgears performance dropped significantly, and glxgears disappeared from the output of nvidia-smi. Here's some example output from the glxgears;

Re: [PATCH] glx: don't force version == 2.0 for ES2 GLX context creation

On Wed, 2016-01-20 at 14:53 -0500, Ilia Mirkin wrote: > That said, if you believe the only thing that needs to be done to (on > the X server side) support ES1 with GLX is to remove that return, > more than happy to send another patch that always lets it succeed. I think letting any ES version

[PATCH xserver] glx: Fix GLX_EXT_create_context_es2_profile support

As of v4 of this extension, any GLES version number may be requested (to enable GLES3 and later). To comply with this, simply remove the API version checks and leave it to the DRI driver to validate. This happens to also enable using GLES1 in direct contexts, so if that's the dire situation you

Re: [PATCH] glx: don't force version == 2.0 for ES2 GLX context creation

On Wed, Jan 20, 2016 at 2:47 PM, Adam Jackson wrote: > On Tue, 2016-01-19 at 10:06 -0500, Ilia Mirkin wrote: >> dEQP tests request a specific version. The EXT spec has been updated to >> allow other versions, so allow anything >= 2.0 to be requested. > > (Comic book guy voice)

Re: Diagnosing first vs subsequent performance

On Wed, Jan 20, 2016 at 01:03:35PM -0700, Lloyd Brown wrote: > Something else very odd, as well: > > I was just running glxgears (good performance) on one display, and then > when I ran glxinfo on a second display, the glxgears performance dropped > significantly, and glxgears disappeared from

[PATCH 2/2] release.sh: Don't quit on dry runs if tarball already uploaded

From: Bryce Harrington When doing practice runs of the script, we aren't going to be uploading anything, so don't treat it as a fatal error if the tarball is already uploaded, as this may hide potential subsequent issues that the user should know about. Signed-off-by:

[PATCH 1/2] release.sh: Clarify where the tarball was seen

From: Bryce Harrington Signed-off-by: Bryce Harrington --- release.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/release.sh b/release.sh index ef384de..0a1c607 100755 --- a/release.sh +++ b/release.sh @@ -595,7

Re: Diagnosing first vs subsequent performance

On Mittwoch, 20. Januar 2016 21:03:35 CEST, Lloyd Brown wrote: [lbrown@m8g-1-8 ~]$ DISPLAY=:0.0 glxgears Running synchronized to the vertical refresh. The framerate should be approximately the same as the monitor refresh rate. try DISPLAY=:0.0 __GL_GSYNC_ALLOWED=0 __GL_SYNC_TO_VBLANK=0

Re: Diagnosing first vs subsequent performance

My guess is that each X server you start is switching to its own VT. Since you're running Xorg by itself, there are initially no clients connected. When you run an application such as glxinfo that exits immediately, or kill your copy of glxgears, it causes the server to reset, which makes it

[Bug 93804] mpv opengl vo with vaapi decode renders OK with DRI2 but not DRI3

https://bugs.freedesktop.org/show_bug.cgi?id=93804 --- Comment #1 from Andy Furniss --- Created attachment 121166 --> https://bugs.freedesktop.org/attachment.cgi?id=121166=edit xorg log dri3 enabled -- You are receiving this mail because: You are the assignee for the

Re: [PATCH xserver] present: Handle wraparound when comparing MSC values

On 20/01/16 03:57, Michel Dänzer wrote: On 16.01.2016 02:03, Keith Packard wrote: Michel Dänzer writes: From: Michel Dänzer When a window moves from one CRTC to another, present_window_to_crtc_msc updates window_priv->msc_offset according to the