Issue with 3.8.0-0.rc5.git2.1.fc19 and rv280 based video card

[Bruno Wolff III]

On Wed, Jan 30, 2013 at 22:46:55 -0600,
    Bruno Wolff III <bruno at wolff.to> wrote:
>I tried 3.8.0-0.rc5.git2.1.fc19 on three systems. One without X, one 
>using an rv530 based video card and one using an rv280 based video 
>card. The system using the rv280 based card has either extremely slow 
>graphics or busted graphics. The other two seem to function normally. 
>On the rv280 based system it takes longer than normal to sort of get 
>the gdm screen up. It comes up without the background graphic and 
>when I click on the user it doesn't seem to return a password prompt 
>in a reasonable time. C-A-F2 still works and I can use a vt normally. 
>In one case when I switched back I saw the background image. So it 
>may be that video is just running really slow.
>
>Things work OK with 3.8.0-0.rc5.git1.1.fc19.
>
>When there is a nodebug version of that kernel out, I'll try it to 
>see if it is the ATOMIC_SLEEP debugging or some other change in the 
>kernel causing the problem.

I did some more testing on this. It doesn't appear to be debug related as 
things still don't work with 3.8.0-0.rc5.git2.2.fc19. Things also don't 
work with 3.8.0-0.rc5.git3.1.fc19. I'll test rc6 once the build finishes.

I noticed that the rtkit-daemon service fails to start on the same kernels 
that I have X problems with.

I started the graphical.target on the system that I normally don't, and found 
that gdm/shell fails when using the same problem kernels (Though gdm has 
some other issue with entering the password with 3.8.0-0.rc5.git1.1.fc19. But 
that problem may go back a long way as I don't normally use graphical logins.)
and that rtkit-daemon also has issues there. This machine has an nv28 based 
video card.

The systems that have problems are both i686 (anthlon MP and an old Xeon) and 
the machine without problems is x86_64 (xeon). So it is looking more like an 
i686 issue, rather than a video driver issue.

I also checked that 3.8.0-0.rc5.git1.1.fc19 was built with gcc 4.8, so it 
probably isn't an issue with the change from gcc 4.7 to 4.8.