From: Thomas Gleixner <tglx@linutronix.de>
To: Evan Green <evgreen@chromium.org>, Rajat Jain <rajatja@google.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
linux-pci <linux-pci@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] PCI/MSI: Avoid torn updates to MSI pairs
Date: Thu, 23 Jan 2020 09:49:13 +0100 [thread overview]
Message-ID: <87y2tytv5i.fsf@nanos.tec.linutronix.de> (raw)
In-Reply-To: <CAE=gft6fKQWExW-=xjZGzXs30XohfpA5SKggvL2WtYXAHmzMew@mail.gmail.com>
Evan Green <evgreen@chromium.org> writes:
> In my experiments, the driver no longer misses the interrupt. XHCI is
> particularly sensitive to this, if it misses one interrupt it seems to
> completely wedge the driver.
That does not make the approach more correct.
> I think in my case the device pends the interrupts until MSIs are
> re-enabled, because I don't see anything other than MSI for xhci in
> /proc/interrupts. But I'm not sure if other devices may fall back to
> line-based interrupts for a moment, and if that's a problem.
Yes they can according to standard and it _IS_ a problem.
> Although, I already see we call pci_msi_set_enable(0) whenever we set
> up MSIs, presumably for this same reason of avoiding torn MSIs.
Please stop making random assumptions. This as absolutely nothing to do
with torn MSIs. The way how MSI setup works requires this. And this is
happening on init _before_ any interrupt can be requested on the device.
Different reason, different context.
> So my fix is really just doing the same thing for an additional
> case.
No, it's absolutely not the same. Your device is active and not in
reset/init state.
> And if getting stuck in a never-to-be-handled line based interrupt
> were a problem, you'd think it would also be a problem in
> pci_restore_msi_state(), where the same thing is done.
Again. I told you already it's not the same thing.
> Maybe my fix is at the wrong level, and should be up in
> pci_msi_domain_write_msg() instead? Though I see a lot of callers to
> pci_write_msi_msg() that I worry have the same problem.
This is not yet debugged fully and as this is happening on MSI-X I'm not
really convinced yet that your 'torn write' theory holds.
Thanks,
tglx
next prev parent reply other threads:[~2020-01-23 8:49 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-18 0:25 [PATCH v2] PCI/MSI: Avoid torn updates to MSI pairs Evan Green
2020-01-22 11:25 ` Rajat Jain
2020-01-22 18:00 ` Evan Green
2020-01-23 8:49 ` Thomas Gleixner [this message]
2020-01-23 18:16 ` Thomas Gleixner
[not found] ` <CAE=gft6YiM5S1A7iJYJTd5zmaAa8=nhLE3B94JtWa+XW-qVSqQ@mail.gmail.com>
2020-01-23 22:59 ` Evan Green
2020-01-24 0:29 ` Evan Green
2020-01-24 14:34 ` Thomas Gleixner
2020-01-24 21:53 ` Evan Green
2020-01-24 22:50 ` Thomas Gleixner
2020-01-28 14:38 ` Thomas Gleixner
2020-01-28 22:22 ` Evan Green
2020-01-28 22:48 ` Thomas Gleixner
2020-01-29 18:00 ` Evan Green
2020-01-29 21:00 ` Thomas Gleixner
2020-01-29 22:53 ` Evan Green
2020-01-29 23:16 ` Thomas Gleixner
2020-01-29 23:48 ` Evan Green
2020-01-31 11:27 ` [PATCH] x86/apic/msi: Plug non-maskable MSI affinity race Thomas Gleixner
2020-01-31 14:26 ` [PATCH V2] " Thomas Gleixner
2020-01-31 20:32 ` Evan Green
2020-01-31 21:45 ` Thomas Gleixner
2020-02-01 8:36 ` [tip: x86/urgent] " tip-bot2 for Thomas Gleixner
2020-01-24 0:50 ` [PATCH v2] PCI/MSI: Avoid torn updates to MSI pairs Thomas Gleixner
2020-01-25 18:32 ` Jacob Pan
2020-01-26 8:09 ` Thomas Gleixner
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=87y2tytv5i.fsf@nanos.tec.linutronix.de \
--to=tglx@linutronix.de \
--cc=bhelgaas@google.com \
--cc=evgreen@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=rajatja@google.com \
/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