dri-devel July 2017

dri-devel@lists.freedesktop.org

212 participants
1542 discussions

[Bug 99426] gem_mmap_gtt swap tests are too long - perf: interrupt took too long
by bugzilla-daemon＠freedesktop.org 12 Nov '19

12 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=99426 Bug ID: 99426 Summary: gem_mmap_gtt swap tests are too long - perf: interrupt took too long Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: IGT Assignee: dri-devel(a)lists.freedesktop.org Reporter: christophe.prigent(a)intel.com Tested on BDW, SNB, SKL, IVB, HSW, BYT with SW config: Kernel: 4.10.0-rc3 ea7e3e5 branch drm-tip from https://cgit.freedesktop.org/drm-tip commit ea7e3e5c99e316fb6876399f9b32b2372e45c4af Author: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com> Date: Mon Jan 9 16:46:47 2017 +0200 drm-tip: 2017y-01m-09d-14h-45m-54s UTC integration manifest libdrm-2.4.74-21 geebefaf from git://anongit.freedesktop.org/mesa/drm mesa: mesa-13.0.2 c9e993b from git://anongit.freedesktop.org/mesa/mesa cairo 1.15.4 9fe6683 from git://anongit.freedesktop.org/cairo xorg-server-1.19.0-38 9d32b71 from git://git.freedesktop.org/git/xorg/xserver xf86-video-intel 2.99.917-747 028c946 from git://git.freedesktop.org/git/xorg/driver/xf86-video-intel libva-1.7.2-45 acbc209 from git://git.freedesktop.org/git/vaapi/libva vaapi-intel-driver: 1.7.2-216 70770f9 from git://git.freedesktop.org/git/vaapi/intel-driver intel-gpu-tools-1.17 e2eefcc from http://anongit.freedesktop.org/git/xorg/app/intel-gpu-tools.git Steps: ------- 1. Execute IGT test manually (no timeout is used): ./gem_mmap_gtt --r swap-copy 2. Wait 100 hours Actual results: ---------------- 2. Test is still not finished after 100 hours (IGT is still running - DUT is not freezed) dmesg shows the same logs on all platforms, example on SKL: [ 151.322722] [IGT] gem_mmap_gtt: executing [ 151.353973] [IGT] gem_mmap_gtt: starting subtest swap-copy [ 151.354090] gem_mmap_gtt (31952): drop_caches: 4 [ 4843.205005] perf: interrupt took too long (2540 > 2500), lowering kernel.perf_event_max_sample_rate to 78500 [ 6383.794279] perf: interrupt took too long (3202 > 3175), lowering kernel.perf_event_max_sample_rate to 62250 [ 9271.093175] perf: interrupt took too long (4037 > 4002), lowering kernel.perf_event_max_sample_rate to 49500 [14046.280647] perf: interrupt took too long (5090 > 5046), lowering kernel.perf_event_max_sample_rate to 39250 [22889.758381] perf: interrupt took too long (6365 > 6362), lowering kernel.perf_event_max_sample_rate to 31250 [50315.915256] perf: interrupt took too long (7982 > 7956), lowering kernel.perf_event_max_sample_rate to 25000 Expected results: ----------------- 2. Test is not so long Info: ----- I can't attach dmesg due to its size There is no log from IGT -- You are receiving this mail because: You are the assignee for the bug.

1 2

[Bug 193651] New: Amdgpu error messages at boot with Amd RX460
by bugzilla-daemon＠bugzilla.kernel.org 11 Nov '19

11 Nov '19

