similar to: known MSI errata?

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

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

On Mon, Nov 24, 2014 at 8:33 PM, Andy Ritger <aritger at nvidia.com> wrote: > On Fri, Nov 21, 2014 at 01:39:55AM -0500, Ilia Mirkin wrote: >> On Fri, Nov 21, 2014 at 1:16 AM, Andy Ritger <aritger at nvidia.com> wrote: >> > Hi Ilia, >> > >> > Actually 0x90b8 is different than copy engine. I'm not very familiar >> > with it, but 0x90b8 is

On Fri, Nov 21, 2014 at 1:16 AM, Andy Ritger <aritger at nvidia.com> wrote: > Hi Ilia, > > Actually 0x90b8 is different than copy engine. I'm not very familiar > with it, but 0x90b8 is an engine for performing LZO decompression as > part of performing the copy. It has a variety of limitations (e.g., > cannot handle blocklinear format), and was only in a few Fermi

--- man/nouveau.man | 9 ++++++++- src/nv_driver.c | 8 ++++++-- 2 files changed, 14 insertions(+), 3 deletions(-) diff --git a/man/nouveau.man b/man/nouveau.man index 07d53c8..4878f24 100644 --- a/man/nouveau.man +++ b/man/nouveau.man @@ -63,7 +63,14 @@ GF100, GF104, GF106, GF108, GF110, GF114, GF116, GF117, GF119 GK104, GK106, GK107, GK110, GK208 .TP 22 .B GeForce GTX 750 -GM107 +GM107,

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. Doing a rearm once before getting any interrupts fixes this. Signed-off-by: Karol Herbst <kherbst at redhat.com> --- drm/nouveau/nvkm/subdev/pci/base.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git

Hi, Keir, These patches are rebased version of Yunhong''s original patches, which were sent out before XEN 3.2 was released. These patches enable MSI support and limited MSI-X support in XEN. Here is the original description of the patches from Yunhong''s mail. The basic idea including: 1) Keep vector global resource owned by xen, while split pirq into per-domain

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

int.patch: - Supports only level-triggered interrupts. Edge interrupts support will be added shortly (should be fairly simple) - Change polarity trick: in order to reflect the external device''s assertion state, the ioapic pin gets its polarity changed whenever an interrupt occur. So an interrupt is generated when the _external_ line is asserted (then,

On 25/11/14 22:05, Andy Ritger wrote: > On Tue, Nov 25, 2014 at 10:57:44AM -0500, Ilia Mirkin wrote: >> On Mon, Nov 24, 2014 at 8:33 PM, Andy Ritger <aritger at nvidia.com> wrote: >>> On Fri, Nov 21, 2014 at 01:39:55AM -0500, Ilia Mirkin wrote: >>>> On Fri, Nov 21, 2014 at 1:16 AM, Andy Ritger <aritger at nvidia.com> wrote: >>>>> Hi Ilia,

Wei, Quick question: Am I reading the code correctly, that even with per-device interrupt remap tables, that GSIs are accounted to the intremap table of the corresponding IOAPIC, presumably because the IOMMU sees interrupts generated as GSIs as coming from the IOAPIC? In that case, then we need all devices sharing the same IOAPIC must not have any vector collisions. Is that correct? -George

Due to popular demand, I have finally found time to write this up. I had to rush it a little, but hopefully you get the gist. http://www.altechnative.net/2013/11/25/virtualized-gaming-nvidia-cards-part-3-how-to-modify-a-fermi-based-geforce-into-a-quadro-geforce-gts450gtx470gtx480-to-quadro-200050006000/ Any questions, please ask away, and I''ll update the article to expand on those

I have an Intel e1000e NIC which I put into passthrough for an HVM domain under Xen 4.2. All the corresponding hardware protections are enabled on my system (DMA + Interrupt remapping), however, once in a while I get a SERR NMI in dom0 (NMI - PCI sys error (SERR) in xl dmesg). I am wondering about its exact reason. I am thinking in the following way: [+] Under Intel VT-x, interrupts are

Hello I recently switched from Nvidia binary driver to Nouveau. I have encountered a possible bug in the kernel module. Before I file a bug report I would like to know if this is a known issue or not. I believe it is related to sleep state and power management of the driver. The Bug: When the computer is left on it's own to go to a power save mode X takes 100% CPU-time in its thread. A

Hello, There's a long-standing bug on nouveau (this is a sample bug, but the issue has been around for a while: https://bugs.freedesktop.org/show_bug.cgi?id=85465) whereby we attempt to use the second PCOPY engine on GF116, and it is sometimes does nothing, despite mmio register 22500 saying that it's not disabled (0x22500 == 0 for this user). In the bug you can see a dump from

It is not advisable to perform devinit if it has already been done. VBIOS will very likely have invoked devinit if the GPU is the primary graphics device, but there is no accurate way to detect this fact yet. This patch adds such a method for gf100 and later chips, by means of the NV_PTOP_SCRATCH1_DEVINIT_COMPLETED bit. This bit is set to 1 by devinit, and reset to 0 when the GPU is powered.

<<handle_msi_irq_storm.patch>> Hi, Keir, This patch handles MSI irq storm. Unluckily, I have observed this phenomenon again. This will happen when some kind of MSI-X capable NIC is assigned to an HVM guest. The basic idea is to mask the interrupt on receiving the second interrupt and set a timer to unmask after 1ms. Can you have a look and give some comments on that? Thanks! Best

On Wed, Aug 28, 2013 at 10:00 AM, Lucas Stach <dev at lynxeye.de> wrote: > MSIs were only problematic on some old, broken chipsets. But now that we > already see systems where PCI legacy interrupts are somewhat flaky, it's > really time to move to MSIs. > > Signed-off-by: Lucas Stach <dev at lynxeye.de> > --- > drivers/gpu/drm/nouveau/core/include/subdev/mc.h

On Wed, Aug 28, 2013 at 3:28 AM, Lucas Stach <dev at lynxeye.de> wrote: > Am Mittwoch, den 28.08.2013, 17:09 +1000 schrieb Ben Skeggs: >> On Wed, Aug 28, 2013 at 10:00 AM, Lucas Stach <dev at lynxeye.de> wrote: >> > MSIs were only problematic on some old, broken chipsets. But now that we >> > already see systems where PCI legacy interrupts are somewhat flaky,