[lkml]   [2008]   [Jun]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: 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.


     \ /
      Last update: 2008-06-30 12:43    [W:0.065 / U:0.048 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site