search for: rearm

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 a/drm/nouveau/nvkm/subdev/pci/base.c b/drm/nouveau/nvkm/subdev/pci/base.c index b1b1f362..7ee1fbb4...

...r 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 interrupt handler. > > This possibly points to a bug somewhere (the GPU should be completely > idle by the time free_irq() is called), but this seems like a valid > thing to do at initialization in any case to avoid relying on the prior > owner of the device to always b...

...07 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 interrupt handler. This possibly points to a bug somewhere (the GPU should be completely idle by the time free_irq() is called), but this seems like a valid thing to do at initialization in any case to avoid relying on the prior owner of the device to always behave properly. > Do...

I have made the daring (and possibly idiotic) decision to play BCR on my laptop instead of my desktop computer, as my desktop is single core and therefore runs the game rather sluggishly while my laptop is dual-core. The only problem with this is that my laptop runs Linux. Does anyone knwo what I might have to tweak in order to get it to run? Will I have to disable SecuROM?

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

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/dev...

...rlier GPUs so > I can't comment there. > > I investigated our internal documentation and source code, and found a couple > of things that are probably interesting to you: > - For all pre-Fermi GPUs, we use a write through PCI config space to the "EOI" > register to rearm the MSI interrupt after servicing it, rather than a write > through the MMIO pcicfg shadow region in the GPU's PCI BAR0 window at offset > 0x88000. (This was actually originally implemented for NV4x, so you'll > probably want to do that there as well.) Hm, I recently discove...

...enabled MSI by default on earlier GPUs so I can't comment there. I investigated our internal documentation and source code, and found a couple of things that are probably interesting to you: - For all pre-Fermi GPUs, we use a write through PCI config space to the "EOI" register to rearm the MSI interrupt after servicing it, rather than a write through the MMIO pcicfg shadow region in the GPU's PCI BAR0 window at offset 0x88000. (This was actually originally implemented for NV4x, so you'll probably want to do that there as well.) It seems that this was done to avo...

...drivers/gpu/drm/nouveau/core/subdev/mc/nv04.h +++ b/drivers/gpu/drm/nouveau/core/subdev/mc/nv04.h @@ -14,6 +14,7 @@ int nv04_mc_ctor(struct nouveau_object *, struct nouveau_object *, extern const struct nouveau_mc_intr nv04_mc_intr[]; int nv04_mc_init(struct nouveau_object *); void nv40_mc_msi_rearm(struct nouveau_mc *); +int nv44_mc_init(struct nouveau_object *object); int nv50_mc_init(struct nouveau_object *); extern const struct nouveau_mc_intr nv50_mc_intr[]; extern const struct nouveau_mc_intr nvc0_mc_intr[]; diff --git a/drivers/gpu/drm/nouveau/core/subdev/mc/nv44.c b/drivers/gpu/dr...

System Specs wine version: 1.1.0 OS: Gentoo with Linux 2.6.24 Nvidia Drivers: 169.12 wine configs * tried with virtual desktop * tried with WinXP and Vista I was able to install Bionic Commando: Rearmed. However, wine fails when I attempt to start the game with the output shown below. Code: fixme:ntdll:NtQueryInformationProcess (0xffffffff,info_class=34,0x1c3a3b0,0x00000004,0x1c3a3ac) Unknown information class fixme:ntdll:NtQuerySystemInformation info_class SYSTEM_HANDLE_INFORMATION fixme:nt...

...ners, please consider including this in >> your trees. > > But it needs > commit fa8c9ac72fe0bcdf5bc7cc84e85cc2a1af53f9fd > Author: Ilia Mirkin <imirkin at alum.mit.edu> > Date: Wed Feb 5 14:33:02 2014 -0500 > > drm/nv4c/mc: nv4x igp's have a different msi rearm register > > See https://bugs.freedesktop.org/show_bug.cgi?id=74492 > > which is only in 3.14. So I cannot take it into 3.12. Doh! I could have sworn that this commit was also backported, but I guess not. I did a big more digging, a few results: (a) v3.12 didn't actually have...

Hello, I'd like to recommend backporting this commit: commit 0a363e85cdafbceeee6a49b91c604d0d4d070dc7 Author: Hans de Goede <hdegoede at redhat.com> Date: Thu Jul 23 17:20:12 2015 +0200 drm/nouveau/nv46: Change mc subdev oclass from nv44 to nv4c This disables MSI by default on G72 (NV46) devices where it's apparently a bit buggy. We have a later patch which turns MSI back

...t = drm_fb_helper_init(dev, &fbcon->helper, > > @@ -571,6 +607,8 @@ nouveau_fbcon_fini(struct drm_device *dev) > > if (!drm->fbcon) > > return; > > > > + flush_work(&drm->fbdev_suspend_work); > > Hmm, since suspend_work can theorectically rearm itself, this should be > cancel_work_sync(). How so? The worker calls with state = FBINFO_STATE_RUNNING and synchronous = true, so schedule_work() can never be called. > The copy'n'paste of the code looks fine, so (other than the bug copied > across): > > Reviewed-by: Chri...

...w.timer_divisor; - + uint32_t lvtt = vlapic_get_reg(s, APIC_LVTT); + + s->pt.irq = lvtt & APIC_VECTOR_MASK; create_periodic_time(v, &s->pt, period, s->pt.irq, vlapic_lvtt_period(s), NULL, s); printk("lapic_load to rearm the actimer:" "bus cycle is %uns, " - "saved tmict count %lu, period %"PRIu64"ns\n", - APIC_BUS_CYCLE_NS, tmict, period); + "saved tmict count %lu, period %"PRIu64"ns, irq...

...#39;t comment there. > > > > I investigated our internal documentation and source code, and found a couple > > of things that are probably interesting to you: > > - For all pre-Fermi GPUs, we use a write through PCI config space to the "EOI" > > register to rearm the MSI interrupt after servicing it, rather than a write > > through the MMIO pcicfg shadow region in the GPU's PCI BAR0 window at offset > > 0x88000. (This was actually originally implemented for NV4x, so you'll > > probably want to do that there as well.) > Hm...

...#39;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") Cc: stable at vger.kernel.org Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- nvkm/subdev/mc/nv4c.c | 8 -------- 1 file changed, 8 deletions(-) diff --git a/nvkm/subdev/mc/nv4c.c b/nvkm/subdev/mc/nv4c.c index a75c35c..165401c 100644 --- a/nvkm/subdev/mc/nv4c.c +++...

...ing > maintained. To those maintainers, please consider including this in > your trees. But it needs commit fa8c9ac72fe0bcdf5bc7cc84e85cc2a1af53f9fd Author: Ilia Mirkin <imirkin at alum.mit.edu> Date: Wed Feb 5 14:33:02 2014 -0500 drm/nv4c/mc: nv4x igp's have a different msi rearm register See https://bugs.freedesktop.org/show_bug.cgi?id=74492 which is only in 3.14. So I cannot take it into 3.12. thanks, -- js suse labs

..._CMDLINE_SIZE]; - memset(buf, 0, cmdline_size); + memset(buf, 0, NVKM_MSGQUEUE_CMDLINE_SIZE); nvkm_msgqueue_write_cmdline(queue, buf); - nvkm_falcon_load_dmem(falcon, buf, addr_args, cmdline_size, 0); + nvkm_falcon_load_dmem(falcon, buf, addr_args, + NVKM_MSGQUEUE_CMDLINE_SIZE, 0); /* rearm the queue so it will wait for the init message */ nvkm_msgqueue_reinit(queue); -- 2.7.4

...uf[cmdline_size]; + u8 buf[NVKM_MSGQUEUE_CMDLINE_SIZE]; - memset(buf, 0, cmdline_size); + memset(buf, 0, sizeof(buf)); nvkm_msgqueue_write_cmdline(queue, buf); - nvkm_falcon_load_dmem(falcon, buf, addr_args, cmdline_size, 0); + nvkm_falcon_load_dmem(falcon, buf, addr_args, sizeof(buf), 0); /* rearm the queue so it will wait for the init message */ nvkm_msgqueue_reinit(queue); -- 2.7.4

Just re-tried this, and it doesn't seem to fire getmail on access for me. My incrontab is as follows: /home/user/Maildir/cur/ IN_ALL_EVENTS,IN_ONESHOT /home/user/bin/mvmail.sh The incrontab rule does work, but only if I make a physical change in /home/user/Maildir/cur/ e.g. by moving a mail from another folder in there. Just accessing the particular inbox doesn't seem to trigger