-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Pink column of pixels with the KMS/DRM driver #46
Comments
Can you attach a full dmesg and /sys/class/drm/card0-HDMI-A-1/edid Due to limitations of EDID, 1366x768 has to be reported as 1360 or 1368 wide, and there are hacks to see this and do the right thing, which might not be doing the right thing on your display. |
(also, if you can start X, the output of xrandr when the bug is present would be interesting) |
Full dmesg:
However, /sys/class/drm/card0-HDMI-A-1/edid seems to contain non-text symbols, I guess it has to be decoded somehow, here it is mine: https://www.dropbox.com/s/ao2vfdnvkyyhraa/pink_line_monitor_pi_edid?dl=0 I have set up a fresh raspbian jessie SD to test this (I never use X for anything, so it's not on my system), so I have access to xrandr:
Hope it helps! :) |
There's a link just below the comment entry box to attach files; that was the intent (and is required for edid). The xrandr output there definitely shows that the 1366 hack isn't taking effect. |
@anholt: I have built and installed today's git kernel from the raspberrypi/linux repository and the pink column is no more. EDIT: Simply updating to current kernel via rpi-update fixes this issue, too. Thanks, Anholt 👍 |
For our fake dma objects we can leak the underlying gem object if we fail to pin our "backing storage". [ 39.952618] ============================================================================= [ 39.952625] BUG mock_object (Tainted: G U ): Objects remaining in mock_object on __kmem_cache_shutdown() [ 39.952629] ----------------------------------------------------------------------------- [ 39.952633] Disabling lock debugging due to kernel taint [ 39.952635] INFO: Slab 0xffffea00086c6a00 objects=21 used=1 fp=0xffff88021b1abc00 flags=0x5fff8000008100 [ 39.952640] CPU: 1 PID: 1258 Comm: drv_selftest Tainted: G BU 4.10.0+ #46 [ 39.952641] Hardware name: Apple Inc. MacBookPro11,1/Mac-189A3D4F975D5FFC, BIOS MBP111.88Z.0138.B17.1602221718 02/22/2016 [ 39.952642] Call Trace: [ 39.952648] dump_stack+0x4d/0x6f [ 39.952651] slab_err+0x9d/0xb0 [ 39.952654] ? ksm_migrate_page+0xe0/0xe0 [ 39.952657] ? on_each_cpu_cond+0x9a/0xc0 [ 39.952658] ? __kmalloc+0x1af/0x1c0 [ 39.952660] ? __kmem_cache_shutdown+0x173/0x3e0 [ 39.952661] __kmem_cache_shutdown+0x196/0x3e0 [ 39.952664] kmem_cache_destroy+0xa0/0x150 [ 39.952708] mock_device_release+0x113/0x140 [i915] [ 39.952726] drm_dev_release+0x20/0x40 [drm] [ 39.952735] drm_dev_unref+0x23/0x30 [drm] [ 39.952768] i915_gem_gtt_mock_selftests+0x55/0x70 [i915] [ 39.952803] __run_selftests+0x169/0x1c0 [i915] [ 39.952805] ? 0xffffffffa0151000 [ 39.952840] i915_mock_selftests+0x30/0x60 [i915] [ 39.952869] i915_init+0xc/0x78 [i915] [ 39.952870] ? 0xffffffffa0151000 [ 39.952872] do_one_initcall+0x43/0x170 [ 39.952874] ? __vunmap+0x81/0xd0 [ 39.952875] ? kmem_cache_alloc_trace+0x37/0x170 [ 39.952877] ? do_init_module+0x27/0x1f8 [ 39.952879] do_init_module+0x5f/0x1f8 [ 39.952881] load_module+0x2423/0x29b0 [ 39.952882] ? __symbol_put+0x40/0x40 [ 39.952885] ? kernel_read_file+0x1a3/0x1c0 [ 39.952887] SYSC_finit_module+0xbc/0xf0 [ 39.952889] SyS_finit_module+0xe/0x10 [ 39.952892] entry_SYSCALL_64_fastpath+0x13/0x94 v2: use onion teardown and favour i915_gem_object_put Fixes: 8d28ba4 ("drm/i915: Exercise filling the top/bottom portions of the ppgtt") Signed-off-by: Matthew Auld <[email protected]> Cc: Chris Wilson <[email protected]> Cc: Joonas Lahtinen <[email protected]> Reviewed-by: Joonas Lahtinen <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Chris Wilson <[email protected]>
… await Although we do check the completion-status of the request before actually adding a wait on it (either to its submit fence or its completion dma-fence), we currently do not check before adding it to the dependency lists. In fact, without checking for a completed request we may try to use the signaler after it has been retired and its dependency tree freed: [ 60.044057] BUG: KASAN: use-after-free in __list_add_valid+0x1d/0xd0 at addr ffff880348c9e6a0 [ 60.044118] Read of size 8 by task gem_exec_fence/530 [ 60.044164] CPU: 1 PID: 530 Comm: gem_exec_fence Tainted: G E 4.11.0-rc7+ #46 [ 60.044226] Hardware name: ��������������������������������� ���������������������������������/���������������������������������, BIOS RYBDWi35.86A.0246.2 [ 60.044290] Call Trace: [ 60.044337] dump_stack+0x4d/0x6a [ 60.044383] kasan_object_err+0x21/0x70 [ 60.044435] kasan_report+0x225/0x4e0 [ 60.044488] ? __list_add_valid+0x1d/0xd0 [ 60.044534] ? kasan_kmalloc+0xad/0xe0 [ 60.044587] __asan_load8+0x5e/0x70 [ 60.044639] __list_add_valid+0x1d/0xd0 [ 60.044788] __i915_priotree_add_dependency+0x67/0x130 [i915] [ 60.044895] i915_gem_request_await_request+0xa8/0x370 [i915] [ 60.044974] i915_gem_request_await_dma_fence+0x129/0x140 [i915] [ 60.045049] i915_gem_do_execbuffer.isra.37+0xb0a/0x26b0 [i915] [ 60.045077] ? save_stack+0xb1/0xd0 [ 60.045105] ? save_stack_trace+0x1b/0x20 [ 60.045132] ? save_stack+0x46/0xd0 [ 60.045158] ? kasan_kmalloc+0xad/0xe0 [ 60.045184] ? __kmalloc+0xd8/0x670 [ 60.045229] ? drm_ioctl+0x359/0x640 [drm] [ 60.045256] ? SyS_ioctl+0x41/0x70 [ 60.045330] ? i915_vma_move_to_active+0x540/0x540 [i915] [ 60.045360] ? tty_insert_flip_string_flags+0xa1/0xf0 [ 60.045387] ? tty_flip_buffer_push+0x63/0x70 [ 60.045414] ? remove_wait_queue+0xa9/0xc0 [ 60.045441] ? kasan_unpoison_shadow+0x35/0x50 [ 60.045467] ? kasan_kmalloc+0xad/0xe0 [ 60.045494] ? kasan_check_write+0x14/0x20 [ 60.045568] i915_gem_execbuffer2+0xdb/0x2a0 [i915] [ 60.045616] drm_ioctl+0x359/0x640 [drm] [ 60.045705] ? i915_gem_execbuffer+0x5a0/0x5a0 [i915] [ 60.045751] ? drm_version+0x150/0x150 [drm] [ 60.045778] ? compat_start_thread+0x60/0x60 [ 60.045805] ? plist_del+0xda/0x1a0 [ 60.045833] do_vfs_ioctl+0x12e/0x910 [ 60.045860] ? ioctl_preallocate+0x130/0x130 [ 60.045886] ? pci_mmcfg_check_reserved+0xc0/0xc0 [ 60.045913] ? vfs_write+0x196/0x240 [ 60.045939] ? __fget_light+0xa7/0xc0 [ 60.045965] SyS_ioctl+0x41/0x70 [ 60.045991] entry_SYSCALL_64_fastpath+0x17/0x98 [ 60.046017] RIP: 0033:0x7feb2baefc47 [ 60.046042] RSP: 002b:00007fff56d28e58 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 60.046075] RAX: ffffffffffffffda RBX: 00007fff56d290a8 RCX: 00007feb2baefc47 [ 60.046102] RDX: 00007fff56d29050 RSI: 00000000c0406469 RDI: 0000000000000003 [ 60.046129] RBP: 00007fff56d29050 R08: 000055ecc4cd27d0 R09: 00007feb2bda8600 [ 60.046154] R10: 0000000000000073 R11: 0000000000000246 R12: 00000000c0406469 [ 60.046177] R13: 0000000000000003 R14: 000000000000000f R15: 0000000000000099 [ 60.046203] Object at ffff880348c9e680, in cache i915_dependency size: 64 [ 60.046225] Allocated: [ 60.046246] PID = 530 [ 60.046269] save_stack_trace+0x1b/0x20 [ 60.046292] save_stack+0x46/0xd0 [ 60.046318] kasan_kmalloc+0xad/0xe0 [ 60.046343] kasan_slab_alloc+0x12/0x20 [ 60.046368] kmem_cache_alloc+0xab/0x650 [ 60.046445] i915_gem_request_await_request+0x88/0x370 [i915] [ 60.046559] i915_gem_request_await_dma_fence+0x129/0x140 [i915] [ 60.046705] i915_gem_do_execbuffer.isra.37+0xb0a/0x26b0 [i915] [ 60.046849] i915_gem_execbuffer2+0xdb/0x2a0 [i915] [ 60.046936] drm_ioctl+0x359/0x640 [drm] [ 60.046987] do_vfs_ioctl+0x12e/0x910 [ 60.047038] SyS_ioctl+0x41/0x70 [ 60.047090] entry_SYSCALL_64_fastpath+0x17/0x98 [ 60.047139] Freed: [ 60.047179] PID = 530 [ 60.047223] save_stack_trace+0x1b/0x20 [ 60.047269] save_stack+0x46/0xd0 [ 60.047317] kasan_slab_free+0x72/0xc0 [ 60.047366] kmem_cache_free+0x39/0x160 [ 60.047512] i915_gem_request_retire+0x83f/0x930 [i915] [ 60.047657] i915_gem_request_alloc+0x166/0x600 [i915] [ 60.047799] i915_gem_do_execbuffer.isra.37+0xad8/0x26b0 [i915] [ 60.047897] i915_gem_execbuffer2+0xdb/0x2a0 [i915] [ 60.047942] drm_ioctl+0x359/0x640 [drm] [ 60.047968] do_vfs_ioctl+0x12e/0x910 [ 60.047993] SyS_ioctl+0x41/0x70 [ 60.048019] entry_SYSCALL_64_fastpath+0x17/0x98 [ 60.048044] Memory state around the buggy address: [ 60.048066] ffff880348c9e580: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc [ 60.048105] ffff880348c9e600: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc [ 60.048138] >ffff880348c9e680: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc [ 60.048170] ^ [ 60.048191] ffff880348c9e700: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc [ 60.048225] ffff880348c9e780: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc Note to hit the use-after-free requires us to be passed back a request via a fence-array, that is from explicit fencing accumulated into a sync-file fence-array. Fixes: 52e5420 ("drm/i915/scheduler: Record all dependencies upon request construction") Testcase: igt/gem_exec_fence/expired-history Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Michał Winiarski <[email protected]> Reviewed-by: Joonas Lahtinen <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit ade0b0c) Signed-off-by: Jani Nikula <[email protected]>
Hi,
Using the old graphics mode, there's no problem, but booting with the VC4 driver shows a pink column of pixels on the console, on the left border of the HDMI TV.
My Pi and TV are running at the recommended mode of 1360x768 pixels.
This is the problem:
https://www.dropbox.com/s/wdf64hb0b26p8ha/20160724_221438.jpg
Any ideas on this issue?
The text was updated successfully, but these errors were encountered: