Hi all! Debian/unstable, xserver-xorg-driver-intel 2:2.0.0-1, kernel 2.6.21-rc7 (self compiled of course) acer tm3012, Chipset 945GM I used xserver-xorg-video-i810-modesetting without any problem. Now I switched to xserver-xorg-driver-intel and at times when I log out of my X session (xfce4, gdm login manager) the screen becomes black (with some blocky shading) and the kernel freezes completely. Not even Sysrq is working (Alt-Prt-s, Alt-Prt-b, ..). The logfiles do not show anything after a reboot. This first was completely reproducible with beryl running. After this I removed beryl from my computer and use plain xfce4/xfwm4 and now the freeze does happen less often, but it does.
Created attachment 9742 [details] xorg configuration file
Created attachment 9743 [details] xorg log file
Is that Xorg log the one belonging to the crash?. I had a very similar problem where I blamed mesa since the backtrace was somehow related to that. Maybe the bug I reported is a duplicate of this: https://bugs.freedesktop.org/show_bug.cgi?id=10809 It would be nice if anyone wiser could tell us if mine's indeed a duplicate. So what I propose is to get somehow a backtrace or at least get the latest information you could get looking at the Xorg after the crash. Maybe looking this howto could help you: http://wiki.debian.org/XStrikeForce/XserverDebugging Feel free to ask if you any doubt about the procedure. I'll try to help you as much as I can, though I must tell I'm just a user.
It cannot be the log from the crash, as the laptop/kernel is frozen and not even Sysrq is working (see original post). So no, I don't have a log of the crash.
(In reply to comment #4) > It cannot be the log from the crash, as the laptop/kernel is frozen and not > even Sysrq is working (see original post). You can increase the chances of the log file getting sane content in that case by remounting the filesystem containing it with -o sync. Then if the X server is started automatically on bootup, the previous log should still be available in Xorg.0.log.old. Does this also happen with the DRI disabled?
> Does this also happen with the DRI disabled? I think I have the same issue. My machine crashes when changing to a text console (chvt or suspend to ram), restarting kdm or starting a new X server (X :1). Disabling DRI doesn't make a difference. The "best" log output I got so far is on kdm restart with mount sync: [...] Synaptics DeviceOff called (II) intel(0): [drm] removed 1 reserved context for kernel (II) intel(0): [drm] unmapping 8192 bytes of SAREA 0x2efff000 at 0x2ae250f6c000 (EE) intel(0): I830 Vblank Pipe Setup Failed 0 (EE) intel(0): I830 Vblank Pipe Setup Failed 0 (EE) intel(0): I830 Vblank Pipe Setup Failed 0 Sometimes my machine doesn't crash: starting/stopping X without any clients works. But starting kde and then chvt usually crashes. Regards, Alexander
Created attachment 10152 [details] xorg log of kdm restart with kernel crash
I also face the same issue. I have a Dell Inspiron 1705. The kernel freezes when you logout/shutdown/change to text terminal. Sometimes I do the following to avoid it: 1. Change to text terminal before logging in from GDM. As soon as GDM login screen appears change to text terminal. 2. Come back to GDM screen 3. Login to your desktop This has worked most of the times. But it is so irritating and I no more do this and am used to kernel freeze. My system specifications are: Dell Inspriron 1705 Intel 945GM chipset Debian sid xserver-xorg 1:7.2-5 xserver-xorg-core 2:1.3.0.0.dfsg-6 xserver-xorg-video-intel 2:2.1.0-1 Linux kernel 2.6.21.1 (custom compiled with CONFIG_NO_HZ) damu@kanini:~/ABAT-20070619$ sudo lspci -vvv Password: 00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS/940GML and 945GT Express Memory Controller Hub (rev 03) Subsystem: Dell Unknown device 01cd Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR- <PERR- Latency: 0 Capabilities: [e0] Vendor Specific Information 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS/940GML Express Integrated Graphics Controller (rev 03) (prog-if 00 [VGA]) Subsystem: Dell Unknown device 01cd Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Interrupt: pin A routed to IRQ 16 Region 0: Memory at dff00000 (32-bit, non-prefetchable) [size=512K] Region 1: I/O ports at eff8 [size=8] Region 2: Memory at c0000000 (32-bit, prefetchable) [size=256M] Region 3: Memory at dfec0000 (32-bit, non-prefetchable) [size=256K] Capabilities: [90] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable- Address: 00000000 Data: 0000 Capabilities: [d0] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/940GML Express Integrated Graphics Controller (rev 03) Subsystem: Dell Unknown device 01cd Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Region 0: Memory at dff80000 (32-bit, non-prefetchable) [size=512K] Capabilities: [d0] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Created attachment 10577 [details] xorg configuration file
Here I can see that at least 3 people is getting this problem. I've also experienced something similar, but I'm blaming https://bugs.freedesktop.org/show_bug.cgi?id=11432 Maybe Alexander's(#6) problem is already solved in the 2.1 version of the intel driver. Would you be so kind to try it and comment out with the results? Everybody, in case you could and you don't mind and to test out that it's not related to #11432 please do everything with a VGA monitor attached into your laptop, this way the pipe A will stay enabled and would discard #11432 problem. When attaching a VGA monitor X will be set in clone mode so you will see same output on both monitors. If it works with an external monitor attached, it could be probably a BIOS issue.
(In reply to comment #10) > Here I can see that at least 3 people is getting this problem. I've also > experienced something similar, but I'm blaming > https://bugs.freedesktop.org/show_bug.cgi?id=11432 I've commented in bug #11432 - the laptop lid works as expected with a CRT attached, so it's probably a BIOS issue. I think this bug is a different issue, or different symptom; the chance of a system freeze (via switching VTs or restarting X) seems much more likely after a 3D application is opened compared to when no 3D application is opened in a session. Is this not a duplicate of your bug #10809, Raul?
(In reply to comment #11) > I've commented in bug #11432 - the laptop lid works as expected with a CRT > attached, so it's probably a BIOS issue. I agree as there I do. > > Is this not a duplicate of your bug #10809, Raul? > That's what I'm trying to guess. Problem is that I don't have an VGA monitor at hand.
I see this bug as well. I use Kubuntu Feisty on i386, with kdm. It happens with the 2.0.0 release of the driver, as well as with the 2.1.0 (in ubuntuforums someone posted a backport). I see it happen quite often, several times per week.
Again a comment from the original poster: After some time it started now again, currently the driver is at version 2:2.1.1-1. Same effect, screen goes into block mode (darker and lighter boxes), no response of the kernel (sysrq). Note that it is NOT happening all the time, but running compiz definitely helps ;-) Best wishes Norbert
I'm experiencing this bug as well, using both 2.1.0 and 2.1.1. I didn't experience it for a long time but within the past couple days it's beginning locking (not consistently but most of the time) when logging out to GDM, when switching to VT and when shutting down. I use a first run MacBook with a 945GM chipset. Additionally, after locking, the system restarts and GRUB is unreachable until the system is powered off and started again. My Xorg logs also contain the "Vblank Pipe Setup Failed" message.
Seán: Have you tried with Xorg 7.3 and/or xserver 1.4? Could you provide us with the Xorg log in that case? Also if you have an Dell laptop with an Intel 855 card, could you try what's advised at bug #11432? Thanks.
Created attachment 11702 [details] Xorg log with -server 1.4 Here's a log running with -server 1.4. I'm not sure how useful it will be as it doesn't appear to have any relevant information at the end. Results were the same as with -server 1.3. I've reverted to 1.3 due to unrelated problems with my touchpad driver. As stated above, this is on a first-run MacBook with a 945GM.
Any chance on progress here? I have a macbook with intel 945GM and I'm experiencing this too: blocky mess, looks like 80x25 text mode with overwritten charmap, usually gray/white, sometimes blinking. Happends about half of the time and leads to the self hard reset. I'm using xserver 1.3 with intel driver from git. How can I help?
Isn't this a duplicate of https://bugs.freedesktop.org/show_bug.cgi?id=10586 ? It is at least for me...
Here is a screenshot of the problem: http://picasaweb.google.com/yglodt/MobileUploads/photo#5098881020222810514
*** This bug has been marked as a duplicate of bug 10586 ***
I am not using a compositing window manager and I am still seeing this problem.
this problem is compositing agnostic, this patch from x.org git fixes it: http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-intel.git;a=blobdiff;h=bfc006a9fcb245cb469d73ac7816fce85d23a6b6;hp=0eb6e2db43e27d3971107c5fb623f3f0c68aeadf;hb=c94cdfd6ddbc580523737f596e97b96a7ce100b9;f=src/i830_driver.c It is definitely duplicate of #10586
I confirm that the above fixed the problem at least at the last three shutdowns. Thanks (I compiled the debian package with the patch).
Sounds like this one is fixed. Please reopen if not.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.