Created attachment 101154 [details] Xorg.0.log of the failure After package update from xf86-video-intel 2.99.911-2 to xf86-video-intel-2.99.912-1 X doesn't start anymore. Downgrading solves the issue. Not sure if this chip is even still supported (?). lspci -v ~~~ 00:02.0 VGA compatible controller: Intel Corporation 82830M/MG Integrated Graphics Controller (rev 03) (prog-if 00 [VGA controller]) Subsystem: Hewlett-Packard Company Device 0021 Flags: bus master, fast devsel, latency 0, IRQ 9 Memory at e8000000 (32-bit, prefetchable) [size=128M] Memory at e0000000 (32-bit, non-prefetchable) [size=512K] Expansion ROM at <unassigned> [disabled] Capabilities: [d0] Power Management version 1 Kernel driver in use: i915 Kernel modules: i915 ~~~ Thanks
Stop overriding the AccelMethod for starters.
You can check which test is causing the failure with: commit 8f0fc2ed4cc19c90dd2f519080915ca0c54e1baf Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Mon Jun 16 10:27:16 2014 +0100 uxa: Add some explanation to why bo were rejected References: https://bugs.freedesktop.org/show_bug.cgi?id=80088 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Created attachment 101165 [details] new Xorg.0.log w/ test output
"Stop overriding the AccelMethod for starters." Ah, that fixes it! Originally I had done this because of this: https://wiki.archlinux.org/index.php/IceWM#No_start_menu_icon_.28Intel_graphics.29 Now, I just checked the latest git build (g10cb36e..) fixes that (using sna). Though it seems to introduce other problems (complete crash black screen, complete freeze of the system) when resizing windows... See the test result in the new log. Thanks, Regards
Created attachment 101167 [details] [review] Make uxa "happy" again on gen2/3
(In reply to comment #4) > Now, I just checked the latest git build (g10cb36e..) fixes that (using sna). > Though it seems to introduce other problems (complete crash black screen, > complete freeze of the system) when resizing windows... Hmm, they are GPU hangs. There has been one report that 830g doesn't handle snooped memory very well. If you can grab the error state from when it is complete black that would help.
commit 4ab99d67990d5834061a10b0bd1dd220d4611248 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Mon Jun 16 12:51:08 2014 +0100 uxa: Allocate frontbuffer to meet old fence constaints libdrm is a little lax and does not allocate sufficient space for us to safely use buffers on old gen. So compute the size we want for ourselves. Reported-by: Cem Aydin <cem.aydin@gmx.ch> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80088 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> that should fix the first bug. Please do file a bug for the sna crash. If you can get an error-state, that would be great, otherwise I can ask you test a few flags.
uxa is happy again! Tested as of e5b94c2d.. I'll see what I can do for the sna-crashes. Thanks again.
Marking as RESOLVED FIXED. (missed that on above comment)
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.