Bug#773303: libgl1-mesa-dev: Symlink error for libGL.so

2014-12-17 Thread Simon McVittie
On Wed, 17 Dec 2014 at 14:52:33 +0800, Shan Ting wrote:
 sudo stat /usr/lib/x86_64-linux-gnu/libGL.so
   File: ‘/usr/lib/x86_64-linux-gnu/libGL.so’ - ‘libGL.so.1.2.0’

OK so far...

 sudo stat /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0
 stat: cannot stat ‘/usr/lib/x86_64-linux-gnu/libGL.so.1.2.0’: No such file or 
 directory

... but that seems wrong for the packages you have installed. You said
you have:

 Package: libgl1-mesa-dev
 Version: 10.3.2-1
 ...
 ii  libgl1-mesa-glx 10.3.2-1

but those same packages on the same (amd64) architecture do provide
libGL.so.1.2.0:

% dpkg -s libgl1-mesa-dev
...
Version: 10.3.2-1
Depends: ..., libgl1-mesa-glx (= 10.3.2-1), ...
...
% dpkg -L libgl1-mesa-glx:amd64
...
/usr/lib/x86_64-linux-gnu/libGL.so.1.2.0
/usr/lib/x86_64-linux-gnu/libGL.so.1

  I’m not using lx-alternative-fglrx, glx-alternative-nvidia or
 glx-diversions. The libGL.so.10.1.1.28614 is come from my graphic card
 driver(parallels).

Then I think this is a bug in your graphics card driver: it is overwriting
and deleting files owned by the packaging system, but not finishing the job
by taking responsibility for setting the target of the libGL.so symlink
(and not participating in glx-alternatives like the non-free drivers
packaged by Debian developers do, which would be the ideal thing).

 Is there some reasons to use libGL.so.1.2.0 directly rather than
 libGL.so.1?

That's how libraries' development symlinks normally work. For instance,
picking a random library for which I have development files
installed (Gtk 2):

% ls -l /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so
lrwxrwxrwx 1 root root 27 Oct 10 18:57 
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so - libgtk-x11-2.0.so.0.2400.25
default|archetype% ls -l /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
lrwxrwxrwx 1 root root 27 Oct 10 18:57 
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 - libgtk-x11-2.0.so.0.2400.25
% ls -l /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.25
-rw-r--r-- 1 root root 4501992 Oct 10 18:57 
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.25

The real file is the versioned one, and the development symlink and the
SONAME (runtime) symlink both point to it.

Regards,
S


-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20141217083434.ga32...@reptile.pseudorandom.co.uk



Bug#769995: xserver-xorg-video-nouveau: displays don't wake up after suspend

2014-12-17 Thread Sven Joachim
On 2014-11-20 18:53 +0100, Johan Kröckel wrote:

 Yes, that solved the problem.

 2014-11-18 22:08 GMT+01:00 Sven Joachim svenj...@gmx.de:
 On 2014-11-18 05:38 +0100, Johan Kröckel wrote:

 Package: xserver-xorg-video-nouveau
 Version: 1:1.0.11-1
 Severity: important

 Dear Maintainer,

 after waking up from suspend, the two monitors stay in power save
 mode, no matter what I do. I am writing this report on the affected
 machine, logged in over ssh. Switching num lock works. ALT-F1 etc has
 no effect.

 That's probably a kernel problem.  Could you please try a 3.17 kernel
 from experimental[1] to see if it's already fixed?

Please test the latest 3.16 kernel in Jessie, version 3.16.7-ckt2-1
contains various nouveau patches that might fix your problem.

Cheers,
   Sven


--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87bnn2jh2o@turtle.gmx.de



Bug#771416: More logs from dmesg

2014-12-17 Thread Yvan Masson
Hi,

I re-installed Jessie on this same computer (followed by an apt-get
dist-upgrade), and tried with previous kernels from
snapshot.debian.org : the same problem appears, but with the 3.12-1
(version 3.12.9-1), the system never completely hangs (wich is a good
thing !).

