similar to: [PATCH] pci: do a msi rearm on init

On Fri, Nov 24, 2017 at 3:02 PM, Thierry Reding <thierry.reding at gmail.com> wrote: > On Fri, Nov 24, 2017 at 03:56:26AM +0100, Karol Herbst wrote: >> On my GP107 when I load nouveau after unloading it, for some reason the >> GPU stopped sending or the CPU stopped receiving interrupts if MSI was >> enabled. > > I suppose this could happen if the GPU raises an

On Fri, Nov 24, 2017 at 03:56:26AM +0100, Karol Herbst wrote: > On my GP107 when I load nouveau after unloading it, for some reason the > GPU stopped sending or the CPU stopped receiving interrupts if MSI was > enabled. I suppose this could happen if the GPU raises an interrupt after the driver's already called free_irq() on it, and hence the driver can't rearm itself in the

For a while we've been having issues with seemingly random interrupts coming from nvidia cards when resuming them. Originally the fix for this was thought to be just re-arming the MSI interrupt registers right after re-allocating our IRQs, however it seems a lot of what we do is both wrong and not even nessecary. This was made apparent by what appeared to be a regression in the mainline

For a while we've been having issues with seemingly random interrupts coming from nvidia cards when resuming them. Originally the fix for this was thought to be just re-arming the MSI interrupt registers right after re-allocating our IRQs, however it seems a lot of what we do is both wrong and not even nessecary. This was made apparent by what appeared to be a regression in the mainline

For a while we've been having issues with seemingly random interrupts coming from nvidia cards when resuming them. Originally the fix for this was thought to be just re-arming the MSI interrupt registers right after re-allocating our IRQs, however it seems a lot of what we do is both wrong and not even nessecary. This was made apparent by what appeared to be a regression in the mainline

On Fri, Oct 25, 2013 at 7:43 AM, Robert Morell <rmorell at nvidia.com> wrote: > On Mon, Sep 30, 2013 at 10:44:12AM -0700, Lucas Stach wrote: >> Hi, >> >> recently we tried to enable MSI interrupts with nouveau. Unfortunately >> there have been some reports of things failing with certain cards, where >> it isn't entirely clear if this is a GPU errata or

In preparation to enabling -Wvla, remove VLA. In this particular case directly use macro NVKM_MSGQUEUE_CMDLINE_SIZE instead of local variable cmdline_size. Also, remove cmdline_size as it is not actually useful anymore. The use of stack Variable Length Arrays needs to be avoided, as they can be a vector for stack exhaustion, which can be both a runtime bug or a security flaw. Also, in general, as

Hi, recently we tried to enable MSI interrupts with nouveau. Unfortunately there have been some reports of things failing with certain cards, where it isn't entirely clear if this is a GPU errata or some other component in the PCIe chain failing. Could you perhaps investigate if there are any known Nvidia GPU erratas with regard to MSI interrupts, or maybe tell us the generations of cards

See https://bugs.freedesktop.org/show_bug.cgi?id=74492 Reported-by: Ronald <ronald645 at gmail.com> Suggested-by: Marcin Ko?cielnicki <koriakin at 0x04.net> Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- drivers/gpu/drm/nouveau/Makefile | 1 + drivers/gpu/drm/nouveau/core/engine/device/nv40.c | 10 ++---

704a6c008b7942bb7f30bb43d2a6bcad7f543662 broke pci msi rearm for g92 GPUs. g92 needs the nv46_pci_msi_rearm, where g94+ gpus used nv40_pci_msi_rearm. Reported-by: Andrew Randrianasulu <randrianasulu at gmail.com> Signed-off-by: Karol Herbst <karolherbst at gmail.com> --- drm/nouveau/include/nvkm/subdev/pci.h | 1 + drm/nouveau/nvkm/engine/device/base.c | 20 +++++++-------

On Mon, Sep 30, 2013 at 10:44:12AM -0700, Lucas Stach wrote: > Hi, > > recently we tried to enable MSI interrupts with nouveau. Unfortunately > there have been some reports of things failing with certain cards, where > it isn't entirely clear if this is a GPU errata or some other component > in the PCIe chain failing. > > Could you perhaps investigate if there are any

On 12/03/2015 06:21, Fam Zheng wrote: > If the device doesn't support shutdown, disabling interrupts may cause > trouble. For example, virtio-scsi-pci doesn't implement shutdown, and > after we disable MSI-X, futher notifications from device will be > delivered to IRQ, which is unexpected. This IRQ will not be cleared, and > may prevent us from making progress, by keep

On 12/03/2015 06:21, Fam Zheng wrote: > If the device doesn't support shutdown, disabling interrupts may cause > trouble. For example, virtio-scsi-pci doesn't implement shutdown, and > after we disable MSI-X, futher notifications from device will be > delivered to IRQ, which is unexpected. This IRQ will not be cleared, and > may prevent us from making progress, by keep

From: Thierry Reding <treding at nvidia.com> Most IOMMU drivers only need to free the memory allocated for each reserved region. Instead of open-coding the loop to do this in each driver, extract the code into a common function that can be used by all these drivers. Changes in v2: - change subject prefix to "iommu: virtio: " for virtio-iommu.c driver Thierry Thierry Reding (5):

On Thu, Oct 24, 2013 at 04:03:12PM -0700, Ben Skeggs wrote: > On Fri, Oct 25, 2013 at 7:43 AM, Robert Morell <rmorell at nvidia.com> wrote: > > On Mon, Sep 30, 2013 at 10:44:12AM -0700, Lucas Stach wrote: > >> Hi, > >> > >> recently we tried to enable MSI interrupts with nouveau. Unfortunately > >> there have been some reports of things failing

Several users have, over time, reported issues with MSI on these IGPs. They're old, rarely available, and MSI doesn't provide such huge advantages on them. Just disable. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87361 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74492 Fixes: fa8c9ac72fe ("drm/nv4c/mc: nv4x igp's have a different msi rearm register")

From: Thierry Reding <treding at nvidia.com> Most IOMMU drivers only need to free the memory allocated for each reserved region. Instead of open-coding the loop to do this in each driver, extract the code into a common function that can be used by all these drivers. Changes in v3: - add Reviewed-by from Jean-Philippe Brucker on virtio patch - add Acked-by from Will Deacon on ARM SMMU patch

From: Anthony Liguori <aliguori at amazon.com> If MSI-X initialization fails after setting msix_enabled = 1, then the device is left in an inconsistent state. This would normally only happen if there was a bug in the device emulation but it still should be handled correctly. Cc: Matt Wilson <msw at amazon.com> Cc: Rusty Russell <rusty at rustcorp.com.au> Cc: Michael Tsirkin

From: Anthony Liguori <aliguori at amazon.com> If MSI-X initialization fails after setting msix_enabled = 1, then the device is left in an inconsistent state. This would normally only happen if there was a bug in the device emulation but it still should be handled correctly. Cc: Matt Wilson <msw at amazon.com> Cc: Rusty Russell <rusty at rustcorp.com.au> Cc: Michael Tsirkin

From: Thierry Reding <treding at nvidia.com> Tegra firmware doesn't actually use any version numbers and passing -1 causes the existing firmware binaries not to be found. Use version 0 to find the correct files. Signed-off-by: Thierry Reding <treding at nvidia.com> --- drivers/gpu/drm/nouveau/nvkm/engine/gr/gk20a.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff