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." > > 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. Maciej -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
