Summary: | i915GM: Pageflip completion has impossible msc | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | xorg | Reporter: | Knut Petersen <Knut_Petersen> | ||||||
Component: | Driver/intel | Assignee: | Chris Wilson <chris> | ||||||
Status: | RESOLVED WONTFIX | QA Contact: | Xorg Project Team <xorg-team> | ||||||
Severity: | normal | ||||||||
Priority: | medium | CC: | mario.kleiner, mattst88, mus.svz | ||||||
Version: | git | ||||||||
Hardware: | x86 (IA32) | ||||||||
OS: | Linux (All) | ||||||||
Whiteboard: | |||||||||
i915 platform: | i915 features: | ||||||||
Attachments: |
|
Description
Knut Petersen
2011-04-12 01:23:05 UTC
Created attachment 45505 [details]
Xorg log
Mario, can you clarify what the actual warning means? IIUC, we expected a flip to happen but the kernel returned the event for the current flip rather than the next. (In reply to comment #2) > Mario, can you clarify what the actual warning means? > > IIUC, we expected a flip to happen but the kernel returned the event for the > current flip rather than the next. It means that the pageflip completion event says the pageflip completed at a vblank count (msc) that was before the expected target_msc count. The posted messages say the flip happened 1 frame before they should have happened. Pageflips get programmed into the hardware 1 frame before the target frame, then the gpu executes the flip at the next vblank -> at the target_msc. Ideally msc == target_msc, or msc > target_msc if the deadline was missed, but msc < target_msc shouldn't ever happen. I'd expect this error message if sync of flips to the vblank is broken, so the gpu executes the flip immediatly instead of waiting for next vblank. Or the pageflip completion path is broken and signals flip completion before the hw actually completed it. The code looks correct Are these errors spurious, just during x startup? Or also when a fullscreen opengl app is run? Why do pageflips happen at all during x startup, somewhere in the middle of mode setting? -mario These errors seem to appear exactly once and only at X startup. The problem seems to be 100% reproducible with current kernels and current Xorg. The bug is still alive and 100% reproducible in the current git trees of Xorg and the kernel. The bug is still alive and 100% reproducible in the current git trees of Xorg and the kernel. When exiting a full-screen video on Youtube on my Sandy Bridge system, X seg faults after this warning. [ 36393.665] (WW) intel(0): I830DRI2FlipEventHandler: Pageflip completion has impossible msc 86687 < target_msc 86688 [ 37949.810] Backtrace: [ 37949.810] 0: /usr/bin/X (xorg_backtrace+0x28) [0x45f658] [ 37949.810] 1: /usr/bin/X (0x400000+0x63fb9) [0x463fb9] [ 37949.810] 2: /lib/libpthread.so.0 (0x7fb882f99000+0xf4d0) [0x7fb882fa84d0] [ 37949.810] 3: /lib/libc.so.6 (0x7fb881ee9000+0x7413a) [0x7fb881f5d13a] [ 37949.810] 4: /lib/libc.so.6 (cfree+0x6c) [0x7fb881f607fc] [ 37949.810] 5: /usr/lib64/xorg/modules/extensions/libdri2.so (0x7fb88036e000+0x1e7d) [0x7fb88036fe7d] [ 37949.810] 6: /usr/bin/X (0x400000+0x4cbf2) [0x44cbf2] [ 37949.810] 7: /usr/bin/X (FreeResource+0xc4) [0x44d374] [ 37949.810] 8: /usr/bin/X (0x400000+0x2ac7f) [0x42ac7f] [ 37949.810] 9: /usr/bin/X (0x400000+0x30811) [0x430811] [ 37949.810] 10: /usr/bin/X (0x400000+0x246fa) [0x4246fa] [ 37949.810] 11: /lib/libc.so.6 (__libc_start_main+0xfd) [0x7fb881f07cdd] [ 37949.810] 12: /usr/bin/X (0x400000+0x24299) [0x424299] [ 37949.810] Segmentation fault at address 0x18 [ 37949.810] Fatal server error: [ 37949.810] Caught signal 11 (Segmentation fault). Server aborting It doesn't happen every time, but it's regular enough that I'm very hesitant to full-screen a video. This is all with very recent kernel/libdrm/mesa/xserver/-intel from git. Perhaps this is a separate bug, I don't know. @Chris: I see that bug only with compositing enabled. @Matt: Please try if this happens only with the "Composite" extension enabled. Created attachment 46780 [details]
Xorg.0.log showing crash when exiting full-screen youtube video
Yes, I'm able to cause it to crash with Composite disabled. Although, with Composite disabled, no error message about pageflipping immediately preceded the crash.
@Chris: I have to correct myself: If "Composite" is enabled, I see the "impossible msc" reliably during Xorg startup. If it is not enabled, it sometimes does show up later. @Matt: I don't think that the crash is related to the "impossible msc" message. Have a look at the timestamps ... Since kernel 2.6.39 my TV (HDMI) loses the signal as soon as I start XBMC in fullscreen AND start a video (it doesn't matter which one I do first, the XBMC menu works fine). Most of the time, I get this in the Xorg.0.log in the exact moment the signal is gone. [ 693.472] (WW) intel(0): I830DRI2FlipEventHandler: Pageflip completion has impossible msc 41192 < target_msc 41193 At one time it happened without going to fullscreen and the signal was back a few seconds later. This seemed totally random to me. My other monitor (DVI) works fine while this is happening. Restarting my display manager brings back the signal. Is this somehow related or should I create a more detailed bug report about this? I already reverted back to 2.6.38.8 and the issue is gone. I'm running ArchLinux x64 on an Intel DH67GD with a Core i5 2500 and my monitor and the TV are mirrored. Actually reading the code, for a flip it is comparing the frame counter with an estimate of which frame we are expecting to see after the event completes - but not the one we explicitly ask the kernel to wait for. So just the warn itself is buggy, expecting the code to be correct. (In reply to comment #11) > Is this somehow related or should I create a more detailed bug report > about this? I already reverted back to 2.6.38.8 and the issue is gone. Shouldn't be related (or rather the first warning happens within 20ms of the modeset that triggers the error). Sorry for the delay but if you still have the issue we better tackle with a drm/intel bug. > (In reply to comment #11)
> > Is this somehow related or should I create a more detailed bug report
> > about this? I already reverted back to 2.6.38.8 and the issue is gone.
>
> Shouldn't be related (or rather the first warning happens within 20ms of the
> modeset that triggers the error). Sorry for the delay but if you still have the
> issue we better tackle with a drm/intel bug.
This has been fixed. Although I have no idea how or when (I actually completely forgot about this bug).
|
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.