gmane.linux.debian.devel.x

Bug#673669: EDID extracted from proprietary nvidia driver fromlaptop

DAVID HAND — 2012-05-26T00:37:06

(via ubuntu 10.04) is the same as in Xorg.0.log (from debian live cd on
laptop) - yet gives accurate resolution choices.

I'm really confused.

Bug#673669: more info

DAVID HAND — 2012-05-25T23:43:08

I booted my laptop from the live CD with the CRT plugged in directly, and
while things are better, I'm not sure if everything is OK. I believe the
nouveau driver is working, but the available resolution and refresh rates
are incomplete. Looking through Xorg.0.log there are several bunches of
modelines - not one group has all the correct resolutions, and many appear
to be set at 0.0Hz.
Also, the hex EDID seems to have many 00 in it - could be fine, just looks
strange.

UPDATE
Just been looking at the EDID extracted from windows (using Phoenix I
think). It is different. I will include the two files extracted *.dat *.raw
When extracting using this software, it gave a waning about converting data
from one version to another. Maybe this is where the differences came from.

Processed: reassign 674575 to xorg-server, forcibly merging 666468674575

Debian Bug Tracking System — 2012-05-25T22:03:24

Processing commands for control< at >bugs.debian.org:

Bug #674575 [xorg] xorg eats CPU time
Bug reassigned from package 'xorg' to 'xorg-server'.
No longer marked as found in versions xorg/1:7.6+13.
Ignoring request to alter fixed versions of bug #674575 to the same values previously set
Bug #666468 [xorg-server] xorg-server: major text display problems in several apps
Bug #666538 [xorg-server] xorg-server: major text display problems in several apps
Bug #666564 [xorg-server] xorg-server: major text display problems in several apps
Bug #666565 [xorg-server] xorg-server: major text display problems in several apps
Bug #666695 [xorg-server] xorg-server: major text display problems in several apps
Bug #666922 [xorg-server] xorg-server: major text display problems in several apps
Bug #666998 [xorg-server] xorg-server: major text display problems in several apps
Bug #667048 [xorg-server] xorg-server: major text display problems in several apps
Bug #667073 [xorg-server] xorg-server: major text display problems in sever

Bug#667754: xserver-xorg-video-radeon: [RV250] Gnome shell unusable(permanent crashes)

Julien Cristau — 2012-05-25T22:00:47

Don't disable 3d support?

Cheers,
Julien

Bug#674501: xserver-xorg-video-openchrome: gdm3 spawns tens ofslaves and X servers after upgrade to 0.2.904+svn1050-1+b1

Julien Cristau — 2012-05-25T21:57:22

What's in the gdm log?

Cheers,
Julien

Bug#674600: Regression: OpenGL broken

Sebastian Reichel — 2012-05-25T21:06:57

When trying to trace the reason I found out that GL works if AIGLX
is enabled. I guess this is a regression in the X-Server and not in
the intel driver?

Bug#674600: Regression: OpenGL broken

Sebastian Reichel — 2012-05-25T20:52:50

Package: xserver-xorg-video-intel
Version: 2:2.18.0-2+b1
Severity: important

Hi,

There has been a regression on my system recently, which broke
OpenGL:

sre< at >earth ~ % glxinfo
name of display: :0.0
Error: couldn't find RGB GLX visual or fbconfig

Bug#667754: xserver-xorg-video-radeon: [RV250] Gnome shell unusable(screen corruptions & permanent crashes)

Fabian Fagerholm — 2012-05-25T17:32:08

Package: xserver-xorg-video-radeon
Version: 1:6.14.4-4
Followup-For: Bug #667754

Hi,

I'm seeing something very similar with a Radeon HD 6310. Gnome shell locks up,
and sometimes the screen goes black for a while, then returns. I suspect this
is due to the driver resetting the GPU, as shown in this dmesg fragment:

[  438.504167] radeon 0000:00:01.0: GPU lockup CP stall for more than 10000msec
[  438.504183] GPU lockup (waiting for 0x00002BD5 last fence id 0x00002BD4)
[  438.505523] radeon 0000:00:01.0: GPU softreset
[  438.505532] radeon 0000:00:01.0:   GRBM_STATUS=0xE55008A0
[  438.505540] radeon 0000:00:01.0:   GRBM_STATUS_SE0=0xEC000001
[  438.505549] radeon 0000:00:01.0:   GRBM_STATUS_SE1=0x00000007
[  438.505557] radeon 0000:00:01.0:   SRBM_STATUS=0x20000040
[  438.505573] radeon 0000:00:01.0:   GRBM_SOFT_RESET=0x00007F6B
[  438.505682] radeon 0000:00:01.0:   GRBM_STATUS=0x00003828
[  438.505689] radeon 0000:00:01.0:   GRBM_STATUS_SE0=0x00000007
[  438.505697] radeon 0000:00:01.0:   GRBM_STATUS_SE1=0x

