Bug 57567

Can you bisect?  Please also attach your xorg log and dmesg output.

Created attachment 70606 [details]
3.5.0 dmesg

Created attachment 70607 [details]
3.7 dmesg

Created attachment 70608 [details]
Xorg log on 3.5 kernel

Created attachment 70609 [details]
Xorg log on 3.7 kernel

Added logs with 3.5 kernel (where it works fine) and 3.7 kernel

videocard - 6870, 1920x1080 display.

Video of what's happening - http://www.youtube.com/watch?v=-m3geT3RMXM&feature=g-upl

Could this be related to bug 56139? Description is similar to what is shown in recorded boot process videos.

In fact, Vladimir, could you edit your grub entry and see if there is "set gfxpayload=keep". If so, change it to "set gfxpayload=text" or remove the line completely. If it solves your boot issue, this would be a start. Could you also test suspend/resume if it fixes your boot process?

From your posted video, I'm pretty sure this is what I also see in bug 56139. You could check if the same commit shows up to be the culprit.

I disabled that line (here it was inside a function) before commiting this bug, due to another, probably ubuntu-specific bug - https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1069452

Some news which makes it easier to isolate the bug

ubuntu updated kernel to 3.5.0-22 and bug appeared on this kernel
3.5.0-21 - no bug

looks like they added some upstream changes.

here is list of changes 21 to 22 from their deb pkg for kernel - http://pastebin.com/4uUWUtLV

this looks like it may be a duplicate of bug 59431.

I found the exact commit that causes this bug

http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-quantal.git;a=commit;h=8f53b5444a25b5be3bfe0164316f9bc7845279c9

drm/radeon: properly handle mc_stop/mc_resume on evergreen+ (v2)

BugLink: http://bugs.launchpad.net/bugs/1091251

commit 62444b7462a2b98bc78d68736c03a7c4e66ba7e2 upstream.

- Stop the displays from accessing the FB
- Block CPU access
- Turn off MC client access

This should fix issues some users have seen, especially
with UEFI, when changing the MC FB location that result
in hangs or display corruption.

v2: fix crtc enabled check noticed by Luca Tettamanti

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[ herton: adjust context ]
Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>

Hope you guys can fix it

Does this patch help?
http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-fixes-3.8&id=bb588820ef421c6098dca1fec29c3b347f1c8c19

No, that doesn't fix it. still the same

Does adding:
udelay(100);
at the end of evergreen_mc_stop() help?

didn't help either


btw, reverting that commit(62444b7462a2b98bc78d68736c03a7c4e66ba7e2) fixed 3.8-rc5 for me. finally ogl 3.0 :D

A patch referencing this bug report has been merged in Linux v3.8-rc7:

commit ed39fadd6df01095378e499fac3674883f16b853
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Thu Jan 31 09:00:52 2013 -0500

    drm/radeon/evergreen+: wait for the MC to settle after MC blackout

That patch didn't help ass I wrote earlier.

The only thing that helps 3.7/3.8 kernel is reverting 62444b7462a2b98bc78d68736c03a7c4e66ba7e2 commit

Created attachment 77383 [details] [review]
possible fix

Does this kernel patch (against 3.9) help?

Created attachment 77406 [details]
new dmesg with drm.debug=14

It's a little bit better now, framebuffer is always shifted. (previously framebuffer usualy was lost, or messed up). it's 3.9-rc5 + patch

I've also tried 3.8.5+patch, and saw no difference to just 3.8.5, just saying.

Created attachment 77407 [details]
screenshot of 3.9

screenshot of what happens

I've just tested vanilla 3.9-rc5, to be sure that it's actually your patch that make things a little bit better, not 3.9 kernel itself.

unpatched 3.9-rc5 - same ersult as 3.7/3.8 kernel, so yeah, it's definetly a patch.

(In reply to comment #21)
> Created attachment 77407 [details]
> screenshot of 3.9
> 
> screenshot of what happens

I don't have a picture as neat as yours. I also saw a change in the display, but my display is flickering after the first few vertical lines (only the first few lines are stable, but they are still shifted as in your screenshot).

Created attachment 77441 [details] [review]
updated patch

Does this patch work any better?

I have strange results

few notes first, 3.8-ati is 3.8.5 kernel + reverted 62444b7462a2b98bc78d68736c03a7c4e66ba7e2

3.9-rc5_patched is  3.9-rc5 with your latest patch

3.8 - ubuntu vanilla 3.8.5

so, here is all results:

1) cold boot, boot 3.9-rc5_patched - same screen as with 3.8 (bad)
2) boot macosx, reboot, boot 3.9-rc5_patched - same screen as with 3.8
3) boot 3.8-ati, reboot, boot 3.9-rc5_patched - result like on previous screenshot I've posted, horizontal shift is always different 

