https://bugs.freedesktop.org/show_bug.cgi?id=34969
Summary: [nouveau] Card lockup on openarena
Product: DRI
Version: XOrg CVS
Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
Severity: normal
Priority: medium
Component: DRM/other
AssignedTo: dri-devel(a)lists.freedesktop.org
ReportedBy: mad.f3ka(a)gmail.com
Created an attachment (id=44068)
--> (https://bugs.freedesktop.org/…
[View More]attachment.cgi?id=44068)
messages.log part
Each time I try to start openarena or any other game, card locks up (not in
menu, but in game).
I'm not sure, but log in messages seems to be related to this issue (see
messages attachment).
Software versions:
kernel 2.6.37.2
libdrm 2.4.23
mesa 7.10.1
xf86-video-nouveau 0.0.16_git20101217
Hardware:
06:00.0 VGA compatible controller: nVidia Corporation NV43 [GeForce 6600] (rev
a2)
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[View Less]
https://bugs.freedesktop.org/show_bug.cgi?id=63192
Priority: medium
Bug ID: 63192
Assignee: dri-devel(a)lists.freedesktop.org
Summary: [nouveau] drmModeSetCursor->nouveau_bo_rd32->ioread32
provides high cpu load when using weston
drm-compositor
Severity: normal
Classification: Unclassified
OS: Linux (All)
Reporter: vova7890(a)mail.ru
Hardware: x86-64 (AMD64)…
[View More]
Status: NEW
Version: DRI CVS
Component: DRM/other
Product: DRI
Weston runned in drm-mode provide very high cpu load on mouse moving. I don`t
think that the bug of weston, seems problem in nouveau drm. At launch weston
have a log:
...
[24465.734894] nouveau W[ PFIFO][0000:02:00.0] INTR 0x00000001: 0x00000004
[24465.748153] nouveau W[ PFIFO][0000:02:00.0] INTR 0x00000001: 0x00000004
[24521.950788] nouveau W[ PFIFO][0000:02:00.0] INTR 0x00000001: 0x00000004
[24521.955032] nouveau W[ PFIFO][0000:02:00.0] INTR 0x00000001: 0x00000004
...
ioread32_native(ioread32 on litle-endian) using 100% of cpu core. If in weston
comment out drmModeSetCursor - cpu load is normal, but no see cursor ofcourse.
They copying cursor(64x64) from bo-object. Seems TTM iomem access provide very
high cpu load... On radeon it works smoothly and no have very high cpu load.
Kernel 3.9-rc5 (x86_64)
Wayland/Weston: git
Mesa: git
libdrm: git
--
You are receiving this mail because:
You are the assignee for the bug.
[View Less]
https://bugs.freedesktop.org/show_bug.cgi?id=57352
Priority: medium
Bug ID: 57352
Assignee: dri-devel(a)lists.freedesktop.org
Summary: [nouveau] Kernel Tux logo incorrectly displayed at
boot
Severity: normal
Classification: Unclassified
OS: All
Reporter: bonbons67(a)internet.lu
Hardware: Other
Status: NEW
Version: XOrg CVS
Component: DRM/other
…
[View More] Product: DRI
When booting with build-in nouveau (KMS enabled) the Tux logos displayed are
not recognizable. It looks like incorrect tiling configuration of either source
or destination buffer when rendering the logo. Normal fbcon console text
displays as expected.
This happens with linux-3.7-rc5 and newer (don't know since when).
Hardware is MacBookAir with GeForce 9400M (C79) [10de:0870].
(screenshot following later on)
--
You are receiving this mail because:
You are the assignee for the bug.
[View Less]
https://bugs.freedesktop.org/show_bug.cgi?id=34296
Summary: Failure loading nouveau for nVidia GeForce 8600 GT on
ASUS XG Station(external 1x PCIe encasing for an GPU)
Product: DRI
Version: XOrg CVS
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: normal
Priority: medium
Component: DRM/other
AssignedTo: dri-devel(a)lists.freedesktop.org
…
[View More]ReportedBy: revellion(a)gmail.com
loading Nouveau fails with
Feb 15 01:39:21 localhost kernel: [drm] nouveau 0000:0c:00.0: Detected 256MiB
VRAM
Feb 15 01:39:21 localhost kernel: mtrr: zero sized request
Feb 15 01:39:21 localhost kernel: [drm] nouveau 0000:0c:00.0: 512 MiB GART
(aperture)
Feb 15 01:39:21 localhost kernel: [drm] nouveau 0000:0c:00.0: Error mapping EVO
DMA push buffer: -12
Feb 15 01:39:21 localhost kernel: [drm] nouveau 0000:0c:00.0: Error creating
EVO channel: -12
Feb 15 01:39:21 localhost kernel: nouveau 0000:0c:00.0: PCI INT A disabled
Feb 15 01:39:21 localhost kernel: nouveau: probe of 0000:0c:00.0 failed with
error -12
And nothing gets outputted on any of the connected monitors during any part of
the driver loading, not even a mode switch or anything.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[View Less]
https://bugs.freedesktop.org/show_bug.cgi?id=28095
Summary: X crash with PFIFO_CACHE_ERROR. (Nouveau on Riva TNT).
Product: DRI
Version: unspecified
Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
Severity: normal
Priority: medium
Component: DRM/other
AssignedTo: dri-devel(a)lists.freedesktop.org
ReportedBy: bzipitidoo(a)hotmail.com
Created an attachment (id=35642)
--> (…
[View More]https://bugs.freedesktop.org/attachment.cgi?id=35642)
lernel log
System is a Pentium II with a Diamond Viper V550 (Riva TNT) card. OS is Arch
Linux, with latest versions of Nouveau from git repositories on
freedesktop.org:
kernel 2.6.34-rc5
libdrm 2.4.20
xf86-video-nouveau 0.0.16
I have "options drm debug=1" in /etc/modprobe.d/modprobe.conf. Acceleration is
enabled.
With this setup, X works for a few minutes and then crashes. I was running
Firefox and lxterminal (am using lxde with openbox window manager). The first
problem I saw was the titlebar for lxterminal was not always rendered. Grabbed
the graphics from the web page behind it. The crash happened when I tried to
search for something in Firefox's search dialog at the upper left. Went into a
loop in which the pop up menu of suggested search terms flickered on and off
perhaps 10 times, then X crashed. Saw many of these messages in kernel.log:
[drm] nouveau 0000:01:00.0: PFIFO_CACHE_ERROR - Ch
15/5 Mthd 0x0638 Data 0x00dcdad5
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[View Less]
https://bugs.freedesktop.org/show_bug.cgi?id=81690
Priority: medium
Bug ID: 81690
Assignee: dri-devel(a)lists.freedesktop.org
Summary: nouveau GPU locks up under memory pressure
Severity: normal
Classification: Unclassified
OS: Linux (All)
Reporter: hramrach(a)gmail.com
URL: http://download.wakfu.asia/full/unix/
Hardware: x86-64 (AMD64)
Status: NEW
Version: …
[View More]unspecified
Component: DRM/other
Product: DRI
When there is memory pressure GPU tends to hang.
This is probably related to system memory pressure (not vram) although I have
no idea about vram utilisation.
Usually crash happens when I start an application that uses the GPU and the
system starts to swap and/or OOM killer kills something and/or applications
crash due to bad handling of OOM condition.
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GeForce GT 620
[10de:0f01] (rev a1) (prog-if 00 [VGA controller])
Subsystem: ASUSTeK Computer Inc. Device [1043:83ff]
Flags: bus master, fast devsel, latency 0, IRQ 52
Memory at fc000000 (32-bit, non-prefetchable) [size=16M]
Memory at f0000000 (64-bit, prefetchable) [size=128M]
Memory at f8000000 (64-bit, prefetchable) [size=32M]
I/O ports at dc80 [size=128]
Expansion ROM at fde00000 [disabled] [size=512K]
Capabilities: [60] Power Management version 3
Capabilities: [68] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [78] Express Endpoint, MSI 00
Capabilities: [b4] Vendor Specific Information: Len=14 <?>
Capabilities: [100] Virtual Channel
Capabilities: [128] Power Budgeting <?>
Capabilities: [600] Vendor Specific Information: ID=0001 Rev=1 Len=024 <?>
Kernel driver in use: nouveau
Linux 3.15-trunk-amd64 #1 SMP Debian 3.15.5-1~exp1 (2014-07-10) x86_64
GNU/Linux
ii libgl1-mesa-dri:am 10.2.3-1 amd64
[ 2574.171692] nouveau E[ PFIFO][0000:01:00.0] read fault at 0x0000011000
[INVALID_STORAGE_TYPE] from PFIFO/PFIFO on channel 0x007edbc000 [unknown]
[ 2664.669780] nouveau E[ DRM] GPU lockup - switching to software fbcon
[ 2679.688012] nouveau E[Xorg[1971]] failed to idle channel 0xcccc0001
[Xorg[1971]]
[ 151.697805] nouveau E[ PFIFO][0000:01:00.0] read fault at 0x0000011000
[INVALID_STORAGE_TYPE] from PFIFO/PFIFO on channel 0x007ed88000 [unknown]
[ 168.639601] nouveau E[ DRM] GPU lockup - switching to software fbcon
[ 183.760010] nouveau E[Xorg[2027]] failed to idle channel 0xcccc0001
[Xorg[2027]]
[ 134.917421] nouveau E[ PFIFO][0000:01:00.0] read fault at 0x0000011000
[INVALID_STORAGE_TYPE] from PFIFO/PFIFO on channel 0x007ed88000 [unknown]
[ 165.296145] nouveau E[ DRM] GPU lockup - switching to software fbcon
[ 7.563122] nouveau [ DEVICE][0000:01:00.0] BOOT0 : 0x0c1080a1
[ 7.569331] nouveau [ DEVICE][0000:01:00.0] Chipset: GF108 (NVC1)
[ 7.575693] nouveau [ DEVICE][0000:01:00.0] Family : NVC0
[ 7.586561] usbcore: registered new interface driver snd-usb-audio
[ 7.644889] nouveau [ VBIOS][0000:01:00.0] checking PRAMIN for image...
[ 7.790243] nouveau [ VBIOS][0000:01:00.0] ... appears to be valid
[ 7.790245] nouveau [ VBIOS][0000:01:00.0] using image from PRAMIN
[ 7.790338] nouveau [ VBIOS][0000:01:00.0] BIT signature found
[ 7.790340] nouveau [ VBIOS][0000:01:00.0] version 70.08.ae.00.02
[ 7.790366] Bluetooth: HCI socket layer initialized
[ 7.790367] Bluetooth: L2CAP socket layer initialized
[ 7.790376] Bluetooth: SCO socket layer initialized
[ 7.797368] nouveau 0000:01:00.0: irq 52 for MSI/MSI-X
[ 7.797377] nouveau [ PMC][0000:01:00.0] MSI interrupts enabled
[ 7.797415] nouveau W[ PFB][0000:01:00.0][0x00000000][ffff88022bbb7800]
reclocking of this ram type unsupported
[ 7.797416] nouveau [ PFB][0000:01:00.0] RAM type: DDR3
[ 7.797417] nouveau [ PFB][0000:01:00.0] RAM size: 2048 MiB
[ 7.797418] nouveau [ PFB][0000:01:00.0] ZCOMP: 0 tags
[ 7.801509] nouveau [ VOLT][0000:01:00.0] GPU voltage: 900000uv
[ 9.300033] nouveau [ PTHERM][0000:01:00.0] FAN control: none / external
[ 9.306998] nouveau [ PTHERM][0000:01:00.0] fan management: automatic
[ 9.313701] nouveau [ PTHERM][0000:01:00.0] internal sensor: yes
[ 9.320011] nouveau [ CLK][0000:01:00.0] 03: core 50 MHz memory 324 MHz
[ 9.320113] EXT4-fs (sdd1): mounting ext3 file system using the ext4
subsystem
[ 9.334538] nouveau [ CLK][0000:01:00.0] 07: core 405 MHz memory 324
MHz
[ 9.341863] nouveau [ CLK][0000:01:00.0] 0f: core 700 MHz memory 700
MHz
[ 9.349339] nouveau [ CLK][0000:01:00.0] --: core 405 MHz memory 324
MHz
[ 9.359052] [TTM] Zone kernel: Available graphics memory: 4032366 kiB
[ 9.365668] [TTM] Zone dma32: Available graphics memory: 2097152 kiB
[ 9.372279] [TTM] Initializing pool allocator
[ 9.376741] [TTM] Initializing DMA pool allocator
[ 9.381547] nouveau [ DRM] VRAM: 2048 MiB
[ 9.386087] nouveau [ DRM] GART: 1048576 MiB
[ 9.390892] nouveau [ DRM] TMDS table version 2.0
[ 9.396126] nouveau [ DRM] DCB version 4.0
[ 9.400746] nouveau [ DRM] DCB outp 00: 01000302 00020030
[ 9.406675] nouveau [ DRM] DCB outp 01: 02000300 00000000
[ 9.412608] nouveau [ DRM] DCB outp 02: 08011392 00020020
[ 9.418523] nouveau [ DRM] DCB outp 03: 04022310 00000000
[ 9.421527] EXT4-fs (sdd1): mounted filesystem with ordered data mode. Opts:
errors=remount-ro
[ 9.433144] nouveau [ DRM] DCB conn 00: 00001030
[ 9.439774] nouveau [ DRM] DCB conn 01: 00002161
[ 9.446363] nouveau [ DRM] DCB conn 02: 00000200
[ 9.452457] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[ 9.459164] [drm] Driver supports precise vblank timestamp query.
[ 9.470482] nouveau [ DRM] MM: using COPY0 for buffer copies
[ 9.500028] usb 4-2: new full-speed USB device number 4 using uhci_hcd
[ 9.584981] nouveau [ DRM] allocated 1600x1600 fb: 0x60000, bo
ffff88022e07c800
[ 9.592947] fbcon: nouveaufb (fb0) is primary device
[ 9.642993] EXT4-fs (dm-4): mounted filesystem with ordered data mode. Opts:
(null)
[ 9.684077] Console: switching to colour frame buffer device 150x75
[ 9.705241] nouveau 0000:01:00.0: fb0: nouveaufb frame buffer device
[ 9.705246] nouveau 0000:01:00.0: registered panic notifier
[ 9.705257] [drm] Initialized nouveau 1.1.1 20120801 for 0000:01:00.0 on
minor 0
[177491.295050] nouveau E[Wakfu[2020]] fail ttm_validate
[177491.300109] nouveau E[Wakfu[2020]] validate gart_list
[177491.305449] nouveau E[Wakfu[2020]] validate: -12
[177717.658727] usb 8-4: USB disconnect, device number 14
[177803.434648] nouveau E[ PFIFO][0000:01:00.0] write fault at 0x0000218000
[PAGE_NOT_PRESENT] from PGRAPH/DISPATCH on channel 0x007f89c000 [Wakfu[2020]]
[177803.438624] nouveau E[ PFIFO][0000:01:00.0] PGRAPH engine fault on
channel 5, recovering...
[177983.108013] nouveau E[Xorg[1899]] failed to idle channel 0xcccc0000
[Xorg[1899]]
[177998.112017] nouveau E[Xorg[1899]] failed to idle channel 0xcccc0000
[Xorg[1899]]
[177998.119751] nouveau E[ PFIFO][0000:01:00.0] read fault at 0x000001b000
[PAGE_NOT_PRESENT] from PFIFO/BAR_READ on channel 0x007fb5a000 [unknown]
[178002.857403] nouveau E[ DRM] GPU lockup - switching to software fbcon
[178015.816010] nouveau E[Wakfu[2016]] failed to idle channel 0xcccc0000
[Wakfu[2016]]
an easy way to trigger the issue is to
download the above game client,
unpack,
run the launcher script (wakfu/wakfu),
wait for updates to finish,
and press the PLAY button repeatedly until memory runs out.
The client takes about 1.2GB
--
You are receiving this mail because:
You are the assignee for the bug.
[View Less]
Spotted while reviewing the DRM changes in Linux 3.18 for LinuxFR.
CC: Daniel Vetter <daniel.vetter(a)ffwll.ch>
Signed-off-by: Martin Peres <martin.peres(a)free.fr>
---
drivers/gpu/drm/drm_crtc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 4a44f89..90ad762 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -3454,7 +3454,7 @@ void drm_fb_release(struct drm_file *priv)
/…
[View More]*
* When the file gets released that means no one else can access the fb
- * list any more, so no need to grab fpriv->fbs_lock. And we need to to
+ * list any more, so no need to grab fpriv->fbs_lock. And we need to
* avoid upsetting lockdep since the universal cursor code adds a
* framebuffer while holding mutex locks.
*
--
2.1.3
[View Less]
From: Daniel Kurtz <djkurtz(a)chromium.org>
A framebuffer gets committed to FIMD's default window like this:
exynos_drm_crtc_update()
exynos_plane_commit()
fimd_win_commit()
fimd_win_commit() programs BUF_START[0]. At each vblank, FIMD hardware
copies the value from BUF_START to BUF_START_S (BUF_START's shadow
register), starts scanning out from BUF_START_S, and asserts its irq.
This irq is handled by fimd_irq_handler(), which calls
exynos_drm_crtc_finish_pageflip() to free the …
[View More]old buffer that FIMD just
finished scanning out, and potentially commit the next pending flip.
There is a race, however, if fimd_win_commit() programs BUF_START(0)
between the actual vblank irq, and its corresponding fimd_irq_handler().
=> FIMD vblank: BUF_START_S[0] := BUF_START[0], and irq asserted
| => fimd_win_commit(0) writes new BUF_START[0]
| exynos_drm_crtc_try_do_flip() marks exynos_fb as prepared
=> fimd_irq_handler()
exynos_drm_crtc_finish_pageflip() sees prepared exynos_fb,
and unmaps "old" fb
==> but, since BUF_START_S[0] still points to that "old" fb...
==> FIMD iommu fault
This patch ensures that fimd_irq_handler() only calls
exynos_drm_crtc_finish_pageflip() if any previously scheduled flip
has really completed.
This works because exynos_drm_crtc's flip fifo ensures that
fimd_win_commit() is never called more than once per
exynos_drm_crtc_finish_pageflip().
Signed-off-by: Daniel Kurtz <djkurtz(a)chromium.org>
Reviewed-by: Sean Paul <seanpaul(a)chromium.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan(a)collabora.co.uk>
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 26 ++++++++++++++++++++++++++
include/video/samsung_fimd.h | 1 +
2 files changed, 27 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index e5810d1..afb0586 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -55,6 +55,7 @@
#define VIDOSD_D(win) (VIDOSD_BASE + 0x0C + (win) * 16)
#define VIDWx_BUF_START(win, buf) (VIDW_BUF_START(buf) + (win) * 8)
+#define VIDWx_BUF_START_S(win, buf) (VIDW_BUF_START_S(buf) + (win) * 8)
#define VIDWx_BUF_END(win, buf) (VIDW_BUF_END(buf) + (win) * 8)
#define VIDWx_BUF_SIZE(win, buf) (VIDW_BUF_SIZE(buf) + (win) * 4)
@@ -1039,6 +1040,7 @@ static irqreturn_t fimd_irq_handler(int irq, void *dev_id)
{
struct fimd_context *ctx = (struct fimd_context *)dev_id;
u32 val, clear_bit;
+ u32 start, start_s;
val = readl(ctx->regs + VIDINTCON1);
@@ -1066,6 +1068,30 @@ static irqreturn_t fimd_irq_handler(int irq, void *dev_id)
}
}
+ /*
+ * Ensure finish_pageflip is called iff a pending flip has completed.
+ * This works around a race between a page_flip request and the latency
+ * between vblank interrupt and this irq_handler:
+ * => FIMD vblank: BUF_START_S[0] := BUF_START[0], and asserts irq
+ * | => fimd_win_commit(0) writes new BUF_START[0]
+ * | exynos_drm_crtc_try_do_flip() marks exynos_fb as prepared
+ * => fimd_irq_handler()
+ * exynos_drm_crtc_finish_pageflip() sees prepared exynos_fb,
+ * and unmaps "old" fb
+ * ==> but, since BUF_START_S[0] still points to that "old" fb...
+ * ==> FIMD iommu fault
+ */
+ start = readl(ctx->regs + VIDWx_BUF_START(0, 0));
+ start_s = readl(ctx->regs + VIDWx_BUF_START_S(0, 0));
+ if (start == start_s)
+ exynos_drm_crtc_finish_pageflip(ctx->drm_dev, ctx->pipe);
+
+ /* set wait vsync event to zero and wake up queue. */
+ if (atomic_read(&ctx->wait_vsync_event)) {
+ atomic_set(&ctx->wait_vsync_event, 0);
+ wake_up(&ctx->wait_vsync_queue);
+ }
+
out:
return IRQ_HANDLED;
}
diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h
index a20e4a3..f81d081 100644
--- a/include/video/samsung_fimd.h
+++ b/include/video/samsung_fimd.h
@@ -291,6 +291,7 @@
/* Video buffer addresses */
#define VIDW_BUF_START(_buff) (0xA0 + ((_buff) * 8))
+#define VIDW_BUF_START_S(_buff) (0x40A0 + ((_buff) * 8))
#define VIDW_BUF_START1(_buff) (0xA4 + ((_buff) * 8))
#define VIDW_BUF_END(_buff) (0xD0 + ((_buff) * 8))
#define VIDW_BUF_END1(_buff) (0xD4 + ((_buff) * 8))
--
1.9.3
[View Less]