Bug#674575: xorg eats CPU time

Nigel Horne — 2012-05-25T15:48:37

Package: xorg
Version: 1:7.6+13
Severity: important

Dear Maintainer,
*** Please consider answering these questions, where appropriate ***

   * What led up to the situation?
   I logged in
   * What exactly did you do (or not do) that was effective (or
     ineffective)?
   Nothing
   * What was the outcome of this action?
   N/A
   * What outcome did you expect instead?
   N/A


Xorg eats CPU.  Even when I do nothing for 5 minutes to let the system
settle down, uptime gives a value of nearly 1 and 'top' shows Xorg is using
a lot of CPU.

Bug#674563: mesa: install libGL.so* into $libdir/mesa, add links to$libdir

Andreas Beckmann — 2012-05-25T12:56:48

Source: mesa
Version: 7.11.2-1
Severity: wishlist
Tags: patch

Hi,

this is in response to a thread started here:
http://lists.debian.org/debian-x/2011/07/msg00292.html
and later continued here:
http://lists.debian.org/debian-x/2011/10/msg00137.html

In order to simplify managing alternative GL implementations, I propose
to ship the MESA libraries in $libdir/mesa/ with symlinks to libGL.so.1
and libGL.so in $libdir/
This is a first start and helps to reduce the number of diversions
needed.
The next step would be the use of some alternatives system directly
in the MESA packages (that needs to be multi-arch aware). This will
remove the need for diversions at all, but needs more discussion ...

I also sent some patches to debian-x< at > but never submitted a bug report,
so these patches for moving libGL* probably were forgotten:
http://lists.debian.org/debian-x/2011/10/msg00149.html (for GL)
http://lists.debian.org/debian-x/2011/10/msg00378.html (for EGL, GLES)

If anyone is interested, I'll update the patches for M

Bug#661073: xorg crashes [SOLVED]

Loïc Fejoz — 2012-05-25T09:37:35

Hi,

I was having the same trouble and after lurking on the web, especially 
[1], I found how to avoid it:
jsut remove the FontPath with unix paths style from /etc/X11/xorg.conf !

I have just rebooted and launch previously applications known to crash 
and it works...

I do not know what/who has written this line in the configuration. I 
have migrated from Squeeze to testing a while ago, may it helps?

[1] 
https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/927288

Bug#674501: xserver-xorg-video-openchrome: gdm3 spawns tens ofslaves and X servers after upgrade to 0.2.904+svn1050-1+b1

Fred Korz — 2012-05-25T03:38:06

Package: xserver-xorg-video-openchrome
Version: 1:0.2.904+svn1050-1+b1
Severity: important

Dear Maintainer,

   [* What led up to the situation?]

Been running "testing" for 8 years now.  Currently that's wheezy. Do
dist-upgrade daily and reboot & backup weekly.

Reboot on 2012.05.20 after dist-upgrade failed to bring up network and display.

   * What exactly did you do (or not do) that was effective (or
     ineffective)?

Rebooted single user, manually configured network to get debugging
access off of console.  (New startup sequences, network configured by
network manager and that isn't started until it has a screen to start
on.  So if gdm3 doesn't come up, you loose your network path onto the
system, e.g. sshd. *boo*) Worked around that by reinstalling the old
ifupdown package, which had been autoremoved but config data left in
place.

With ssh access, investigated server and found 40 to 80
/usr/lib/gdm3/gdm-simple-slave processes, all children of one
/usr/sbin/gdm3, and each slave had started a /usr/bi

xserver-xorg-input-evdev: Changes to 'ubuntu'

Chase Douglas — 2012-05-24T17:35:04

 debian/changelog |    7 +++++++
 1 file changed, 7 insertions(+)

New commits:
commit 8855f38a4e45a5d27d3c03b5809d63791c659980
Author: Chase Douglas <chase.douglas< at >canonical.com>
Date:   Fri May 18 11:10:10 2012 -0700

    releasing version 1:2.7.0-0ubuntu1.1

