[Nouveau] [Bug 69882] [NVE6] GPU lockups

2015-11-10 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=69882

--- Comment #18 from Dainius Masiliūnas  ---
Testing it a few more times, it is indeed the read fault by nouveau that's
causing the lockup in this case. The general DRM error does not appear during
all boots, but the nouveau read fault does. When waiting around for a long
time, the kernel log also has this:

INFO: task kworker/0:4:956 blocked for more than 480 seconds.
  Tainted: GW  O4.3.0-1-default #1
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
kworker/0:4 D  0   956  2 0x0080
Workqueue: events gk104_fifo_recover_work [nouveau]
8800d9d8bbc8 0046 8801fd2b2080 880214b0e040
8800d9d8c000 8800d9d8bd18 8800d9d8bd10 880214b0e040
8802142d8810 8800d9d8bbe0 8166a1aa 7fff
Call Trace:
[] schedule+0x3a/0x90
[] schedule_timeout+0x197/0x260
[] wait_for_completion+0x96/0x100
[] flush_work+0xed/0x180
[] gk104_fifo_fini+0x1d/0x50 [nouveau]
[] nvkm_fifo_fini+0x1c/0x30 [nouveau]
[] nvkm_engine_fini+0x20/0x30 [nouveau]
[] nvkm_subdev_fini+0x61/0x1e0 [nouveau]
[] gk104_fifo_recover_work+0xeb/0x290 [nouveau]
[] process_one_work+0x159/0x470
[] worker_thread+0x48/0x4a0
[] kthread+0xc9/0xe0
[] ret_from_fork+0x3f/0x70
DWARF2 unwinder stuck at ret_from_fork+0x3f/0x70

Leftover inexact backtrace:
[] ? kthread_worker_fn+0x170/0x170

I'm still not sure if this should be a separate bug report.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [PATCH] drm/nouveau: Fix pre-nv50 pageflip events (v3)

2015-11-10 Thread Mario Kleiner 
From: Daniel Vetter 

Apparently pre-nv50 pageflip events happen before the actual vblank
period. Therefore that functionality got semi-disabled in

commit af4870e406126b7ac0ae7c7ce5751f25ebe60f28
Author: Mario Kleiner 
Date:   Tue May 13 00:42:08 2014 +0200

drm/nouveau/kms/nv04-nv40: fix pageflip events via special case.

Unfortunately that hack got uprooted in

commit cc1ef118fc099295ae6aabbacc8af94d8d8885eb
Author: Thierry Reding 
Date:   Wed Aug 12 17:00:31 2015 +0200

drm/irq: Make pipe unsigned and name consistent

Trigering a warning when trying to sample the vblank timestamp for a
non-existing pipe. There's a few ways to fix this:

- Open-code the old behaviour, which just enshrines this slight
  breakage of the userspace ABI.

- Revert Mario's commit and again inflict broken timestamps, again not
  pretty.

- Fix this for real by delaying the pageflip TS until the next vblank
  interrupt, thereby making it accurate.

This patch implements the third option. Since having a page flip
interrupt that happens when the pageflip gets armed and not when it
completes in the next vblank seems to be fairly common (older i915 hw
works very similarly) create a new helper to arm vblank events for
such drivers.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=106431
Cc: Thierry Reding 
Cc: Mario Kleiner 
Cc: Ben Skeggs 
Cc: Ilia Mirkin 

v2 (mario): Integrate my own review comments into Daniels patch.
   - Fix function prototypes in drmP.h
   - Add missing vblank_put() for pageflip completion without
 pageflip event.
   - Initialize sequence number for queued pageflip event to avoid
 trouble in drm_handle_vblank_events().
   - Remove dead code and spelling fix.

v3 (mario): Add a signed-off-by and cc stable tag per Ilja's advice.

Signed-off-by: Daniel Vetter 
(v1) Reviewed-by: Mario Kleiner 
(v2/v3) Signed-off-by: Mario Kleiner 