https://bugzilla.kernel.org/show_bug.cgi?id=193651 Bug ID: 193651 Summary: Amdgpu error messages at boot with Amd RX460 Product: Drivers Version: 2.5 Kernel Version: 4.11-wip Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: low Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: fin4478(a)hotmail.com Regression: No Created attachment 253581 --> https://bugzilla.kernel.org/attachment.cgi?id=253581&action=edit dmesg logfile I have Gigabyte RX460 2GB gpu card, Debian testing Xfce and adg5f drm-next-4.11-wip kernel downloaded and compiled as today. Computer works ok but the dmesg command shows the following boot errors that might interest amdgou driver developers. Mounting my home partiton fails amdgpu IB tests: [ 7.001953] [drm] ib test on ring 12 succeeded [ 7.055163] EXT4-fs (sda5): mounted filesystem with ordered data mode. Opts: (null) [ 8.011874] [drm:0xffffffffa01360ce] *ERROR* amdgpu: IB test timed out. [ 8.011910] [drm:0xffffffffa00e1b4b] *ERROR* amdgpu: failed testing IB on ring 13 (-110). [ 8.011943] [drm:0xffffffffa00be574] *ERROR* ib ring test failed (-110). Some powerplay errors: [ 4.888584] amdgpu: [powerplay] [AVFS] Something is broken. See log! [ 4.891452] amdgpu: [powerplay] Can't find requested voltage id in vdd_dep_on_sclk table! [ 4.894807] amdgpu: [powerplay] failed to send message 309 ret is 254 [ 4.894824] amdgpu: [powerplay] failed to send pre message 14e ret is 254 Bios recognition errors: [ 4.729628] [drm] BIOS signature incorrect 20 7 [ 4.729635] amdgpu 0000:01:00.0: Invalid PCI ROM header signature: expecting 0xaa55, got 0xffff -- You are receiving this mail because: You are watching the assignee of the bug.

1 30

[Bug 94581] Red flood in dmesg when running applications
by bugzilla-daemon＠freedesktop.org 23 Oct '19

23 Oct '19

https://bugs.freedesktop.org/show_bug.cgi?id=94581 Bug ID: 94581 Summary: Red flood in dmesg when running applications Product: Mesa Version: 11.0 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 Assignee: dri-devel(a)lists.freedesktop.org Reporter: mazahakaforever(a)ya.ru QA Contact: dri-devel(a)lists.freedesktop.org Hi there. Im using laptop with hybrid graphics. Intel Core i5-2450m with integrated videocard and AMD Radeon HD 6650m as discrete. My glxinfo output glxinfo | grep OpenGL OpenGL vendor string: Intel Open Source Technology Center OpenGL renderer string: Mesa DRI Intel(R) Sandybridge Mobile OpenGL core profile version string: 3.3 (Core Profile) Mesa 11.0.4 OpenGL core profile shading language version string: 3.30 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL core profile extensions: OpenGL version string: 3.0 Mesa 11.0.4 OpenGL shading language version string: 1.30 OpenGL context flags: (none) OpenGL extensions: OpenGL ES profile version string: OpenGL ES 3.0 Mesa 11.0.4 OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00 OpenGL ES profile extensions: And output with DRI_PRIME set. DRI_PRIME=1 glxinfo | grep OpenGL OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD TURKS (DRM 2.43.0, LLVM 3.6.2) OpenGL core profile version string: 3.3 (Core Profile) Mesa 11.0.4 OpenGL core profile shading language version string: 3.30 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL core profile extensions: OpenGL version string: 3.0 Mesa 11.0.4 OpenGL shading language version string: 1.30 OpenGL context flags: (none) OpenGL extensions: OpenGL ES profile version string: OpenGL ES 3.0 Mesa 11.0.4 OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00 OpenGL ES profile extensions: So, i guess when im using DRI_PRIME environmental variable as one - kernel tries to use discrete videocard. And when im trying to launch applications (glxgears, etracer, steam) i got many messages in dmesg like this [ 1376.309602] [drm:radeon_cs_parser_relocs [radeon]] *ERROR* gem object lookup failed 0xe [ 1376.309620] [drm:radeon_cs_ioctl [radeon]] *ERROR* Failed to parse relocation -2! [ 1376.822639] [drm:radeon_cs_parser_relocs [radeon]] *ERROR* gem object lookup failed 0xe [ 1376.822661] [drm:radeon_cs_ioctl [radeon]] *ERROR* Failed to parse relocation -2! Looking forward to some discussion. -- You are receiving this mail because: You are the assignee for the bug.

1 11

[Bug 100389] Can't cap framerate
by bugzilla-daemon＠freedesktop.org 14 Oct '19

14 Oct '19

