From: Olaf Dabrunz <od@suse.de>
To: Jon Masters <jcm@redhat.com>
Cc: Olaf Dabrunz <od@suse.de>, Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@elte.hu>, "H. Peter Anvin" <hpa@zytor.com>,
Stefan Assmann <sassmann@suse.de>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/7] Boot IRQ quirks and rerouting
Date: Tue, 3 Jun 2008 18:56:37 +0200 [thread overview]
Message-ID: <20080603165637.GD16200@suse.de> (raw)
In-Reply-To: <1212508321.22357.13.camel@londonpacket.bos.redhat.com>
On 03-Jun-08, Jon Masters wrote:
> I like the patch series, insomuch as the intention is good, and it does
> away with the special PCI IRQ quirk patches some of us are carrying in
> our vendor trees to temporarily workaround this problem[0]. Also, I'm
> extremely impressed with the research that went into this, since I
> repeatedly tried to get ahold of information about disabling this
> unfortunate "feature" of various bridges, without much success.
Thanks a lot. :)
BTW, your blog was really helpful to get up to speed on this again. :)
(I read about (RT) IRQ problems a looong time ago on lkml... ;))
We also looked through the code and added tests to make sure that
IRQ-handling works correctly and to test a few theories. We became
relatively convinced that the code was correct. Then we thought the
failures were too systematic to be caused by glitches. Always the same
IRQs were triggered, and only when the "original" ones were masked.
We found first answers in the i6700PXH datasheet. After the first
reroute patch worked, the rest was about finding similar answers for
other chipsets.
> However, I really am not happy with the implementation as it stands. The
> duplicated table of quirks that doesn't really fit in with the existing
> PCI quirks infrastructure, the weird naming of the kernel options, and
> various other things that Thomas has already mentioned in his reply.
> Therefore, I think this needs a bit more reworking before going in.
Yep. We are working on it. Thanks for your comments. :)
> Thanks!
>
> Jon.
>
> [0] The real fix come when we move IRQ handling in RT to per-device
> threads, as is the longer term intention. Then you can quiesse the
> device immediately and not the mask/unmask cycle that fails here.
Yes, per-device threads help with the latency. I believe the boot irq
patches here can then make drivers work that do not (yet) use the new
approach. Also, I am not sure so far whether all devices can quiesce
their IRQs on the device without introducing possible loss of IRQs --
but that is just theory (or FUD? BS? oh-oh *duck*), so please don't
mind... :}
Thanks,
--
Olaf Dabrunz (od/odabrunz), SUSE Linux Products GmbH, Nürnberg
next prev parent reply other threads:[~2008-06-03 16:56 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-02 12:45 [PATCH 0/7] Boot IRQ quirks and rerouting Olaf Dabrunz
2008-06-02 12:45 ` [PATCH 1/7] add kernel cmdline option to disable pci-irq quirks Olaf Dabrunz
2008-06-03 10:13 ` Thomas Gleixner
2008-06-03 17:00 ` Stefan Assmann
2008-06-02 12:45 ` [PATCH 2/7] reroute PCI interrupt to legacy boot interrupt equivalent Olaf Dabrunz
2008-06-03 10:37 ` Thomas Gleixner
2008-06-03 22:59 ` Randy Dunlap
2008-06-12 14:14 ` Olaf Dabrunz
2008-06-02 12:45 ` [PATCH 3/7] disable legacy boot interrupt generation Olaf Dabrunz
2008-06-03 10:40 ` Thomas Gleixner
2008-06-02 12:45 ` [PATCH 4/7] disable broadcomm " Olaf Dabrunz
2008-06-03 10:46 ` Thomas Gleixner
2008-06-03 15:46 ` Jon Masters
2008-06-03 15:59 ` Olaf Dabrunz
2008-06-03 16:05 ` Jon Masters
2008-06-03 17:27 ` Olaf Dabrunz
2008-06-02 12:45 ` [PATCH 5/7] disable AMD/ATI " Olaf Dabrunz
2008-06-03 10:54 ` Thomas Gleixner
2008-06-12 14:14 ` Olaf Dabrunz
2008-06-02 12:45 ` [PATCH 6/7] disable pci legacy boot irq quirks on noapic boot Olaf Dabrunz
2008-06-03 10:55 ` Thomas Gleixner
2008-06-02 12:45 ` [PATCH 7/7] bootirqquirk= parameter to enable bootirq quirks for additional chips Olaf Dabrunz
2008-06-03 10:56 ` Thomas Gleixner
2008-06-04 10:06 ` Olaf Dabrunz
2008-06-02 16:43 ` [PATCH 0/7] Boot IRQ quirks and rerouting Olaf Dabrunz
2008-06-03 10:11 ` Thomas Gleixner
2008-06-03 17:08 ` Olaf Dabrunz
2008-06-03 10:21 ` Olaf Dabrunz
2008-06-03 15:52 ` Jon Masters
2008-06-03 16:17 ` Stefan Assmann
2008-06-03 16:56 ` Olaf Dabrunz [this message]
2008-06-04 2:35 ` Eric W. Biederman
2008-06-04 9:49 ` Stefan Assmann
2008-06-04 10:45 ` Eric W. Biederman
2008-06-04 11:33 ` Stefan Assmann
2008-06-04 15:52 ` Maciej W. Rozycki
2008-06-04 16:08 ` Thomas Gleixner
2008-06-04 17:18 ` Maciej W. Rozycki
2008-06-04 17:33 ` Thomas Gleixner
2008-06-04 17:53 ` Maciej W. Rozycki
2008-06-04 18:35 ` Thomas Gleixner
2008-06-04 18:51 ` Maciej W. Rozycki
2010-02-16 0:30 ` Yuhong Bao
2008-06-04 18:57 ` Jon Masters
2008-06-04 19:19 ` Maciej W. Rozycki
2008-06-04 19:59 ` Jon Masters
2008-06-04 22:07 ` Maciej W. Rozycki
2008-06-04 22:27 ` Jon Masters
2008-06-04 23:08 ` Maciej W. Rozycki
2008-06-04 11:37 ` Olaf Dabrunz
2008-06-04 18:44 ` Jon Masters
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080603165637.GD16200@suse.de \
--to=od@suse.de \
--cc=hpa@zytor.com \
--cc=jcm@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=sassmann@suse.de \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox