Prev: i915: slow acpi_lid_open() causes flickering - V2
Next: [56/74] Fix flush_old_exec()/setup_new_exec() split
From: Matthew Garrett on 4 Feb 2010 11:50
On Thu, Feb 04, 2010 at 08:17:05AM +0100, Ingo Molnar wrote:

> btw., i just found another bug activated via this same commit, a boot hang
> after DRM init:

The commit in question didn't cause the hang, so reverting it isn't the
appropriate fix.

--
Matthew Garrett | mjg59(a)srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Matthew Garrett on 4 Feb 2010 12:40
On Thu, Feb 04, 2010 at 06:08:26PM +0100, Ingo Molnar wrote:

> Well, once i applied the revert i got no more hangs or crashes today, in lots
> of bootups. This is fully repeatable - if i re-apply that commit with the
> config i sent the hang happens again.

If you leave the commit applied, use that config and then enable Radeon
KMS under staging, do you get the hang?

--
Matthew Garrett | mjg59(a)srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Matthew Garrett on 4 Feb 2010 13:10
On Thu, Feb 04, 2010 at 06:54:45PM +0100, Ingo Molnar wrote:

> But you could claim that it's not a regression because 1) technically the
> code got introduced in drivers/staging/, and staging drivers are not on the
> regression list 2) the Kconfig value is default-off so it can only harm those
> who got lured by a new Kconfig value popping up in -rc7 in a well working
> driver they already have enabled.
>
> So the moving of driver functionality from drivers/staging/ to drivers/ is a
> grey area it appears. Wouldnt it have been better to do this in the next
> merge window, as all other drivers do? It's not new hardware enablement
> either, it's feature enablement for an existing driver.

The reason the option was in staging (as has been mentioned before) was
because the ABI wasn't felt to be stable enough. Upstream is now willing
to commit to that stability, so now seems as good a time to move it as
any. There's no code change and there's no default configuration change,
so I really can't see any way that it can be classed as a regression.

--
Matthew Garrett | mjg59(a)srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Matthew Garrett on 4 Feb 2010 13:20
On Thu, Feb 04, 2010 at 07:12:18PM +0100, Ingo Molnar wrote:
>
> * Matthew Garrett <mjg59(a)srcf.ucam.org> wrote:
> > The reason the option was in staging (as has been mentioned before) was
> > because the ABI wasn't felt to be stable enough. Upstream is now willing to
> > commit to that stability, so now seems as good a time to move it as any.
> > There's no code change and there's no default configuration change, so I
> > really can't see any way that it can be classed as a regression.
>
> But that argument in essence renders the regression policy meaningless for
> such code: just about any new driver feature under the sun could be shaped as
> a Kconfig option, introduced via a drivers/staging Kconfig entry, and then
> activated via a twoliner commit in a later -rc.

Before this patch, CONFIG_DRM_RADEON_KMS=y would crash your system on
boot. After this patch, CONFIG_DRM_RADEON_KMS=y still crashes your
system. There's certainly the argument that this means it's premature to
make that change, but given that the same configuration behaves in the
same way, it's clearly not a regression.

--
Matthew Garrett | mjg59(a)srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Matthew Garrett on 4 Feb 2010 14:10
On Thu, Feb 04, 2010 at 07:56:03PM +0100, Ingo Molnar wrote:

> Do you see my argument why any user who is hit by this would categorize this
> as a kernel regression in an existing driver?

No. If a user changes configuration and gets a hang, that's a bug but
not a regression.

--
Matthew Garrett | mjg59(a)srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 |  Next  |  Last
Pages: 1 2
Prev: i915: slow acpi_lid_open() causes flickering - V2
Next: [56/74] Fix flush_old_exec()/setup_new_exec() split