Cc: sta...@vger.kernel.org # v4.3
---
 drivers/gpu/drm/drm_irq.c | 54 ++-
 drivers/gpu/drm/nouveau/nouveau_display.c | 19 ++-
 include/drm/drmP.h|  4 +++
 3 files changed, 68 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index eba6337..819b8c1 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -972,7 +972,8 @@ static void send_vblank_event(struct drm_device *dev,
struct drm_pending_vblank_event *e,
unsigned long seq, struct timeval *now)
 {
-   WARN_ON_SMP(!spin_is_locked(>event_lock));
+   assert_spin_locked(>event_lock);
+
e->event.sequence = seq;
e->event.tv_sec = now->tv_sec;
e->event.tv_usec = now->tv_usec;
@@ -985,6 +986,57 @@ static void send_vblank_event(struct drm_device *dev,
 }
 
 /**
+ * drm_arm_vblank_event - arm vblank event after pageflip
+ * @dev: DRM device
+ * @pipe: CRTC index
+ * @e: the event to prepare to send
+ *
+ * A lot of drivers need to generate vblank events for the very next vblank
+ * interrupt. For example when the page flip interrupt happens when the page
+ * flip gets armed, but not when it actually executes within the next vblank
+ * period. This helper function implements exactly the required vblank arming
+ * behaviour.
+ *
+ * Caller must hold event lock. Caller must also hold a vblank reference for 
the
+ * event @e, which will be dropped when the next vblank arrives.
+ *
+ * This is the legacy version of drm_crtc_arm_vblank_event().
+ */
+void drm_arm_vblank_event(struct drm_device *dev, unsigned int pipe,
+ struct drm_pending_vblank_event *e)
+{
+   assert_spin_locked(>event_lock);
+
+   e->pipe = pipe;
+   e->event.sequence = drm_vblank_count(dev, pipe);
+   list_add_tail(>base.link, >vblank_event_list);
+}
+EXPORT_SYMBOL(drm_arm_vblank_event);
+
+/**
+ * drm_arm_vblank_event - arm vblank event after pageflip
+ * @crtc: the source CRTC of the vblank event
+ * @e: the event to send
+ *
+ * A lot of drivers need to generate vblank events for the very next vblank
+ * interrupt. For example when the page flip interrupt happens when the page
+ * flip gets armed, but not when it actually executes within the next vblank
+ * period. This helper function implements exactly the required vblank arming
+ * behaviour.
+ *
+ * Caller must hold event lock. Caller must also hold a vblank reference for 
the
+ * event @e, which will be dropped when the next vblank arrives.
+ *
+ * This is the native KMS version of drm_send_vblank_event().
+ */
+void drm_crtc_arm_vblank_event(struct drm_crtc *crtc,
+  struct drm_pending_vblank_event *e)
+{
+   drm_arm_vblank_event(crtc->dev, drm_crtc_index(crtc), e);
+}

Re: [Nouveau] [PATCH] drm/nouveau: Fix pre-nv50 pageflip events (v3)

2015-11-10 Thread Thierry Reding 
On Tue, Nov 10, 2015 at 03:54:52PM +0100, Mario Kleiner wrote:
> From: Daniel Vetter 
> 
> Apparently pre-nv50 pageflip events happen before the actual vblank
> period. Therefore that functionality got semi-disabled in
> 
> commit af4870e406126b7ac0ae7c7ce5751f25ebe60f28
> Author: Mario Kleiner 
> Date:   Tue May 13 00:42:08 2014 +0200
> 
> drm/nouveau/kms/nv04-nv40: fix pageflip events via special case.
> 
> Unfortunately that hack got uprooted in
> 
> commit cc1ef118fc099295ae6aabbacc8af94d8d8885eb
> Author: Thierry Reding 
> Date:   Wed Aug 12 17:00:31 2015 +0200
> 
> drm/irq: Make pipe unsigned and name consistent
> 
> Trigering a warning when trying to sample the vblank timestamp for a
> non-existing pipe. There's a few ways to fix this:
> 
> - Open-code the old behaviour, which just enshrines this slight
>   breakage of the userspace ABI.
> 
> - Revert Mario's commit and again inflict broken timestamps, again not
>   pretty.
> 
> - Fix this for real by delaying the pageflip TS until the next vblank
>   interrupt, thereby making it accurate.
> 
> This patch implements the third option. Since having a page flip
> interrupt that happens when the pageflip gets armed and not when it
> completes in the next vblank seems to be fairly common (older i915 hw
> works very similarly) create a new helper to arm vblank events for
> such drivers.
> 
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=106431
> Cc: Thierry Reding 
> Cc: Mario Kleiner 
> Cc: Ben Skeggs 
> Cc: Ilia Mirkin 
> 
> v2 (mario): Integrate my own review comments into Daniels patch.
>- Fix function prototypes in drmP.h
>- Add missing vblank_put() for pageflip completion without
>  pageflip event.
>- Initialize sequence number for queued pageflip event to avoid
>  trouble in drm_handle_vblank_events().
>- Remove dead code and spelling fix.
> 
> v3 (mario): Add a signed-off-by and cc stable tag per Ilja's advice.
> 
> Signed-off-by: Daniel Vetter 
> (v1) Reviewed-by: Mario Kleiner 
> (v2/v3) Signed-off-by: Mario Kleiner 
> 
> Cc: sta...@vger.kernel.org # v4.3
> ---
>  drivers/gpu/drm/drm_irq.c | 54 
> ++-
>  drivers/gpu/drm/nouveau/nouveau_display.c | 19 ++-
>  include/drm/drmP.h|  4 +++
>  3 files changed, 68 insertions(+), 9 deletions(-)

This looks good to me. Let me clean this up a little and submit it to
Dave.

Thierry


signature.asc
Description: PGP signature
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH] drm/nouveau: Fix pre-nv50 pageflip events (v3)

2015-11-10 Thread Mario Kleiner 

On 11/10/2015 05:00 PM, Thierry Reding wrote:

On Tue, Nov 10, 2015 at 03:54:52PM +0100, Mario Kleiner wrote:

From: Daniel Vetter 

Apparently pre-nv50 pageflip events happen before the actual vblank
period. Therefore that functionality got semi-disabled in

commit af4870e406126b7ac0ae7c7ce5751f25ebe60f28
Author: Mario Kleiner 
Date:   Tue May 13 00:42:08 2014 +0200

 drm/nouveau/kms/nv04-nv40: fix pageflip events via special case.

Unfortunately that hack got uprooted in

commit cc1ef118fc099295ae6aabbacc8af94d8d8885eb
Author: Thierry Reding 
Date:   Wed Aug 12 17:00:31 2015 +0200

 drm/irq: Make pipe unsigned and name consistent

Trigering a warning when trying to sample the vblank timestamp for a
non-existing pipe. There's a few ways to fix this:

- Open-code the old behaviour, which just enshrines this slight
   breakage of the userspace ABI.

- Revert Mario's commit and again inflict broken timestamps, again not
   pretty.

- Fix this for real by delaying the pageflip TS until the next vblank
   interrupt, thereby making it accurate.

This patch implements the third option. Since having a page flip
interrupt that happens when the pageflip gets armed and not when it
completes in the next vblank seems to be fairly common (older i915 hw
works very similarly) create a new helper to arm vblank events for
such drivers.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=106431
Cc: Thierry Reding 
Cc: Mario Kleiner 
Cc: Ben Skeggs 
Cc: Ilia Mirkin 

v2 (mario): Integrate my own review comments into Daniels patch.
- Fix function prototypes in drmP.h
- Add missing vblank_put() for pageflip completion without
  pageflip event.
- Initialize sequence number for queued pageflip event to avoidng
  trouble in drm_handle_vblank_events().
- Remove dead code and spelling fix.

v3 (mario): Add a signed-off-by and cc stable tag per Ilja's advice.

Signed-off-by: Daniel Vetter 
(v1) Reviewed-by: Mario Kleiner 
(v2/v3) Signed-off-by: Mario Kleiner 