https://bugs.freedesktop.org/show_bug.cgi?id=100389 Bug ID: 100389 Summary: Can't cap framerate Product: DRI Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: medium Component: General Assignee: dri-devel(a)lists.freedesktop.org Reporter: nw9165-3201(a)yahoo.com Hi, it's seems like it's not possible to cap (limit) the framerate. Or is it? If it's not currently possible, could you please implement it? Regards -- You are receiving this mail because: You are the assignee for the bug.

1 3

[Bug 51042] New: Turning off connector polling in drm_kms_helper inhibits HDMI hot plug
by bugzilla-daemon＠freedesktop.org 14 Oct '19

14 Oct '19

https://bugs.freedesktop.org/show_bug.cgi?id=51042 Bug #: 51042 Summary: Turning off connector polling in drm_kms_helper inhibits HDMI hot plug Classification: Unclassified Product: DRI Version: XOrg CVS Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: dargllun(a)gmail.com When turning off connector polling in drm_kms_helper using the poll=N module parameter HDMI hot plugging does not work anymore. Quoting Alex Deucher: See this discussion for details and some logs: http://comments.gmane.org/gmane.comp.freedesktop.xorg.drivers.ati/22107 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 2

[Bug 88921] X fails to start on QEMU/KVM with cirrus KMS since 3.19-rc
by bugzilla-daemon＠freedesktop.org 14 Oct '19

14 Oct '19

https://bugs.freedesktop.org/show_bug.cgi?id=88921 Bug ID: 88921 Summary: X fails to start on QEMU/KVM with cirrus KMS since 3.19-rc Product: DRI Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/other Assignee: dri-devel(a)lists.freedesktop.org Reporter: tiwai(a)suse.de X modesetting driver fails to start with cirrus KMS on QEMU/KVM since 3.19-rc. The culprit is the commit 8975626ea35adcca561f8a81dedccfbc5dd8ec72 drm/cirrus: allow 32bpp framebuffers for cirrus drm Reverting this commit makes X working again. X modesetting driver seems to try to open 1024x768x32 graphics, where the pitch is 4096 and greater than max_pitch (4088) defined in cirrus_check_framebuffer(). And it doesn't fall back to 24bpp as the patch expected. Tested with 3.19-rc7 with qemu 2.1 -vga cirrus option. -- You are receiving this mail because: You are the assignee for the bug.

1 1

[Bug 93718] nouveau + moveablecore => endless havoc (possibly a general drm problem)
by bugzilla-daemon＠freedesktop.org 14 Oct '19

14 Oct '19

https://bugs.freedesktop.org/show_bug.cgi?id=93718 Bug ID: 93718 Summary: nouveau + moveablecore => endless havoc (possibly a general drm problem) Product: DRI Version: XOrg git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: General Assignee: dri-devel(a)lists.freedesktop.org Reporter: rwhite(a)pobox.com NOTE: I'm actually using the gentoo x11 overlay which seems to be an xorg git... So reserving movable core on the linux command line seems to cause random failure in my nouveau dual monitor desktop system. (I suspect it's happening to a lessor extent on my radeon laptop as well). So anyway, I've been using "moveablecore=2G" on my kernel command line for some time in order to accommodate hugepages (etc) for transient virtual machines. When I started playing with SDDM and kde Plasma I started getting display hangs. The exact moment and error of the hang/error is hard to catch, but just starting sddm is enough to cause my dmesg to fill with faults. They all looked memory/state related so I started playing around. With no kernelcore= or moveablecore= options on the kernel command line the system seems rock steady. Using either (they both reserve a movable memory NUMA region that anonymous mappings via mmap() "like" and the kernel is free to relocate by juggling page tables and copying physical images) seems to steal data will-he/nil-he out from under nouveau. ASIDE: I say it may be happening on my radeon laptop because Chromium gets render-hung there for odd reasons but the diagnostics are more vague. So the work-around is to not use these options, but I suspect there's some missing page locking or whatever creating phantom failures... particularly in nouveau... particularly under high render pressure. With "moveablecore=2G kernelcore=3G" I can't even get all the way through the sddm password entry without a messy crash. This seems to line up with a lot of can-not-duplicate type of error reports I found with google, so I figure'd I drop my datapoint here. -- You are receiving this mail because: You are the assignee for the bug.