It also permitted to get more logs from dmesg, with a few things wich
might be interesting at the end. You will find it attached.

Thanks for your time and work,
Yvan
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Initializing cgroup subsys cpuacct
[0.00] Linux version 3.12-1-amd64 (debian-ker...@lists.debian.org) (gcc 
version 4.8.2 (Debian 4.8.2-14) ) #1 SMP Debian 3.12.9-1 (2014-02-01)
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-3.12-1-amd64 
root=UUID=a39633a5-68c7-45ed-bced-d019e3e87839 ro quiet
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009efff] usable
[0.00] BIOS-e820: [mem 0x0009f000-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000f-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x7bec] usable
[0.00] BIOS-e820: [mem 0x7bed-0x7bed2fff] ACPI NVS
[0.00] BIOS-e820: [mem 0x7bed3000-0x7bed] ACPI data
[0.00] BIOS-e820: [mem 0x7bee-0x7bef] reserved
[0.00] BIOS-e820: [mem 0x7c00-0x7fff] reserved
[0.00] BIOS-e820: [mem 0xf000-0xf3ff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0x] reserved
[0.00] NX (Execute Disable) protection: active
[0.00] SMBIOS 2.4 present.
[0.00] DMI: Dell Inc. OptiPlex 740 Enhanced/0YP806, BIOS 2.1.6  
05/04/2008
[0.00] e820: update [mem 0x-0x0fff] usable == reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] No AGP bridge found
[0.00] e820: last_pfn = 0x7bed0 max_arch_pfn = 0x4
[0.00] MTRR default type: uncachable
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-B uncachable
[0.00]   C-C7FFF write-protect
[0.00]   C8000-F uncachable
[0.00] MTRR variable ranges enabled:
[0.00]   0 base 00 mask FF8000 write-back
[0.00]   1 base 007FF0 mask F0 uncachable
[0.00]   2 disabled
[0.00]   3 disabled
[0.00]   4 disabled
[0.00]   5 disabled
[0.00]   6 disabled
[0.00]   7 disabled
[0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[0.00] found SMP MP-table at [mem 0x000f3fc0-0x000f3fcf] mapped at 
[880f3fc0]
[0.00] Base memory trampoline at [88099000] 99000 size 24576
[0.00] init_memory_mapping: [mem 0x-0x000f]
[0.00]  [mem 0x-0x000f] page 4k
[0.00] BRK [0x01a91000, 0x01a91fff] PGTABLE
[0.00] BRK [0x01a92000, 0x01a92fff] PGTABLE
[0.00] BRK [0x01a93000, 0x01a93fff] PGTABLE
[0.00] init_memory_mapping: [mem 0x7bc0-0x7bdf]
[0.00]  [mem 0x7bc0-0x7bdf] page 2M
[0.00] BRK [0x01a94000, 0x01a94fff] PGTABLE
[0.00] init_memory_mapping: [mem 0x7800-0x7bbf]
[0.00]  [mem 0x7800-0x7bbf] page 2M
[0.00] init_memory_mapping: [mem 0x0010-0x77ff]
[0.00]  [mem 0x0010-0x001f] page 4k
[0.00]  [mem 0x0020-0x77ff] page 2M
[0.00] init_memory_mapping: [mem 0x7be0-0x7bec]
[0.00]  [mem 0x7be0-0x7bec] page 4k
[0.00] BRK [0x01a95000, 0x01a95fff] PGTABLE
[0.00] RAMDISK: [mem 0x3667e000-0x37336fff]
[0.00] ACPI: RSDP 000f86e0 00014 (v00 DELL  )
[0.00] ACPI: RSDT 7bed3040 00044 (v01 DELLbMk 42302E31 
AWRD )
[0.00] ACPI: FACP 7bed3100 00074 (v01 DELLbMk 42302E31 
AWRD )
[0.00] ACPI: DSDT 7bed31c0 0646A (v01 DELL   AWRDACPI 1000 
MSFT 0301)
[0.00] ACPI: FACS 7bed 00040
[0.00] ACPI: BOOT 7bed9680 00028 (v01 DELLbMk 42302E31 
AWRD )
[0.00] ACPI: SSDT 7bed9880 00248 (v01 PTLTD  POWERNOW 0001  
LTP 0001)
[0.00] ACPI: ASF! 7bed9b40 0008A (v32 DELLbMk 42302E31 
AWRD )
[0.00] ACPI: HPET 7bed9c40 00038 (v01 DELLbMk 42302E31 
AWRD 0098)
[0.00] ACPI: MCFG 7bed9cc0 0003C (v01 DELLbMk 42302E31 
AWRD )
[0.00] ACPI: SLIC 7bed9d40 00176 (v01 DELLbMk 42302E31 
AWRD 010E)
[0.00] ACPI: APIC 7bed9700 00098 (v01 DELLbMk 42302E31 
AWRD )
[0.00] ACPI: Local APIC address 

Bug#769995: xserver-xorg-video-nouveau: displays don't wake up after suspend

2014-12-17 Thread Johan Kröckel
I sold my nvidia adapters and bought an ATI one... Sorry.

2014-12-17 18:56 GMT+01:00 Sven Joachim svenj...@gmx.de:
 On 2014-11-20 18:53 +0100, Johan Kröckel wrote:

 Yes, that solved the problem.

 2014-11-18 22:08 GMT+01:00 Sven Joachim svenj...@gmx.de:
 On 2014-11-18 05:38 +0100, Johan Kröckel wrote:

 Package: xserver-xorg-video-nouveau
 Version: 1:1.0.11-1
 Severity: important

 Dear Maintainer,

 after waking up from suspend, the two monitors stay in power save
 mode, no matter what I do. I am writing this report on the affected
 machine, logged in over ssh. Switching num lock works. ALT-F1 etc has
 no effect.

 That's probably a kernel problem.  Could you please try a 3.17 kernel
 from experimental[1] to see if it's already fixed?

 Please test the latest 3.16 kernel in Jessie, version 3.16.7-ckt2-1
 contains various nouveau patches that might fix your problem.

 Cheers,
Sven


--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cabgvyo9degk6_5fwu-hmnik37k2rnugqhvb1rkxmfqwoju9...@mail.gmail.com



Bug#771416: More logs from dmesg

2014-12-17 Thread Sven Joachim
On 2014-12-17 18:11 +0100, Yvan Masson wrote:

 I re-installed Jessie on this same computer (followed by an apt-get
 dist-upgrade), and tried with previous kernels from
 snapshot.debian.org : the same problem appears, but with the 3.12-1
 (version 3.12.9-1), the system never completely hangs (wich is a good
 thing !).

Does booting the 3.16 kernel with nouveau.config=NvMSI=0 improve the
situation?  That's suggested in two upstream bug reports[1,2].

Cheers,
   Sven


1. https://bugs.freedesktop.org/show_bug.cgi?id=73445
2. https://bugs.freedesktop.org/show_bug.cgi?id=74492


-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/874msujgl4@turtle.gmx.de



Bug#769995: marked as done (xserver-xorg-video-nouveau: displays don't wake up after suspend)

2014-12-17 Thread Debian Bug Tracking System
Your message dated Wed, 17 Dec 2014 19:29:43 +0100
with message-id 87y4q6i0yw@turtle.gmx.de
and subject line Re: Bug#769995: xserver-xorg-video-nouveau: displays don't 
wake up after suspend
has caused the Debian Bug report #769995,
regarding xserver-xorg-video-nouveau: displays don't wake up after suspend
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
769995: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769995
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
---BeginMessage---
Package: xserver-xorg-video-nouveau
Version: 1:1.0.11-1
Severity: important

Dear Maintainer,

after waking up from suspend, the two monitors stay in power save mode, no 
matter what I do. I am writing this report on the affected machine, logged in 
over ssh. Switching num lock works. ALT-F1 etc has no effect.
The closed source driver wakes up from suspend, but leaves corruptions in the 
wallpaper, so I tried nouveau again. I added my problem discription to #768896, 
but I am not sure whether this is the correct one.
I have a disabled closed source nvidia driver installed.
It's disabled by renaming modprobes.conf.d's to nvidia*.conf-disabled, 
blacklist nvidia, setting alternatives for glx, loading nouveau explicitly over 
an xorg.conf.d.
Hope the installed closed source driver is not the problem.

-- Package-specific info:
X server symlink status:

lrwxrwxrwx 1 root root 13 Oct 12 22:00 /etc/X11/X - /usr/bin/Xorg
-rwxr-xr-x 1 root root 2397280 Nov  3 22:52 /usr/bin/Xorg

Diversions concerning libGL are in place

diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2.0 by glx-diversions
diversion of /usr/lib/libGL.so.1 to /usr/lib/mesa-diverted/libGL.so.1 by 
glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2.0.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2.0.0 by glx-diversions
diversion of /usr/lib/libGLESv2.so.2 to /usr/lib/mesa-diverted/libGLESv2.so.2 
by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGL.so to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so.1.1.0 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv2.so.2 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLESv2.so.2 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2 by glx-diversions
diversion of /usr/lib/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/libGLESv1_CM.so.1.1.0 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so.1 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so.1.1.0 by 
glx-diversions
diversion of /usr/lib/libGL.so.1.2.0 to /usr/lib/mesa-diverted/libGL.so.1.2.0 
by glx-diversions
diversion of /usr/lib/libGLESv2.so to /usr/lib/mesa-diverted/libGLESv2.so by 
glx-diversions
diversion of /usr/lib/libGL.so.1.2 to /usr/lib/mesa-diverted/libGL.so.1.2 by 
glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1.1.0 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1.2.0 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so by glx-diversions
diversion of /usr/lib/libGL.so to /usr/lib/mesa-diverted/libGL.so by 
glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1.2 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1.2 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv2.so to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so by glx-diversions
diversion of /usr/lib/libGLESv1_CM.so to 

Bug#758460: xserver-xorg-video-nouveau: [GeForce 6150 LE] complete system freeze as soon as GDM launches on kernel (= 3.14)

2014-12-17 Thread Sven Joachim
On 2014-08-17 20:33 +0200, Martin-Éric Racine wrote:

 Package: xserver-xorg-video-nouveau
 Version: 1:1.0.10-1+b2
 Severity: important

 This Athlon 64 system complete freezes (requires a hard poweroff via the 
 power switch) 
 as soon as X 1.16 launches via GDM when booting from kernel 3.14 or 
 3.16-trunk.

Does it help to boot with the nouveau.config=NvMSI=0 kernel parameter?
See https://bugs.freedesktop.org/show_bug.cgi?id=87361 for more
information on that topic.

Cheers,
   Sven


--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87sigei0m8@turtle.gmx.de



Bug#758460: xserver-xorg-video-nouveau: [GeForce 6150 LE] complete system freeze as soon as GDM launches on kernel (= 3.14)

2014-12-17 Thread Martin-Éric Racine
2014-12-17 20:37 GMT+02:00 Sven Joachim svenj...@gmx.de:
 On 2014-08-17 20:33 +0200, Martin-Éric Racine wrote:

 Package: xserver-xorg-video-nouveau
 Version: 1:1.0.10-1+b2
 Severity: important

 This Athlon 64 system complete freezes (requires a hard poweroff via the 
 power switch)
 as soon as X 1.16 launches via GDM when booting from kernel 3.14 or 
 3.16-trunk.

 Does it help to boot with the nouveau.config=NvMSI=0 kernel parameter?
 See https://bugs.freedesktop.org/show_bug.cgi?id=87361 for more
 information on that topic.

Yes, it does.  Thank you.  Could this exception be incorporated into the driver?

Martin-Éric


--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/debian-x



Bug#773303: libgl1-mesa-dev: Symlink error for libGL.so

2014-12-17 Thread Shan Ting
Yeah.. After some more check I'm now sure it's a bug in driver side. Sadly 
Parallels doesn't have open source drivers so I can't patch it's installing 
behavior... (Ugly non-free software!)
Sorry for the misplaced bug report.

 在 2014年12月17日,下午4:34,Simon McVittie s...@debian.org 写道:
 
 On Wed, 17 Dec 2014 at 14:52:33 +0800, Shan Ting wrote:
 sudo stat /usr/lib/x86_64-linux-gnu/libGL.so
  File: ‘/usr/lib/x86_64-linux-gnu/libGL.so’ - ‘libGL.so.1.2.0’
 
 OK so far...
 
 sudo stat /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0
 stat: cannot stat ‘/usr/lib/x86_64-linux-gnu/libGL.so.1.2.0’: No such file 
 or directory
 
 ... but that seems wrong for the packages you have installed. You said
 you have:
 
 Package: libgl1-mesa-dev
 Version: 10.3.2-1
 ...
 ii  libgl1-mesa-glx 10.3.2-1
 
 but those same packages on the same (amd64) architecture do provide
 libGL.so.1.2.0:
 
 % dpkg -s libgl1-mesa-dev
 ...
 Version: 10.3.2-1
 Depends: ..., libgl1-mesa-glx (= 10.3.2-1), ...
 ...
 % dpkg -L libgl1-mesa-glx:amd64
 ...
 /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0
 /usr/lib/x86_64-linux-gnu/libGL.so.1
 
 I’m not using lx-alternative-fglrx, glx-alternative-nvidia or
 glx-diversions. The libGL.so.10.1.1.28614 is come from my graphic card
 driver(parallels).
 
 Then I think this is a bug in your graphics card driver: it is overwriting
 and deleting files owned by the packaging system, but not finishing the job
 by taking responsibility for setting the target of the libGL.so symlink
 (and not participating in glx-alternatives like the non-free drivers
 packaged by Debian developers do, which would be the ideal thing).
 
 Is there some reasons to use libGL.so.1.2.0 directly rather than
 libGL.so.1?
 
 That's how libraries' development symlinks normally work. For instance,
 picking a random library for which I have development files
 installed (Gtk 2):
 
 % ls -l /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so
 lrwxrwxrwx 1 root root 27 Oct 10 18:57 
 /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so - libgtk-x11-2.0.so.0.2400.25
 default|archetype% ls -l /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
 lrwxrwxrwx 1 root root 27 Oct 10 18:57 
 /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 - libgtk-x11-2.0.so.0.2400.25
 % ls -l /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.25
 -rw-r--r-- 1 root root 4501992 Oct 10 18:57 
 /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.25
 
 The real file is the versioned one, and the development symlink and the
 SONAME (runtime) symlink both point to it.
 
 Regards,
S


--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5bb95a48-5d4c-4640-9093-4f5234be9...@gmail.com



Bug#758460: xserver-xorg-video-nouveau: [GeForce 6150 LE] complete system freeze as soon as GDM launches on kernel (= 3.14)

2014-12-17 Thread Sven Joachim
On 2014-12-17 19:55 +0100, Martin-Éric Racine wrote:

 2014-12-17 20:37 GMT+02:00 Sven Joachim svenj...@gmx.de:
 On 2014-08-17 20:33 +0200, Martin-Éric Racine wrote:

 Package: xserver-xorg-video-nouveau
 Version: 1:1.0.10-1+b2
 Severity: important

 This Athlon 64 system complete freezes (requires a hard poweroff via the 
 power switch)
 as soon as X 1.16 launches via GDM when booting from kernel 3.14 or 
 3.16-trunk.

 Does it help to boot with the nouveau.config=NvMSI=0 kernel parameter?
 See https://bugs.freedesktop.org/show_bug.cgi?id=87361 for more
 information on that topic.

 Yes, it does.  Thank you.  Could this exception be incorporated into the 
 driver?

There's a patch in Ben Skegg's nouveau master branch[1].  It should go
into the stable kernels eventually, but that will take some time.

Cheers,
   Sven


1. 
http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=b7387454bda64a16350fabee4d81bec3b8de8fa2


--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87lhm6hyyj@turtle.gmx.de



Bug#758460: xserver-xorg-video-nouveau: [GeForce 6150 LE] complete system freeze as soon as GDM launches on kernel (= 3.14)

2014-12-17 Thread Martin-Éric Racine
2014-12-17 21:13 GMT+02:00 Sven Joachim svenj...@gmx.de:
 On 2014-12-17 19:55 +0100, Martin-Éric Racine wrote:

 2014-12-17 20:37 GMT+02:00 Sven Joachim svenj...@gmx.de:
 On 2014-08-17 20:33 +0200, Martin-Éric Racine wrote:

 Package: xserver-xorg-video-nouveau
 Version: 1:1.0.10-1+b2
 Severity: important

 This Athlon 64 system complete freezes (requires a hard poweroff via the 
 power switch)
 as soon as X 1.16 launches via GDM when booting from kernel 3.14 or 
 3.16-trunk.

 Does it help to boot with the nouveau.config=NvMSI=0 kernel parameter?
 See https://bugs.freedesktop.org/show_bug.cgi?id=87361 for more
 information on that topic.

 Yes, it does.  Thank you.  Could this exception be incorporated into the 
 driver?

 There's a patch in Ben Skegg's nouveau master branch[1].  It should go
 into the stable kernels eventually, but that will take some time.

Could this fix be cherry-picked for Jessie's kernels?

-- Martin-Éric


--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/debian-x



Bug#758460: xserver-xorg-video-nouveau: [GeForce 6150 LE] complete system freeze as soon as GDM launches on kernel (= 3.14)

2014-12-17 Thread Sven Joachim
On 2014-12-17 20:19 +0100, Martin-Éric Racine wrote:

 2014-12-17 21:13 GMT+02:00 Sven Joachim svenj...@gmx.de:
 On 2014-12-17 19:55 +0100, Martin-Éric Racine wrote:

 2014-12-17 20:37 GMT+02:00 Sven Joachim svenj...@gmx.de:
 On 2014-08-17 20:33 +0200, Martin-Éric Racine wrote:

 Package: xserver-xorg-video-nouveau
 Version: 1:1.0.10-1+b2
 Severity: important

 This Athlon 64 system complete freezes (requires a hard poweroff via the 
 power switch)
 as soon as X 1.16 launches via GDM when booting from kernel 3.14 or 
 3.16-trunk.

 Does it help to boot with the nouveau.config=NvMSI=0 kernel parameter?
 See https://bugs.freedesktop.org/show_bug.cgi?id=87361 for more
 information on that topic.

 Yes, it does.  Thank you.  Could this exception be incorporated into the 
 driver?

 There's a patch in Ben Skegg's nouveau master branch[1].  It should go
 into the stable kernels eventually, but that will take some time.

 Could this fix be cherry-picked for Jessie's kernels?

It should land there via Canonical's 3.16.y releases.

Cheers,
   Sven


--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87d27ihx7z@turtle.gmx.de



Bug#758460: xserver-xorg-video-nouveau: [GeForce 6150 LE] complete system freeze as soon as GDM launches on kernel (= 3.14)

2014-12-17 Thread Martin-Éric Racine
2014-12-17 21:50 GMT+02:00 Sven Joachim svenj...@gmx.de:
 On 2014-12-17 20:19 +0100, Martin-Éric Racine wrote:

 2014-12-17 21:13 GMT+02:00 Sven Joachim svenj...@gmx.de:
 On 2014-12-17 19:55 +0100, Martin-Éric Racine wrote:

 2014-12-17 20:37 GMT+02:00 Sven Joachim svenj...@gmx.de:
 On 2014-08-17 20:33 +0200, Martin-Éric Racine wrote:

 Package: xserver-xorg-video-nouveau
 Version: 1:1.0.10-1+b2
 Severity: important

 This Athlon 64 system complete freezes (requires a hard poweroff via the 
 power switch)
 as soon as X 1.16 launches via GDM when booting from kernel 3.14 or 
 3.16-trunk.

 Does it help to boot with the nouveau.config=NvMSI=0 kernel parameter?
 See https://bugs.freedesktop.org/show_bug.cgi?id=87361 for more
 information on that topic.

 Yes, it does.  Thank you.  Could this exception be incorporated into the 
 driver?

 There's a patch in Ben Skegg's nouveau master branch[1].  It should go
 into the stable kernels eventually, but that will take some time.

 Could this fix be cherry-picked for Jessie's kernels?

 It should land there via Canonical's 3.16.y releases.

Come again? Has the Ubuntu team taken over maintenance of Debian's kernels?

-- Martin-Éric


--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/debian-x



Bug#758460: xserver-xorg-video-nouveau: [GeForce 6150 LE] complete system freeze as soon as GDM launches on kernel (= 3.14)

2014-12-17 Thread Sven Joachim
On 2014-12-17 21:14 +0100, Martin-Éric Racine wrote:

 2014-12-17 21:50 GMT+02:00 Sven Joachim svenj...@gmx.de:
 On 2014-12-17 20:19 +0100, Martin-Éric Racine wrote:

 2014-12-17 21:13 GMT+02:00 Sven Joachim svenj...@gmx.de:

 There's a patch in Ben Skegg's nouveau master branch[1].  It should go
 into the stable kernels eventually, but that will take some time.

 Could this fix be cherry-picked for Jessie's kernels?

 It should land there via Canonical's 3.16.y releases.

 Come again? Has the Ubuntu team taken over maintenance of Debian's kernels?

No, but they are maintaining a 3.16 branch[1] which the Debian kernel team
uses for Jessie[2].

Cheers,
   Sven


1. 
http://kernel.ubuntu.com/git?p=ubuntu/linux.git;a=shortlog;h=refs/heads/linux-3.16.y
2. https://lists.debian.org/debian-devel-announce/2014/07/msg6.html


--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87388ehu9e@turtle.gmx.de



Bug#773389: xserver-xorg-input-synaptics: Pointer gets hidden requires tap or window exchange to re-appear

2014-12-17 Thread ael
Package: xserver-xorg-input-synaptics
Version: 1.8.1-1
Severity: normal

I first noticed this today (17/12/14) although it is possible that it
happened yesterday. Checking /var/log/dpkg.log, no obvious (to me) 
package update stood out.

If I have several xterms open, and I work in one, then updating the
that window (say executing ls -l) causes the pointer to vanish. I think
any repainting of the window does the same.

The pointer does not reappear until I remove a finger from the touch
pad (or tap). Just moving the (unseen) pointer around the window - by
moving a finger - does not cause tho pointer to appear. If I move the
(unseen) pointer out of the window - a guess because I cannot see it - 
and then back into the window (my focus is set to follow pointer) then
the pointer reappears. This is quite new and disturbing behaviour.
The same problem is happening as I edit this report in vim.

Although I have given this example with xterm windows, something similar
seems to be happening in other windows. I can't be sure that this is
just the synaptic driver or something more generic.

However, I have just plugged in a trackball (~ mouse) and that does
*not* show the problem, so it does suggest a touchpad problem.


-- Package-specific info:
X server symlink status:

lrwxrwxrwx 1 root root 13 Jan 17  2010 /etc/X11/X - /usr/bin/Xorg
-rwxr-xr-x 1 root root 2556784 Nov  3 21:52 /usr/bin/Xorg

VGA-compatible devices on PCI bus:
--
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 945GSE 
Express Integrated Graphics Controller [8086:27ae] (rev 03)

Xorg X server configuration file status:

-rw-r--r-- 1 root root 1717 Oct 12 10:23 /etc/X11/xorg.conf

Contents of /etc/X11/xorg.conf:
---
#Section Screen### Used to test whether xrandr now requires
#  Identifier   945GME ### a Virtual entry below. Did not make
#  Monitor  LVDS1  ### any difference.
#  SubSection Display
#   Depth 24
#   Virtual 1024 1024
#  EndSubSection
#EndSection

Section InputClass
Identifier  marble
Driver  evdev
MatchProductImExPS/2 Logitech Explorer Mouse|Logitech USB 
Trackball
MatchIsPointer  true
Option  ButtonMapping 1 9 3 4 5 6 7 8 2
EndSection

Section InputClass
Identifier  marble_FX
Driver  evdev
MatchProductImExPS/2 Logitech Explorer Mouse|Logitech USB 
Trackball|PS2++ Logitech Mouse|PS2++ Logitech TrackMan
MatchIsPointer  true
#   Option  Protocol  ExplorerPS/2
Option  EmulateWheel  true
Option  EmulateWheelButton8
#   Option  EmulateWheelTimeout   300
Option  XAxisMapping  6 7
Option  YAxisMapping  4 5
Option  ZAxisMapping  4 5

EndSection

Section InputClass

Identifier  Synaptics TouchPad
MatchProductSynPS/2 Synaptics TouchPad
MatchDevicePath /dev/input/event*
MatchIsTouchpad true
Driver  synaptics
Option  LeftEdge  1700
Option  BottomEdge5100
Option  FingerLow 25
Option  FingerHigh30
Option  MaxTapTime180
Option  MaxTapTime180
# Next mainly for josm/java double click: default is 180
Option  MaxDoubleTapTime  140
Option  AccelFactor   0.02
Option  VertEdgeScrolltrue
Option  VertScrollDelta   100
Option  VertTwoFingerScroll   true
Option  HorizTwoFingerScroll  true
Option  MinSpeed  0.5
Option  MaxSpeed  20
Option  HorizEdgeScroll   true
Option  TapButton11
Option  TapButton22
Option  RTCornerButton 2
Option  PalmDetect true
EndSection


/etc/X11/xorg.conf.d does not exist.

KMS configuration files:

/etc/modprobe.d/i915-kms.conf:
  options i915 modeset=1

Kernel version (/proc/version):
---
Linux version 3.16.0-4-686-pae (debian-ker...@lists.debian.org) (gcc version 
4.8.3 (Debian 4.8.3-16) ) #1 SMP Debian 3.16.7-ckt2-1 (2014-12-08)

Xorg X server log files on system:
--
-rw-r--r-- 1 root root 25871 Dec 17 19:54 /var/log/Xorg.0.log

Contents of most recent Xorg X server log file (/var/log/Xorg.0.log):
-
[71.040] 
X.Org X Server 1.16.1.901 (1.16.2 RC 1)
Release Date: 2014-11-02
[71.041] X Protocol Version 11, Revision 0
[71.041] Build Operating System: Linux 3.2.0-4-amd64 i686 Debian
[71.041] Current Operating System: Linux elf 3.16.0-4-686-pae #1 SMP Debian 
3.16.7-ckt2-1 (2014-12-08) i686
[71.041] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.16.0-4-686-pae 

Bug#773389: Also in firefox

2014-12-17 Thread ael
Just realised that the same is happening in firefox. I noticed this
for the first time (I think) yesterday. Presumably certain xevents
are being missed? I couldn't figure out a way to use xev to 
investigate this problem. 

ael


-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141217211419.GA4410@elf.conquest



Processed: closing 773303

2014-12-17 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

 close 773303
Bug #773303 [libgl1-mesa-dev] libgl1-mesa-dev: Symlink error for libGL.so
Marked Bug as done
 thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
773303: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=773303
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/handler.s.c.141885414519858.transcr...@bugs.debian.org