On Sunday, 29 of June 2008, Maciej W. Rozycki wrote:
quoted text
> On Sun, 29 Jun 2008, Ingo Molnar wrote:
> 
> > >  You may argue this is a regression, but this is simply the cost paid 
> > > for progress -- the kernel stays within the spec as defined both by 
> > > ACPI and MPS, we have just started using a different configuration now 
> > > and an interrupt source override provided by the manufacturer 
> > > explicitly states INTIN2 is good to use.  In a sense you were simply 
> > > lucky previously the kernel was bad enough with the way it configured 
> > > the timer through the I/O APIC it failed completely avoiding the bug 
> > > in your firmware.  Now the bug has got uncovered.
> > 
> > well as long as we eliminate the bad effects around via DMI exceptions 
> > nobody will feel the need to argue whether it's a regression ;-) [this 
> > problem could be argued to be a regression, even if it's caused by prior 
> > luck/stupidity of Linux. We have to live with the effects of our 
> > mistakes.]
> 
>  Of course -- this is the only reason I can be bothered with the issue in
> the first place.  Otherwise, I would have said: 'Get the manufacturer to
> fix it, use "noapic" or live with a local patch.'

In that case your patch would surely make it to the regression list.

quoted text
>  This is actually how I have kept one of my old MPS SMP systems up for
> years now -- it has a broken MP table which prevents interrupts from
> working when too many PCI option cards are present, so I have prepared a
> patch for patching the table manually.  I proposed it once, which you may
> recall, but it was rejected on the grounds of the syntax being too tough
> to comprehend to a poor average user being.  I am sure more systems would
> benefit as MP table breakages used to be quite common.
> 
>  Here the simple workaround was "noapic" too, so everyone else could be
> happy and I have been happy to keep the patch and use the capabilities of
> the piece of hardware properly despite its broken firmware.

Again.  If there's a configuration that didn't need any manual workarounds
before, it's expected to continue to work without any manual workarounds and
as a patch submitter, it's _your_ burden to make that happen.

Otherwise you throw this burden onto users who
(1) don't expect things to stop working,
(2) may not be able to figure out themselves what the right workaround is,
(3) may not be able to make hardware manufacturers do anything.

If there's a configuration that worked before your patch and doesn't work
after it, you're hurting the users of that configuration.

Thanks,
Rafael
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/