lkml.org 
[lkml]   [2008]   [Jun]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: linux-next: Tree for June 13: IO APIC breakage on HP nx6325
    On Sat, 21 Jun 2008, Matthew Garrett wrote:

    > > Meanwhile we may consider implementing a workaround. I think one that
    > > does not hurt competent vendors would be preferable. The DSDT containing
    > > the rubbish described here is marked with an OEM ID: "HP " and OEM
    > > Table ID: "SB400". These keys could be used to remove IRQ0 information
    > > from the IRQ tables. Our code is prepared to handle such a case.
    > > Something easy to do for a seasoned ACPI fiddler, I suppose. ;)
    >
    > Something roughly like the following? Entirely untested, my 6125 is in a

    Maybe, though your code seems to match product IDs rather than the broken
    DSDT itself. I think the latter would be preferable as it would cover all
    the pieces of equipment using the broken piece of firmware rather than
    ones we have already tracked down. Perhaps the version could be included
    too, but that would only make sense if the breakage ever gets fixed -- the
    use of the through-8259A mode for the 8254 timer would allow this piece of
    equipment to benefit from the I/O APIC driven NMI watchdog.

    > box somewhere. My recollection is that skip_timer_override will disable
    > the IRQ 0->2 mapping, which I believe is what's broken here?

    Not exactly. The IRQ0->2 mapping is certainly wrong here, but so is the
    identity IRQ0->0 one. Which means it should not be recorded in
    mp_config_acpi_legacy_irqs() at all. I can cook this part if you'd rather
    not to, if you do the ACPI part. If you think there is no easy way to
    match the DSDT rather than the product ID -- we are trying to cope with
    outright breakage here after all, so any amount of effort is too much ;)
    -- I can update your proposal with what I have in mind.

    One point to note -- perhaps it would be better to avoid these #ifdef
    clauses -- even though it's a workaround, I think the amount of resources
    consumed does not justify the clutter introduced.

    Thanks for your submission.

    Maciej


    \
     
     \ /
      Last update: 2008-06-21 04:45    [W:3.764 / U:0.164 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site