lkml.org 
[lkml]   [2010]   [Feb]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: hung bootup with "drm/radeon/kms: move radeon KMS on/off switch out of staging."
    On Thu, 4 Feb 2010 22:05:59 +0100
    Ingo Molnar <mingo@elte.hu> wrote:

    >
    > * Matthew Garrett <mjg59@srcf.ucam.org> wrote:
    >
    > > On Thu, Feb 04, 2010 at 09:22:54PM +0100, Ingo Molnar wrote:
    > >
    > > > " Hey, -rc7 just hung on me after enabling this new .config option it
    > > > offered for the radeon driver i am using, please add this to the list of
    > > > regressions. "
    > >
    > > If the same configuration options hang on both an old kernel and a new
    > > kernel, how is that in any plausible way a regression? What's regressed?
    >
    > Regressions are not limited to 'same config' kernels, last i checked. If that
    > has changed (or if i'm misunderstanding it) then it would be nice to hear a
    > clarification about that from Linus.
    >
    > The way i understand it is that there are narrow exceptions from the
    > regression rules, such as completely new drivers for which there can be no
    > prior expectation of stability by users. (but for even them we are generally
    > on the safer side to list bugs in them as regressions as well - especially if
    > we expect many users to enable it.)
    >
    > AFAIK there's no exception for new sub-features of existing facilities or
    > drivers, even if it's default-disabled.
    >
    > This issue materially affects quite a few bugs i'm handling as a maintainer.
    > Many of them are under default-off config options - most new aspects to
    > existing code are introduced in such a way. It would remove quite a bit of
    > urgent-workload from my workflow if i could strike them from Rafael's list
    > and could deprioritize them as "plain bugs", to be fixed as time permits.
    >
    > IMHO it would be rather counter-productive to kernel quality if we did that
    > kind of regression-lawyering though.
    >

    Yes, it's mainly semantics.

    From the user's point of view

    kernel N: boots, works, plays nethack
    kernel N+1: goes splat

    That kernel regressed for that user. He'll shrug and will go back to
    kernel N and we lost an N+1 tester. And the distros who ship N+1 get a
    lot of hack work to do.

    If the feature is this buggy, it was wrong to make it accessible in Kconfig.


    Anyway. The number of DRI regressions which have come in over the past
    few weeks is really quite extraordinary. We're now showing 31 open
    DRI regressions in bugzilla, but a lot of those are presumably
    defunct.

    It's been bad ever since the KMS stuff went in. That's understandable
    given the magnitude of the change, I guess, but the wheels really seem
    to have falled off in 2.6.32 and 2.6.33.



    \
     
     \ /
      Last update: 2010-02-04 22:27    [W:0.028 / U:0.220 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site