Re: Posssible bug in kernel/irq/handle.c

From: Linus Torvalds (torvalds_at_osdl.org)
Date: 11/09/05

  • Next message: Andrew Theurer: "Re: Database regression due to scheduler changes ?" 
    Date:	Tue, 8 Nov 2005 18:07:22 -0800 (PST)
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>

    On Wed, 9 Nov 2005, Benjamin Herrenschmidt wrote:
    >
    > Hrm... yah, it should... still, I find that a bit fragile.
    >
    > > So I think the code is correct. It has certainly worked for years on x86
    > > (and it got serious debugging, since we had some rather nasty and subtle
    > > issues with edge-triggered APIC interrupts that just get lost if they are
    > > disabled at the controller).
    >
    > Well, we have a "funny" case with some pSeries... the firmware may
    > enable interrupts behind our back, and expects us to call a firmware
    > "try to handle that interrupt" kind of call when we get one we don't
    > handle. That is, either all the handlers returned IRQ_NONE or there is
    > no action. I'm not sure how to do that with the current code without
    > having our own __do_IRQ() which I'd rather avoid...

    Well, I don't think it would be _wrong_ to change the IRQ_INPROGRESS
    handling to work so that it's usabel for PPC.

    Some of it may actually be purely historical: I have this dim memory that
    we may have used IRQ_INPROGRESS for the irq autodetection originally (it
    now uses the IRQ_WAITING flag for that).

    So I was really only arguing for it not being actively buggy the way it is
    now - which is not to say that we can't change it to be friendlier to
    whatever your needs are.

    Be vewy vewy caweful when changing that code, though. If you end up with a
    patch, please try to give it some nice stress-testing (both on ppc and
    x86), and then post it for comments, ok? Maybe the arch mailing list and
    Ingo (who else has touched that logic?)

                    Linus
    -
    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/

  • Next message: Andrew Theurer: "Re: Database regression due to scheduler changes ?"

    Relevant Pages

    • Re: pci_fixup_video() bogosity
      ... >> enable bits of the VGA cards themselves. ... What happens on PPC? ... (they are fully posted in "native" mode by the firmware). ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [RFC] invalidate_mmap_range() misses remap_file_pages()-affected targets
      ... At some point we burned a bit of effort to ensure we wiped all the ptes ... up invalidate_mmap_rangewith its intent (unmapping file offset ranges ... pte, which is disturbing, but a sign ppc* maintainers already handle it. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [PATCH] ppc64: Fix possible race with set_pte on a present PTE
      ... this case is useless on ppc... ... completely instead and define it's arch impl. ... ptep_set_dirty_accessedresponsibility to do the TLB flush if ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: PowerMac 8500 (summary)
      ... [To reduce noise, i've replied personally to specific points not ... Yeah, much of what was in the earlier summary has been cleared up. ... One not specific to PPC is that it would be better if 'bootlogd' ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: swsusp_restore crap
      ... On Út 15-03-05 14:31:56, Benjamin Herrenschmidt wrote: ... > generic swsusp code and moves it to arch/i386. ... > ppc with swsusp enabled. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)