Cc: sta...@vger.kernel.org # v4.3
---
  drivers/gpu/drm/drm_irq.c | 54 ++-
  drivers/gpu/drm/nouveau/nouveau_display.c | 19 ++-
  include/drm/drmP.h|  4 +++
  3 files changed, 68 insertions(+), 9 deletions(-)


This looks good to me. Let me clean this up a little and submit it to
Dave.

Thierry



Btw., if somebody has a functional old card for testing this, it should 
be easy to verify if it works on pre-nv50. If it would not work it would 
deliver the pageflip event 1 frame delayed, so at least on standard 
nouveau + default DRI2 + default double-buffering the rate for a tight 
loop of page-flipped swaps should go down to 30 fps on a 60 Hz display, 
quite noticeable. Afaik we also have Piglit tests for OML_sync_control 
which would likely fail if this would be broken.


Oh and if someone has tips on how to resurrect an old nv-40 PC (booted 
with BIOS only) graphics card in a MacPro (EFI boot), i wouldn't mind 
hearing them. It would be nice to still be able to use that card for 
testing.


thanks,
-mario
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 92892] [NVA8] KDE Plasma locks up: Nouveau reports error "resource sanity check" "unable to handle kernel paging request"

2015-11-10 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=92892

Ilia Mirkin  changed:

   What|Removed |Added

Summary|KDE Plasma locks up:|[NVA8] KDE Plasma locks up:
   |Nouveau reports error   |Nouveau reports error
   |"resource sanity check" |"resource sanity check"
   |"unable to handle kernel|"unable to handle kernel
   |paging request" |paging request"

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 92892] KDE Plasma locks up: Nouveau reports error "resource sanity check" "unable to handle kernel paging request"

2015-11-10 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=92892

--- Comment #1 from Volker Lukas  ---
Created attachment 119548
  --> https://bugs.freedesktop.org/attachment.cgi?id=119548=edit
Output of hwinfo --gfx

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 92892] [NVA8] KDE Plasma locks up: Nouveau reports error "resource sanity check" "unable to handle kernel paging request"

2015-11-10 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=92892

--- Comment #2 from Volker Lukas  ---
Created attachment 119549
  --> https://bugs.freedesktop.org/attachment.cgi?id=119549=edit
Version information of some relevant packages

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 92863] Complete freeze even with NvGrUseFW=1

2015-11-10 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=92863

--- Comment #9 from xen...@overtmind.com ---
[61117.028780] nouveau E[   PFIFO][:01:00.0] read fault at 0x0002456000
[PTE] from GR/GPC2/T1_0 on channel 0x023f65 [plasmashell[15103]]
[61117.028784] nouveau E[   PFIFO][:01:00.0] PGRAPH engine fault on channel
8, recovering...
[61117.028793] nouveau E[  PGRAPH][:01:00.0] TRAP ch 8 [0x023f65
plasmashell[15103]]
[61117.028799] nouveau E[  PGRAPH][:01:00.0] GPC0/TPC0/TEX: 0x8049
[61117.028804] nouveau E[  PGRAPH][:01:00.0] GPC1/TPC0/TEX: 0x8049
[61117.028808] nouveau E[  PGRAPH][:01:00.0] GPC1/TPC1/TEX: 0x8049
[61117.028814] nouveau E[  PGRAPH][:01:00.0] GPC2/TPC0/TEX: 0x8049
[61117.028818] nouveau E[  PGRAPH][:01:00.0] GPC2/TPC1/TEX: 0x8049
[61196.361410] nouveau E[Xorg[14738]] failed to idle channel 0x
[Xorg[14738]]
[61211.347041] nouveau E[Xorg[14738]] failed to idle channel 0x
[Xorg[14738]]
[61211.348250] nouveau E[   PFIFO][:01:00.0] read fault at 0x023000
[PTE] from PBDMA0/HOST_CPU on channel 0x023fc2 [unknown]
[61226.391616] nouveau E[kwin_x11[15043]] failed to idle channel 0x
[kwin_x11[15043]]
[61241.377248] nouveau E[kwin_x11[15043]] failed to idle channel 0x
[kwin_x11[15043]]
[61256.373870] nouveau E[abrt-applet[15208]] failed to idle channel 0x
[abrt-applet[15208]]
[61271.359500] nouveau E[abrt-applet[15208]] failed to idle channel 0x
[abrt-applet[15208]]
[61272.787225] nouveau E[ DRM] GPU lockup - switching to software fbcon
[61286.430049] nouveau E[krunner[15049]] failed to idle channel 0x
[krunner[15049]]
[61301.415681] nouveau E[krunner[15049]] failed to idle channel 0x
[krunner[15049]]
[61316.413300] nouveau E[owncloud[15369]] failed to idle channel 0x
[owncloud[15369]]
[61331.398930] nouveau E[owncloud[15369]] failed to idle channel 0x
[owncloud[15369]]
[61346.394552] nouveau E[konversation[15193]] failed to idle channel 0x
[konversation[15193]]
[61361.380183] nouveau E[konversation[15193]] failed to idle channel 0x
[konversation[15193]]
[61376.372810] nouveau E[Compositor[8716]] failed to idle channel 0x
[Compositor[8716]]
[61391.358520] nouveau E[Compositor[8716]] failed to idle channel 0x
[Compositor[8716]]
[61406.348148] nouveau E[plasmashell[15103]] failed to idle channel 0x
[plasmashell[15103]]
[61421.333780] nouveau E[plasmashell[15103]] failed to idle channel 0x
[plasmashell[15103]]
[61436.335397] nouveau E[Compositor[9501]] failed to idle channel 0x
[Compositor[9501]]
[61451.321028] nouveau E[Compositor[9501]] failed to idle channel 0x
[Compositor[9501]]
[61466.314650] nouveau E[Compositor[10121]] failed to idle channel 0x
[Compositor[10121]]
[61481.300274] nouveau E[Compositor[10121]] failed to idle channel 0x
[Compositor[10121]]

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 92851] NV34: err: MEM_FAULT

2015-11-10 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=92851