1 1

[Bug 71083] New: (struct drm_encoder_helper_funcs)->mode_set not re-called after display (and EDID) change
by bugzilla-daemon＠freedesktop.org 14 Oct '19

14 Oct '19

https://bugs.freedesktop.org/show_bug.cgi?id=71083 Priority: medium Bug ID: 71083 Assignee: dri-devel(a)lists.freedesktop.org Summary: (struct drm_encoder_helper_funcs)->mode_set not re-called after display (and EDID) change Severity: normal Classification: Unclassified OS: All Reporter: zajec5(a)gmail.com Hardware: Other Status: NEW Version: unspecified Component: DRM/other Product: DRI I use my DCE5 Barts (HD69xx) with AV-receiver Onkyo TX-SR605 and one of the following displays: 1) TV Sony Bravia KDL-52X3500 2) Projector Epson EH-TW6100 My problem is that when I change display connected to the Onkyo's output EDID changes, but drm doesn't call mode_set as long as I use the same resolution. To force drm to call mode_set I've to change resolution (xrandr --output HDMI-0 --mode X) and then swtich back to the mode I want. While the display seems to be working fine without that mode_set call, the audio engine doesn't. As part of the modesetting handler we read ELD-related info from EDID and write it to the audio engine of the GPU. Without this happening I can't play correctly audio (because also sees info about previous device, not the current one). I think mode_set should be called every time EDID changes. Is that right? In case someone's curious: 1) EDID with Onkyo + Sony TV: 00ffffffffffff003dcb610700000000 0011010380a05a780a0dc9a057479827 12484c21080081800101010101010101 010101010101023a801871382d40582c 450040846300001e011d007251d01e20 6e28550040846300001e000000fc0054 582d53523630350a20202020000000fd 00303e0e460f000a2020202020200185 02034c705c1f03041213051420071610 15110206010f1e0b1a191d0e0a242625 2335097f070f7f071707503f06c05706 005f7e01671e00834f00006c030c0012 00b82dc000000000e3050301023a80d0 72382d40102c458040846300001e011d 00bc52d01e20b828554040846300001e 00000000000000000000000000000078 2) EDID with Onkyo + Epson projector: 00ffffffffffff004ca333d000000000 0c150104952616780aa0558d515a962a 1c505400000001010101010101010101 0101010101016a4d80a07038fc413020 36007ed710000018d49a80a07038fc41 302036007ed710000038000000fc0053 414d53554e470a2020202020000000fc 00313733485430322d4330310a200035 -- You are receiving this mail because: You are the assignee for the bug.

1 3

[Bug 92481] [Patch] Mostly cosmetic changes for drm_dp_mst_i2c_xfer in Linux 4.3-rc5
by bugzilla-daemon＠freedesktop.org 14 Oct '19

14 Oct '19

