Toby Corkindale <toby@dryft.net> writes:
OTOH, I've noticed a weird artefact where sometimes -- especially just after booting? -- the screen's blank areas aren't cleared properly. e.g. doing dmesg then ^L in xterm, the dmesg output is still there except at the very top and bottom. Or unmapping the xterm, and the xterm is still there until I make ratpoison popup a dialog in the corner.
Hmm, nope, never seen that on mine.
I think I know why. I *think* I'm only seeing this behaviour after a kexec reboot, *not* after a cold power off/power on. That means the issue is probably related to the GPU not being reset properly. Aha! When this occurs, I get this in dmesg (other lines elided): [ 3.1] [drm] Initialized drm 1.1.0 20060810 [ 3.1] [drm] Memory usable by graphics device = 2048M [ 3.1] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 3.1] [drm] Driver supports precise vblank timestamp query. [ 3.2] fbcon: inteldrmfb (fb0) is primary device [ 4.8] [drm] Enabling RC6 states: RC6 on, RC6p off, RC6pp off [ 4.9] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device [ 4.9] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0 [13.8] [drm] stuck on render ring [13.8] [drm] GPU crash dump saved to /sys/class/drm/card0/error [13.8] [drm] GPU hangs can indicate a bug anywhere in the entire gfx stack, including userspace. [13.8] [drm] Please file a _new_ bug report on bugs.freedesktop.org against DRI -> DRM/Intel [13.8] [drm] drm/i915 developers can then reassign to the right component if it's not a kernel issue. [13.8] [drm] The gpu crash dump is required to analyze gpu hangs, so please always attach it. That'd be why I couldn't find that dmesg this morning -- it was a cold boot.