Experimenting with new HD 5750 card, looking for appropriate mailing list

[Dave Witbrodt]

Alex Deucher wrote:
> On Mon, Feb 15, 2010 at 10:03 PM, Dave Witbrodt <dawitbro at sbcglobal.net> wrote:
>>   It seems like the most appropriate mailing list for that discussion
>> would be dri-users @ SourceForge.  Unfortunately, that list looks pretty
>> much dead.  There is LKML, but that seems to be more for development
>> than testing and user discussions; I'm not (yet) a developer, so I don't
>> want to add noise over there.
>>   This list is for xf86-video-radeon, but I see a thread about HD 5830
>> support here, so I thought I'd ask first.  Where is the best place for
>> me to post results (and kudos) for the people working on Evergreen support?
> 
> You've come to the right list.
 >
 > Alex

In that case, here goes.  I mentioned the following in my previous message:

 >> I built two kernels out of the drm-radeon-testing branch, and would
 >> like to share my results.

The first kernel I built worked better than the second.  I have slowly 
been learning about git over the past few years, but never had the 
opportunity to really try out merging.  Since I had recently built 
kernel 2.6.33-rc8 with Radeon DRM + KMS for my HD 4850, I decided to try 
merging drm-radeon-testing into 2.6.33-rc8!

I made a local branch off the "v2.6.33-rc8" tag, did a 'git checkout' of 
the new branch, ran a 'git merge' using the HEAD commit ID of 
drm-radeon-testing, resolved the conflicts in the one file that had 
problems (atombios.h -- they were fairly trivial), and used 'git 
archive' to prepare a tarball.  (I keep my git repositories on one 
machine [hostname="fileserver"], but use the Radeon cards on my main 
machine [hostname="desktop"]).

Results (first kernel):

1.  No KMS-radeondrmfb.  Since I had no other framebuffers built into 
the kernel, I ended up with VGA text mode.  (I have a non-X runlevel set 
up, so the boot scripts were not trying to run X.)  I didn't think to 
save 'dmesg', so I cannot provide that until I try the next round of 
experiments.

2.  X refused to use my monitor's preferred 1920x1200 resolution.  I was 
disappointed, but not surprised:  I am using Debian here, and the Debian 
Team had just released some newer packages in "unstable" and 
"experimental" for libdrm, Mesa, the X server, and the radeon driver, 
but only the radeon driver was including upstream commits from February, 
AFAIK.  I think the latest commits that Brice Goglin got into that 
version were from Feb. 1 or Feb. 2, but I see that more Evergreen stuff 
got into xf86-video-radeon in the days immediate following that. 
(Missed it by THAT much!)

Anyway, I was getting 1600x1200 instead of 1920x1200.  Using 'xrandr', I 
was able to switch modes to 1280x800, 1600x1200, and... well... it even 
lied, and let me select 1920x1200 without error messages, but was only 
giving me 1600x1200.  (My monitor has an information feature that 
displays current mode setting using on-screen display.)

I think we would all be wise to ignore what I'm reporting about X, 
though; the 2.6.33-rc8 kernel was giving me the following warning with 
those Debian packages:

     radeon: You have old & broken userspace please consider updating
     mesa & xf86-video-ati

(This morning before work I started building updated libdrm and Mesa 
from git; when I got home, I built a much newer X server and 
xf86-video-ati.  I can try these new packages on Friday.)

3.  Switching to a virtual terminal with Ctrl-Alt-F1 gave me a black 
screen; going back to X with Alt-F7 worked fine, though.


Thinking that I had outsmarted myself by getting fancy with the merging 
against 2.6.33-rc8, I decided to build the 2.6.32 kernel the way it 
appears in drm-radeon-testing.

Results (second kernel):

1.  Black screen in the virtual terminals

2.  Black screen when switching runlevel to X.

This left my head shaking.  I never would have guessed that my playing 
around with merging to 2.6.33 would actually work better than a kernel 
compiled directly from the experimental git tree!

My main concern is that KMS failed to work with either kernel.  Or does 
the black screen mean that 2.6.32 was trying to work (and failing) while 
the merged 2.6.33 wasn't even doing that well?

Once again, I didn't think to save 'dmesg'.  When the 2.6.33 kernel 
didn't seem to be working, I uninstalled it, deleted the DEB I had made, 
and even blew away my local git branch where I had performed the merge. 
  Later, I wished I hadn't done that!  However, for the 2.6.32 kernel, I 
still have the kernel config I used as well as Xorg.0.log output, if 
anyone wants to look at them.  (I can easily redo the merge to 
2.6.33-rc8, and will probably do so on Friday.)

In spite of the black screens, I believe the system was functioning just 
fine.  I was able to log in blind, and switch runlevels with 'telinit' 
to start X.  The hard disk activity led me to believe X was starting up, 
and later I was able to recover the Xorg.0.log file, which actually 
doesn't look too bad in terms of indicating errors or problems.

My attitude was not very serious during all of these experiments:  I 
just thought I'd give it a try to see how well it would work.  Since my 
HD 4850 now works perfectly with any software I throw at it, I decided 
to remove the HD 5750 so that I have a usable machine during the work week.

This Friday I can easily log into the "desktop" machine via SSH and get 
'dmesg', Xorg.0.log, and any other data of interest.  I even bought a 
serial port bracket for my motherboard several weeks ago, in case I ever 
needed to troubleshoot a crashing kernel.  Neither of these kernels 
crashed or hung, but there may be messages going to the screen that do 
not get recorded in 'dmesg' or anything in /var/log.  Like with git 
merging, I've never used the serial console feature before, so I look 
forward to giving it a try.

I welcome suggestions, requests for information, and more code to test! 
  Just let me know.


Sincere thanks,
Dave W.