[PATCH libdrm 1/5] xf86drm: implement drmGetMinorNameForFD for non-sysfs
Implement drmGetMinorNameForFD for systems without sysfs by adapting drm_get_device_name_for_fd() from the Mesa loader. Signed-off-by: Jonathan Gray --- xf86drm.c | 20 +++- 1 file changed, 19 insertions(+), 1 deletion(-) diff --git a/xf86drm.c b/xf86drm.c index ed924a7..216220c 100644 --- a/xf86drm.c +++ b/xf86drm.c @@ -2818,7 +2818,25 @@ static char *drmGetMinorNameForFD(int fd, int type) out_close_dir: closedir(sysdir); #else -#warning "Missing implementation of drmGetMinorNameForFD" +struct stat sbuf; +unsigned int maj, min; +char buf[PATH_MAX + 1]; +int n; + +if (fstat(fd, &sbuf)) +return NULL; + +maj = major(sbuf.st_rdev); +min = minor(sbuf.st_rdev); + +if (maj != DRM_MAJOR || !S_ISCHR(sbuf.st_mode)) +return NULL; + +n = snprintf(buf, sizeof(buf), DRM_DEV_NAME, DRM_DIR_NAME, min); +if (n == -1 || n >= sizeof(buf)) +return NULL; + +return strdup(buf); #endif return NULL; } -- 2.10.2
[PATCH libdrm 5/5] xf86drm: implement an OpenBSD specific drmGetDevice
This avoids walking all of /dev and directly maps the fd to a path to a
primary node.
Signed-off-by: Jonathan Gray
---
xf86drm.c | 41 +
1 file changed, 41 insertions(+)
diff --git a/xf86drm.c b/xf86drm.c
index 2a60b2e..a4b2506 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -3175,6 +3175,46 @@ static void drmFoldDuplicatedDevices(drmDevicePtr
local_devices[], int count)
*/
int drmGetDevice(int fd, drmDevicePtr *device)
{
+#ifdef __OpenBSD__
+drmDevicePtr d;
+struct stat sbuf;
+char node[PATH_MAX + 1];
+char d_name[PATH_MAX + 1];
+int maj, min, n;
+int ret;
+int max_count = 1;
+
+if (fd == -1 || device == NULL)
+return -EINVAL;
+
+if (fstat(fd, &sbuf))
+return -errno;
+
+maj = major(sbuf.st_rdev);
+min = minor(sbuf.st_rdev);
+
+if (maj != DRM_MAJOR || !S_ISCHR(sbuf.st_mode))
+return -EINVAL;
+
+n = snprintf(d_name, PATH_MAX, "drm%d", min);
+if (n == -1 || n >= PATH_MAX)
+ return -errno;
+
+n = snprintf(node, PATH_MAX, DRM_DEV_NAME, DRM_DIR_NAME, min);
+if (n == -1 || n >= PATH_MAX)
+ return -errno;
+if (stat(node, &sbuf))
+return -EINVAL;
+
+ret = drmProcessPciDevice(&d, d_name, node, DRM_NODE_PRIMARY,
+ maj, min, true);
+if (ret)
+return ret;
+
+*device = d;
+
+return 0;
+#else
drmDevicePtr *local_devices;
drmDevicePtr d;
DIR *sysdir;
@@ -3282,6 +3322,7 @@ free_devices:
free_locals:
free(local_devices);
return ret;
+#endif
}
/**
--
2.10.2
[PATCH libdrm 2/5] xf86drm: implement drmParseSubsystemType for OpenBSD
Implement drmParseSubsystemType for OpenBSD by always returning DRM_BUS_PCI. No non-pci drm drivers are in the kernel and this is unlikely to change anytime soon as the existing ones aren't permissively licensed. Signed-off-by: Jonathan Gray --- xf86drm.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/xf86drm.c b/xf86drm.c index 216220c..b355c83 100644 --- a/xf86drm.c +++ b/xf86drm.c @@ -2872,6 +2872,8 @@ static int drmParseSubsystemType(int maj, int min) return DRM_BUS_PCI; return -EINVAL; +#elif defined(__OpenBSD__) + return DRM_BUS_PCI; #else #warning "Missing implementation of drmParseSubsystemType" return -EINVAL; -- 2.10.2
[PATCH libdrm 3/5] xf86drm: implement drmParsePciDeviceInfo for OpenBSD
Implement drmParsePciDeviceInfo for OpenBSD by using the new
DRM_IOCTL_GET_PCIINFO ioctl.
Signed-off-by: Jonathan Gray
---
xf86drm.c | 51 +++
1 file changed, 51 insertions(+)
diff --git a/xf86drm.c b/xf86drm.c
index b355c83..581527b 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -102,6 +102,26 @@
#define DRM_MAJOR 226 /* Linux */
#endif
+#ifdef __OpenBSD__
+
+#define X_PRIVSEP
+
+struct drm_pciinfo {
+ uint16_tdomain;
+ uint8_t bus;
+ uint8_t dev;
+ uint8_t func;
+ uint16_tvendor_id;
+ uint16_tdevice_id;
+ uint16_tsubvendor_id;
+ uint16_tsubdevice_id;
+ uint8_t revision_id;
+};
+
+#define DRM_IOCTL_GET_PCIINFO DRM_IOR(0x15, struct drm_pciinfo)
+
+#endif
+
#define DRM_MSG_VERBOSITY 3
#define memclear(s) memset(&s, 0, sizeof(s))
@@ -2991,6 +3011,37 @@ static int drmParsePciDeviceInfo(const char *d_name,
device->subdevice_id = config[46] | (config[47] << 8);
return 0;
+#elif defined(__OpenBSD__)
+struct drm_pciinfo pinfo;
+char buf[PATH_MAX + 1];
+int fd, n;
+
+n = snprintf(buf, sizeof(buf), "%s/%s", DRM_DIR_NAME, d_name);
+if (n == -1 || n >= sizeof(buf))
+return -errno;
+
+#ifndef X_PRIVSEP
+fd = open(buf, O_RDWR, 0);
+#else
+fd = priv_open_device(buf);
+#endif
+
+if (fd < 0)
+return -errno;
+
+if (drmIoctl(fd, DRM_IOCTL_GET_PCIINFO, &pinfo)) {
+close(fd);
+return -errno;
+}
+close(fd);
+
+device->vendor_id = pinfo.vendor_id;
+device->device_id = pinfo.device_id;
+device->revision_id = pinfo.revision_id;
+device->subvendor_id = pinfo.subvendor_id;
+device->subdevice_id = pinfo.subdevice_id;
+
+return 0;
#else
#warning "Missing implementation of drmParsePciDeviceInfo"
return -EINVAL;
--
2.10.2
[PATCH libdrm 4/5] xf86drm: implement drmParsePciBusInfo for OpenBSD
Implement drmParsePciBusInfo for OpenBSD by using the new
DRM_IOCTL_GET_PCIINFO ioctl.
Signed-off-by: Jonathan Gray
---
xf86drm.c | 20
1 file changed, 20 insertions(+)
diff --git a/xf86drm.c b/xf86drm.c
index 581527b..2a60b2e 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -2936,6 +2936,26 @@ static int drmParsePciBusInfo(int maj, int min,
drmPciBusInfoPtr info)
info->func = func;
return 0;
+#elif defined(__OpenBSD__)
+struct drm_pciinfo pinfo;
+int fd;
+
+fd = drmOpenMinor(min, 0, DRM_NODE_PRIMARY);
+if (fd < 0)
+return -errno;
+
+if (drmIoctl(fd, DRM_IOCTL_GET_PCIINFO, &pinfo)) {
+close(fd);
+return -errno;
+}
+close(fd);
+
+info->domain = pinfo.domain;
+info->bus = pinfo.bus;
+info->dev = pinfo.dev;
+info->func = pinfo.func;
+
+return 0;
#else
#warning "Missing implementation of drmParsePciBusInfo"
return -EINVAL;
--
2.10.2
[Bug 98239] saints row 3: performance is limited by flushes
https://bugs.freedesktop.org/show_bug.cgi?id=98239
--- Comment #3 from Marek Olšák ---
Things to try:
1) You can try increasing the IB size in radeon_drm_cs.h:
struct radeon_cs_context {
uint32_tbuf[16 * 1024]; // HERE
2) Add buffer-wait-time to the HUD and see if it corresponds with the flushes.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161126/477da948/attachment.html>
[Bug 98638] Panic on shutdown with AMDGPU and Ubuntu Plymouth
https://bugs.freedesktop.org/show_bug.cgi?id=98638 --- Comment #8 from Ernst Sjöstrand --- Now I got this interesting blob: [ 1457.810773] systemd-shutdown[1]: All swaps deactivated. [ 1457.810777] systemd-shutdown[1]: Detaching loop devices. [ 1457.814471] kvm: exiting hardware virtualization [ 1458.021577] sd 4:0:0:0: [sdd] Synchronizing SCSI cache [ 1458.022423] sd 4:0:0:0: [sdd] Stopping disk [ 1458.058826] sd 3:0:0:0: [sdc] Synchronizing SCSI cache [ 1458.059003] sd 3:0:0:0: [sdc] Stopping disk [ 1458.059179] sd 2:0:0:0: [sdb] Synchronizing SCSI cache [ 1458.059390] sd 2:0:0:0: [sdb] Stopping disk [ 1458.248733] sd 0:0:0:0: [sda] Synchronizing SCSI cache [ 1458.248840] sd 0:0:0:0: [sda] Stopping disk [ 1458.305064] [drm] amdgpu: finishing device. [ 1459.409471] Console: switching to colour dummy device 80x25 [ 1459.417354] BUG: unable to handle kernel NULL pointer dereference at 0010 [ 1459.417367] IP: [] amdgpu_fence_wait_empty+0x2a/0xd0 [amdgpu] [ 1459.417398] PGD 0 [ 1459.417401] [ 1459.417405] Oops: [#1] SMP [ 1459.417409] Modules linked in: netconsole configfs binfmt_misc eeepc_wmi asus_wmi mxm_wmi video sparse_keymap intel_rapl x86_pkg_temp_thermal kvm_intel kvm snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec_hdmi snd_hda_intel snd_hda_codec snd_hda_core irqbypass snd_pcm input_leds crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hwdep snd_seq_midi aesni_intel snd_seq_midi_event aes_x86_64 snd_rawmidi glue_helper lrw ablk_helper cryptd snd_seq intel_cstate snd_timer intel_rapl_perf snd_seq_device serio_raw snd mei_me mei soundcore lpc_ich mac_hid shpchp wmi sbs sbshc max6650 coretemp parport_pc ppdev lp parport ip_tables x_tables autofs4 btrfs xor raid6_pq hid_generic usbhid hid amdkfd amd_iommu_v2 amdgpu i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm psmouse e1000e ahci ptp libahci pps_core fjes [ 1459.417534] CPU: 1 PID: 2847 Comm: plymouthd Not tainted 4.9.0-rc4+ #78 [ 1459.417537] Hardware name: System manufacturer System Product Name/P8P67 PRO REV 3.1, BIOS 1704 06/08/2011 [ 1459.417540] task: 92d031034380 task.stack: b33482184000 [ 1459.417543] RIP: 0010:[] [] amdgpu_fence_wait_empty+0x2a/0xd0 [amdgpu] [ 1459.417565] RSP: 0018:b33482187af0 EFLAGS: 00010202 [ 1459.417568] RAX: 0010 RBX: 92d02f28a938 RCX: [ 1459.417571] RDX: RSI: 4532 RDI: 92d02f28c570 [ 1459.417573] RBP: b33482187b00 R08: 0004 R09: 00030003 [ 1459.417576] R10: 00030303 R11: 4000 R12: 92d02f288000 [ 1459.417578] R13: 92d02f28a9b0 R14: 92d02fee4800 R15: [ 1459.417582] FS: 7f86ba048b80() GS:92d03f48() knlGS: [ 1459.417585] CS: 0010 DS: ES: CR0: 80050033 [ 1459.417587] CR2: 0010 CR3: 0002301b6000 CR4: 000406e0 [ 1459.417590] Stack: [ 1459.417592] 92d02fee4800 92d02f28a938 b33482187b40 c02096d2 [ 1459.417600] b33482187b40 28d54302 92d02f514000 92d02f288000 [ 1459.417608] 0003 b33482187b68 c0227945 [ 1459.417615] Call Trace: [ 1459.417640] [] amdgpu_pm_compute_clocks+0x92/0x560 [amdgpu] [ 1459.417666] [] dce_v10_0_crtc_dpms+0xd5/0x110 [amdgpu] [ 1459.417676] [] drm_helper_connector_dpms+0x82/0x100 [drm_kms_helper] [ 1459.417700] [] ? dce_v10_0_bandwidth_update+0x260/0x260 [amdgpu] [ 1459.417709] [] drm_crtc_helper_set_config+0xabf/0xaf0 [drm_kms_helper] [ 1459.417731] [] amdgpu_crtc_set_config+0x48/0x120 [amdgpu] [ 1459.417749] [] drm_mode_set_config_internal+0x65/0x110 [drm] [ 1459.417765] [] drm_mode_setcrtc+0x3fd/0x4f0 [drm] [ 1459.417779] [] drm_ioctl+0x21b/0x4c0 [drm] [ 1459.417794] [] ? drm_mode_getcrtc+0x140/0x140 [drm] [ 1459.417812] [] amdgpu_drm_ioctl+0x4f/0x90 [amdgpu] [ 1459.417819] [] do_vfs_ioctl+0xa3/0x600 [ 1459.417823] [] SyS_ioctl+0x79/0x90 [ 1459.417829] [] entry_SYSCALL_64_fastpath+0x1e/0xad [ 1459.417832] Code: 90 66 66 66 66 90 8b 47 20 85 c0 0f 84 9a 00 00 00 55 48 89 e5 53 48 83 ec 08 23 87 88 00 00 00 48 8b 97 90 00 00 00 48 8d 04 c2 <48> 8b 18 48 85 db 74 6f 8b 0b 85 c9 74 69 8d 51 01 89 c8 f0 0f [ 1459.417923] RIP [] amdgpu_fence_wait_empty+0x2a/0xd0 [amdgpu] [ 1459.417945] RSP [ 1459.417947] CR2: 0010 [ 1459.417951] ---[ end trace 71c209200bdc61d0 ]--- -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161126/aa5f329b/attachment.html>
[Bug 98638] Panic on shutdown with AMDGPU and Ubuntu Plymouth
https://bugs.freedesktop.org/show_bug.cgi?id=98638
--- Comment #9 from Ernst Sjöstrand ---
(gdb) l *(amdgpu_fence_wait_empty+0x29)
0x112d9 is in amdgpu_fence_wait_empty
(drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c:270).
270 ptr = &ring->fence_drv.fences[seq &
ring->fence_drv.num_fences_mask];
(gdb) l *(amdgpu_fence_wait_empty+0x2a)
0x112da is in amdgpu_fence_wait_empty (./include/linux/compiler.h:243).
243 __READ_ONCE_SIZE;
(gdb) l *(amdgpu_fence_wait_empty+0x2b)
0x112db is in amdgpu_fence_wait_empty (./include/linux/compiler.h:243).
243 __READ_ONCE_SIZE;
(gdb) l *(amdgpu_fence_wait_empty+0x2c)
0x112dc is in amdgpu_fence_wait_empty (./include/linux/compiler.h:243).
243 __READ_ONCE_SIZE;
(gdb) l *(amdgpu_fence_wait_empty+0x2d)
0x112dd is in amdgpu_fence_wait_empty
(drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c:273).
273 if (!fence || !dma_fence_get_rcu(fence)) {
It's not line 270 and not line 273 so I guess it's line 271 or 272:
rcu_read_lock();
fence = rcu_dereference(*ptr);
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161126/4bc64a63/attachment-0001.html>
drm: GPF in drm_getcap
Hi
On Sat, Nov 26, 2016 at 6:17 PM, Dmitry Vyukov wrote:
> On Fri, Sep 9, 2016 at 1:56 PM, Dmitry Vyukov wrote:
>> Hello,
>>
>> The following program triggers GPF in drm_getcap:
>>
>> // autogenerated by syzkaller (http://github.com/google/syzkaller)
>> #include
>> #include
>> #include
>> #include
>> #include
>> #include
>> #include
>> #include
>>
>> int main()
>> {
>> int fd = open("/dev/dri/card0", O_RDONLY);
>> uint64_t data[2] = {0x11, 0x80};
>> ioctl(fd, 0xc010640cul /*DRM_IOCTL_GET_CAP*/, data);
>> return 0;
>> }
>>
>>
>> general protection fault: [#1] SMP DEBUG_PAGEALLOC KASAN
>> Modules linked in:
>> CPU: 1 PID: 5745 Comm: syz-executor Not tainted 4.8.0-rc5-next-20160905+ #14
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>> task: 8800310dc540 task.stack: 88003cbc
>> RIP: 0010:[] []
>> drm_getcap+0x34b/0x4f0 drivers/gpu/drm/drm_ioctl.c:260
>> RSP: 0018:88003cbc7c28 EFLAGS: 00010202
>> RAX: 0058 RBX: 88003cbc7cf8 RCX: c90001db
>> RDX: 005d RSI: 88003cbc7cf8 RDI: 02c0
>> RBP: 88003cbc7c50 R08: ed0007978fa1 R09: ed0007978fa0
>> R10: 88003cbc7d07 R11: ed0007978fa1 R12: fff0
>> R13: dc00 R14: 88003bcc6850 R15: fff2
>> FS: 7fcbf4e03700() GS:88003ed0() knlGS:
>> CS: 0010 DS: ES: CR0: 80050033
>> CR2: 006dce00 CR3: 66135000 CR4: 06e0
>> DR0: 001e DR1: 001e DR2:
>> DR3: DR6: 0ff0 DR7: 0600
>> Stack:
>> 88003c26db00 88003cbc7cf8 875a3000 88cf0ee0
>> fff2 88003cbc7dc0 834cb57c e200
>> 1101 875a1ba0 882ae930 0010
>> Call Trace:
>> [] drm_ioctl+0x54c/0xaf0 drivers/gpu/drm/drm_ioctl.c:728
>> [< inline >] vfs_ioctl fs/ioctl.c:43
>> [] do_vfs_ioctl+0x18c/0x1080 fs/ioctl.c:675
>> [< inline >] SYSC_ioctl fs/ioctl.c:690
>> [] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:681
>> [] entry_SYSCALL_64_fastpath+0x23/0xc1
>> Code: 3c 28 00 0f 85 88 01 00 00 49 8b 44 24 10 49 39 c6 4c 8d 60 f0
>> 74 82 e8 64 19 10 fe 49 8d bc 24 d0 02 00 00 48 89 f8 48 c1 e8 03 <42>
>> 80 3c 28 00 0f 85 6f 01 00 00 4d 8b bc 24 d0 02 00 00 49 8d
>> RIP [] drm_getcap+0x34b/0x4f0
>> drivers/gpu/drm/drm_ioctl.c:260
>> RSP
>> ---[ end trace c6e1afa8cd73b880 ]---
>>
>>
>> On commit 4affa544adb8077403893e62b9e327fcf87de6f7 (Sep 8) of linux-next.
>
> ping
>
> Still happens on 16ae16c6e5616c084168740990fc508bda6655d4 (Nov 24).
I suspect this is because we run drm_for_each_crtc() in
drm_getcap(DRM_PAGE_FLIP_TARGET) on a legacy driver (meaning
mode_config is not initialized). @danvet, how about always
initializing mode_config to 0/empty/dummy?
Dmitry, what driver do you run this on? And is CONFIG_DRM_LEGACY enabled?
Thanks
David
drm: GPF in drm_getcap
Hi
On Sat, Nov 26, 2016 at 6:50 PM, Dmitry Vyukov wrote:
> On Sat, Nov 26, 2016 at 6:35 PM, David Herrmann
> wrote:
>> Hi
>>
>> On Sat, Nov 26, 2016 at 6:17 PM, Dmitry Vyukov wrote:
>>> On Fri, Sep 9, 2016 at 1:56 PM, Dmitry Vyukov wrote:
Hello,
The following program triggers GPF in drm_getcap:
// autogenerated by syzkaller (http://github.com/google/syzkaller)
#include
#include
#include
#include
#include
#include
#include
#include
int main()
{
int fd = open("/dev/dri/card0", O_RDONLY);
uint64_t data[2] = {0x11, 0x80};
ioctl(fd, 0xc010640cul /*DRM_IOCTL_GET_CAP*/, data);
return 0;
}
general protection fault: [#1] SMP DEBUG_PAGEALLOC KASAN
Modules linked in:
CPU: 1 PID: 5745 Comm: syz-executor Not tainted 4.8.0-rc5-next-20160905+
#14
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs
01/01/2011
task: 8800310dc540 task.stack: 88003cbc
RIP: 0010:[] []
drm_getcap+0x34b/0x4f0 drivers/gpu/drm/drm_ioctl.c:260
RSP: 0018:88003cbc7c28 EFLAGS: 00010202
RAX: 0058 RBX: 88003cbc7cf8 RCX: c90001db
RDX: 005d RSI: 88003cbc7cf8 RDI: 02c0
RBP: 88003cbc7c50 R08: ed0007978fa1 R09: ed0007978fa0
R10: 88003cbc7d07 R11: ed0007978fa1 R12: fff0
R13: dc00 R14: 88003bcc6850 R15: fff2
FS: 7fcbf4e03700() GS:88003ed0()
knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 006dce00 CR3: 66135000 CR4: 06e0
DR0: 001e DR1: 001e DR2:
DR3: DR6: 0ff0 DR7: 0600
Stack:
88003c26db00 88003cbc7cf8 875a3000 88cf0ee0
fff2 88003cbc7dc0 834cb57c e200
1101 875a1ba0 882ae930 0010
Call Trace:
[] drm_ioctl+0x54c/0xaf0 drivers/gpu/drm/drm_ioctl.c:728
[< inline >] vfs_ioctl fs/ioctl.c:43
[] do_vfs_ioctl+0x18c/0x1080 fs/ioctl.c:675
[< inline >] SYSC_ioctl fs/ioctl.c:690
[] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:681
[] entry_SYSCALL_64_fastpath+0x23/0xc1
Code: 3c 28 00 0f 85 88 01 00 00 49 8b 44 24 10 49 39 c6 4c 8d 60 f0
74 82 e8 64 19 10 fe 49 8d bc 24 d0 02 00 00 48 89 f8 48 c1 e8 03 <42>
80 3c 28 00 0f 85 6f 01 00 00 4d 8b bc 24 d0 02 00 00 49 8d
RIP [] drm_getcap+0x34b/0x4f0
drivers/gpu/drm/drm_ioctl.c:260
RSP
---[ end trace c6e1afa8cd73b880 ]---
On commit 4affa544adb8077403893e62b9e327fcf87de6f7 (Sep 8) of linux-next.
>>>
>>> ping
>>>
>>> Still happens on 16ae16c6e5616c084168740990fc508bda6655d4 (Nov 24).
>>
>> I suspect this is because we run drm_for_each_crtc() in
>> drm_getcap(DRM_PAGE_FLIP_TARGET) on a legacy driver (meaning
>> mode_config is not initialized). @danvet, how about always
>> initializing mode_config to 0/empty/dummy?
>>
>> Dmitry, what driver do you run this on? And is CONFIG_DRM_LEGACY enabled?
>
>
> CONFIG_DRM_LEGACY is enabled.
>
> How can I understand what driver is used?
> This happens inside of qemu. This is the device:
> crw-rw---T 1 root video 226, 0 Nov 26 17:45 /dev/dri/card0
Usually by looking into `dmesg` and grepping for 'card0', or by inspecting:
/sys/class/drm/card0/device/
or more importantly looking at the symlink:
/sys/class/drm/card0/device/driver
Thanks
David
drm: GPF in drm_getcap
Hi On Sat, Nov 26, 2016 at 7:07 PM, Dmitry Vyukov wrote: > grep "card0" dmesg: > [5.298617] device: 'card0': device_add > [5.298946] PM: Adding info for No Bus:card0 > [6.436178] device: 'card0': device_add > [6.436488] PM: Adding info for No Bus:card0 > > > # ls -l /dev/dri/card0 > crw-rw---T 1 root video 226, 0 Nov 26 18:05 /dev/dri/card0 > > # ls -lt /sys/class/drm/card0/device/ > ls: cannot access /sys/class/drm/card0/device/: No such file or directory > > # ls -lt /sys/class/drm/card0/device/driver > ls: cannot access /sys/class/drm/card0/device/driver: No such file or > directory Looks like vgem. Something like this should help: https://gist.github.com/dvdhrm/1bcdf4f3485aa1614a0198a7b90515e2 I wonder whether it would be more appropriate to return -ENOTSUPP rather than 0. Thanks David
[Bug 98862] Awesomenauts black text
https://bugs.freedesktop.org/show_bug.cgi?id=98862 Bug ID: 98862 Summary: Awesomenauts black text Product: Mesa Version: 13.0 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: medium Component: Drivers/Gallium/r300 Assignee: dri-devel at lists.freedesktop.org Reporter: cosiekvfj at o2.pl QA Contact: dri-devel at lists.freedesktop.org Created attachment 128208 --> https://bugs.freedesktop.org/attachment.cgi?id=128208&action=edit picture Informacje o komputerze: Producent: Unknown Model: Unknown Rodzaj: Laptop Nie wykryto panelu dotykowego Informacje o procesorze: Dostawca CPU: GenuineIntel Marka procesora: Intel(R) Core(TM)2 CPU T5500 @ 1.66GHz Rodzina CPU: 0x6 Model CPU: 0xf Stepping CPU: 0x6 Typ CPU: 0x0 CzÄstotliwoÅÄ: 1667 MHz 2 rdzenie logiczne 2 rdzenie fizyczne HyperThreading: NieobsÅugiwane FCMOV: ObsÅugiwane SSE2: ObsÅugiwane SSE3: ObsÅugiwane SSSE3: ObsÅugiwane SSE4a: NieobsÅugiwane SSE41: NieobsÅugiwane SSE42: NieobsÅugiwane AES: NieobsÅugiwane AVX: NieobsÅugiwane CMPXCHG16B: ObsÅugiwane LAHF/SAHF: ObsÅugiwane PrefetchW: NieobsÅugiwane Informacje o sieci: SzybkoÅÄ sieci: Wersja systemu operacyjnego: "Manjaro Linux" (64-bitowy) Nazwa kernela: Linux Wersja kernela: 4.8.9-1-MANJARO Dostawca serwera X: The X.Org Foundation Wydanie serwera X: 11804000 Menedżer okien X: Xfwm4 Wersja biblioteki Steam: Karta graficzna: Sterownik: X.Org R300 Project Gallium 0.4 on ATI RC410 Wersja sterownika: 2.1 Mesa 13.0.1 Wersja OpenGL: 2.1 GÅÄbia kolorów pulpitu: 24 bitów na piksel CzÄstotliwoÅÄ odÅwieżania monitora: 59 Hz Ident. producenta: 0x1002 ID urzÄ dzenia: 0x5a62 Nie wykryto wersji Liczba monitorów: 1 Liczba logicznych ukÅadów graficznych: 1 RozdzielczoÅÄ gÅównego ekranu: 1280 x 800 RozdzielczoÅÄ pulpitu: 1280 x 800 Rozmiar gÅównego ekranu: 13,03" x 8,15" (15,35" diag) 33,1cm x 20,7cm (39,0cm diag) Nie wykryto gÅównego VRAM Karta dźwiÄkowa: DźwiÄk: Realtek ALC861-VD PamiÄÄ: RAM: 1877 MB Dodatki: JÄzyk interfejsu: Polski JÄZYK: pl_PL.utf8 Mikrofon: Not set PrzedÅużka i kabel Steam Controllera: Not set DostÄpne miejsce na twardym dysku: 54188 MB NajwiÄkszy wolny blok na twardym dysku: 26858 MB Gogle VR: Nie wykryto Ostatnie raporty niepowodzeÅ: Sat Nov 26 18:19:41 2016 GMT: file ''/tmp/dumps/crash_20161126191939_2.dmp'', upload yes: ''Discarded=1'' -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161126/482d5d5b/attachment.html>
[Bug 98862] Awesomenauts black text
https://bugs.freedesktop.org/show_bug.cgi?id=98862 --- Comment #1 from cosiekvfj at o2.pl --- Created attachment 128209 --> https://bugs.freedesktop.org/attachment.cgi?id=128209&action=edit log -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161126/a6822c10/attachment-0001.html>
[Bug 98862] Awesomenauts black text and background
https://bugs.freedesktop.org/show_bug.cgi?id=98862 cosiekvfj at o2.pl changed: What|Removed |Added Summary|Awesomenauts black text |Awesomenauts black text and ||background -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161126/56c3ef02/attachment.html>
[Bug 96868] AMDGPU Tonga only does 2560x1440 at 120hz, switching to 144hz causes display errors, same thing used to happen with fglrx.
https://bugs.freedesktop.org/show_bug.cgi?id=96868 --- Comment #10 from sonyp2p at gmail.com --- Same here with a RX 480. If I set 144Hz the screen start to flicker, but at 120Hz it works fine. I tried Xorg and Wayland and this issue is present in both. I'm using amdgpu with linux 4.8.10 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161126/25634fff/attachment.html>
[Bug 98005] VCE dual instance encoding inconsistent since st/va: enable dual instances encode by sync surface
https://bugs.freedesktop.org/show_bug.cgi?id=98005 --- Comment #28 from Andy Furniss --- Still good, so I think these are OK to go in. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161126/1af41012/attachment.html>
[Bug 96868] AMDGPU Tonga only does 2560x1440 at 120hz, switching to 144hz causes display errors, same thing used to happen with fglrx.
https://bugs.freedesktop.org/show_bug.cgi?id=96868 --- Comment #11 from sonyp2p at gmail.com --- (In reply to Alex Deucher from comment #4) > Does forcing the clocks to high or low fix the issue? (as root): > echo high > /sys/class/drm/card0/device/power_dpm_force_performance_level > or > echo low > /sys/class/drm/card0/device/power_dpm_force_performance_level I did this test and I can confirm that if I set power_dpm_force_performance_level to high or log the flickering stops. So at 144Hz with power_dpm_force_performance_level set to auto there is flickering. With power_dpm_force_performance_level set to high or low this bug is not present. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161126/9a632c39/attachment.html>
[Bug 98005] VCE dual instance encoding inconsistent since st/va: enable dual instances encode by sync surface
https://bugs.freedesktop.org/show_bug.cgi?id=98005 --- Comment #29 from Andy Furniss --- Maybe not yet - Been testing cbr and vbr and these seem OK still. There is an issue with cqp that I'll have to test further - it could be related to the source size, I am not sure yet. With 2160p gstreamer is Ok with its default QP of 26 or 28, but any higher it bails with - 0:00:00.252952155 6716 0x7f8898002d90 ERRORvaapiencode gstvaapiencode.c:210:gst_vaapiencode_default_alloc_buffer: invalid GstVaapiCodedBuffer size (0 bytes) 0:00:00.253007252 6716 0x7f8898002d90 ERRORvaapiencode gstvaapiencode.c:316:gst_vaapiencode_push_frame: failed to allocate encoded buffer in system memory It may be that there are other ways to hit this before the patches - I'll try more tomorrow. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161126/a3155d2f/attachment.html>
[Bug 98005] VCE dual instance encoding inconsistent since st/va: enable dual instances encode by sync surface
https://bugs.freedesktop.org/show_bug.cgi?id=98005 --- Comment #30 from Andy Furniss --- Seems that error is a bit random and not always there. It's possible with the patches to get corrupted output with cqp, fix seems easy = disable the statement - if (context->desc.h264enc.rate_ctrl.rate_ctrl_method != PIPE_H264_ENC_RATE_CONTROL_METHOD_DISABLE Unerlated observation while testing related to perf = I guess it depends on stream, but on a raw 2160p60 input from ram, with or without patches, I am more than twice as fast with init-qp <= 28. Timing luck loosing me dual instance? Or something more fundamental meaning the encoder works harder al lower rates? I notice that unlike omx when using cqp, some rate control settings are still filled in. omx is the same speed with higher qp - and produces bigger files for the same qp. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161126/98bedc5e/attachment.html>
drm: GPF in drm_getcap
On Fri, Sep 9, 2016 at 1:56 PM, Dmitry Vyukov wrote:
> Hello,
>
> The following program triggers GPF in drm_getcap:
>
> // autogenerated by syzkaller (http://github.com/google/syzkaller)
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
>
> int main()
> {
> int fd = open("/dev/dri/card0", O_RDONLY);
> uint64_t data[2] = {0x11, 0x80};
> ioctl(fd, 0xc010640cul /*DRM_IOCTL_GET_CAP*/, data);
> return 0;
> }
>
>
> general protection fault: [#1] SMP DEBUG_PAGEALLOC KASAN
> Modules linked in:
> CPU: 1 PID: 5745 Comm: syz-executor Not tainted 4.8.0-rc5-next-20160905+ #14
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> task: 8800310dc540 task.stack: 88003cbc
> RIP: 0010:[] []
> drm_getcap+0x34b/0x4f0 drivers/gpu/drm/drm_ioctl.c:260
> RSP: 0018:88003cbc7c28 EFLAGS: 00010202
> RAX: 0058 RBX: 88003cbc7cf8 RCX: c90001db
> RDX: 005d RSI: 88003cbc7cf8 RDI: 02c0
> RBP: 88003cbc7c50 R08: ed0007978fa1 R09: ed0007978fa0
> R10: 88003cbc7d07 R11: ed0007978fa1 R12: fff0
> R13: dc00 R14: 88003bcc6850 R15: fff2
> FS: 7fcbf4e03700() GS:88003ed0() knlGS:
> CS: 0010 DS: ES: CR0: 80050033
> CR2: 006dce00 CR3: 66135000 CR4: 06e0
> DR0: 001e DR1: 001e DR2:
> DR3: DR6: 0ff0 DR7: 0600
> Stack:
> 88003c26db00 88003cbc7cf8 875a3000 88cf0ee0
> fff2 88003cbc7dc0 834cb57c e200
> 1101 875a1ba0 882ae930 0010
> Call Trace:
> [] drm_ioctl+0x54c/0xaf0 drivers/gpu/drm/drm_ioctl.c:728
> [< inline >] vfs_ioctl fs/ioctl.c:43
> [] do_vfs_ioctl+0x18c/0x1080 fs/ioctl.c:675
> [< inline >] SYSC_ioctl fs/ioctl.c:690
> [] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:681
> [] entry_SYSCALL_64_fastpath+0x23/0xc1
> Code: 3c 28 00 0f 85 88 01 00 00 49 8b 44 24 10 49 39 c6 4c 8d 60 f0
> 74 82 e8 64 19 10 fe 49 8d bc 24 d0 02 00 00 48 89 f8 48 c1 e8 03 <42>
> 80 3c 28 00 0f 85 6f 01 00 00 4d 8b bc 24 d0 02 00 00 49 8d
> RIP [] drm_getcap+0x34b/0x4f0
> drivers/gpu/drm/drm_ioctl.c:260
> RSP
> ---[ end trace c6e1afa8cd73b880 ]---
>
>
> On commit 4affa544adb8077403893e62b9e327fcf87de6f7 (Sep 8) of linux-next.
ping
Still happens on 16ae16c6e5616c084168740990fc508bda6655d4 (Nov 24).
drm: GPF in drm_getcap
grep "card0" dmesg:
[5.298617] device: 'card0': device_add
[5.298946] PM: Adding info for No Bus:card0
[6.436178] device: 'card0': device_add
[6.436488] PM: Adding info for No Bus:card0
# ls -l /dev/dri/card0
crw-rw---T 1 root video 226, 0 Nov 26 18:05 /dev/dri/card0
# ls -lt /sys/class/drm/card0/device/
ls: cannot access /sys/class/drm/card0/device/: No such file or directory
# ls -lt /sys/class/drm/card0/device/driver
ls: cannot access /sys/class/drm/card0/device/driver: No such file or directory
On Sat, Nov 26, 2016 at 7:02 PM, David Herrmann
wrote:
> Hi
>
> On Sat, Nov 26, 2016 at 6:50 PM, Dmitry Vyukov wrote:
>> On Sat, Nov 26, 2016 at 6:35 PM, David Herrmann
>> wrote:
>>> Hi
>>>
>>> On Sat, Nov 26, 2016 at 6:17 PM, Dmitry Vyukov
>>> wrote:
On Fri, Sep 9, 2016 at 1:56 PM, Dmitry Vyukov
wrote:
> Hello,
>
> The following program triggers GPF in drm_getcap:
>
> // autogenerated by syzkaller (http://github.com/google/syzkaller)
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
>
> int main()
> {
> int fd = open("/dev/dri/card0", O_RDONLY);
> uint64_t data[2] = {0x11, 0x80};
> ioctl(fd, 0xc010640cul /*DRM_IOCTL_GET_CAP*/, data);
> return 0;
> }
>
>
> general protection fault: [#1] SMP DEBUG_PAGEALLOC KASAN
> Modules linked in:
> CPU: 1 PID: 5745 Comm: syz-executor Not tainted 4.8.0-rc5-next-20160905+
> #14
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs
> 01/01/2011
> task: 8800310dc540 task.stack: 88003cbc
> RIP: 0010:[] []
> drm_getcap+0x34b/0x4f0 drivers/gpu/drm/drm_ioctl.c:260
> RSP: 0018:88003cbc7c28 EFLAGS: 00010202
> RAX: 0058 RBX: 88003cbc7cf8 RCX: c90001db
> RDX: 005d RSI: 88003cbc7cf8 RDI: 02c0
> RBP: 88003cbc7c50 R08: ed0007978fa1 R09: ed0007978fa0
> R10: 88003cbc7d07 R11: ed0007978fa1 R12: fff0
> R13: dc00 R14: 88003bcc6850 R15: fff2
> FS: 7fcbf4e03700() GS:88003ed0()
> knlGS:
> CS: 0010 DS: ES: CR0: 80050033
> CR2: 006dce00 CR3: 66135000 CR4: 06e0
> DR0: 001e DR1: 001e DR2:
> DR3: DR6: 0ff0 DR7: 0600
> Stack:
> 88003c26db00 88003cbc7cf8 875a3000 88cf0ee0
> fff2 88003cbc7dc0 834cb57c e200
> 1101 875a1ba0 882ae930 0010
> Call Trace:
> [] drm_ioctl+0x54c/0xaf0
> drivers/gpu/drm/drm_ioctl.c:728
> [< inline >] vfs_ioctl fs/ioctl.c:43
> [] do_vfs_ioctl+0x18c/0x1080 fs/ioctl.c:675
> [< inline >] SYSC_ioctl fs/ioctl.c:690
> [] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:681
> [] entry_SYSCALL_64_fastpath+0x23/0xc1
> Code: 3c 28 00 0f 85 88 01 00 00 49 8b 44 24 10 49 39 c6 4c 8d 60 f0
> 74 82 e8 64 19 10 fe 49 8d bc 24 d0 02 00 00 48 89 f8 48 c1 e8 03 <42>
> 80 3c 28 00 0f 85 6f 01 00 00 4d 8b bc 24 d0 02 00 00 49 8d
> RIP [] drm_getcap+0x34b/0x4f0
> drivers/gpu/drm/drm_ioctl.c:260
> RSP
> ---[ end trace c6e1afa8cd73b880 ]---
>
>
> On commit 4affa544adb8077403893e62b9e327fcf87de6f7 (Sep 8) of linux-next.
ping
Still happens on 16ae16c6e5616c084168740990fc508bda6655d4 (Nov 24).
>>>
>>> I suspect this is because we run drm_for_each_crtc() in
>>> drm_getcap(DRM_PAGE_FLIP_TARGET) on a legacy driver (meaning
>>> mode_config is not initialized). @danvet, how about always
>>> initializing mode_config to 0/empty/dummy?
>>>
>>> Dmitry, what driver do you run this on? And is CONFIG_DRM_LEGACY enabled?
>>
>>
>> CONFIG_DRM_LEGACY is enabled.
>>
>> How can I understand what driver is used?
>> This happens inside of qemu. This is the device:
>> crw-rw---T 1 root video 226, 0 Nov 26 17:45 /dev/dri/card0
>
> Usually by looking into `dmesg` and grepping for 'card0', or by inspecting:
>
> /sys/class/drm/card0/device/
>
> or more importantly looking at the symlink:
>
> /sys/class/drm/card0/device/driver
>
> Thanks
> David
drm: GPF in drm_getcap
On Sat, Nov 26, 2016 at 6:35 PM, David Herrmann
wrote:
> Hi
>
> On Sat, Nov 26, 2016 at 6:17 PM, Dmitry Vyukov wrote:
>> On Fri, Sep 9, 2016 at 1:56 PM, Dmitry Vyukov wrote:
>>> Hello,
>>>
>>> The following program triggers GPF in drm_getcap:
>>>
>>> // autogenerated by syzkaller (http://github.com/google/syzkaller)
>>> #include
>>> #include
>>> #include
>>> #include
>>> #include
>>> #include
>>> #include
>>> #include
>>>
>>> int main()
>>> {
>>> int fd = open("/dev/dri/card0", O_RDONLY);
>>> uint64_t data[2] = {0x11, 0x80};
>>> ioctl(fd, 0xc010640cul /*DRM_IOCTL_GET_CAP*/, data);
>>> return 0;
>>> }
>>>
>>>
>>> general protection fault: [#1] SMP DEBUG_PAGEALLOC KASAN
>>> Modules linked in:
>>> CPU: 1 PID: 5745 Comm: syz-executor Not tainted 4.8.0-rc5-next-20160905+ #14
>>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>>> task: 8800310dc540 task.stack: 88003cbc
>>> RIP: 0010:[] []
>>> drm_getcap+0x34b/0x4f0 drivers/gpu/drm/drm_ioctl.c:260
>>> RSP: 0018:88003cbc7c28 EFLAGS: 00010202
>>> RAX: 0058 RBX: 88003cbc7cf8 RCX: c90001db
>>> RDX: 005d RSI: 88003cbc7cf8 RDI: 02c0
>>> RBP: 88003cbc7c50 R08: ed0007978fa1 R09: ed0007978fa0
>>> R10: 88003cbc7d07 R11: ed0007978fa1 R12: fff0
>>> R13: dc00 R14: 88003bcc6850 R15: fff2
>>> FS: 7fcbf4e03700() GS:88003ed0() knlGS:
>>> CS: 0010 DS: ES: CR0: 80050033
>>> CR2: 006dce00 CR3: 66135000 CR4: 06e0
>>> DR0: 001e DR1: 001e DR2:
>>> DR3: DR6: 0ff0 DR7: 0600
>>> Stack:
>>> 88003c26db00 88003cbc7cf8 875a3000 88cf0ee0
>>> fff2 88003cbc7dc0 834cb57c e200
>>> 1101 875a1ba0 882ae930 0010
>>> Call Trace:
>>> [] drm_ioctl+0x54c/0xaf0 drivers/gpu/drm/drm_ioctl.c:728
>>> [< inline >] vfs_ioctl fs/ioctl.c:43
>>> [] do_vfs_ioctl+0x18c/0x1080 fs/ioctl.c:675
>>> [< inline >] SYSC_ioctl fs/ioctl.c:690
>>> [] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:681
>>> [] entry_SYSCALL_64_fastpath+0x23/0xc1
>>> Code: 3c 28 00 0f 85 88 01 00 00 49 8b 44 24 10 49 39 c6 4c 8d 60 f0
>>> 74 82 e8 64 19 10 fe 49 8d bc 24 d0 02 00 00 48 89 f8 48 c1 e8 03 <42>
>>> 80 3c 28 00 0f 85 6f 01 00 00 4d 8b bc 24 d0 02 00 00 49 8d
>>> RIP [] drm_getcap+0x34b/0x4f0
>>> drivers/gpu/drm/drm_ioctl.c:260
>>> RSP
>>> ---[ end trace c6e1afa8cd73b880 ]---
>>>
>>>
>>> On commit 4affa544adb8077403893e62b9e327fcf87de6f7 (Sep 8) of linux-next.
>>
>> ping
>>
>> Still happens on 16ae16c6e5616c084168740990fc508bda6655d4 (Nov 24).
>
> I suspect this is because we run drm_for_each_crtc() in
> drm_getcap(DRM_PAGE_FLIP_TARGET) on a legacy driver (meaning
> mode_config is not initialized). @danvet, how about always
> initializing mode_config to 0/empty/dummy?
>
> Dmitry, what driver do you run this on? And is CONFIG_DRM_LEGACY enabled?
CONFIG_DRM_LEGACY is enabled.
How can I understand what driver is used?
This happens inside of qemu. This is the device:
crw-rw---T 1 root video 226, 0 Nov 26 17:45 /dev/dri/card0