--- Comment #8 from poma  ---

The same happens with:

- XRender - configure --enable-render --disable-epoxy --disable-xpresent
   Build Configuration for xfwm4:
 XSync support:yes
 Render support:   yes
 Xrandr support:   yes
 Xpresent support: no
 Embedded compositor:  yes
 Epoxy support:no


as if the compositor as whole is affected.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 92892] [NVA8] KDE Plasma locks up: Nouveau reports error "resource sanity check" "unable to handle kernel paging request"

2015-11-10 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=92892

--- Comment #3 from Volker Lukas  ---
Created attachment 119550
  --> https://bugs.freedesktop.org/attachment.cgi?id=119550=edit
Recent weeks of package install history

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 92892] New: KDE Plasma locks up: Nouveau reports error "resource sanity check" "unable to handle kernel paging request"

2015-11-10 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=92892

Bug ID: 92892
   Summary: KDE Plasma locks up: Nouveau reports error "resource
sanity check" "unable to handle kernel paging request"
   Product: Mesa
   Version: 11.0
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/DRI/nouveau
  Assignee: nouveau@lists.freedesktop.org
  Reporter: vlu...@gmx.de
QA Contact: nouveau@lists.freedesktop.org

Created attachment 119547
  --> https://bugs.freedesktop.org/attachment.cgi?id=119547=edit
Dmesg from system start until and including the second time a kernel backtrace
appears

I was referred by my distributions bug tracking to report an error related to
the Nouveau drivers here.

I use the "Tumbleweed" distribution by Opensuse. This is a kind of rolling
release with package upgrades circa once a week. On 2015-11-08 I pulled that
distributions latest snapshot, which installed among not many other packages
Linux kernel version 4.3.0, which was an upgrade from 4.2.4.

Since then I experience grave issues when using the KDE desktop. Beginning on
that Sunday (i.e. 2015-11-08) after some time of using the desktop I noticed
that KDEs text editor ("Kwrite") would not start anymore when launched from the
file manager. Initially I thought this was an communcation problem inside KDE,
because I could restart the file manager and managed to open one text file. But
then, attempting to launch a second instance of Kwrite via the file mananger
failed again. I tried repeatedly and found that after very few attempts Kwrite
could not be launched anymore. At that time I could still interact with other,
running programs. But after some time the whole desktop locked up. Not even
switchting to a text console via Ctrl + F1 worked. The system had to be
rebooted.

I can now reproduce a whole desktop lockup by this simple procedure:

- Power on
- Login in KDM
- Pressing Alt + F2, then typing konsole in the mini command line
- Entering dmesg in Konsole window.
- Opening a second Konsole tab.
- In that new tab, typing kwrite. Kwrite is not launched successfully by that
attempt.


To gather information, I installed kernel version 4.2.4 from the distributions
package in parallel to 4.3.0.

When I boot 4.2.4, I can not reproduce the desktop lockups.

I have attached the complete dmesg output which stems from the procedure to
reproduce above. As you can see, there are some suspicious kernel backtraces
related to Nouveau. One of these backtraces is associated in time closely to
attempting to launch Kwrite, i.e. after I type "dmesg" for the first time I
only see one backtrace. Then, after entering kwrite I can request dmesg again
and spot the second kernel backtrace.

With slightly older kernel versions I also get these kernel backtraces in the
system log (journalctl), but I do NOT experience whole desktop lockups. With
even older kernel versions, I do not get these types of kernel backtraces. 
These are the lines from when journactl indicates a similar backtrace for the
first time: (The installed kernel must have been 4.2.3 as far as I can
determine through inspecting the package install history logfile.)
- Kernel 4.2.3:

Okt 27 15:42:10 linux-5rjk kernel: resource sanity check: requesting [mem
0xddf6d000-0xde06cfff], which spans more than :01:00.0 [mem
0xdc00-0xddff 64bit pref]
Okt 27 15:42:10 linux-5rjk kernel: [ cut here ]
Okt 27 15:42:10 linux-5rjk kernel: WARNING: CPU: 0 PID: 5113 at
../arch/x86/mm/ioremap.c:198 __ioremap_caller+0x2de/0x360()
Okt 27 15:42:10 linux-5rjk kernel: Info: mapping multiple BARs. Your kernel is
fine.
Okt 27 15:42:10 linux-5rjk kernel: Modules linked in:
Okt 27 15:42:10 linux-5rjk kernel:  nf_log_ipv6 xt_pkttype nf_log_ipv4
nf_log_common xt_LOG xt_limit iscsi_ibft iscsi_boot_sysfs af_packet ip6t_REJECT
xt_tcpudp nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_raw ipt_REJECT iptable_raw
xt_CT iptable_filter ip6table_mangle nf_conntrack_netbios_ns
nf_conntrack_broadcast nf_conntrack_ipv4 nf_defrag_ipv4 ip_tables xt_conntrack
nf_conntrack ip6table_filter ip6_tables x_tables snd_hda_codec_hdmi
snd_hda_codec_analog snd_hda_codec_generic iTCO_wdt gpio_ich
iTCO_vendor_support ppdev dm_mod coretemp kvm_intel kvm pcspkr i2c_i801
snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep lpc_ich mfd_core snd_pcm
asus_atk0110 8250_fintek parport_pc parport snd_timer nouveau snd mxm_wmi wmi
video ttm drm_kms_helper drm i2c_algo_bit acpi_cpufreq button processor shpchp
soundcore hid_generic usbhid
Okt 27 15:42:10 linux-5rjk kernel:  ata_generic serio_raw firewire_ohci
firewire_core crc_itu_t atl1 mii pata_jmicron ehci_pci uhci_hcd ehci_hcd
usbcore usb_common sg
Okt 27 15:42:10 linux-5rjk kernel: CPU: 0 PID: 5113 Comm: kwrite Not tainted

[Nouveau] [Bug 92892] [NVA8] KDE Plasma locks up: Nouveau reports error "resource sanity check" "unable to handle kernel paging request"

2015-11-10 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=92892

