Bug#675138: weston: not installable, fails to build from source
twied (30/05/2012): > Dear Maintainer, > package weston (0.85.0-1) is currently uninstallable due to a depend > (=0.85.0-1) on libwayland0. This depend should read (=0.85.0-2) or (>= > 0.85.0-1). > > The package also fails to build from source, some libpng12 vs. > libpng15 issues. See > https://buildd.debian.org/status/package.php?p=weston&suite=experimental Yep, thanks for the heads-up on IRC by the way. Since binNMUs dramatically failed due to yet another libpng mess, I'm pondering just uploading weston to unstable instead, but I'd have to see which toy apps to enable and how. That might take some days as it's low priority on my todo list. Mraw, KiBi. signature.asc Description: Digital signature
Bug#675161: xserver-xorg-video-nouveau: Random artefacts in any application
Hi, darx (30/05/2012): > Hi there, > > I'v got some crazy artifacts randomly displayed in any applications. > Those artifacts generally disappears when I scroll, click or move the > windows > > You can find an example here (black and blurry zones): > https://www.omch.ch/hfr/screen.png attaching stuff is better than linking to them (they tend to disappear after a while), but anyway: That's a known problem with nouveau. You can downgrade to libcairo2 1.10 until a fix is available. You can find it on snapshot.debian.org: http://snapshot.debian.org/binary/libcairo2/ Mraw, KiBi. signature.asc Description: Digital signature
Bug#673595: xserver-xorg-core: Mouse wheel not responding while moving mouse
Package: xserver-xorg-core Version: 2:1.12.1.902-1 Followup-For: Bug #673595 Dear Maintainer, my xorg is update and PROBLEM still persists again. In game, mouse wheel not responding while moving mouse, right to left. :-((( -- Package-specific info: X server symlink status: lrwxrwxrwx 1 root root 13 May 21 22:40 /etc/X11/X -> /usr/bin/Xorg -rwxr-xr-x 1 root root 2027892 May 20 12:31 /usr/bin/Xorg Diversions concerning libGL are in place diversion of /usr/lib/libGL.so to /usr/lib/mesa-diverted/libGL.so 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/i386-linux-gnu/libGL.so.1 to /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1 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/libGL.so to /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGL.so.1.2 to /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1.2 by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1 to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1 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/x86_64-linux-gnu/libGL.so to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so by glx-diversions VGA-compatible devices on PCI bus: -- 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation G96 [GeForce 9500 GT] [10de:0640] (rev a1) Xorg X server configuration file status: -rw-r--r-- 1 root root 1306 May 28 19:51 /etc/X11/xorg.conf Contents of /etc/X11/xorg.conf: --- # nvidia-xconfig: X configuration file generated by nvidia-xconfig # nvidia-xconfig: version 295.33 (buildd@murphy) Wed Apr 4 13:03:17 UTC 2012 Section "ServerLayout" Identifier "Layout0" Screen 0 "Screen0" 0 0 InputDevice"Keyboard0" "CoreKeyboard" InputDevice"Mouse0" "CorePointer" EndSection Section "Files" EndSection Section "InputDevice" # generated from default Identifier "Mouse0" Driver "mouse" Option "Protocol" "auto" Option "Device" "/dev/psaux" Option "Emulate3Buttons" "no" Option "ZAxisMapping" "4 5" EndSection Section "InputDevice" # generated from default Identifier "Keyboard0" Driver "kbd" EndSection Section "Monitor" Identifier "Monitor0" VendorName "Unknown" ModelName "Unknown" HorizSync 28.0 - 33.0 VertRefresh 43.0 - 72.0 Option "DPMS" EndSection Section "Device" Identifier "Device0" Driver "nvidia" VendorName "NVIDIA Corporation" EndSection Section "Screen" Identifier "Screen0" Device "Device0" Monitor"Monitor0" DefaultDepth24 SubSection "Display" Depth 24 EndSubSection EndSection /etc/X11/xorg.conf.d does not exist. KMS configuration files: /etc/modprobe.d/i915-kms.conf: options i915 modeset=1 /etc/modprobe.d/radeon-kms.conf: options radeon modeset=1 Kernel version (/proc/version): --- Linux version 3.2.0-2-686-pae (Debian 3.2.17-1) (debian-ker...@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-5) ) #1 SMP Sun May 13 07:51:23 UTC 2012 Xorg X server log files on system: -- -rw-r--r-- 1 root root 19097 May 30 12:29 /var/log/Xorg.0.log Contents of most recent Xorg X server log file (/var/log/Xorg.0.log): - [13.850] X.Org X Server 1.12.1.902 (1.12.2 RC 2) Release Date: 2012-05-19 [13.850] X Protocol Version 11, Revision 0 [13.850] Build Operating System: Linux 2.6.32-5-686-bigmem i686 Debian [13.850] Current Operating System: Linux dq35jo 3.2.0-2-686-pae #1 SMP Sun May 13 07:51:23 UTC 2012 i686 [13.850] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.2.0-2-686-pae root=UUID=1ae7c996-235f-4a01-8d49-62ce2869d4ac ro quiet [13.850] Build Date: 20 May 2012 10:23:38AM [13.850] xorg-server 2:1.12.1.902-1 (Cyril Brulebois ) [13.850] Current version of pixman: 0.24.4 [13.850]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [13.850] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [13.850] (==) Log file: "/var/log/Xorg.0.log", Time: Wed May 30 12:29:48 2012 [13.893] (==) Using config file: "/etc/X11/xorg.conf" [13.893] (==) Using
Bug#675173: libx11-6: New version: 1.4.99.902
Package: libx11-6 Version: 2:1.4.99.901-2 Severity: wishlist New version: 1.4.99.902 Url: http://cgit.freedesktop.org/xorg/lib/libX11/tag/?id=libX11-1.4.99.902 -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (900, 'testing'), (800, 'unstable'), (500, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.3.0-trunk-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libx11-6 depends on: ii libc6 2.13-32 ii libx11-data2:1.4.99.901-2 ii libxcb11.8.1-1 ii multiarch-support 2.13-32 libx11-6 recommends no packages. libx11-6 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120530111531.1582.88799.reportbug@vienna.local
Bug#675173: libx11-6: New version: 1.4.99.902
Giorgio Marinelli (30/05/2012): > Package: libx11-6 > Version: 2:1.4.99.901-2 > Severity: wishlist > > New version: 1.4.99.902 > Url: http://cgit.freedesktop.org/xorg/lib/libX11/tag/?id=libX11-1.4.99.902 We know, we read the xorg announce list. We're happy to take your patches. Mraw, KiBi. signature.asc Description: Digital signature
Processed: reassign 675022 to src:linux-2.6
Processing commands for cont...@bugs.debian.org: > reassign 675022 src:linux-2.6 3.2.18-1 Bug #675022 [xserver-xorg-video-intel] Frequent lockups when using icedove (thunderbird) Bug reassigned from package 'xserver-xorg-video-intel' to 'src:linux-2.6'. No longer marked as found in versions xserver-xorg-video-intel/2:2.19.0-1. Ignoring request to alter fixed versions of bug #675022 to the same values previously set Bug #675022 [src:linux-2.6] Frequent lockups when using icedove (thunderbird) Marked as found in versions linux-2.6/3.2.18-1. > thanks Stopping processing here. Please contact me if you need assistance. -- 675022: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675022 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: http://lists.debian.org/handler.s.c.133838551117516.transcr...@bugs.debian.org
Processed: reassign 674668 to xserver-xorg-core, severity of 674668 is important
Processing commands for cont...@bugs.debian.org: > reassign 674668 xserver-xorg-core Bug #674668 [gnome-shell] Starting Evolution often crashes the GNOME session Bug reassigned from package 'gnome-shell' to 'xserver-xorg-core'. No longer marked as found in versions gnome-shell/3.2.2.1-4. Ignoring request to alter fixed versions of bug #674668 to the same values previously set > severity 674668 important Bug #674668 [xserver-xorg-core] Starting Evolution often crashes the GNOME session Severity set to 'important' from 'grave' > thanks Stopping processing here. Please contact me if you need assistance. -- 674668: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674668 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: http://lists.debian.org/handler.s.c.133839219323798.transcr...@bugs.debian.org
Bug#674952: xserver-xorg-video-radeon: fails to work properly without -ati
On Wed, May 30, 2012 at 08:33:47AM +0200, Maarten Lankhorst wrote:
> >>> The current situation just makes some people (eg. me ;) break the
> >>> dependency link that's the weakest to get rid of useless drivers, with
> >>> the results described in my original report.
> >> What are you gaining?
> >> $ for f in $(dpkg -L xserver-xorg-video-r128); do if [ -f $f ]; then ls
> >> -lh $f; fi; done|awk '{print $5}'
> >> 110K
> >> 5.1K
> >> 676
> >> 6.0K
> >> 117K
> >> 2.2K
> >> 27
> >>
> >>> If I check the Policy about Depends, "This declares an absolute
> >>> dependency", which is clearly not the case here. Even the official
> >>> definition of Recommends makes me wonder if it would not be too
> >>> strong. After all, someone with a radeon is likely to select the
> >>> readon driver, then the ati wrapper will be selected as Recommended,
> >>> but the latter should IMHO have no reason to pull mach64 and r128,
> >>> that would not fit the "packages that would be found together with
> >>> this one in all but unusual installations" criteria.
> >> The current situation ensures that X works by default. People can still
> >> select this or that driver manually as explained previously, so it looks
> >> to me like the current relationships are fine (and have been for I think
> >> many years).
> > At least downgrading to Recommends would keep things working by
> > default. And even downgrading to Suggests, together with -all
> > depending on {radeon,r128,mach64}, would keep things working by
> > default - while allowing those who don't want extra stuff to avoid
> > cruft.
> >
> The extra cruft of a few 100kb? Make your own xorg.conf and remove ati.
> You'll sacrifice auto config but whatever is more important to you. :-)
The problem is, I still do not see why the small changes I propose
would not work, and thus I don't see the need for whatever sacrifice
of the auto config feature.
If there are any arguments that I missed against lowering the Depends
of ati against those drivers it knows how to wrap (and I am not saying
there can be no reason, I only have a radeon to test - I'm just
pointing to the lack of arguments, whereas I did my best to find
arguments for my proposal), I'd be glad to see them before I send a patch...
Best regards,
--
Yann
--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120530181629.gw9...@home.lan
Bug#674952: xserver-xorg-video-radeon: fails to work properly without -ati
On Tue, May 29, 2012 at 23:32:58 +0200, Yann Dirson wrote: > The current situation just makes some people (eg. me ;) break the > dependency link that's the weakest to get rid of useless drivers, with > the results described in my original report. > That's good, then we can point and laugh. Cheers, Julien -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120530191101.gi31...@radis.cristau.org
Bug#674668: Starting Evolution often crashes the GNOME session
On Sat, May 26, 2012 at 18:10:35 +0200, Alexander Kurtz wrote: > Hi, > > I've just upgraded gnome-shell and evolution to version 3.4.1-1 and > 3.4.2-1 (both from experimental). Unfortunately the crashes still occur. > What's interesting though, is that the crash actually seems to happen in > the X-Server. I found this in /var/log/Xorg.0.log.old: > You need to attach the full file. Cheers, Julien -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120530191443.ga9...@radis.cristau.org
Bug#675289: libpciaccess: Implement legacy map & io for hurd-i386
Package: libpciaccess
Version: 0.13.1-2
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd
Hello,
Just like kfreebsd needed in #669062, hurd-i386 needs legacy map & io
support in libpciaccess, otherwise Xorg segfaults, here is a patch.
Samuel
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1,
'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 3.0.4 (SMP w/8 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
--
Samuel Thibault
mr - remove the home of correct users who accidentally enter mr
instead of rm
--- src/x86_pci.c.original 2012-05-31 03:03:48.0 +
+++ src/x86_pci.c 2012-05-31 03:20:17.0 +
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2009 Samuel Thibault
+ * Copyright (c) 2009, 2012 Samuel Thibault
* Heavily inspired from the freebsd, netbsd, and openbsd backends
* (C) Copyright Eric Anholt 2006
* (C) Copyright IBM Corporation 2006
@@ -550,6 +550,92 @@
x86_disable_io();
}
+static struct pci_io_handle *
+pci_device_x86_open_legacy_io(struct pci_io_handle *ret,
+struct pci_device *dev, pciaddr_t base, pciaddr_t size)
+{
+x86_enable_io();
+
+ret->base = base;
+ret->size = size;
+
+return ret;
+}
+
+static void
+pci_device_x86_close_io(struct pci_device *dev, struct pci_io_handle *handle)
+{
+x86_disable_io();
+}
+
+static uint32_t
+pci_device_x86_read32(struct pci_io_handle *handle, uint32_t reg)
+{
+return inl(reg + handle->base);
+}
+
+static uint16_t
+pci_device_x86_read16(struct pci_io_handle *handle, uint32_t reg)
+{
+return inw(reg + handle->base);
+}
+
+static uint8_t
+pci_device_x86_read8(struct pci_io_handle *handle, uint32_t reg)
+{
+return inb(reg + handle->base);
+}
+
+static void
+pci_device_x86_write32(struct pci_io_handle *handle, uint32_t reg,
+ uint32_t data)
+{
+outl(data, reg + handle->base);
+}
+
+static void
+pci_device_x86_write16(struct pci_io_handle *handle, uint32_t reg,
+ uint16_t data)
+{
+outw(data, reg + handle->base);
+}
+
+static void
+pci_device_x86_write8(struct pci_io_handle *handle, uint32_t reg,
+ uint8_t data)
+{
+outb(data, reg + handle->base);
+}
+
+static int
+pci_device_x86_map_legacy(struct pci_device *dev, pciaddr_t base,
+pciaddr_t size, unsigned map_flags, void **addr)
+{
+struct pci_device_mapping map;
+int err;
+
+map.base = base;
+map.size = size;
+map.flags = map_flags;
+err = pci_device_x86_map_range(dev, &map);
+*addr = map.memory;
+
+return err;
+}
+
+static int
+pci_device_x86_unmap_legacy(struct pci_device *dev, void *addr,
+pciaddr_t size)
+{
+struct pci_device_mapping map;
+
+map.size = size;
+map.flags = 0;
+map.memory = addr;
+
+return pci_device_generic_unmap_range(dev, &map);
+}
+
static const struct pci_system_methods x86_pci_methods = {
.destroy = pci_system_x86_destroy,
.read_rom = pci_device_x86_read_rom,
@@ -559,6 +645,16 @@
.read = pci_device_x86_read,
.write = pci_device_x86_write,
.fill_capabilities = pci_fill_capabilities_generic,
+.open_legacy_io = pci_device_x86_open_legacy_io,
+.close_io = pci_device_x86_close_io,
+.read32 = pci_device_x86_read32,
+.read16 = pci_device_x86_read16,
+.read8 = pci_device_x86_read8,
+.write32 = pci_device_x86_write32,
+.write16 = pci_device_x86_write16,
+.write8 = pci_device_x86_write8,
+.map_legacy = pci_device_x86_map_legacy,
+.unmap_legacy = pci_device_x86_unmap_legacy,
};
static int pci_probe(struct pci_system_x86 *pci_sys_x86)
Bug#675289: libpciaccess: Implement legacy map & io for hurd-i386
Samuel Thibault, le Thu 31 May 2012 03:24:14 +0200, a écrit :
> Just like kfreebsd needed in #669062, hurd-i386 needs legacy map & io
> support in libpciaccess, otherwise Xorg segfaults, here is a patch.
Please rather use the attached patch actually: just like on Linux (e.g.
on my laptop actually), it does not disable i/o access, otherwise
several opens and then fewer closes would not leave i/o access enabled.
E.g. with the cirrus driver.
Samuel
--- libpciaccess-0.13.1.orig/src/x86_pci.c
+++ libpciaccess-0.13.1/src/x86_pci.c
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2009 Samuel Thibault
+ * Copyright (c) 2009, 2012 Samuel Thibault
* Heavily inspired from the freebsd, netbsd, and openbsd backends
* (C) Copyright Eric Anholt 2006
* (C) Copyright IBM Corporation 2006
@@ -550,6 +550,94 @@
x86_disable_io();
}
+static struct pci_io_handle *
+pci_device_x86_open_legacy_io(struct pci_io_handle *ret,
+struct pci_device *dev, pciaddr_t base, pciaddr_t size)
+{
+x86_enable_io();
+
+ret->base = base;
+ret->size = size;
+
+return ret;
+}
+
+static void
+pci_device_x86_close_io(struct pci_device *dev, struct pci_io_handle *handle)
+{
+/* do not disable I/O, as it may be opened several times, and closed
+ * fewer times. */
+/* x86_disable_io(); */
+}
+
+static uint32_t
+pci_device_x86_read32(struct pci_io_handle *handle, uint32_t reg)
+{
+return inl(reg + handle->base);
+}
+
+static uint16_t
+pci_device_x86_read16(struct pci_io_handle *handle, uint32_t reg)
+{
+return inw(reg + handle->base);
+}
+
+static uint8_t
+pci_device_x86_read8(struct pci_io_handle *handle, uint32_t reg)
+{
+return inb(reg + handle->base);
+}
+
+static void
+pci_device_x86_write32(struct pci_io_handle *handle, uint32_t reg,
+ uint32_t data)
+{
+outl(data, reg + handle->base);
+}
+
+static void
+pci_device_x86_write16(struct pci_io_handle *handle, uint32_t reg,
+ uint16_t data)
+{
+outw(data, reg + handle->base);
+}
+
+static void
+pci_device_x86_write8(struct pci_io_handle *handle, uint32_t reg,
+ uint8_t data)
+{
+outb(data, reg + handle->base);
+}
+
+static int
+pci_device_x86_map_legacy(struct pci_device *dev, pciaddr_t base,
+pciaddr_t size, unsigned map_flags, void **addr)
+{
+struct pci_device_mapping map;
+int err;
+
+map.base = base;
+map.size = size;
+map.flags = map_flags;
+err = pci_device_x86_map_range(dev, &map);
+*addr = map.memory;
+
+return err;
+}
+
+static int
+pci_device_x86_unmap_legacy(struct pci_device *dev, void *addr,
+pciaddr_t size)
+{
+struct pci_device_mapping map;
+
+map.size = size;
+map.flags = 0;
+map.memory = addr;
+
+return pci_device_generic_unmap_range(dev, &map);
+}
+
static const struct pci_system_methods x86_pci_methods = {
.destroy = pci_system_x86_destroy,
.read_rom = pci_device_x86_read_rom,
@@ -559,6 +647,16 @@
.read = pci_device_x86_read,
.write = pci_device_x86_write,
.fill_capabilities = pci_fill_capabilities_generic,
+.open_legacy_io = pci_device_x86_open_legacy_io,
+.close_io = pci_device_x86_close_io,
+.read32 = pci_device_x86_read32,
+.read16 = pci_device_x86_read16,
+.read8 = pci_device_x86_read8,
+.write32 = pci_device_x86_write32,
+.write16 = pci_device_x86_write16,
+.write8 = pci_device_x86_write8,
+.map_legacy = pci_device_x86_map_legacy,
+.unmap_legacy = pci_device_x86_unmap_legacy,
};
static int pci_probe(struct pci_system_x86 *pci_sys_x86)
Re: nouveau: hard lockup when gdm3 starts
Hi, Gedalya wrote: > Tried removing the nvidia stuff and booting up with nouveau. [...] > Total system hang as soon as xorg starts. No response from keyboard, > mouse, no response on the network (no ping, no ARP response) [...] > Using an Nvidia GeForce GT 520. Do I understand correctly that the system works fine until X starts (e.g., if you use the "text" kernel command line option)? Does X with the fbdev driver work? (You can test by putting the following in /etc/X11/xorg.conf.) Section "Device" Identifier "geforce" Driver "fbdev" EndSection Does starting X with the nouveau driver work if you do not start a GNOME session? (You can test by running "startx xterm" if the xinit package is installed.) Thanks for a clear report. Hope that helps, Jonathan -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120531055946.GC1447@burratino
Re: nouveau: hard lockup when gdm3 starts
Gedalya wrote: > On 5/31/2012 1:59 AM, Jonathan Nieder wrote: >> Does starting X with the nouveau driver work if you do not start a >> GNOME session? (You can test by running "startx xterm" if the xinit >> package is installed.) > > Interesting. Still working on this one. startx was complaining > something about xorg.conf so I just renamed it, and then it started > up. Pretty frozen at this point, no keyboard, only reset button > helps, but I do get network response - there is ping, initial ssh > response but nothing more, can't actually log in. Hm. Might be possible to get a log with netconsole[1]. [1] http://www.kernel.org/doc/Documentation/networking/netconsole.txt http://blog.mraw.org/2010/11/08/Debugging_using_netconsole/ -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120531063143.GD1447@burratino
Re: nouveau: hard lockup when gdm3 starts
On 5/31/2012 2:31 AM, Jonathan Nieder wrote: Gedalya wrote: On 5/31/2012 1:59 AM, Jonathan Nieder wrote: Does starting X with the nouveau driver work if you do not start a GNOME session? (You can test by running "startx xterm" if the xinit package is installed.) Interesting. Still working on this one. startx was complaining something about xorg.conf so I just renamed it, and then it started up. Pretty frozen at this point, no keyboard, only reset button helps, but I do get network response - there is ping, initial ssh response but nothing more, can't actually log in. Hm. Might be possible to get a log with netconsole[1]. [1] http://www.kernel.org/doc/Documentation/networking/netconsole.txt http://blog.mraw.org/2010/11/08/Debugging_using_netconsole/ Tried this again and this time I got a total hang again. Then I got it to work with the config file so I first tried fbdev and it worked, then when I switched to nouveau I got again this situation that it's pretty much hung but with ping. SSH does respond with failed authentication when it's the wrong password, but no successful login is possible. I'm gonna study netconsole now, let's see if I can figure it out. -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fc7117d.9040...@gedalya.net
Re: nouveau: hard lockup when gdm3 starts
On 5/31/2012 1:59 AM, Jonathan Nieder wrote: Hi, Gedalya wrote: Tried removing the nvidia stuff and booting up with nouveau. [...] Total system hang as soon as xorg starts. No response from keyboard, mouse, no response on the network (no ping, no ARP response) [...] Using an Nvidia GeForce GT 520. Do I understand correctly that the system works fine until X starts (e.g., if you use the "text" kernel command line option)? Yes. As long as X doesn't start it seems rock solid. Does X with the fbdev driver work? (You can test by putting the following in /etc/X11/xorg.conf.) Section "Device" Identifier "geforce" Driver "fbdev" EndSection Yes. This does work. BTW driver "vesa" hangs the same. Does starting X with the nouveau driver work if you do not start a GNOME session? (You can test by running "startx xterm" if the xinit package is installed.) Interesting. Still working on this one. startx was complaining something about xorg.conf so I just renamed it, and then it started up. Pretty frozen at this point, no keyboard, only reset button helps, but I do get network response - there is ping, initial ssh response but nothing more, can't actually log in. Thanks for a clear report. Hope that helps, Jonathan -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fc70ec3.7040...@gedalya.net
