Re: [Bugme-new] [Bug 13869] New: Radeon framebuffer (w/o KMS) corruption at boot.

(switched to email.  Please respond via emailed reply-to-all, not via the
bugzilla web interface).

(lots of cc's added)

On Wed, 29 Jul 2009 16:45:00 GMT
bugzilla-daemon@bugzilla.kernel.org wrote:

http://bugzilla.kernel.org/show_bug.cgi?id=13869

           Summary: Radeon framebuffer (w/o KMS) corruption at boot.
           Product: Drivers
           Version: 2.5
    Kernel Version: 2.6.31-rc4-198-g7d3e91b
          Platform: All
        OS/Version: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: Bluetooth
        AssignedTo: drivers_bluetooth@kernel-bugs.osdl.org
        ReportedBy: 1i5t5.duncan@cox.net
        Regression: No


I have an older rv280 Radeon 9200 SE AGP, dual CRTC, DVI + VGA (plus
unconnected TV-Out).  To it I have connected dual 1920x1200 monitors, one each
to the DVI and VGA out ports.

I run the radeon framebuffer in native 1920x1200 mode at the text console, and
haven't yet enabled KMS.

I've noted that for most of the 2.6.31 cycle, thru rc4-198-g7d3e91b pulled just
this morning, at boot, sometimes both monitors come up fine, sometimes the VGA
connected monitor comes up fine in framebuffer, while the DVI connected monitor
has the characteristic larger print stair-step scramble of unmatched hardware
and software resolution.  Normally, they come up as clones of each other.

I strongly suspect that the changes introducing Radeon KMS (even tho I don't
have it enabled) disrupted the hardware mode reset of the DVI CRTC, such that
it stays in whatever mode grub or early-boot uses, before the framebuffer mode
switch.  The VGA CRTC switches just fine, thus allowing me to actually see what
I'm doing on it, login, do whatever, startx, etc.  I'm guessing the code now
only checks for and resets one of the CRTCs instead of both of them, as it did
before.   It's only when I startx and its mode switches kick in that the DVI
connected monitor gets reset to normal, after which I can VT-switch back to a
text VT, and they both come up fine.  However, before starting X, simply
switching between text/framebuffer mode VTs doesn't unscramble the DVI
connected one.

However, sometimes it works just fine.  I /think/ it has something to do with
whether it's a cold startup, or a warm C-A-D based reboot, possibly with whever
mode it was in before the reboot as a triggering factor.  Whatever.  I've not
been able to pin that angle down specifically.  But that, combined with other
factors including the post-hibernate load bug (bug 13750, see there for much
more detail on my system, hardware, kernel config, compiler, etc) that was just
fixed prior to rc4, meant that every time I was about ready to file a bug, it
seemed to go away, only to return a bit later.

I can git bisect this if necessary, but hopefully the above is sufficient to
nail it, as I have my hands full with a problematic kde4 upgrade ATM.

I don't actually see any post-2.6.31 commit to drivers/video/aty/ which
could be attributed to KMS-related things.  Perhaps the change lay
elsewhere in the tree?

Yes, I suspect that a bisect would be useful, thanks.

I'll tentatively reassign this bugzilla report to DRI (how'd it get
assigned to bluetooth??).  I shall mark it as a regression and shall ask
Rafael to add it to his (large) list.  I assume that it's a post-2.6.30
regression.



------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july