--- Comment #4 from Ilia Mirkin  ---
Nouveau underwent a significant rewrite for kernel 4.3. Any chance you could
bisect the changes to drivers/gpu/drm/nouveau between v4.2 and v4.3?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 92893] NV34: XPresent compositor scrambled

2015-11-10 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=92893

--- Comment #4 from Ilia Mirkin  ---
(In reply to poma from comment #3)
> (In reply to Ilia Mirkin from comment #2)
> > (In reply to poma from comment #0)
> > > Created attachment 119551 [details]
> > > NV34 xf86-video-nouveau XPresent scramble
> > > 
> > > "enable dri3 support without glamor"
> > > http://cgit.freedesktop.org/nouveau/xf86-video-nouveau/commit/?id=241e728
> > > 
> > > broke XPresent compositor on NV34.
> > 
> > Yeah that commit had a bunch of problems, many of which were subsequently
> > fixed. Do the issues still happen with git head? Or at least at commit
> > 08ef36dc67 ?
> 
> For NV34, tutto completo ist kaputt.

Please answer my questions.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 92893] NV34: XPresent compositor scrambled display

2015-11-10 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=92893

poma  changed:

   What|Removed |Added

Summary|NV34: XPresent compositor   |NV34: XPresent compositor
   |scrambled   |scrambled display

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 92893] NV34: XPresent compositor scrambled

2015-11-10 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=92893

--- Comment #2 from Ilia Mirkin  ---
(In reply to poma from comment #0)
> Created attachment 119551 [details]
> NV34 xf86-video-nouveau XPresent scramble
> 
> "enable dri3 support without glamor"
> http://cgit.freedesktop.org/nouveau/xf86-video-nouveau/commit/?id=241e728
> 
> broke XPresent compositor on NV34.

Yeah that commit had a bunch of problems, many of which were subsequently
fixed. Do the issues still happen with git head? Or at least at commit
08ef36dc67 ?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 92893] NV34: XPresent compositor scrambled

2015-11-10 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=92893

--- Comment #3 from poma  ---
(In reply to Ilia Mirkin from comment #2)
> (In reply to poma from comment #0)
> > Created attachment 119551 [details]
> > NV34 xf86-video-nouveau XPresent scramble
> > 
> > "enable dri3 support without glamor"
> > http://cgit.freedesktop.org/nouveau/xf86-video-nouveau/commit/?id=241e728
> > 
> > broke XPresent compositor on NV34.
> 
> Yeah that commit had a bunch of problems, many of which were subsequently
> fixed. Do the issues still happen with git head? Or at least at commit
> 08ef36dc67 ?


For NV34, tutto completo ist kaputt.

For all other GPUs tested - AMD, INTEL, NVIDIA - DRI3/XPresent compositor is
actually recommended, it outperforms GLX compositor.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 92851] NV34: Xfwm4 compositor broken on S4(Suspend to disk) RESUME

2015-11-10 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=92851

poma  changed:

   What|Removed |Added

Summary|NV34: Xfwm4 compositor  |NV34: Xfwm4 compositor
   |broken on S4 RESUME(Suspend |broken on S4(Suspend to
   |to disk)|disk) RESUME

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 92851] NV34: Xfwm4 compositor broken on S4 RESUME(Suspend to disk)

2015-11-10 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=92851

poma  changed:

   What|Removed |Added

Summary|NV34: err: MEM_FAULT|NV34: Xfwm4 compositor
   ||broken on S4 RESUME(Suspend
   ||to disk)

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 92893] New: NV34: XPresent compositor scrambled

2015-11-10 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=92893

Bug ID: 92893
   Summary: NV34: XPresent compositor scrambled
   Product: xorg
   Version: git
  Hardware: x86 (IA32)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Driver/nouveau
  Assignee: nouveau@lists.freedesktop.org
  Reporter: pomidorabelis...@gmail.com
QA Contact: xorg-t...@lists.x.org

Created attachment 119551
  --> https://bugs.freedesktop.org/attachment.cgi?id=119551=edit
NV34 xf86-video-nouveau XPresent scramble

"enable dri3 support without glamor"
http://cgit.freedesktop.org/nouveau/xf86-video-nouveau/commit/?id=241e728

broke XPresent compositor on NV34.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 92893] NV34: XPresent compositor scrambled

2015-11-10 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=92893

--- Comment #1 from poma  ---

- DRI2&3/XPresent - configure --disable-epoxy --enable-xpresent
   Build Configuration for xfwm4:
 Xpresent support: yes
 Epoxy support:no

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 92893] NV34: XPresent compositor scrambled

2015-11-10 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=92893

