Date:	Mon, 30 Jun 2008 12:41:56 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	"Maciej W. Rozycki" <macro@...ux-mips.org>
Cc:	Ingo Molnar <mingo@...e.hu>, Matthew Garrett <mjg59@...f.ucam.org>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	linux-next@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
	Len Brown <lenb@...nel.org>,
	Andi Kleen <andi-suse@...stfloor.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325

On Monday, 30 of June 2008, Maciej W. Rozycki wrote:
> On Mon, 30 Jun 2008, Rafael J. Wysocki wrote:
> 
> > > > 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.
> 
>  Please be careful -- you seem to contradict yourself.  I wrote to the
> effect of: "If this wasn't a regression, I would have said [...]" and your
> reply is: "In that case your [non-regressing] patch would surely make it
> to the regression list."

Sorry, I didn't parse that paragraph correctly

> > >  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.
> 
>  That is certainly true for standard hardware.  We have to take
> responsibility for own bugs, sure.  I cannot readily understand why you
> apparently try to imply hardware vendors do not.
> 
> > 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.
> 
>  Honestly?  These poor users who have no clue or time to follow the
> development lists and/or fix bugs themselves should report the problem to
> the supplier of their Linux distribution, who would sort it out by, first,
> providing a temporary workaround till the problem is sorted out correctly,
> second, contacting the hardware vendor through a recognised channel to
> request the problem to be investigated and fixed properly.  I am fairly
> sure all the reputable (responsible?) distribution vendors have service
> agreements already in place with all the major hardware vendors and all
> the minor hardware vendors will be happy to cooperate anyway so as not to
> be minor vendors anymore.  This is why I have asked for points of contact 
> repeatedly in this thread.
> 
>  Of course it leaves hobbyist distributions at a slight disadvantage, but
> their users are sort of expected to be "power users" (otherwise they
> wouldn't have been hobbyists, would they?) and adding an option or a patch
> even should not be a problem for them.  We may try to do our best to help
> them, but not at the price of penalising good hardware.

Well, there are lots of pieces of hardware that are not up to the
specifications, more or less, and I don't think that's a good enough reason
for us to refuse to support them.  The same applies to BIOSes IMO.

Of course, the _default_ should be to follow the spec, but if that doesn't work
on given hardware/BIOS combination and we know what to do to handle it, we
should just handle it instead of asking users to fix their BIOSes.

I have seen enough failed BIOS upgrades to be very cautious about such things.
Certainly, I wouldn't have seriously asked anyone to upgrade the BIOS in a
notebook, because if that had failed, the user would have end up with a piece
of electronic junk.

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

Powered by blists - more mailing lists