I didnt test 3.9 with your first patch with all cases.

Ah, and without patch it is always same as with 3.8.
So patch matters.

Created attachment 77602 [details] [review]
updated patch

Does this variant work any better?

Created attachment 77625 [details]
New screenshot

It actually became worse, hard to replicate scenario with shifted screen(most of time looks like 3.8), and then it panics on reboot. Sshot of panic attached.

Created attachment 77705 [details] [review]
possible fix

Does this patch help?

Created attachment 77706 [details] [review]
additional fix

Apply this along with attachment 77705 [details] [review].

(In reply to comment #30)
> Created attachment 77706 [details] [review] [review]
> additional fix
> 
> Apply this along with attachment 77705 [details] [review] [review].

Using a Cayman 6950 with both patches didn't help over here. Tried two times, two times where the screen was shifted (like in Vladimir's screenshot). First time flickering, second only shifted.

Created attachment 77743 [details] [review]
additional fix

Try this one in addition to the previous two (apply all 3).

Tried all three patches, still same, shifted after 3.8-ati reboot.

and same as 3.8 after cold start.

btw, am I supposed to apply it against 3.9-rc5 or 3.9-rc6, or it doesn't matter ?

(In reply to comment #33)
> btw, am I supposed to apply it against 3.9-rc5 or 3.9-rc6, or it doesn't
> matter ?

Doesn't matter.

Are there any "frame never updated!" messages in your dmesg with the patches applied?

Created attachment 77761 [details]
dmesg with 3 patches

Looks like there is none.

dmesg from boot with sshifted screen.

When the display is shifted, does a dpms cycle fix it?

How to do dpms cycle ?

(In reply to comment #38)
> How to do dpms cycle ?

On the console, just wait for the screen to blank.  In X:
xset dpms force off
will force a dpms cycle.

(In reply to comment #39)
> (In reply to comment #38)
> > How to do dpms cycle ?
> 
> On the console, just wait for the screen to blank.  In X:
> xset dpms force off
> will force a dpms cycle.

That would valid if we were able to log in X. Is there a way to do it if we are still in the console?

(In reply to comment #40)
> (In reply to comment #39)
> > (In reply to comment #38)
> > > How to do dpms cycle ?
> > 
> > On the console, just wait for the screen to blank.  In X:
> > xset dpms force off
> > will force a dpms cycle.
> 
> That would valid if we were able to log in X. Is there a way to do it if we
> are still in the console?

I think you can adjust the console blanking with setterm.  Can you start X and force a dpms cycle even if the screen is garbled?

(In reply to comment #41)
> (In reply to comment #40)
> > (In reply to comment #39)
> > > (In reply to comment #38)
> > > > How to do dpms cycle ?
> > > 
> > > On the console, just wait for the screen to blank.  In X:
> > > xset dpms force off
> > > will force a dpms cycle.
> > 
> > That would valid if we were able to log in X. Is there a way to do it if we
> > are still in the console?
> 
> I think you can adjust the console blanking with setterm.  Can you start X
> and force a dpms cycle even if the screen is garbled?

X starts, but I'm never getting to the log screen. Once X is started, if I go into console and come back, only my mouse pointer is being displayed correctly, the background stays as what was in the console. I suppose something is hanging or crashing X.

Exactly same happens here

Does disabling acceleration help?

Option "NoAccel" "True"

In the device section of you xorg.conf

(In reply to comment #44)
> Does disabling acceleration help?
> 
> Option "NoAccel" "True"
> 
> In the device section of you xorg.conf

I was able to log in, launch "xset dpms force off". My screen turned off. After waking it up, the display was still shifted.

Created attachment 77808 [details] [review]
temporary workaround

Apply this on top of the previous patches.  It's a hack to workaround the issue until I can sort out what is going on with the hw guys.

That works.

Will any of these four patches land in 3.9 kernel ?

(In reply to comment #47)
> That works.
> 
> Will any of these four patches land in 3.9 kernel ?

Possibly.  I'm hoping to get hear back from the hw guys early next week to see if I can get teh existing code to work as it's supposed to.  If not, I'll just send these patches upstream for now.  If they don't make 3.9 final, they'll show up via the stable kernel stream.

Vladimir, do you see a page fault in your dmesg after applying the four patches? Something that would look like:
[    8.727726] AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0 domain=0x0016 address=0x000000f800041000 flags=0x0010]
[    8.727737] AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0 domain=0x0016 address=0x000000f800042400 flags=0x0010]
[    8.727750] AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0 domain=0x0016 address=0x000000f800041040 flags=0x0010]
[    8.727753] AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0 domain=0x0016 address=0x000000f800041080 flags=0x0010]
[    8.727756] AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0 domain=0x0016 address=0x000000f800041240 flags=0x0010]
[    8.727759] AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0 domain=0x0016 address=0x000000f8000410c0 flags=0x0010]
[    8.727762] AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0 domain=0x0016 address=0x000000f800041280 flags=0x0010]
[    8.727764] AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0 domain=0x0016 address=0x000000f800041100 flags=0x0010]
[    8.727767] AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0 domain=0x0016 address=0x000000f8000412c0 flags=0x0010]
[    8.727770] AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0 domain=0x0016 address=0x000000f800041140 flags=0x0010]


Alex, is this expected for the workaround?

Created attachment 77915 [details]
Page Fault with four patches applied

AMD-Vi -> IO PAGE FAULTS in dmesg when using 3.9-rc6 with the four patches applied (77705, 77706, 77743, 77808).

(In reply to comment #49)
> 
> Alex, is this expected for the workaround?

No.  So it appears turning off the displays doesn't help either :/

I don't have these messages, all is quiet here with 3.9-rc5 + 4 patches.

6870

(In reply to comment #51)
> (In reply to comment #49)
> > 
> > Alex, is this expected for the workaround?
> 
> No.  So it appears turning off the displays doesn't help either :/

Well, it does help: the screen switches from GRUB to kernel correctly set (displaying the console), then the screen flashes for a moment (one white flash instead of one blue flash when the reported bug happens), comes back to normal in console (where there is now the AMD-Vi IO PAGE FAULT messages) and continues to work even after Xorg is started.

A difference between Vladimir and I is we don't have the same video card (6950 over here).

Just tested with 6970, still fine, no AMD-Vi messages in dmesg.

I have gfxmode/gfxpayload commented out from grub.cfg, maybe that's the difference between your and mine setups.

(In reply to comment #54)
> Just tested with 6970, still fine, no AMD-Vi messages in dmesg.
> 
> I have gfxmode/gfxpayload commented out from grub.cfg, maybe that's the
> difference between your and mine setups.

Maybe, I'll test it later then. After all, I do have gfxmode and gxpayload used in my grub.cfg.

I have a panic back on reboot tho, same as in https://bugs.freedesktop.org/attachment.cgi?id=77625

(In reply to comment #55)
> (In reply to comment #54)
> > Just tested with 6970, still fine, no AMD-Vi messages in dmesg.
> > 
> > I have gfxmode/gfxpayload commented out from grub.cfg, maybe that's the
> > difference between your and mine setups.
> 
> Maybe, I'll test it later then. After all, I do have gfxmode and gxpayload
> used in my grub.cfg.

Even with gfxpayload=text (which is working correctly without all the patches), I still have the AMD-Vi IO PAGE FAULT messages.

Created attachment 77999 [details] [review]
temporary workaround v2

Try this patch as a replacement for attachment 77808 [details] [review].  Do you still get the iommu errors?

Created attachment 78000 [details] [review]
temporary workaround v3

argh.  typo in that one.  try this one as a replacement instead.

(In reply to comment #59)
> Created attachment 78000 [details] [review] [review]
> temporary workaround v3
> 
> argh.  typo in that one.  try this one as a replacement instead.

After fixing the patch (it was not applying correctly on the previous three patches 77705, 77706 and 77743) and recompiling, it seems to fix the error.

Created attachment 78081 [details] [review]
one more test

One more thing to try.  Can you try this patch on top of the previous patches (attachment 77705 [details] [review], attachment 77743 [details] [review], attachment 78000 [details] [review]).

Created attachment 78090 [details] [review]
another test

Please also try this patch on top of only attachment 77705 [details] [review].  No other patches.

(In reply to comment #62)
> Created attachment 78090 [details] [review] [review]
> another test
> 
> Please also try this patch on top of only attachment 77705 [details] [review]
> [review].  No other patches.

Both patches don't fix anything over here. They do pretty much as if nothing was applied.

Any of the patchs pushed in drm-next? I've been playing with drm-next since yesterday and display is running fine when setting GRUB_GFXPAYLOAD_LINUX=keep at GRUB's launch.

(In reply to comment #64)
> Any of the patchs pushed in drm-next? I've been playing with drm-next since
> yesterday and display is running fine when setting
> GRUB_GFXPAYLOAD_LINUX=keep at GRUB's launch.

Yes.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/amd/issues/314.