--- Comment #5 from poma  ---
(In reply to Ilia Mirkin from comment #4)
> (In reply to poma from comment #3)
> > (In reply to Ilia Mirkin from comment #2)
> > > (In reply to poma from comment #0)
> > > > Created attachment 119551 [details]
> > > > NV34 xf86-video-nouveau XPresent scramble
> > > > 
> > > > "enable dri3 support without glamor"
> > > > http://cgit.freedesktop.org/nouveau/xf86-video-nouveau/commit/?id=241e728
> > > > 
> > > > broke XPresent compositor on NV34.
> > > 
> > > Yeah that commit had a bunch of problems, many of which were subsequently
> > > fixed. Do the issues still happen with git head? Or at least at commit
> > > 08ef36dc67 ?
> > 
> > For NV34, tutto completo ist kaputt.
> 
> Please answer my questions.

For NV34,
"tutto completo ist kaputt" - translated: all of them are broken.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 92893] NV34: XPresent compositor scrambled

2015-11-10 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=92893

poma  changed:

   What|Removed |Added

 Attachment #119551|text/plain  |image/jpg
  mime type||

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 92863] Complete freeze even with NvGrUseFW=1

2015-11-10 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=92863

--- Comment #10 from xen...@overtmind.com ---
[2.087715] nouveau  [  DEVICE][:01:00.0] BOOT0  : 0x0e6000a1
[2.087716] nouveau  [  DEVICE][:01:00.0] Chipset: GK106 (NVE6)
[2.087717] nouveau  [  DEVICE][:01:00.0] Family : NVE0
[2.147941] nouveau  [   VBIOS][:01:00.0] using image from PROM
[2.148026] nouveau  [   VBIOS][:01:00.0] BIT signature found
[2.148028] nouveau  [   VBIOS][:01:00.0] version 80.06.28.00.08
[2.148267] nouveau  [ PMC][:01:00.0] MSI interrupts enabled
[2.148309] nouveau  [ PFB][:01:00.0] RAM type: GDDR5
[2.148310] nouveau  [ PFB][:01:00.0] RAM size: 2048 MiB
[2.148311] nouveau  [ PFB][:01:00.0]ZCOMP: 0 tags
[2.150251] nouveau  [VOLT][:01:00.0] GPU voltage: 862500uv
[2.199717] nouveau  [  PTHERM][:01:00.0] FAN control: PWM
[2.199730] nouveau  [  PTHERM][:01:00.0] fan management: automatic
[2.199747] nouveau  [  PTHERM][:01:00.0] internal sensor: yes
[2.199799] nouveau  [ CLK][:01:00.0] 07: core 324 MHz memory 648
MHz 
[2.199817] nouveau  [ CLK][:01:00.0] 0a: core 324-862 MHz memory
1620 MHz 
[2.199867] nouveau  [ CLK][:01:00.0] 0d: core 549-1280 MHz memory
6008 MHz 
[2.199927] nouveau  [ CLK][:01:00.0] 0f: core 549-1280 MHz memory
6008 MHz 
[2.16] nouveau  [ CLK][:01:00.0] --: core 324 MHz memory 648
MHz 
[2.321325] nouveau  [  PGRAPH][:01:00.0] using external firmware
[2.321845] nouveau  [ DRM] VRAM: 2048 MiB
[2.321847] nouveau  [ DRM] GART: 1048576 MiB
[2.321852] nouveau  [ DRM] TMDS table version 2.0
[2.321854] nouveau  [ DRM] DCB version 4.0
[2.321857] nouveau  [ DRM] DCB outp 00: 02000f00 
[2.321860] nouveau  [ DRM] DCB outp 01: 01000f02 00020030
[2.321862] nouveau  [ DRM] DCB outp 03: 02011f62 00020010
[2.321864] nouveau  [ DRM] DCB outp 04: 04822fb6 0f420010
[2.321866] nouveau  [ DRM] DCB outp 05: 04022f72 00020010
[2.321868] nouveau  [ DRM] DCB outp 06: 08033f82 00020030
[2.321870] nouveau  [ DRM] DCB conn 00: 1030
[2.321873] nouveau  [ DRM] DCB conn 01: 00010161
[2.321875] nouveau  [ DRM] DCB conn 02: 00020246
[2.321877] nouveau  [ DRM] DCB conn 03: 01000331
[2.331934] nouveau  [ DRM] MM: using COPY for buffer copies
[2.618631] nouveau  [ DRM] allocated 1920x1080 fb: 0x6, bo
880408cea000
[2.618767] fbcon: nouveaufb (fb0) is primary device
[3.105431] nouveau :01:00.0: fb0: nouveaufb frame buffer device
[3.105431] nouveau :01:00.0: registered panic notifier
[3.117562] [drm] Initialized nouveau 1.2.2 20120801 for :01:00.0 on
minor 0
[ 4940.515646] nouveau E[   PFIFO][:01:00.0] PBDMA0: SIGNATURE
[ 4940.515652] nouveau E[   PFIFO][:01:00.0] PBDMA0: ch 16 [dolphin[8564]]
subc 7 mthd 0x1808 data 0x0017180a
[ 4940.515668] nouveau E[   PFIFO][:01:00.0] PBDMA0: SIGNATURE
[ 4940.515670] nouveau E[   PFIFO][:01:00.0] PBDMA0: ch 16 [dolphin[8564]]
subc 7 mthd 0x1808 data 0x0017180a
[ 4940.515682] nouveau E[   PFIFO][:01:00.0] PBDMA0: GPPTR PBENTRY
SIGNATURE
[ 4940.515684] nouveau E[   PFIFO][:01:00.0] PBDMA0: ch 16 [dolphin[8564]]
subc 7 mthd 0x1808 data 0x0017180a
[ 4940.515695] nouveau E[   PFIFO][:01:00.0] PBDMA0: GPPTR PBENTRY
SIGNATURE
[ 4940.515697] nouveau E[   PFIFO][:01:00.0] PBDMA0: ch 16 [dolphin[8564]]
subc 7 mthd 0x1808 data 0x0017180a
[ 4940.515709] nouveau E[   PFIFO][:01:00.0] PBDMA0: GPPTR PBENTRY
SIGNATURE
[ 4940.515710] nouveau E[   PFIFO][:01:00.0] PBDMA0: ch 16 [dolphin[8564]]
subc 7 mthd 0x1808 data 0x0017180a
[ 4940.515723] nouveau E[   PFIFO][:01:00.0] PBDMA0: GPPTR SIGNATURE
[ 4940.515725] nouveau E[   PFIFO][:01:00.0] PBDMA0: ch 16 [dolphin[8564]]
subc 7 mthd 0x1808 data 0x0017180a
[ 4940.515727] nouveau E[   PFIFO][:01:00.0] PBDMA0: HCE_RE_ILLEGAL_OP
[ 4940.515730] nouveau E[   PFIFO][:01:00.0] PBDMA0: ch 16 1808
0017180a
[ 4940.515739] nouveau E[   PFIFO][:01:00.0] PBDMA0: SIGNATURE
[ 4940.515741] nouveau E[   PFIFO][:01:00.0] PBDMA0: ch 16 [dolphin[8564]]
subc 7 mthd 0x1808 data 0x0017180a
[ 4940.515753] nouveau E[   PFIFO][:01:00.0] PBDMA0: SIGNATURE
[ 4940.515754] nouveau E[   PFIFO][:01:00.0] PBDMA0: ch 16 [dolphin[8564]]
subc 7 mthd 0x1808 data 0x0017180a
[ 4940.515772] nouveau E[   PFIFO][:01:00.0] PBDMA0: SIGNATURE
[ 4940.515774] nouveau E[   PFIFO][:01:00.0] PBDMA0: ch 16 [dolphin[8564]]
subc 7 mthd 0x1808 data 0x0017180a
[ 4940.515785] nouveau E[   PFIFO][:01:00.0] PBDMA0: SIGNATURE
[ 4940.515787] nouveau E[   PFIFO][:01:00.0] PBDMA0: ch 16 [dolphin[8564]]
subc 7 mthd 0x1808 data 0x0017180a
[ 4940.515800] nouveau E[   PFIFO][:01:00.0] read fault at 0x02000f1000
[VA_LIMIT_VIOLATION] from PBDMA0/HOST on channel 0x023eec4000 [unknown]

--

[Nouveau] [Bug 92892] [NVA8] KDE Plasma locks up: Nouveau reports error "resource sanity check" "unable to handle kernel paging request"

2015-11-10 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=92892

--- Comment #5 from Volker Lukas  ---
I will try to bisect between 4.2 and 4.3. I will likely not report back until
the weekend. Thanks for answering so fast.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH] instmem/gk20a: fix race conditions

2015-11-10 Thread Ben Skeggs 
On 11/09/2015 05:37 PM, Alexandre Courbot wrote:
> The LRU list used for recycling CPU mappings was handling concurrency
> very poorly. For instance, if an instobj was acquired twice before being
> released once, it would end up into the LRU list even though there is
> still a client accessing it.
> 
> This patch fixes this by properly counting how many clients are
> currently using a given instobj.
Out of curiosity, which instobjs are being accessed concurrently?

> 
> While at it, we also raise errors when inconsistencies are detected, and
> factorize some code.
> 
> Signed-off-by: Alexandre Courbot 
> ---
>  drm/nouveau/nvkm/subdev/instmem/gk20a.c | 66 
> ++---
>  1 file changed, 37 insertions(+), 29 deletions(-)
> 
> diff --git a/drm/nouveau/nvkm/subdev/instmem/gk20a.c 
> b/drm/nouveau/nvkm/subdev/instmem/gk20a.c
> index fc419bb8eab7..681b2541229a 100644
> --- a/drm/nouveau/nvkm/subdev/instmem/gk20a.c
> +++ b/drm/nouveau/nvkm/subdev/instmem/gk20a.c
> @@ -57,6 +57,8 @@ struct gk20a_instobj {
>   /* CPU mapping */
>   u32 *vaddr;
>   struct list_head vaddr_node;
> + /* How many clients are using vaddr? */
> + u32 use_cpt;
>  };
>  #define gk20a_instobj(p) container_of((p), struct gk20a_instobj, memory)
>  
> @@ -158,27 +160,35 @@ gk20a_instobj_cpu_map_iommu(struct nvkm_memory *memory)
>  }
>  
>  /*
> - * Must be called while holding gk20a_instmem_lock
> + * Recycle the vaddr of obj. Must be called with gk20a_instmem::lock held.
> + */
> +static void
> +gk20a_instobj_recycle_vaddr(struct gk20a_instobj *obj)
> +{
> + struct gk20a_instmem *imem = obj->imem;
> + /* there should not be any user left... */
> + WARN_ON(obj->use_cpt);
> + list_del(>vaddr_node);
> + vunmap(obj->vaddr);
> + obj->vaddr = NULL;
> + imem->vaddr_use -= nvkm_memory_size(>memory);
> + nvkm_debug(>base.subdev, "vaddr used: %x/%x\n", imem->vaddr_use,
> +imem->vaddr_max);
> +}
> +
> +/*
> + * Must be called while holding gk20a_instmem::lock
>   */
>  static void
>  gk20a_instmem_vaddr_gc(struct gk20a_instmem *imem, const u64 size)
>  {
>   while (imem->vaddr_use + size > imem->vaddr_max) {
> - struct gk20a_instobj *obj;
> -
>   /* no candidate that can be unmapped, abort... */
>   if (list_empty(>vaddr_lru))
>   break;
>  
> - obj = list_first_entry(>vaddr_lru, struct gk20a_instobj,
> -vaddr_node);
> - list_del(>vaddr_node);
> - vunmap(obj->vaddr);
> - obj->vaddr = NULL;
> - imem->vaddr_use -= nvkm_memory_size(>memory);
> - nvkm_debug(>base.subdev, "(GC) vaddr used: %x/%x\n",
> -imem->vaddr_use, imem->vaddr_max);
> -
> + gk20a_instobj_recycle_vaddr(list_first_entry(>vaddr_lru,
> +  struct gk20a_instobj, vaddr_node));
>   }
>  }
>  
> @@ -196,9 +206,10 @@ gk20a_instobj_acquire(struct nvkm_memory *memory)
>   spin_lock_irqsave(>lock, flags);
>  
>   if (node->vaddr) {
> - /* remove us from the LRU list since we cannot be unmapped */
> - list_del(>vaddr_node);
> -
> + if (!node->use_cpt) {
> + /* remove from LRU list since mapping in use again */
> + list_del(>vaddr_node);
> + }
>   goto out;
>   }
>  
> @@ -218,6 +229,7 @@ gk20a_instobj_acquire(struct nvkm_memory *memory)
>  imem->vaddr_use, imem->vaddr_max);
>  
>  out:
> + node->use_cpt++;
>   spin_unlock_irqrestore(>lock, flags);
>  
>   return node->vaddr;
> @@ -233,9 +245,15 @@ gk20a_instobj_release(struct nvkm_memory *memory)
>  
>   spin_lock_irqsave(>lock, flags);
>  
> - /* add ourselves to the LRU list so our CPU mapping can be freed */
> - list_add_tail(>vaddr_node, >vaddr_lru);
> + /* we should at least have one user to release... */
> + if (WARN_ON(node->use_cpt == 0))
> + goto out;
> +
> + /* add unused objs to the LRU list to recycle their mapping */
> + if (--node->use_cpt == 0)
> + list_add_tail(>vaddr_node, >vaddr_lru);
>  
> +out:
>   spin_unlock_irqrestore(>lock, flags);
>  
>   wmb();
> @@ -273,25 +291,15 @@ static void
>  gk20a_instobj_dtor(struct gk20a_instobj *node)
>  {
>   struct gk20a_instmem *imem = node->imem;
> - struct gk20a_instobj *obj;
>   unsigned long flags;
>  
>   spin_lock_irqsave(>lock, flags);
>  
> + /* vaddr has already been recycled */
>   if (!node->vaddr)
>   goto out;
>  
> - list_for_each_entry(obj, >vaddr_lru, vaddr_node) {
> - if (obj == node) {
> - list_del(>vaddr_node);
> - break;
> - }
> - }
> - vunmap(node->vaddr);
> - node->vaddr = NULL;
> - imem->vaddr_use -=

Re: [Nouveau] [PATCH] instmem/gk20a: fix race conditions

2015-11-10 Thread Alexandre Courbot 
On Wed, Nov 11, 2015 at 9:19 AM, Ben Skeggs  wrote:
> On 11/09/2015 05:37 PM, Alexandre Courbot wrote:
>> The LRU list used for recycling CPU mappings was handling concurrency
>> very poorly. For instance, if an instobj was acquired twice before being
>> released once, it would end up into the LRU list even though there is
>> still a client accessing it.
>>
>> This patch fixes this by properly counting how many clients are
>> currently using a given instobj.
> Out of curiosity, which instobjs are being accessed concurrently?

PGTs it seems - at least this is what dumping a stack when detecting a
concurrent usage on an instobj indicates:

[  270.547052] [] (gk20a_instobj_acquire [nouveau]) from
[] (gf100_vm_map_sg+0x58/0x124 [nouveau])
[  270.557568] [] (gf100_vm_map_sg [nouveau]) from
[] (nvkm_vm_map+0x300/0x3bc [nouveau])
[  270.567333] [] (nvkm_vm_map [nouveau]) from []
(nouveau_bo_vma_add+0x74/0xa0 [nouveau])
[  270.577189] [] (nouveau_bo_vma_add [nouveau]) from
[] (nouveau_gem_object_open+0x124/0x158 [nouveau])
[  270.588196] [] (nouveau_gem_object_open [nouveau]) from
[] (drm_gem_handle_create_tail+0x104/0x19c)
[  270.599025] [] (drm_gem_handle_create_tail) from
[] (nouveau_gem_ioctl_new+0x90/0x18c [nouveau])
[  270.609594] [] (nouveau_gem_ioctl_new [nouveau]) from
[] (drm_ioctl+0x284/0x440)
[  270.618777] [] (drm_ioctl) from []
(nouveau_drm_ioctl+0x54/0x98 [nouveau])
[  270.627441] [] (nouveau_drm_ioctl [nouveau]) from
[] (do_vfs_ioctl+0x458/0x6dc)
[  270.636471] [] (do_vfs_ioctl) from []
(SyS_ioctl+0x34/0x5c)
[  270.643767] [] (SyS_ioctl) from []
(ret_fast_syscall+0x0/0x3c)
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH] instmem/gk20a: fix race conditions

