Created attachment 15174 [details] x server log i guess the recent tinkering with the ring buffer had some side effects ... :} this happens from time to time when switching vts, but is pretty much always reproducible when starting a second x server.
please refer to http://www.intellinuxgraphics.org/how_to_report_bug.html on what we usually need for a bug report. Would you add more details accordingly? thanks.
How about revert c20d78a7bc ? might be some kind of regression.
Zhenyu will fix it.
I have met some weird thing on 845G actually. Debian sid xorg-7.3 with intel 2.2.1 driver seems fine. But it looks master branch couldn't give me stable result, and gave me random hangs. Try Eric's advice to change MI_8BIT_A8 to MI_8BIT_I8 or revert Eric's workaround patch still crashed sometime. Could you try that too? As I can't 100% reproduce the crash, I don't know if I might do sth wrong. Pls help to test, thanks.
My current test is xserver-1.4 with current intel master works fine on 845G here, but xserver master will crash it. I haven't tested xserver-1.5 yet.
ok, had some questionable fun with git now. the commit to blame is 750beb9232b... Refactor memory allocation into a separate function. xserver is at master.
This is weird, as that patch doesn't change what origin memory allocation code does, but just cleanups. Are you sure that patch is culprit? how about revert Eric's workaround patch?
i tried twice, so yes, i'm fairly sure. it wouldn't be the first cleanup ever that went awry ... given that it's really reproducible only with two servers and that the buffer size pretty obviously overflows, an allocation problem doesn't seem all that unlikely.
ok, I'll try it later. So you mean in single xserver, current intel driver and xserver master can work ok? Crash only happen in multi-head X?
X :1 inside an x session on :0 doesn't exactly qualify as multi-head, if you ask me ... whatever - *seems* about correct.
Just tried again, and it seems if disable "Tiling", then it works fine. I believe there's some issue in our driver to handle tiled front buffer for older chipset.
(In reply to comment #6) > ok, had some questionable fun with git now. the commit to blame is > 750beb9232b... Refactor memory allocation into a separate function. > xserver is at master. > Oswald, that commit is not culprit, but it changed allocation behavior indeed. Original if no DRI enabled, we won't try to fit front buffer to tiled surface, and normally depends on your screen size you got untiled front buffer. (Could you paste your log in working case?) You may try to see in DRI enable case. And now we will try tiled allocation even without DRI, as exa can support tiled front buffer now. So in this case tiling front buffer on 845G seems not work, I don't know the reason yet, and it seems broken on older releases too.
Created attachment 16191 [details] log with working driver here's the requested log with the old driver and no dri. now i'll try the new one wiht dri ...
Created attachment 16192 [details] log with bad driver here's the log with the current driver and dri enabled. the bad news is: - it still crashes - glxgears exposes some z-ordering problems (or something to that effect) - basic 2d is *yet* slower the good news is: - ... actually, there is none. :( i should note that i did not upgrade the x server or any other part of x, as it didn't compile at an early point.
cannot reproduce any more. maybe bug 15807 was a dupe, in fact. no idea.
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.