same setup as in bug 22575:
01:00.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200 SE]
(rev 01) (prog-if 00 [VGA controller])
with upstream Linux kernel commit 5a4f13fad1ab5bd08dea78fc55321e429d83cddf
drm master branch commit de1ed01214874dcdd6116ff2587c8710d6ed4d2d
mesa master commit 5e6b593d35156a0068dc0eb3e55dec086f1cadd3
xf86-video-ati kms-support branch commit
xserver master commit 84662e40c3d4141ebb298a1ad714f75056a4ab74
progs/demos/spectex gives me only completely black window. With any mode, selectable from right-click menu.
Created attachment 27291 [details]
Spectex demo works with mesa master, commit 681ede8836746735fbb904edf89b076343507a8b (radeon: fix unsigned vs signed comparison in stencil code.)
may be this bug just duplicate #22746? I can't remember if i has compositor on or off in initial testing.
BTW, you can resolve bugs yourself. :)
Mass version move, cvs -> git
Sorry guys, after some additional testing i found new pattern for triggering this bug.
Author: Zack Rusin <email@example.com>
Date: Wed Apr 7 17:46:55 2010 -0400
draw llvm: highly reduce the compilation times for draw llvm
Author: Ben Skeggs <firstname.lastname@example.org>
Date: Fri Mar 19 10:20:09 2010 +1000
nouveau: fix annoying compiler warning
Author: Alex Deucher <email@example.com>
Date: Thu Apr 8 00:31:52 2010 -0400
radeon: don't setup Xv on rn50
1. First try kernel 2.6.32 and this stack _in UMS mode_, run glxgears (important).
2. reboot into D.R.T. kernel (2.6.34-rc3)
3. load radeon (in my config i have KMS enabled by default).
4. observe perfect spectex demo
5. power off machine.
6. wait few mins.
7. Power on machine, boot 2.6.34-rc3, rc4
8. load radeon (it will defaulted into KMS)
10. observe black screen/horizontal black bars in mesa/progs/demos/spectex
11. Verify what this effect survived warm reboots.
12. repeat "fix" described in 1, but reboot machine machine instead of powering it off.
13. Observe same persistence ("fix" survived warm reboots)
Guess i can mark bug 22575 ( [KMS] mesa demo projtex broken on rv280 ) as duplicate of this, because projtex works after same " run UMS/glxgears first" fix?
P.S.: bisecting kernel right now, hopefully will have bisect result today. But i'll also re-test with current 2.6.34-rc5 kernel (UMS mode) just in case.
Can it be some wrong-initialized register on-card? I mean KMS code write bunch of regs, but at least one of them stuck/not responded to write, and UMS "fix" just unlock this reg ? Just possible scenario, i can be completely wrong here ...
(In reply to comment #6)
> P.S.: bisecting kernel right now, hopefully will have bisect result today. But
> i'll also re-test with current 2.6.34-rc5 kernel (UMS mode) just in case.
> Can it be some wrong-initialized register on-card? I mean KMS code write bunch
> of regs, but at least one of them stuck/not responded to write, and UMS "fix"
> just unlock this reg ? Just possible scenario, i can be completely wrong here
It's probably a register that KMS is not setting. I suspect there is some state that's not getting emitted under KMS that is under UMS. When you run UMS, it sets the reg to the appropriate value, then things work under KMS.
Well, no need for 2.6.32 or something like this, 2.6.34-rc5 (current drm-radeon-testing) works just fine, as "fix" for this bug.
But UMS itself seems broken, i can't see any OpenGL output with glxgears, only black window! And killing X with ctrl-alt-bs lock mouse and keyboard, I can only power-off via ACPI button. I'll upgrade X + evdev, and if problem still there - will look for filling/updating additional bugs about this behavior.
*** Bug 22575 has been marked as a duplicate of this bug. ***
(In reply to comment #8)
> Well, no need for 2.6.32 or something like this, 2.6.34-rc5 (current
> drm-radeon-testing) works just fine, as "fix" for this bug.
> But UMS itself seems broken, i can't see any OpenGL output with glxgears, only
> black window! And killing X with ctrl-alt-bs lock mouse and keyboard, I can
> only power-off via ACPI button. I'll upgrade X + evdev, and if problem still
> there - will look for filling/updating additional bugs about this behavior.
After upgrading X server and xf86-input-evdev (recompile + install) ctrl-alt-bs works again in UMS. But black gears in UMS mode still here ... looking at other bugs, i'll try to play with various desktop sizes (800x600, etc). Sorry for adding this info here, I was mostly run KMS-only setup and hardly noticed when UMS broke ....
Black window in spectex demo still here, with 2.6.35
Created attachment 38678 [details] [review]
After some looking at r200_tcl.c I tried to replace old-style check for specular color with more modern macro. And was hit by 'spectex: radeon_cs_gem.c:181: cs_gem_write_reloc: Assertion `boi->space_accounted' failed.'
Created attachment 38679 [details]
What puzzled me most - even after i reverted my patch and tried to use another (system-wise installed) version of mesa, even with different demo - same assert hit me again. But after some time at least lodbias demo working again ....
This could be fixed in mesa master and 7.9 branch:
(In reply to comment #14)
> This could be fixed in mesa master and 7.9 branch:
It still broken, but in slightly different way:
sphere has few horizontal black stripes now. I'll add screenshot.
Created attachment 39559 [details]
screenshot of corruption
Bug is here with kernel 3.1.8, xserver 1.10.4 and git from whole stack.
Load UMS and mesa 7.5.2 to fix lighting, reboot into KMS with current mesa
and lighting is fixed... until power off:(.
I think i've found source of these lighting problems on r200 in this and other bugs. It is just a typo it seems in r200_state_init.c lit_emit()
instead of OUT_VEC it needs to be OUT_SCL:
And that fixed tcl lighting emit complitely for me on 9250 card, but of course that introduce 2 more dwords which atom complain about:
CS section size missmatch start at (r200_state_init.c,lit_emit,361) 41 vs 39
CS section end at (r200_state_init.c,lit_emit,364)
I've turned off check and it stops :), but don't know how to or where to stop it properly...
So maybe someone who read this can do that :)?
This fixes lighting bug 26809 with NWN on my rv250, but R200 untested as yet. To correct the section size mismatch, add the following before the BEGIN_BATCH_NO_AUTOSTATE() line;
dwords += 2;
Thank you very much for finding this three year old radeon rewrite bug. I assume you discerned this from cmdscl used for LIT_CMD_1 versus cmdvec used for LIT_CMD_0?
Yeah, i just see that, assume that it must be scl there then compared it with radeon state, there is setup just like that, but with correct vec/scl as i assume, so i changed it like that and that is it - tcl lighting works. Three year old typo - i deserve a medal ;).
Someone could pushed it in git.
(In reply to comment #18)
> I think i've found source of these lighting problems on r200 in this and
> other bugs. It is just a typo it seems in r200_state_init.c lit_emit()
> OUT_VEC(atom->cmd[LIT_CMD_1], atom->cmd+LIT_CMD_1+1);
> instead of OUT_VEC it needs to be OUT_SCL:
> OUT_SCL(atom->cmd[LIT_CMD_1], atom->cmd+LIT_CMD_1+1);
Should be fixed by 320d531373e7b0873f5de42f6173b986290f593f, thanks!
FWIW the command emit mechanism looks a bit too complicated it could profit from some refactoring. For instance it is still based on the fake drm_radeon_cmd_header_t structure, the scl vs. scl2 and vec vs. veclinear emits are nothing but crude hacks around limitations in that structure, even though since ums is gone there is absolutely no point in using that struct...
Section size calcs are also somewhat confusing, the sanity code (which was really great back then) is totally unused etc.
Maybe another day...
*** Bug 25883 has been marked as a duplicate of this bug. ***
*** Bug 39285 has been marked as a duplicate of this bug. ***