2015-11-10 Thread Ben Skeggs 
On 11/11/2015 03:08 PM, Alexandre Courbot wrote:
> On Wed, Nov 11, 2015 at 9:19 AM, Ben Skeggs  wrote:
>> On 11/09/2015 05:37 PM, Alexandre Courbot wrote:
>>> The LRU list used for recycling CPU mappings was handling concurrency
>>> very poorly. For instance, if an instobj was acquired twice before being
>>> released once, it would end up into the LRU list even though there is
>>> still a client accessing it.
>>>
>>> This patch fixes this by properly counting how many clients are
>>> currently using a given instobj.
>> Out of curiosity, which instobjs are being accessed concurrently?
> 
> PGTs it seems - at least this is what dumping a stack when detecting a
> concurrent usage on an instobj indicates:
Ah, of course.  That makes sense, as the mmu code has its own methods of
dealing with concurrent access to particular areas of a page table.

I'll merge your fix shortly, after another quick eyeball.

Thanks,
Ben.

> 
> [  270.547052] [] (gk20a_instobj_acquire [nouveau]) from
> [] (gf100_vm_map_sg+0x58/0x124 [nouveau])
> [  270.557568] [] (gf100_vm_map_sg [nouveau]) from
> [] (nvkm_vm_map+0x300/0x3bc [nouveau])
> [  270.567333] [] (nvkm_vm_map [nouveau]) from []
> (nouveau_bo_vma_add+0x74/0xa0 [nouveau])
> [  270.577189] [] (nouveau_bo_vma_add [nouveau]) from
> [] (nouveau_gem_object_open+0x124/0x158 [nouveau])
> [  270.588196] [] (nouveau_gem_object_open [nouveau]) from
> [] (drm_gem_handle_create_tail+0x104/0x19c)
> [  270.599025] [] (drm_gem_handle_create_tail) from
> [] (nouveau_gem_ioctl_new+0x90/0x18c [nouveau])
> [  270.609594] [] (nouveau_gem_ioctl_new [nouveau]) from
> [] (drm_ioctl+0x284/0x440)
> [  270.618777] [] (drm_ioctl) from []
> (nouveau_drm_ioctl+0x54/0x98 [nouveau])
> [  270.627441] [] (nouveau_drm_ioctl [nouveau]) from
> [] (do_vfs_ioctl+0x458/0x6dc)
> [  270.636471] [] (do_vfs_ioctl) from []
> (SyS_ioctl+0x34/0x5c)
> [  270.643767] [] (SyS_ioctl) from []
> (ret_fast_syscall+0x0/0x3c)
> 



signature.asc
Description: OpenPGP digital signature
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau