| Summary: | Corrupted X with Radeon/KMS on DEC Alpha | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | xorg | Reporter: | Matt Turner <mattst88> | ||||||||||||||||||
| Component: | Driver/Radeon | Assignee: | xf86-video-ati maintainers <xorg-driver-ati> | ||||||||||||||||||
| Status: | RESOLVED FIXED | QA Contact: | Xorg Project Team <xorg-team> | ||||||||||||||||||
| Severity: | normal | ||||||||||||||||||||
| Priority: | medium | ||||||||||||||||||||
| Version: | git | ||||||||||||||||||||
| Hardware: | Alpha | ||||||||||||||||||||
| OS: | All | ||||||||||||||||||||
| Whiteboard: | |||||||||||||||||||||
| i915 platform: | i915 features: | ||||||||||||||||||||
| Attachments: |
|
||||||||||||||||||||
Created attachment 28453 [details]
Xorg.0.log
Created attachment 28454 [details]
dmesg
Created attachment 28455 [details]
xorg.conf
Can you attach a screenshot? Created attachment 28488 [details]
Screenshot of corruption
I grabbed the screenshot with xwd, but it is not representative of how the corruption actually appears on screen. For instance
- in the screenshot, the background is garbage, but on the screen, it's just black (which I think is normal)
- text appears in the screenshot, whereas no text appears on the screen
- the borders are corrupted in the screenshot, but they are drawn file on the screen
The three red lines mentioned before turned out to be the totally-corrupted cursor.
Turning on SWcursor causes the cursor to not be drawn at all. Option "EXANoComposite" "true" causes all text on the xdm login screen to not be drawn. Option "EXANoUploadToScreen" "false" causes more corruption.
Dave suggested on IRC last night that it may be either a cache problem or an oversight with page sizes.
Notes: (1) Page size on Alpha is 8K. (2) Alpha is extremely relaxed with memory ordering (see Documentation/memory-barriers.txt in the kernel), and (3) Alpha is entirely cache coherent by design.
Additionally, glxinfo reports that hardware acceleration via DRI2 is functional. glxgears renders perfectly at between 350~500 FPS. (In reply to comment #5) > I grabbed the screenshot with xwd, but it is not representative of how the > corruption actually appears on screen. Sounds like maybe there's a problem with the CRTC palette, in addition to incorrect rendering. > Notes: (1) Page size on Alpha is 8K. That sounds like a likely lead - there's probably lots of places which assume 4K. Created attachment 33205 [details]
Xorg.0.log
X log showing nothing interesting...
Created attachment 33206 [details]
Screenshot of corruption
As you can see, the corruption has gotten better. That is, it's not as bad as it was.
X is still dead. The hw cursor is a corrupted block in the middle of the screen that doesn't move at all. Windows don't get focus. No keyboard response.
I checked /proc/cpuinfo before and after running startx. There were 15 kernel unaligned accesses before (almost undoubtedly from drm/radeon/kms) and 63 after. This needs some serious attention, but I guess is a separate issue.
Using mesa, libdrm, xf86-video-ati, xserver from git, and drm-radeon-testing.
Does it work if you start X with the NoAccel option set to true? Created attachment 33223 [details]
Screenshot with NoAccel true
With Option "NoAccel" "true" the screen is still horribly corrupted, but the screenshot taken with xwd shows zero corruption.
X appears totally unresponsive to mouse/keyboard.
Screenshots here: http://mattst88.com/alpha-x11/ Without NoAccel, screenshot and screen look screwy (and identical?) With NoAccel, screenshot looks normal, but only corrupted cursor appears on screen. XAA looks same as without NoAccel. SWcursor causes no cursor to be drawn on the screen. Got mouse working by killing off most of xorg.conf. Created attachment 46784 [details] [review] Patch to fix DRM and Radeon/TTM on alpha Patch by Jay Estabrook. Tested by me and others. (In reply to comment #13) > Created an attachment (id=46784) [details] > Patch to fix DRM and Radeon/TTM on alpha > > Patch by Jay Estabrook. Tested by me and others. Send this to dri-devel and Dave if you want to get it merged. (In reply to comment #14) > (In reply to comment #13) > > Created an attachment (id=46784) [details] [details] > > Patch to fix DRM and Radeon/TTM on alpha > > > > Patch by Jay Estabrook. Tested by me and others. > > Send this to dri-devel and Dave if you want to get it merged. Yep, will do. Just trying to get the patch's author to learn git and send it himself before I do it for him. :) Review of attachment 46784 [details] [review]: Won't the DRM core changes break UMS? The radeon TTM changes also seem rather hackish, might be better to handle this more explicitly in radeon or possibly even TTM itself. Would probably be a good idea to make sure Thomas Hellström is in the loop as well for reviewing this. This was fixed almost a year ago in commit ffb57c4b8612c31204b06713770f6df4b8a94e4f. Whoops. :) |
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.
==Software== Kernel: airlied's drm-2.6.git, branch drm-radeon-kms, b4a033e3c9200a8d8946ff8eb802f93258caa45a libdrm: d74c67fb13d8c3e8c2e5968d827285d147a5dfc0 mesa: 483a7916d1c93d1edf125dc671dcfbff42a9fc5e xserver:93d9646c713336e03c135204c061f561d3654e23 radeon: cd99d9f0d715f1f74de4fe22f2fd30046f2c7568 ==Hardware== UP1500 Alpha PCI Radeon X1550, 256MB RAM Radeon KMS works, no problems. See attached dmesg. Starting X also works, no errors reported in attached Xorg.0.log, but a lot of graphical corruption exists. For instance, all text is unreadable, and there are three transparent red bars less than 100px wide in the middle of the screen.