Re: linux-next: Tree for December 17 (Radeon DRM BUG)

[Dave Airlie <airlied@redhat.com>]

On Thu, 2008-12-18 at 23:09 +0100, Bartlomiej Zolnierkiewicz wrote:
> tOn Thursday 18 December 2008, Dave Airlie wrote:
> > On Thu, 2008-12-18 at 20:00 +0100, Bartlomiej Zolnierkiewicz wrote:
> > > On Thursday 18 December 2008, Dave Airlie wrote:
> > > > On Thu, Dec 18, 2008 at 10:14 AM, Kevin Winchester
> > > > <kjwinchester@gmail.com> wrote:
> > > > > Stephen Rothwell wrote:
> > > > >>
> > > > >> Hi all,
> > > > >>
> > > > >>
> > > > >
> > > > > I get the following BUG in the radeon drm code with today's linux-next when
> > > > > I run "startx".  I have not built or tested linux-next in a while, but the
> > > > > problem definitely does not occur in mainline.
> > > 
> > > [...]
> > > 
> > > This reminds me that drm tree in linux-next still results in BSOD (Black
> > > Screen Of Death) on starting X for me (as reported on Saturday [1]).
> > > 
> > > Actually there is more to it as I discovered that my custom X radeon driver
> > > (which is xorg-x11-drv-ati-6.9.0-61.fc10.i386 with "radeon: no need for this
> > > anymore" from radeon-gem-cs change reverted, please see [2] for my previous
> > > monologue) works fine while following stock driver versions:
> > > 
> > > 	xorg-x11-drv-ati-6.8.0-19.fc9.i386
> > > 	xorg-x11-drv-ati-6.9.0-61.fc10.i386
> > > 	xorg-x11-drv-ati-6.9.0-62.fc10.i386
> > > 
> > > result in BSOD.  OTOH they all work with next-20081128 (modulo hangs with
> > > fc10 ones when "radeon: no need for this anymore" change is not reverted).
> > > 
> > > [ BTW xorg-x11-drv-ati-6.9.0-62.fc10.i386 still causes hangs when used with
> > >   non-Fedora kernels and Fedora/kms kernel still has performance problems ]
> > > 
> > > IOW there are a lot of compatibility issues in recent drm/radeon changes.
> > > 
> > > Dave, could you please start looking into these problems?  I'm sure that we
> > > all want recent drm changes + kms in 2.6.29 but given tight schedule and the
> > > way things are looking right now I'm quite sceptical...
> > > 
> > > [1] http://lkml.org/lkml/2008/12/13/76
> > > [2] http://lkml.org/lkml/2008/12/13/77
> > > 
> > 
> > Bart,
> > 
> > please file bugs in RH bugzilla for Fedora issues. Fedora is shipping
> > drivers that aren't upstream, and I'm attempting to resolve the issues
> > as they arise. However not having a bug to track stuff in means it just
> > goes far enough out of my inbox that I forget about it.
> 
> OK, I'll try to put all issues into RH bugzilla once I find some time. 
> 
> [ OTOH the hang issue mentioned above happens only with vanilla kernels,
>   Fedora kernels are not affected because they ship KMS.  Anyway, you
>   could have just told me that you prefer to have a RH bugzilla bug for
>   it two weeks ago (and indeed KMS performance issue should have been
>   handled through bugzilla -- however this one is of lower priority). ]

I know, literally I didn't see a mail in my inbox and forgot about this
bug until it showed up again, so I should mention Fedora BZ for Fedora
bugs earlier indeed..

drm-next should be fine in the next iteration, there was a missing patch
hunk in the last commit, and then a locking bug after that.

I'll try and look at the other stability issues you are seeing with
Fedora today,

however halving the amount of video RAM everyone gets as a fix for an
issue you are seeing is clearly not the answer, I'd like to actually
track down the root cause of where it went wrong.

Dave.

> 
> > The revert isn't a fix for -ati, and I haven't seen any reports of
> > performance problems with profiles attached in my bugzilla.
> 
> "isn't a fix" is a brave statement since it makes a difference between hang
> within minutes and rock stable operation (sure the revert itself may not be
> a proper fix but it works and is a good starting point).  I spend quite some
> time narrowing down the bug and this is not exactly the reaction I expected.
> 
> [ Well, I can fix/workaround the issues that I encounter quite quickly and I
>   don't really have to put extra time into narrowing them down so they can be
>   fixed in upstream distro if distro people don't see a value in such work. ]
> 
> > I'm booting drm-next on more various radeon hw today to see what I can
> > reproduce, most of the kms changes for 2.6.29 are nothing to do with
> > radeon at all, we are only upstreaming KMS for Intel hw, so I'm not sure
> > what the sceptical bit is about. Its much more likely this is
> 
> F9 -> F10 upgrade has been a nightmare for me thanks to radeon/kms
> changes (which are still Fedora specific stuff and it is good to hear
> that they will not be upstreamed now).
> 
> On top of it drm-next tree has been broken for me since next-20081203
> (yes, that is two weeks period!).
> 
> It could be just my luck and things may be working perfectly for 99.9%
> of other people but are you still surprised that I'm sceptical?
> 
> > multi-master changes before KMS that are interacting badly.
> 
> Yes, multi-master changes are to blame but currently KMS patch depends on
> them (though maybe it could be made independent -- I don't know this).
> 
> If you want me to try some debugging I will be happy to help but please
> start taking more serious approach, and if you don't have the idea where
> the problem is or don't have time to work on it currently please just
> drop the broken changes from drm-next tree for now.
> 
> Thanks,
> Bart