Oops while changing resolutions of rotated EVDI screen
Reported by
dawid.ku...@displaylink.com,
Mar 21 2016
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.87 Safari/537.36 Platform: 8074.0.0 (Official Build) dev-channel lulu test Steps to reproduce the problem: 1. Attach extended EVDI monitor (DL3 device) 2. Rotate extended screen 90degs 3. Cycle via all available resolutions for screen 4. After each cycle wait for monitor to fully display pixels What is the expected behavior? No oops, clean change via all available resolution What went wrong? During toggle via resolutions system reboots, because of oops. Did this work before? No Chrome version: 51.0.2679.0 (Official Build) dev (64-bit) Channel: stable OS Version: Flash Version: [ 220.386156] ------------[ cut here ]------------ [ 220.386171] WARNING: CPU: 0 PID: 55 at /mnt/host/source/src/third_party/kernel/v3.14/include/linux/kref.h:47 drm_framebuffer_reference+0x64/0x71() [ 220.386183] Modules linked in: rfcomm i2c_dev uinput evdi cros_ec_accel btusb btbcm x86_pkg_temp_thermal iio_trig_sysfs kfifo_buf industrialio btintel aesni_intel bluetooth aes_x86_64 glue_helper memc_x86 uvcvideo lrw gf128mul ablk_helper cryptd videobuf2_vmalloc zram snd_soc_sst_acpi fuse ctr ccm nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables snd_hda_codec_realtek iwlmvm iwl7000_mac80211 snd_hda_codec_generic snd_hda_codec_hdmi iwlwifi snd_hda_intel snd_hda_controller cfg80211 snd_hda_codec cdc_mbim cdc_wdm cdc_ncm usbnet mii snd_usb_audio snd_usbmidi_lib snd_hwdep joydev snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device ppp_async ppp_generic slhc tun [ 220.386359] CPU: 0 PID: 55 Comm: kworker/u8:2 Not tainted 3.14.0 #1 [ 220.386367] Hardware name: GOOGLE Lulu, BIOS Google_Lulu.6301.136.16 07/14/2015 [ 220.386380] Workqueue: flip evdi_driver_preclose [evdi] [ 220.386388] 0000000000000000 00000000ae6579de ffff88017930fd00 ffffffff9279b136 [ 220.386401] 0000000000000000 ffff88017930fd38 ffffffff9223dedb ffffffff924c1c12 [ 220.386413] ffff88006c4a8b40 ffff88017930fdb0 ffff88006b8026c0 ffff88006c4a8b40 [ 220.386426] Call Trace: [ 220.386435] [<ffffffff9279b136>] dump_stack+0x4d/0x6f [ 220.386446] [<ffffffff9223dedb>] warn_slowpath_common+0x7f/0x98 [ 220.386456] [<ffffffff924c1c12>] ? drm_framebuffer_reference+0x64/0x71 [ 220.386466] [<ffffffff9223dfed>] warn_slowpath_null+0x1a/0x1c [ 220.386475] [<ffffffff924c1c12>] drm_framebuffer_reference+0x64/0x71 [ 220.386487] [<ffffffffc030cf2f>] evdi_painter_mark_dirty+0xd9/0x193 [evdi] [ 220.386498] [<ffffffffc030ba90>] evdi_handle_damage+0x17c/0x41b [evdi] [ 220.386507] [<ffffffff922012f2>] ? __switch_to+0x1cc/0x3f3 [ 220.386518] [<ffffffffc030a819>] evdi_driver_preclose+0x819/0xbba [evdi] [ 220.386529] [<ffffffff92255a63>] process_one_work+0x187/0x2d0 [ 220.386538] [<ffffffff92256736>] worker_thread+0x143/0x202 [ 220.386547] [<ffffffff922565f3>] ? rescuer_thread+0x2c3/0x2c3 [ 220.386556] [<ffffffff9225b706>] kthread+0x108/0x110 [ 220.386565] [<ffffffff9225b5fe>] ? __kthread_parkme+0x67/0x67 [ 220.386576] [<ffffffff927a02ec>] ret_from_fork+0x7c/0xb0 [ 220.386584] [<ffffffff9225b5fe>] ? __kthread_parkme+0x67/0x67 [ 220.386593] ---[ end trace f345d0720f7a5448 ]--- [ 220.392851] general protection fault: 0000 [#1] PREEMPT SMP [ 220.395250] gsmi: Log Shutdown Reason 0x03 [ 220.395256] Modules linked in: rfcomm i2c_dev uinput evdi cros_ec_accel btusb btbcm x86_pkg_temp_thermal iio_trig_sysfs kfifo_buf industrialio btintel aesni_intel bluetooth aes_x86_64 glue_helper memc_x86 uvcvideo lrw gf128mul ablk_helper cryptd videobuf2_vmalloc zram snd_soc_sst_acpi fuse ctr ccm nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables snd_hda_codec_realtek iwlmvm iwl7000_mac80211 snd_hda_codec_generic snd_hda_codec_hdmi iwlwifi snd_hda_intel snd_hda_controller cfg80211 snd_hda_codec cdc_mbim cdc_wdm cdc_ncm usbnet mii snd_usb_audio snd_usbmidi_lib snd_hwdep joydev snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device ppp_async ppp_generic slhc tun [ 220.395409] CPU: 0 PID: 55 Comm: kworker/u8:2 Tainted: G W 3.14.0 #1 [ 220.395418] Hardware name: GOOGLE Lulu, BIOS Google_Lulu.6301.136.16 07/14/2015 [ 220.395431] Workqueue: flip evdi_driver_preclose [evdi] [ 220.395439] task: ffff880179afb480 ti: ffff88017930e000 task.ti: ffff88017930e000 [ 220.395447] RIP: 0010:[<ffffffff924c037a>] [<ffffffff924c037a>] list_del+0x8/0x2f [ 220.395461] RSP: 0018:ffff88017930fcf8 EFLAGS: 00010202 [ 220.395468] RAX: dead000000200200 RBX: ffff88006c4a8b40 RCX: 00000000fffffffe [ 220.395475] RDX: dead000000100100 RSI: ffffffff9299d264 RDI: ffff88006c4a8b50 [ 220.395484] RBP: ffff88017930fd20 R08: ffff88006c4a8b40 R09: 0000000000000000 [ 220.395492] R10: 0000000000000000 R11: 0000000000000006 R12: ffff88006c4a8240 [ 220.395500] R13: ffff88006c4a8610 R14: ffff88006c4a8c00 R15: ffff88006c4a8c00 [ 220.395508] FS: 0000000000000000(0000) GS:ffff88017ec00000(0000) knlGS:0000000000000000 [ 220.395517] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 220.395523] CR2: 00007fe2a236c4e8 CR3: 0000000073dd6000 CR4: 00000000003407f0 [ 220.395531] Stack: [ 220.395534] ffff88017930fd20 ffffffff924c0a95 ffff88006c4a8b40 ffff88017930fdb0 [ 220.395546] ffff88006b8026c0 ffff88017930fd38 ffffffffc030b909 ffff88006c4a8b40 [ 220.395558] ffff88017930fd48 ffffffff924c0416 ffff88017930fd60 ffffffff924c2041 [ 220.395569] Call Trace: [ 220.395579] [<ffffffff924c0a95>] ? drm_framebuffer_cleanup+0x2d/0x44 [ 220.395590] [<ffffffffc030b909>] evdi_driver_unload+0x4fe/0x509 [evdi] [ 220.395601] [<ffffffff924c0416>] drm_framebuffer_free+0x13/0x15 [ 220.395610] [<ffffffff924c2041>] drm_framebuffer_unreference+0x4c/0x52 [ 220.395621] [<ffffffffc030cf27>] evdi_painter_mark_dirty+0xd1/0x193 [evdi] [ 220.395632] [<ffffffffc030ba90>] evdi_handle_damage+0x17c/0x41b [evdi] [ 220.395642] [<ffffffff922012f2>] ? __switch_to+0x1cc/0x3f3 [ 220.395651] [<ffffffffc030a819>] evdi_driver_preclose+0x819/0xbba [evdi] [ 220.395662] [<ffffffff92255a63>] process_one_work+0x187/0x2d0 [ 220.395671] [<ffffffff92256736>] worker_thread+0x143/0x202 [ 220.395680] [<ffffffff922565f3>] ? rescuer_thread+0x2c3/0x2c3 [ 220.395689] [<ffffffff9225b706>] kthread+0x108/0x110 [ 220.395697] [<ffffffff9225b5fe>] ? __kthread_parkme+0x67/0x67 [ 220.395708] [<ffffffff927a02ec>] ret_from_fork+0x7c/0xb0 [ 220.395716] [<ffffffff9225b5fe>] ? __kthread_parkme+0x67/0x67 [ 220.395723] Code: 4d 89 e0 4c 89 f9 4c 89 f6 48 c7 c7 3d f7 99 92 31 c0 e8 ad a4 2d 00 58 5b 41 5c 41 5d 41 5e 41 5f 5d c3 48 8b 47 08 48 8b 17 55 <48> 89 42 08 48 89 10 48 b8 00 01 10 00 00 00 ad de 48 89 07 48 [ 220.395813] RIP [<ffffffff924c037a>] list_del+0x8/0x2f [ 220.395824] RSP <ffff88017930fcf8>
,
Apr 25 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/b7eefc97efc98537874a5a3a66be41f521a27c3f commit b7eefc97efc98537874a5a3a66be41f521a27c3f Author: Dawid Kurek <dawid.kurek@displaylink.com> Date: Mon Mar 21 12:32:13 2016 drm/evdi: Threadsafe reference of framebuffer count Fixed the way how we store recentFB pointer. Previously it was referenced in evdi_sched_page_flip function which runs asynchronously. This sometimes leads to incrementing ref count of 0 and assertion hit, i.e. when framebuffer is removed from other thread. Safe way of storing framebuffer is to reference it in evdi_crtc_mode_set or in evdi_crtc_page_flip. Also refactored a bit evdi_painter_grabpix_ioctl. BUG= chromium:596408 TEST=Manual looping through extended and rotated EVDI monitor works fine, without any system crash. Change-Id: Iffa7d13e6e647d09ec534081d8f5801137fd6ab9 Signed-off-by: Dawid Kurek <dawid.kurek@displaylink.com> Reviewed-on: https://chromium-review.googlesource.com/333753 Tested-by: Łukasz Spintzyk <lukasz.spintzyk@displaylink.com> Reviewed-by: Haixia Shi <hshi@chromium.org> [modify] https://crrev.com/b7eefc97efc98537874a5a3a66be41f521a27c3f/drivers/gpu/drm/evdi/evdi_painter.c [modify] https://crrev.com/b7eefc97efc98537874a5a3a66be41f521a27c3f/drivers/gpu/drm/evdi/evdi_fb.c [modify] https://crrev.com/b7eefc97efc98537874a5a3a66be41f521a27c3f/drivers/gpu/drm/evdi/evdi_modeset.c [modify] https://crrev.com/b7eefc97efc98537874a5a3a66be41f521a27c3f/drivers/gpu/drm/evdi/evdi_drv.h
,
May 19 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/4f549faee44b4f969f2910b68a9529a5b47a1424 commit 4f549faee44b4f969f2910b68a9529a5b47a1424 Author: Dawid Kurek <dawid.kurek@displaylink.com> Date: Mon Mar 21 12:32:13 2016 drm/evdi: Threadsafe reference of framebuffer count Fixed the way how we store recentFB pointer. Previously it was referenced in evdi_sched_page_flip function which runs asynchronously. This sometimes leads to incrementing ref count of 0 and assertion hit, i.e. when framebuffer is removed from other thread. Safe way of storing framebuffer is to reference it in evdi_crtc_mode_set or in evdi_crtc_page_flip. Also refactored a bit evdi_painter_grabpix_ioctl. BUG= chromium:596408 TEST=Manual looping through extended and rotated EVDI monitor works fine, without any system crash. Change-Id: Ie7d0114004341d37561fe1a9dc73d0f2e450bc2b Signed-off-by: Szymon Kunc <szymon.kunc@displaylink.com> Reviewed-on: https://chromium-review.googlesource.com/345830 Commit-Ready: Łukasz Spintzyk <lukasz.spintzyk@displaylink.com> Tested-by: Łukasz Spintzyk <lukasz.spintzyk@displaylink.com> Reviewed-by: Bernie Thompson <bhthompson@chromium.org> [modify] https://crrev.com/4f549faee44b4f969f2910b68a9529a5b47a1424/drivers/gpu/drm/evdi/evdi_painter.c [modify] https://crrev.com/4f549faee44b4f969f2910b68a9529a5b47a1424/drivers/gpu/drm/evdi/evdi_fb.c [modify] https://crrev.com/4f549faee44b4f969f2910b68a9529a5b47a1424/drivers/gpu/drm/evdi/evdi_modeset.c [modify] https://crrev.com/4f549faee44b4f969f2910b68a9529a5b47a1424/drivers/gpu/drm/evdi/evdi_drv.h
,
May 19 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/f30bb0ac514bdb61209effcafdead567b2c888af commit f30bb0ac514bdb61209effcafdead567b2c888af Author: Dawid Kurek <dawid.kurek@displaylink.com> Date: Mon Mar 21 12:32:13 2016 drm/evdi: Threadsafe reference of framebuffer count Fixed the way how we store recentFB pointer. Previously it was referenced in evdi_sched_page_flip function which runs asynchronously. This sometimes leads to incrementing ref count of 0 and assertion hit, i.e. when framebuffer is removed from other thread. Safe way of storing framebuffer is to reference it in evdi_crtc_mode_set or in evdi_crtc_page_flip. Also refactored a bit evdi_painter_grabpix_ioctl. BUG= chromium:596408 TEST=Manual looping through extended and rotated EVDI monitor works fine, without any system crash. Change-Id: Iffa7d13e6e647d09ec534081d8f5801137fd6ab9 Signed-off-by: Dawid Kurek <dawid.kurek@displaylink.com> Reviewed-on: https://chromium-review.googlesource.com/333753 Tested-by: ukasz Spintzyk <lukasz.spintzyk@displaylink.com> Reviewed-by: Haixia Shi <hshi@chromium.org> (cherry picked from commit b7eefc97efc98537874a5a3a66be41f521a27c3f) Reviewed-on: https://chromium-review.googlesource.com/342381 Commit-Ready: Łukasz Spintzyk <lukasz.spintzyk@displaylink.com> Tested-by: Łukasz Spintzyk <lukasz.spintzyk@displaylink.com> Reviewed-by: Bernie Thompson <bhthompson@chromium.org> [modify] https://crrev.com/f30bb0ac514bdb61209effcafdead567b2c888af/drivers/gpu/drm/evdi/evdi_painter.c [modify] https://crrev.com/f30bb0ac514bdb61209effcafdead567b2c888af/drivers/gpu/drm/evdi/evdi_fb.c [modify] https://crrev.com/f30bb0ac514bdb61209effcafdead567b2c888af/drivers/gpu/drm/evdi/evdi_modeset.c [modify] https://crrev.com/f30bb0ac514bdb61209effcafdead567b2c888af/drivers/gpu/drm/evdi/evdi_drv.h
,
May 19 2017
Issue has not been modified or commented on in the last 365 days, please re-open or file a new bug if this is still an issue. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by dchan@google.com
, Apr 8 2016Labels: GPU-Other