diff --git a/debian/changelog b/debian/changelog
index 8fc1ffb..afc9845 100644
--- a/debian/changelog
+++ b/debian/changelog
< at >< at > -1,3 +1,10 < at >< at >
+xserver-xorg-input-evdev (1:2.7.0-0ubuntu1.1) precise-proposed; urgency=low
+
+  * Rebuild to fix an ABI breakage causing crashes when headsets are plugged in
+    (LP: #973297)
+
+ -- Chase Douglas <chase.douglas< at >ubuntu.com>  Fri, 18 May 2012 11:05:44 -0700
+
 xserver-xorg-input-evdev (1:2.7.0-0ubuntu1) precise; urgency=low
 
   * New upstream release

Bug#667754: xserver-xorg-video-radeon: [RV250] Gnome shell unusable(permanent crashes)

Stefan Nagy — 2012-05-24T13:06:05

After installing some updates – sorry, I don't know which was the
relevant one, I assume gnome-shell – I'm forced into GNOME fallback mode
now; I suppose my graphics hardware got blacklisted.

xsession-errors contains the following lines:

Does it make any sense to switch to GNOME shell with 'gnome-shell
--replace' and add more information to this report? Or is there a way to
avoid fallback mode for testing purposes?

Thanks,
Stefan.

xserver-xorg-video-nouveau: Changes to 'debian-unstable'

Sven Joachim — 2012-05-24T12:53:38

 debian/patches/02-drm-nouveau-newabi.patch |   17 +++++++++++++++--
 1 file changed, 15 insertions(+), 2 deletions(-)

New commits:
commit 860471c98557a538a7bcd70183e6ed49113145b4
Author: Sven Joachim <svenjoac< at >gmx.de>
Date:   Thu May 24 14:45:44 2012 +0200

    Amend Maarten's hack by setting AC_SYS_LARGEFILE in configure.ac
    
    The driver does not need this, but the included libdrm_nouveau
    requires a 64-bit off_t.  With a 32-bit off_t, mmap in
    nouveau_bo_map() could easily fail since nvbo->map_handle is of type
    uint64_t.

diff --git a/debian/patches/02-drm-nouveau-newabi.patch b/debian/patches/02-drm-nouveau-newabi.patch
index 8179f9f..95ffce9 100644
--- a/debian/patches/02-drm-nouveau-newabi.patch
+++ b/debian/patches/02-drm-nouveau-newabi.patch
< at >< at > -4,11 +4,24 < at >< at > Date:   Wed May 23 09:29:29 2012 +0200
 
     awful hack to remove dependency on libdrm_nouveau
 
+[ Amendment by Sven Joachim <svenjoac< at >gmx.de>: Set AC_SYS_LARGEFILE
+  in configure.ac, required by the included libdrm_nouveau.

Re: xserver-xorg-video-nouveau: Changes to 'debian-unstable'

Sven Joachim — 2012-05-24T12:54:18


Huh, indeed.


It's mmap in nouveau_bo_map.  Of the parameters passed to it, bo->size
(== 131072) and bo->device->fd (== 15) look innocuous, while
nvbo->map_handle raises some suspicion.  On first investigation GDB
claimed its value had been optimized out(!), so I rebuilt with
DEB_BUILD_OPTIONS=noopt, and now nvbo->map_handle == 4457037824, which
looks a bit large on i386.

Setting AC_SYS_LARGEFILE in configure.ac seems to be necessary, and
hopefully also sufficient.  At least X has started successfully. :-)

Cheers,
       Sven

Bug#671870: upcoming KMS support on GNU/kFreeBSD

Benjamin Kaduk — 2012-05-23T21:11:08


FreeBSD svn r235859 seems to have connected the KMS support to the build.

-Ben Kaduk

Re: xserver-xorg-video-nouveau: Changes to 'debian-unstable'

Maarten Lankhorst — 2012-05-23T19:21:44

Hey,

Op 23-05-12 21:09, Sven Joachim schreef:
Nah, both could have failed. It would be interesting to know which of the 2 failed, and where.

3 probable candidate calls that would fail:
drmCommandWriteRead in abi16_bo_init called from nouveau_bo_new
mmap in nouveau_bo_map
drmCommandWrite in nouveau_bo_wait called from bo_map.

~Maarten

Re: xserver-xorg-video-nouveau: Changes to 'debian-unstable'

Sven Joachim — 2012-05-23T19:09:06


No.  The message only appears once in the driver's source, though; so I
conclude that nouveau_bo_new() must have returned 0 and nouveau_bo_map()
returned -EINVAL at the beginning of NVAccelCommonInit().

Cheers,
       Sven

Processed: Re: xfonts-100dpi: fonts not available until X restarted

Debian Bug Tracking System — 2012-05-23T18:51:06

Processing commands for control< at >bugs.debian.org:

Bug #673170 {Done: Julien Cristau <jcristau< at >debian.org>} [xfs] xfonts-100dpi: fonts not available until X restarted
Bug reopened
Ignoring request to alter fixed versions of bug #673170 to the same values previously set
End of message, stopping processing here.

Please contact me if you need assistance.

Re: xserver-xorg-video-nouveau: Changes to 'debian-unstable'

Maarten Lankhorst — 2012-05-23T18:47:33

Hey Sven,

Op 23-05-12 17:34, Sven Joachim schreef:
The failing line seems to be this:

(EE) NOUVEAU(0): Failed to allocate scratch buffer: -22

aka EINVAL

Is there anything in dmesg that indicates where it comes from?

~Maarten