that ffox interlaced graphic "effect" is the same thing I see on my t420 w/ an i915 display adapter. Firefox seems to be really good at exercising whatever the conditions are to crash X (I frequently get complete hangs that require a hard power cycle), but it's not the only thing.
I'm still really excited about accelerated gfx though ;) Looking forward to further improvements. If there're any tests I can run to collect info on this problem, let me know. -bch On 12/31/14, Chuck Silvers <[email protected]> wrote: > On Tue, Dec 23, 2014 at 04:59:07PM +0100, Havard Eidnes wrote: >> Hi, >> >> I'm running netbsd-7 code on my new Lenovo T430 laptop. I'm >> using code from November 27 at the moment, with the DRM/KMS >> kernel, and there are a few glitches: >> >> 1) Sometimes the rendering of images e.g. in a web browser >> (firefox) is mangled / "interlaced" (not sure how to best >> describe it). Sometimes causing a re-paint fixes the glitch, >> sometimes it doesn't (by the looks of it). > > I get this as well: > http://ftp.netbsd.org/pub/NetBSD/misc/chs/drm2/firefox-drm2-intel965.png > > that partcular instance was immediately after starting firefox > right after a reboot, but usually this problem doesn't happen. > there's not much that could be different from one time to the next, > the thing that seem most likely to be relevant is alignment of the data in > memory. > > >> 2) Sometimes X11 appears to hang, and I get these messages in my >> kernel message buffer: >> >> drm: stuck on blitter ring >> drm: GPU HANG: ecode 2:0x87d0fff5, reason: Ring hung, action: reset >> drm: GPU hangs can indicate a bug anywhere in the entire gfx stack, >> including userspace. >> drm: Please file a _new_ bug report on bugs.freedesktop.org against DRI -> >> DRM/Intel >> drm: drm/i915 developers can then reassign to the right component if it's >> not a kernel issue. >> drm: The gpu crash dump is required to analyze gpu hangs, so please always >> attach it. >> drm: GPU crash dump saved to /sys/class/drm/card0/error >> i915drmkms0: interrupting at ioapic0 pin 16 (pci0@pci:0000:00:02.0) >> drm: Enabling RC6 states: RC6 on, RC6p on, RC6pp off > > yea, there are quite a few problems still at this point. > > the only one I can consistently trivially trigger is by running "x11perf > -movetree". > this causes the screen to go blank and the X server to print: > > (EE) intel(0): Failed to submit batch buffer, expect rendering corruption: > Invalid argument. > > and this is logged in /var/log/messages: > > Dec 27 18:26:10 tp2 /netbsd: drm: GPU HANG: ecode -1:0x00000000, reason: > Kicking stuck wait on render ring, action: continue > Dec 27 18:26:10 tp2 /netbsd: drm: GPU hangs can indicate a bug anywhere in > the entire gfx stack, including userspace. > Dec 27 18:26:10 tp2 /netbsd: drm: Please file a _new_ bug report on > bugs.freedesktop.org against DRI -> DRM/Intel > Dec 27 18:26:10 tp2 /netbsd: drm: drm/i915 developers can then reassign to > the right component if it's not a kernel issue. > Dec 27 18:26:10 tp2 /netbsd: drm: The gpu crash dump is required to analyze > gpu hangs, so please always attach it. > Dec 27 18:26:10 tp2 /netbsd: drm: GPU crash dump saved to > /sys/class/drm/card0/error > Dec 27 18:26:12 tp2 /netbsd: drm: GPU HANG: ecode -1:0x00000000, reason: > Kicking stuck wait on render ring, action: continue > Dec 27 18:26:22 tp2 syslogd[541]: last message repeated 5 times > Dec 27 18:26:22 tp2 /netbsd: drm: no progress on render ring > Dec 27 18:26:22 tp2 /netbsd: drm: GPU HANG: ecode -1:0x00000000, reason: > Ring hung, action: reset > Dec 27 18:26:23 tp2 /netbsd: DRM error in i915_reset: Failed to reset chip: > -60 > > the only way I know to recover after that is rebooting. > I haven't been gotten anywhere investigating this yet. > > this is all on a thinkpad t61 with intel 965 graphics. > > -Chuck >
