Created attachment 13970 [details] Xorg log showing crash at end As referenced over in Gentoo Bugzilla, https://bugs.gentoo.org/show_bug.cgi?id=201519 I can still produce crashes about twice a day using the latest version of the driver from git, as of Friday. Just like with the last release, video playback performance is greatly improved, but the unpredictable crashes outweigh the gain. Attaching my Xorg log. Let me know if I can provide any more information.
So many Gentoo users see X lockup since 2.2.0 including current git tip. It will be good if there's a steady way to reproduce.
The log file is showing an initial error state, I don't see any crash messages. Does the machine hard hang when the crashes occur? If not, can you get the log and a backtrace (intellinuxgraphics.org has bug filing hints)? Can you also attach your xorg.conf and the versions of all the packages you're using?
Created attachment 14189 [details] Xorg.conf
All interactive input with the system halts. I can still shut it off cleanly because the power button is still firing ACPI events. I haven't tried SSHing in, but unfortunately I won't have time to do that before the weekend as this is also my work computer and I can't destabilize it during the week. Current running kernel is 2.6.24, but I have had the same issue with 2.6.22. xf86-input-evdev 1.2.0 xf86-input-keyboard 1.2.2 xf86-input-mouse 1.2.3 mesa 7.0.2 mesa-progs 7.0.1 xorg-server 1.4.0.90-r3 These are all the most current packages in Gentoo unstable.
2.2.0.90 has the same issues. Unfortunately I'm still not in a location where I can remote in after the X server has locked up to get better debugging information. Also, I can't control my backlight's intensity when running with >2.1. It can't be set brighter or dimmer using the controls on my laptop's keyboard.
Please try to login remotely as soon as you can, since we'll need more info to track this one down (either a reliable way to reproduce it or a backtrace). And please file a separate bug with your backlight problem. Thanks, Jesse
Created attachment 14830 [details] dmesg output after crash
Created attachment 14831 [details] KDM crash log I think this will be the most useful of the logs I'm attaching, but I'm afraid there isn't much there even so.
Created attachment 14832 [details] System message log
Also, can you narrow down what causes the crash? Is it lid events? Display switch hotkeys? DPMS activity? VT switch? Anything reproducible?
Please provide us reproduce steps, and try current master for xv crash fix.
Same chip, and very similar things to happen; but I am able to 100% reproduce this while waking up after suspend.
Created attachment 15490 [details] xorg log that ended up with crash This happened after waking laptop after it has been suspended. [vitb@localhost ~]$ rpm -qa|grep i810 xorg-x11-drv-i810-2.1.1-7.fc8.i386
Vitaly, can you reproduce your crash with a more recent driver? Ideally the git version? See http://wiki.x.org/wiki/Development/git for information on how to build the stack if you won't want to overwrite your distro packages.
(In reply to comment #14) > Vitaly, can you reproduce your crash with a more recent driver? Ideally the > git version? See http://wiki.x.org/wiki/Development/git for information on how > to build the stack if you won't want to overwrite your distro packages. > will do after yum update will finish. Need to git-pull && rebuild `tho as well
well, I don't see the same with git version. It works kind of better, in terms of switching to console back and forth, and is actually usable. But suspend will now stick the system, at least video. Looking further, I don't see any criminal in logs. I will attach it here just in case you'll spot into something I've obviously missed. I've rebuilt just intel driver, and replaced original with make install - hope there's no need to rebuild X server.. Nothing is bitching, the only side effect is synaptics driver which stopped to respond for tapping (though scrolling and mouse movement work). Does it make sense to proceed with full (X server, DRI, etc.) rebuild in my case? I have all-in-rawhide except intel driver which is git-top.
Created attachment 15567 [details] xorg log with git-top intel driver. the log reports plenty of warnings, so maybe that's why it is flaky after resume...
Andrew and Vitaly, any updates? Vitaly, since you're running rawhide bits I suspect you're hitting a different problem from Andrew, please file a Fedora bug for that (rawhide has lots of experimental stuff that's probably to blame).
> Andrew and Vitaly, any updates? Vitaly, since you're running rawhide bits I > suspect you're hitting a different problem from Andrew, please file a Fedora > bug for that (rawhide has lots of experimental stuff that's probably to blame). I have no issues after intel driver update, suspend/resume etc working fine (or at least no lock-ups, maybe there's still blame in xorg.log, I'll check
(In reply to comment #18) > Andrew and Vitaly, any updates? Vitaly, since you're running rawhide bits I > suspect you're hitting a different problem from Andrew, please file a Fedora > bug for that (rawhide has lots of experimental stuff that's probably to blame). Thanks for checking up. Unfortunately, after three days on 2.3.0 without any problems, I had a lockup today. Oddly enough, the screen is just going black rather than crashing with the really spectacular corrupted graphics. Xorg logs are the same as before.
Created attachment 16888 [details] Another Xorg.0.log from the 2008-05-28 git version of the driver Looks like the current git still has this issue for us. Is there anything I can try to help you find the cause of this issue?
Since the logs don't give us much to go on, getting some way of reliably reproducing the crash would be the most help, ideally with a minimal environment and just an application or two that cause problems. Is that possible?
Oh, and Andrew if you try running with a recent git version of the driver and see the problem again, please post the log; we've added some debugging to help catch these problems that might give us a clue.
(In reply to comment #20) > (In reply to comment #18) > > Andrew and Vitaly, any updates? Vitaly, since you're running rawhide bits I > > suspect you're hitting a different problem from Andrew, please file a Fedora > > bug for that (rawhide has lots of experimental stuff that's probably to blame). > > Thanks for checking up. Unfortunately, after three days on 2.3.0 without any > problems, I had a lockup today. Oddly enough, the screen is just going black > rather than crashing with the really spectacular corrupted graphics. Xorg logs > are the same as before. > Hello, sorry if I'm wrong here in this bugreport but I've got a simliar X server lockup today. And as Andrew said it has a complete graphic coruption, so nothing is seen in the displays. It seems though, taht Alt+F1 followed by reboot (CTRL+ALT+DEL) workes fine, but well all my docuemnts I had open before were gone. My notebook with intel (945GM/GMS, 943/940GML) controller was running about 3 days and it seems that there is somehow a relation between X crashes and daily reboot which is really odd. I have been strugguling quite a while before I decided to look for a solution. and yes one thing more to mention - I'm not using DRI, not that I don't want to, but I use a second display and as you know it does not support more than 2048pix. So the server crashed unexpectedly as I tried to open a webpage with an applet, which I could open yesterday and also after I rebooted right after the crash. I'm pasting below a snip of the X log. If you are willing to help I'll be very thankful and if you need more information please let me know thank you in advance and kind regards (II) intel(0): I830CheckAvailableMemory: 1955836 kB available (EE) intel(0): Cannot support DRI with frame buffer width > 2048. (**) intel(0): Framebuffer compression enabled (**) intel(0): Tiling enabled (==) intel(0): VideoRam: 262144 KB (II) intel(0): Attempting memory allocation with tiled buffers. (II) intel(0): Tiled allocation successful. (II) intel(0): adjusting plane->pipe mappings to allow for framebuffer compression (II) intel(0): Page Flipping disabled (==) intel(0): Write-combining range (0xd0000000,0x10000000) (II) intel(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is 0x0000 (II) EXA(0): Offscreen pixmap area of 51609600 bytes (II) EXA(0): Driver registered support for the following operations: (II) Solid (II) Copy (II) Composite (RENDER acceleration) (==) intel(0): Backing store disabled (==) intel(0): Silken mouse enabled (II) intel(0): Initializing HW Cursor (II) intel(0): Current clock rate multiplier: 1 (II) intel(0): xf86BindGARTMemory: bind key 0 at 0x007bf000 (pgoffset 1983) (II) intel(0): xf86BindGARTMemory: bind key 1 at 0x03020000 (pgoffset 12320) (II) intel(0): Fixed memory allocation layout: (II) intel(0): 0x00000000-0x0001ffff: ring buffer (128 kB) (II) intel(0): 0x00020000-0x0061ffff: compressed frame buffer (6144 kB, 0x000000007f820000 physical ) (II) intel(0): 0x00620000-0x00620fff: compressed ll buffer (4 kB, 0x000000007fe20000 physical ) (II) intel(0): 0x00621000-0x0062afff: HW cursors (40 kB, 0x000000007fe21000 physical ) (II) intel(0): 0x0062b000-0x00632fff: logical 3D context (32 kB) (II) intel(0): 0x00633000-0x00633fff: overlay registers (4 kB, 0x000000007fe33000 physical ) (II) intel(0): 0x00640000-0x0301ffff: front buffer (42880 kB) (II) intel(0): 0x007bf000: end of stolen memory (II) intel(0): 0x03020000-0x06157fff: exa offscreen (50400 kB) (II) intel(0): 0x10000000: end of aperture (WW) intel(0): PRB0_CTL (0x0001f001) indicates ring buffer enabled (WW) intel(0): PRB0_HEAD (0xd28084fc) and PRB0_TAIL (0x00008670) indicate ring buffer not flushed (WW) intel(0): Existing errors found in hardware state. Error in I830WaitLpRing(), timeout for 2 seconds pgetbl_ctl: 0x7ffc0001 getbl_err: 0x00000000 ipeir: 0x00000000 iphdr: 0x02000011 LP ring tail: 0x00008678 head: 0x000084fc len: 0x0001f001 start 0x00000000 eir: 0x0000 esr: 0x0000 emr: 0xffff instdone: 0xfa41 instpm: 0x0000 memmode: 0x00000306 instps: 0x800f00c4 hwstam: 0xffff ier: 0x0000 imr: 0xffff iir: 0x0000 Ring at virtual 0xa7899000 head 0x84fc tail 0x8678 count 95 0000847c: 030b70b0 00008480: 02000011 00008484: 00000000 00008488: 54f00006 0000848c: 03cc0640 00008490: 01800100 00008494: 01900190 00008498: 031d51d0 0000849c: 00000000 000084a0: 00000240 000084a4: 0309c6b0 000084a8: 02000011 000084ac: 00000000 000084b0: 54f00006 000084b4: 03cc0030 000084b8: 00000000 000084bc: 00090009 000084c0: 0305fe80 000084c4: 00000000 000084c8: 00000030 000084cc: 0305ce30 000084d0: 02000011 000084d4: 00000000 000084d8: 54f00006 000084dc: 03cc0020 000084e0: 00000000 000084e4: 00010005 000084e8: 0302a010 000084ec: 00000000 000084f0: 00000020 000084f4: 03029ff0 000084f8: 02000011 000084fc: 00000000 Ring end space: 130684 wanted 131064 Fatal server error: lockup Error in I830WaitLpRing(), timeout for 2 seconds pgetbl_ctl: 0x7ffc0001 getbl_err: 0x00000000 ipeir: 0x00000000 iphdr: 0x02000011 LP ring tail: 0x00008680 head: 0x000084fc len: 0x0001f001 start 0x00000000 eir: 0x0000 esr: 0x0000 emr: 0xffff instdone: 0xfa41 instpm: 0x0000 memmode: 0x00000306 instps: 0x800f00c4 hwstam: 0xffff ier: 0x0000 imr: 0xffff iir: 0x0000 Ring at virtual 0xa7899000 head 0x84fc tail 0x8680 count 97 0000847c: 030b70b0 00008480: 02000011 00008484: 00000000 00008488: 54f00006 0000848c: 03cc0640 00008490: 01800100 00008494: 01900190 00008498: 031d51d0 0000849c: 00000000 000084a0: 00000240 000084a4: 0309c6b0 000084a8: 02000011 000084ac: 00000000 000084b0: 54f00006 000084b4: 03cc0030 000084b8: 00000000 000084bc: 00090009 000084c0: 0305fe80 000084c4: 00000000 000084c8: 00000030 000084cc: 0305ce30 000084d0: 02000011 000084d4: 00000000 000084d8: 54f00006 000084dc: 03cc0020 000084e0: 00000000 000084e4: 00010005 000084e8: 0302a010 000084ec: 00000000 000084f0: 00000020 000084f4: 03029ff0 000084f8: 02000011 000084fc: 00000000 Ring end space: 130676 wanted 131064 FatalError re-entered, aborting lockup
I just wanted to point out that this issue can be reliably triggered in about 3 minutes by running 'X11perf -all' on my Toughbook CF-19 mark 2 (Intel Corporation Mobile Integrated Graphics Controller). Anyone want me to test git patches for them? --- Xorg.0.log --- Error in I830WaitLpRing(), timeout for 2 seconds pgetbl_ctl: 0xcff80001 pgetbl_err: 0x0 ipeir: 0 iphdr: 1f407d0 LP ring tail: 7808 head: 7814 len: 1f801 start 0 Err ID (eir): 0 Err Status (esr): 0 Err Mask (emr): ffffffdf instdone: ffe5fafc instdone_1: fffff etc, etc, etc.
well, i spoke too soon. I grabbed today's git and now it's been running for 30 minutes. I'll report if it fails again.
I built the 2.3.2 release out of Gentoo Portage last night, and ran x11perf -all for over two hours without crash. I've been working for about two hours today with no problems as well. I'll give it another day or two, but things are looking good so far.
Created attachment 17236 [details] New error log from 2.3.2 Looks like I spoke too soon. I had a crash about half an hour later. Interestingly, it seemed like the server was cycling several times trying to fix itself; the screen went entirely black, but I could see the backlight cycling several times and my cursor showed up on and off. The error reported is slightly different. New log is attached.
Created attachment 17569 [details] Xorg.0.log after X crashed This is happening to me as well, while on X it happens to me randomly, usually when I click on firefox's address bar or open mplayer, X crashes but this happens to me every time I try to suspend... The Xorg.0.log after a random crash has been attached.. I solved ( or actually just a workaround ) suspending by adding what's suggested in comment #151 in bug #4353 to /usr/lib/pm-utils/module.d/kernel --snip-- --- /usr/lib/pm-utils/module.d/kernel.orig 2008-07-08 01:22:13.000000000 +0200 +++ /usr/lib/pm-utils/module.d/kernel 2008-07-08 02:24:04.000000000 +0200 @@ -10,7 +10,9 @@ if [ -c /dev/pmu ]; then pm-pmu --suspend else + cat /proc/bus/pci/00/02.0 > /var/cache/vidpci.config echo -n "mem" > /sys/power/state + cat /var/cache/vidpci.config > /proc/bus/pci/00/02.0 fi } --snip-- OS: Sabayon Linux ( Gentoo Based ) on ~x86 platform Hardware: Toshiba Satellite A135-S4427 relevant `lspci-vvv` : --snip-- 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) (prog-if 00 [VGA controller]) Subsystem: Toshiba America Info Systems Device ff02 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 16 Region 0: Memory at dc100000 (32-bit, non-prefetchable) [size=512K] Region 1: I/O ports at 1800 [size=8] Region 2: Memory at c0000000 (32-bit, prefetchable) [size=256M] Region 3: Memory at dc200000 (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, 943/940GML Express Integrated Graphics Controller (rev 03) Subsystem: Toshiba America Info Systems Device ff02 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 Region 0: Memory at dc180000 (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- --snip-- Here's the information on all relevant packages: x11-base/xorg-server-1.4.2 x11-drivers/xf86-video-i810-2.3.2 media-libs/mesa-7.0.3 sys-kernel/linux-sabayon-2.6.25-r1 Any ideas what is going on? Thanks...
Wael, so your crashes still occur even after the suspend/resume fix you mentioned? Can both of you try disabling render acceleration to see if it's the culprit? You can do that by adding Option "ExaNoComposite" "true" to your xorg.conf file in the intel driver section...
ping for response.
Thanks for the ping to remind me to post this. We have seen a dramatic decrease in this Xorg crash bug, but in our case it has nothing to do with changes in the intel driver. Our application is built on Qt4 and until recently we ran version 4.3. When we did, we saw these crashes multiple times per week. After Qt4-4.4 came out, we wanted to get some of the performance boosts that version brought us and we upgraded our development installer to use it. We immediately saw that all the crashes associated with this bug stopped. When we went back to the Qt4-4.3 version they returned. One of the key differences in the two versions is summarized here: http://labs.trolltech.com/blogs/2007/08/09/qt-invaded-by-aliens-the-end-of-all-flicker/ "As of today, every single widget in Qt has a native window that is managed by the window system — in this case the X server. The flicker you see on the movie is a result of multiple X windows trying to synchronize and play funny games with the X server." When we counted using xrestop, in version 4.3 we utilized approximately 344 X Windows and 1589 pixmaps and consumed 67MB of RAM. The same source code and screen images compiled and running with Qt4-4.4 showed 59 X Windows and 452 pixmaps and consumed 30MB of RAM. The flicker we were seeing trying to composite all those X Windows is gone. Whatever was pissing off the driver and causing the I830WaitLpRing() timeouts is also gone and I don't know why. I don't know how or even if this is even related to the issue, but maybe this info will tickle someone's brain or lead to a more repeatable scenario for testing. Anyway, I hope it helps! Tony
Anthony, thanks for the information. From the explanation, at least it doesn't sound like a driver issue.. Still need to get confirm from Andrew to see if he was using QT and if yes, can his issue be resolved by upgrading to Qt 4.4... Ping Andrew...
Well, if earlier versions of Qt were using render for acceleration the problem may have been there. Either way I think a driver crash is definitely a driver bug of some sort, unless Qt is banging on registers directly or generating batch buffers itself and submitting them... Glad to hear that things are better now though at least.
Pong, I will check to make sure I have the latest QT, X drivers, etc. and see how things go. I am a KDE user, so this makes a certain amount of sense. I'm just getting back from a long vacation, so this may take a little while.
No good, I unmasked/emerged QT 4.4 and still see the same errors I last reported.
Created attachment 18075 [details] log of crash
Created attachment 18076 [details] example of crash no 2 Hello I`ve added two examples of crashes. I have similar problem, my graphic is just getting corupted. i can switch to console alt+f1 and take reboot, but screen isn`t changing in that time. I`m using driver,mesa and drm from git [builded week ago], i have gentoo too. Also, this bug happens to me when i`m playing freeciv [builded on gtk] or when i`m surfing on opera. It`s not happen very often but is very annoying. [sorry for my english, and some mistake if i do any, this is my first post here]
Created attachment 18283 [details] Xorg.0.log: lockup from SuSE factory Xorg 1.4.99.906 00:02.0 VGA compatible controller: Intel Corporation 82G33/G31 Express Integrated Graphics Controller (rev 02) X.Org X Server 1.4.99.906 (1.5.0 RC 6) compiled for 1.4.99.906, module version = 2.4.0
This is happening to me more or less every time I start X. I have a DG45ID board with the G45 chipset. I am using Gentoo Linux. I have tried various combinations of drm, mesa, xorg-server and the intel driver. I have tried i386 and amd64. I have tried forcing XAA in addition to using the default EXA with identical results. Right now I am using kernel 2.6.26 with the drm and i915 support built and loaded as modules. I am using libdrm 2.3.1, mesa 7.1, xorg-server 1.5 and the intel 2.4.2 driver. I am using Fluxbox 1.0 as the window manager. The intent of this machine is to be a mythtv/dvd machine, so the only applications I have run (besides fluxbox) are xterm, mythtv-setup, mythfrontend and glxgears. Yesterday I was using this same set of software and was not having trouble at all. I compiled/installed mythtv and spent well over an hour using the mythtv setup and frontend applications, which are full screen applications that use mesa. Today I upgraded my kernel to 2.6.27_rc5 to see about getting support for my wireless card, only to have X stop working properly. Downgrading did not resolve the problem. I can make the server crash at this point every time I start X. Even if I have an empty .xinitrc and X tries to shut down immediately, it will crash with this error before shutting down cleanly. I have attached an Xorg.0.log and a core file from one of these crashes. It appears substantially similar to other logs attached to this bug. One other thing I notice in the Xorg log is that it is trying to use 256MB of video memory even though I have the DVMT setting in the BIOS at 128MB (Aperture size 256MB). I am not sure if this is important or not.
Created attachment 18791 [details] Core file from fatal crash xorg-server 1.5, libdrm 2.3.1, mesa 7.1, intel driver 2.4.2, kernel 2.6.26. Empty .xinitrc - normally X would shut down as soon as it started up.
Created attachment 18792 [details] Xorg.0.log from session with fatal error xorg-server 1.5, libdrm 2.3.1, mesa 7.1, intel driver 2.4.2, kernel 2.6.26. This was from a session with an empty .xinitrc - normally X would shut down immediately as soon as it started. Board is an Intel DG45ID with G45 chipset.
Will, I would suggest you to open a new bug so we could better track your issues, since you seem to be able to reproduce the crash more steadily, and with a different chipset.
I'm noticing there's still "NEEDINFO" marked. Could the reporters answer comment#30?
Actually, I upgraded to Xorg 1.5 and libdrm 2.3.1 over the weekend, and have not had a crash since then. I had already tried out the intel-2.4.2 driver before that, without much success. That's about four days of continuous use now. The only other change to my system recently is the use of a different mouse, so I have to think the culprit was somewhere in the core Xorg package, or libdrm.
(In reply to comment #45) > Actually, I upgraded to Xorg 1.5 and libdrm 2.3.1 over the weekend, and have > not had a crash since then. I spent a week fighting this bug, then wiped the system, reinstalled with the 1.5/2.3.1/2.4.2 software set and experienced 0 issues. Then I upgraded my kernel to 2.6.27_rc5 and suffered an immediate loss of X functionality. I then downgraded back to 2.6.26, but the problem did not go away. So I guess the next step is to rebuild the system again and be very rigorous about documenting everything I do, to try and identify exactly what triggers this behavior.
It seems this bug can be closed since the reporter said it's gone in comment#45.
On Wed, Sep 17, 2008 at 06:55:51 -0700, bugzilla-daemon@freedesktop.org wrote: > --- Comment #47 from Gordon Jin <gordon.jin@intel.com> 2008-09-17 06:55:49 PST --- > It seems this bug can be closed since the reporter said it's gone in > comment#45. > And then he said it came back, so maybe not.
(In reply to comment #48) > On Wed, Sep 17, 2008 at 06:55:51 -0700, bugzilla-daemon@freedesktop.org wrote: > And then he said it came back, so maybe not. Reporter here, I can't reproduce the bug any more and I think it was fixed in another library. Unless Will Saxon, who can still reproduce, speaks up, I vote to close it for the time being.
(In reply to comment #49) > (In reply to comment #48) > > On Wed, Sep 17, 2008 at 06:55:51 -0700, bugzilla-daemon@freedesktop.org wrote: > > And then he said it came back, so maybe not. > Reporter here, I can't reproduce the bug any more and I think it was fixed in > another library. > > Unless Will Saxon, who can still reproduce, speaks up, I vote to close it for > the time being. > It has happened to me since rebuilding everything again, however it is now intermittent and I can't reliably reproduce it. If this changes, I can file another bug. I am using a G45 anyway and this bug references the 945GM.
*** Bug 17238 has been marked as a duplicate of this bug. ***
Jesse, is "NEEDINFO" still valid? I guess we can close this bug since the original reporter says it's ok. Will, G45 has some additional ring lockup issue, which has been fixed in the latest code. Check the bottom of http://intellinuxgraphics.org/download.html for the addtional kernel AGP patch (and xf86-video-intel 2.5.0 release)
Created attachment 20841 [details] xorg crash log with xorg config file Hello everybody, I hope I added my attachment to a correct excising bug report, if not please tell me how I got have find out what the correct action should have be ;-p 00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03) My xorg server is sometimes crashing and I would like to give this feedback to the developers so they have some more info to make the driver more stable. Best regards, Jelle
I'm closing this bug since the original reporter says it's fixed. If other people still see similar issue, please check if it's bug#14464 or 18640, or you can file a new one.
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.