From: bugzilla-daemon@freedesktop.org
To: dri-devel@lists.freedesktop.org
Subject: [Bug 111789] drm/etnaviv: command buffer outside valid memory window (on cubox i4), Linux 5.3
Date: Mon, 23 Sep 2019 18:17:07 +0000 [thread overview]
Message-ID: <bug-111789-502@http.bugs.freedesktop.org/> (raw)
[-- Attachment #1.1: Type: text/plain, Size: 2340 bytes --]
https://bugs.freedesktop.org/show_bug.cgi?id=111789
Bug ID: 111789
Summary: drm/etnaviv: command buffer outside valid memory
window (on cubox i4), Linux 5.3
Product: DRI
Version: unspecified
Hardware: ARM
OS: Linux (All)
Status: NEW
Severity: not set
Priority: not set
Component: DRM/other
Assignee: dri-devel@lists.freedesktop.org
Reporter: rechner@vlado-do.de
Created attachment 145475
--> https://bugs.freedesktop.org/attachment.cgi?id=145475&action=edit
dmesg from kernel 5.3, loading firmware
I'm trying to get somewhat accelerated video output out of my CuBox i4 (imx6
cpu, GC2000 graphics), but I don't have any luck with kernels 5.0, 5.2, or 5.3.
I tried recent Armbian and Fedora (30 and 31 beta).
The etnaviv messages from dmesg are:
[ 18.891291] etnaviv etnaviv: bound 130000.gpu (ops gpu_ops [etnaviv])
[ 18.895022] etnaviv etnaviv: bound 134000.gpu (ops gpu_ops [etnaviv])
[ 18.898366] etnaviv etnaviv: bound 2204000.gpu (ops gpu_ops [etnaviv])
[ 18.898385] etnaviv-gpu 130000.gpu: model: GC2000, revision: 5108
[ 18.929873] etnaviv-gpu 130000.gpu: command buffer outside valid memory
window
[ 18.931182] etnaviv-gpu 134000.gpu: model: GC320, revision: 5007
[ 19.075240] etnaviv-gpu 134000.gpu: command buffer outside valid memory
window
[ 19.076522] etnaviv-gpu 2204000.gpu: model: GC355, revision: 1215
[ 19.076542] etnaviv-gpu 2204000.gpu: Ignoring GPU with VG and FE2.0
[ 19.083510] [drm] Initialized etnaviv 1.2.0 20151214 for etnaviv on minor 1
I'll attach the complete dmesg - or you can see it here: http://ix.io/1WAW
Google brought me to Russell King's similar problem from June:
https://lists.freedesktop.org/archives/dri-devel/2019-June/224474.html
I don't know why the problem disappeared for him, though.
Initially I reported the problem at the armbian forum:
https://forum.armbian.com/topic/11539-no-hdmi-with-linux-image-dev-cubox-kernel-5211/
I'm more of a user than a developer, especially when it comes to the Linux
kernel. But I can test switches or patches.
Any help would be appreciated!
--
You are receiving this mail because:
You are the assignee for the bug.
[-- Attachment #1.2: Type: text/html, Size: 4034 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next reply other threads:[~2019-09-23 18:17 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-23 18:17 bugzilla-daemon [this message]
2019-09-24 9:19 ` [Bug 111789] drm/etnaviv: command buffer outside valid memory window (on cubox i4), Linux 5.3 bugzilla-daemon
2019-09-24 11:24 ` bugzilla-daemon
2019-09-24 19:16 ` bugzilla-daemon
2019-09-25 6:24 ` bugzilla-daemon
2019-10-19 12:01 ` bugzilla-daemon
2019-11-19 8:54 ` bugzilla-daemon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bug-111789-502@http.bugs.freedesktop.org/ \
--to=bugzilla-daemon@freedesktop.org \
--cc=dri-devel@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.