https://bugs.freedesktop.org/show_bug.cgi?id=92481 Bug ID: 92481 Summary: [Patch] Mostly cosmetic changes for drm_dp_mst_i2c_xfer in Linux 4.3-rc5 Product: DRI Version: unspecified Hardware: Other OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/other Assignee: dri-devel(a)lists.freedesktop.org Reporter: adam_richter2004(a)yahoo.com Created attachment 118905 --> https://bugs.freedesktop.org/attachment.cgi?id=118905&action=edit Numerous mostly cosmetic fixed to drm_dp_mst_i2c_xfer in linux 4.3-rc5/drivers/gpu/drm/drm_dp_mst_topology.c AFTER Dave Airlie's other changes have been applied Thanks to Dave Airlie and Daniel Vitter for the the fixes to drm_dp_mst_i2c_xfer to avoid possibly sending unitialized data in DisplayPort multistream tranport i2c queries and to enforce the limit on the number of i2c transactions in a single i2c request to avoid a possible buffer overflow. The attached patch is based on the file with Dave's aforementioned changes applied. It is an a bunch of mostly cosmetic ("maintainability") changes, which I will list below: a. Move the parameter validations to before the call to drm_dp_get_validated_mstb_ref(), so that, if they fail, they do not need to use "goto out", thereby reducing the number of goto's and the longest distance between a goto and its target label. I imagine it also makes these rare failure cases a few nanoseconds faster without delaying the common case. b. Because of the above, txmsg no longer needs to be initialized to NULL. c. Have different error messages and error codes (E2BIG, and EINVAL) for num > 4 and the i2c transaction not ending with a read statement, for clearer debugging if either of these errors should occur, which should help in cases where the errors only occur sporadically or the person observing the error cannot easily recompile and install a new kernel to get more information. Error reproduction is precious, so it's best not to waste them with unnecessary ambiguity. These errors previous returned EIO, but EIO connotes a complaint from the hardware, hence the change to E2BIG and EINVAL. By the way, I am assuming that these conditions really can be caused by user level code accessing /dev/i2c... If not, then I would be happy to replace them with BUG_ON() statements. d. Delete the comment "see if last msg is a read", since (c) makes it redundant due to the clearer diagnostic message "Final DP-MST I2C transaction was not a read". e. Since we're concerned about invalid i2c message parameters resulting in invalid memory references, also guard against num <= 0. Return -EDOM in this case, since that really would cause a problem with the mathematical domain of a function, because the line "...num_transactions = num - 1" would result in -1 being cast into 255 for the 8 bit field num_transactions. f. Eliminate the variable "reading", which was computed and used only once, immediately after it was computed. g. Be more friendly to the optimizer by using unlikely() (and likely() instead of unlikely() in one place to reduce the number of parentheses). h. Be more friendly to the optimizer and maybe make the code more readable by consolidating the seven computions of "num - 1" into a new variable, "count". I know that having two varaibles named "num" and "count" where count == num - 1 is not the greatest naming convention. Please feel free to rename. There actually is one place toward the end of the function where "num" is used (rather than num - 1). h. Do the check for num - 1 > DP_REMOTE_I2C_READ_MAX_TRANSACTIONS in a manner not susceptible to integer overflow. I realize that this patch conflates all these different minor changes. I would be willing to submit these changes individually or in a few smaller groups if necessary. By the way, the attached patch assumes is against Linux 4.3-rc5 after Dave Airlie's patch from http://lists.freedesktop.org/archives/dri-devel/2015-October/092465.html is applied. Anyhow, I hope this patch is helpful. Adam -- You are receiving this mail because: You are the assignee for the bug.

1 1

[Bug 69675] New: audio broken in 24Hz/24p since 3.11 (regression)
by bugzilla-daemon＠freedesktop.org 14 Oct '19

14 Oct '19

https://bugs.freedesktop.org/show_bug.cgi?id=69675 Priority: medium Bug ID: 69675 Assignee: dri-devel(a)lists.freedesktop.org Summary: audio broken in 24Hz/24p since 3.11 (regression) Severity: normal Classification: Unclassified OS: All Reporter: pierre-bugzilla(a)ossman.eu Hardware: Other Status: NEW Version: unspecified Component: DRM/other Product: DRI Bug 64503 is back again, but this time it isn't a case of PEBKAC. Instead it is commit e6e792092e816bea0797995c886fb057c91d4546 that breaks things. With 3.10 I have just this 24p mode in Xorg: [ 47.361] (II) RADEON(0): Modeline "1920x1080"x24.0 74.25 1920 2558 2602 2750 1080 1084 1089 1125 +hsync +vsync (27.0 kHz e) With 3.11 I have two: Xorg.0.log:[ 56.189] (II) RADEON(0): Modeline "1920x1080"x24.0 74.25 1920 2558 2602 2750 1080 1084 1089 1125 +hsync +vsync (27.0 kHz e) Xorg.0.log:[ 56.189] (II) RADEON(0): Modeline "1920x1080"x24.0 74.18 1920 2558 2602 2750 1080 1084 1089 1125 +hsync +vsync (27.0 kHz e) And although the second one gives me an image, audio is royally screwed up. Please revert, or at least give us a knob to disable these extra modes. -- You are receiving this mail because: You are the assignee for the bug.

1 56

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel July 2017