Mostly blank screen after x-updates merge.

[falsifian]

My X display is mostly black with some noise at the top. There is also a square of noise that follows my cursor. It seems like input is working, because when I type my username and password, my computer starts working as if to log me in.

This happens at commit f7436a9 (when x-updates was merged) and does not happen at commit 0b592ce (just before x-updates got merged). NixOS was at 6a9b855 and a4cad32 respectively when I tested those revisions.

More information forthcoming. (I have an AMD graphics card; I will look up the details.)

[falsifian]

I have a Redon HD 5450. From lspci:
01:00.0 VGA compatible controller: ATI Technologies Inc Cedar PRO [Radeon HD 5450]

[falsifian]

The contents of /var/log/X.0.log.old (corresponding to the non-working X server) are at https://gist.github.com/3924544 . Nothing jumps out at me.

[falsifian]

Commit 2fed9df, "Some X.org updates (include xorg-server to 1.12.4)", is the culprit: I can see the login screen with the previous commit, and get the blank-with-noise screen with 2fed9df. I am not sure what to do next.

[edolstra]

Not having an ATI card, I can't really help here, but you could try if you have more luck with the proprietary driver (services.xserver.videoDriver = "ati_unfree"). Alternatively, as a workaround, you can try the VESA driver (services.xserver.videoDriver = "vesa").

[aszlig]

What is your dmesg output? Are you using a KMS enabled kernel?

[falsifian]

dmsg output: https://gist.github.com/3940435

I don't know if KMS is enabled (or how to check) but https://github.com/falsifian/nixpkgs/blob/master/pkgs/os-specific/linux/kernel/linux-3.2.nix makes me think yes.
$ uname -a
Linux angel-nixos 3.2.31 #1 SMP Thu Oct 11 03:12:57 UTC 2012 x86_64 GNU/Linux
I will try building a kernel with "DRM_RADEON_KMS n" in the config file when I have time.

Information below this line is probably unrelated to this bug.

BTW, building the unfree driver fails with
/tmp/nix-build-lbkb2hdizirnhx1fr9himyr0a98bhp45-ati-drivers-10-11-x86-3.2.32.drv-0/common/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c:117:28: fatal error: linux/smp_lock.h: No such file or directory
It seems that that version of the driver is not compatible with newer kernels; see for example http://www.vultaire.net/blog/2011/08/14/using-nvidia-drivers-on-debian-squeeze-64-bit-with-backported-kernel/ . I started updating to a newer version but it's nontrivial.

Also, services.xserver.videoDriver = "vesa" didn't change anything (X still uses the radeon driver), and services.xserver.videoDrivers = [ "vesa" ] resulted in X not starting; X.0.log contains "vesa: Ignoring device with a bound kernel driver". Full X.0.log: https://gist.github.com/3940479 . I have not started trying to fix this.

[vcunat]

I can't see anything wrong in dmesg, the only suspicious line is
[ 13.464859] mtrr: no more MTRRs available
but I don't understand whether it could be connected to the problems or not.

The fglrx error really does seem like it's a wrong version for your kernel, but I don't have a clue why you're linking to nvidia issue...

It's very unlikely that you're the first one to encounter this problem (across all distros), try searching. Good luck!

[falsifian]

I meant that the nvidia issue seems to have the same root problem; sorry for the confusion. I will search away and report back in a half-day or three.

[viric]

On Tue, Oct 23, 2012 at 11:50:14AM -0700, Vladimír Čunát wrote:

I can't see anything wrong in dmesg, the only suspicious line is
[ 13.464859] mtrr: no more MTRRs available
but I don't understand whether it could be connected to the problems or not.

The fglrx error really does seem like it's a wrong version for your kernel, but I don't have a clue why you're linking to nvidia issue...

I think that MTRR is outdated in recent computers, and PAT is the more flexible
way to tell the kind of caching for memory regions. But these computers can use both
I think.

Some X drivers may still use MTRR rules update. There are kernel commandline
parameters for simplifying the MTRR table, to try to use less entries.

I don't know how much this helps. :)

Regards,
Lluís.

[vcunat]

I just noticed and merged #140
That should make the proprietary drivers work. Edit: hydra at least succeeds to build them now (only caught for some kernels at this moment).

Or maybe the referenced NixOS pull request is also needed, but I really don't feel competent to merge that one.

[falsifian]

Good news! Updating libdrm and mesa fixes the issue.

But first, a quick workaround in case anyone is having the same issue: disable KMS by passing the nomodeset kernel parameter (e.g. add extraKernelParams = [ "nomodeset" ] to configuration.nix).

Now, the real fix is to update libdrm (which requires updating mesa too [0]). I have tested [1], which is based on old commit along the x-updates branch; for a rebased version, see (2) (but it is still compiling, so I can't guarantee that it works).

I will submit a pull request once I've verified that the rebased version works, but I might not be able to do that for another 24 hours. Unfortunately, it involves rebuilding xorg: so let me know if I should make the pull request against some *-updates branch instead of master, but I personally would prefer to see it on master since X+radeon+KMS is broken without it.

Thanks to erc and MrCooper in #radon on Freenode:
< MrCooper> falsifian: looks like your problem is that xf86-video-ati was built without KMS support, which is indeed most likely due to old libdrm_radeon

[0] https://bugs.freedesktop.org/show_bug.cgi?id=50280#c3
[1] falsifian@d5f6a20
(2) falsifian@1b22b3c

[falsifian]

Update: (2) works. I will submit a pull request.

[falsifian]

#171

[falsifian]

Based on the discussion on that pull request, I've submitted a new pull request that simply rolls back the radeon driver.

#175

[peti]

Can we close this issue?

[falsifian]

Yes, thanks, #175 fixed it.