I'll check this one on TOT first.

I got an almost identical kernel panic with a UGA-165 USB 2.0 display adapter + HDMI 1920x1080 on auron_yuna (which happens to also have 1920x1080 primary display). This is on the latest canary 51.0.2671.0.

[  994.618810] ------------[ cut here ]------------
[  994.618847] WARNING: CPU: 3 PID: 28963 at /mnt/host/source/src/third_party/kernel/v3.14/drivers/gpu/drm/i915/intel_display.c:10400 intel_crtc_set_config+0x77c/0x95a()
[  994.618880] Modules linked in: i2c_dev uinput x86_pkg_temp_thermal snd_hda_codec_realtek snd_hda_codec_generic memc_x86 iwlmvm iwl7000_mac80211 aesni_intel snd_hda_codec_hdmi aes_x86_64 glue_helper lrw gf128mul ablk_helper rfcomm cryptd cros_ec_accel iio_trig_sysfs kfifo_buf industrialio iwlwifi zram snd_hda_intel snd_hda_controller snd_hda_codec snd_hwdep snd_soc_sst_acpi fuse cfg80211 btusb btbcm btintel bluetooth nf_conntrack_ipv6 nf_defrag_ipv6 uvcvideo ip6table_filter videobuf2_vmalloc ip6_tables cdc_ether usbnet mii joydev snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device ppp_async ppp_generic slhc tun
[  994.619160] CPU: 3 PID: 28963 Comm: DrmThread Tainted: G        W    3.14.0 #1
[  994.619179] Hardware name: GOOGLE Auron_Yuna, BIOS Google_Auron_yuna.6301.59.8 04/02/2015
[  994.619200]  0000000000000000 000000000e231466 ffff88016c011bd0 ffffffff8af9b186
[  994.619229]  0000000000000000 ffff88016c011c08 ffffffff8aa3dedb ffffffff8ad03c08
[  994.619259]  ffff88016c04de00 ffff88017a2a2000 ffff88017a248000 ffff88016c011ce8
[  994.619288] Call Trace:
[  994.619310]  [<ffffffff8af9b186>] dump_stack+0x4d/0x6f
[  994.619335]  [<ffffffff8aa3dedb>] warn_slowpath_common+0x7f/0x98
[  994.619361]  [<ffffffff8ad03c08>] ? intel_crtc_set_config+0x77c/0x95a
[  994.619386]  [<ffffffff8aa3dfed>] warn_slowpath_null+0x1a/0x1c
[  994.619411]  [<ffffffff8ad03c08>] intel_crtc_set_config+0x77c/0x95a
[  994.619435]  [<ffffffff8acc20ae>] drm_mode_set_config_internal+0x5b/0xe5
[  994.619457]  [<ffffffff8accef78>] commit_crtc_state+0x165/0x21c
[  994.619480]  [<ffffffff8acceb23>] atomic_commit.isra.3+0x54/0xae
[  994.619501]  [<ffffffff8acceb8e>] drm_atomic_commit+0x11/0x13
[  994.619523]  [<ffffffff8acc59f1>] drm_mode_setcrtc+0x2f2/0x392
[  994.619544]  [<ffffffff8acb7403>] drm_ioctl+0x2f2/0x421
[  994.619564]  [<ffffffff8acc56ff>] ? drm_mode_setplane+0x9c/0x9c
[  994.619587]  [<ffffffff8ab203d3>] do_vfs_ioctl+0x355/0x416
[  994.619607]  [<ffffffff8ab28b92>] ? __fget+0x6f/0x79
[  994.619628]  [<ffffffff8ab204eb>] SyS_ioctl+0x57/0x79
[  994.619650]  [<ffffffff8afa055d>] tracesys+0xda/0xdf
[  994.619690] ---[ end trace e0c92fdd410ae39f ]---
[  994.619730] BUG: unable to handle kernel NULL pointer dereference at 0000000000000074
[  994.619773] IP: [<ffffffff8ad0039a>] __intel_set_mode+0x320/0x11ba
[  994.619800] PGD 0 
[  994.619812] Oops: 0000 [#1] PREEMPT SMP 
[  994.622420] gsmi: Log Shutdown Reason 0x03
[  994.622433] Modules linked in: i2c_dev uinput x86_pkg_temp_thermal snd_hda_codec_realtek snd_hda_codec_generic memc_x86 iwlmvm iwl7000_mac80211 aesni_intel snd_hda_codec_hdmi aes_x86_64 glue_helper lrw gf128mul ablk_helper rfcomm cryptd cros_ec_accel iio_trig_sysfs kfifo_buf industrialio iwlwifi zram snd_hda_intel snd_hda_controller snd_hda_codec snd_hwdep snd_soc_sst_acpi fuse cfg80211 btusb btbcm btintel bluetooth nf_conntrack_ipv6 nf_defrag_ipv6 uvcvideo ip6table_filter videobuf2_vmalloc ip6_tables cdc_ether usbnet mii joydev snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device ppp_async ppp_generic slhc tun
[  994.622708] CPU: 3 PID: 28963 Comm: DrmThread Tainted: G        W    3.14.0 #1
[  994.622718] Hardware name: GOOGLE Auron_Yuna, BIOS Google_Auron_yuna.6301.59.8 04/02/2015
[  994.622728] task: ffff880178ef9a40 ti: ffff88016c010000 task.ti: ffff88016c010000
[  994.622737] RIP: 0010:[<ffffffff8ad0039a>]  [<ffffffff8ad0039a>] __intel_set_mode+0x320/0x11ba
[  994.622752] RSP: 0018:ffff88016c011b40  EFLAGS: 00010202
[  994.622760] RAX: 0000000000000000 RBX: ffff880153691000 RCX: 0000000000000000
[  994.622769] RDX: 0000000000000000 RSI: ffff88006ae27ad8 RDI: ffff8801536910e0
[  994.622778] RBP: ffff88016c011bf8 R08: 0000000000000000 R09: 0000000000000000
[  994.622787] R10: ffff88016c011bf0 R11: ffff88017a2a2430 R12: ffff88017a248000
[  994.622796] R13: 0000000000000001 R14: ffff88017a2a2000 R15: ffff88017a2a2000
[  994.622806] FS:  00007f43ddc23700(0000) GS:ffff88017ed80000(0000) knlGS:0000000000000000
[  994.622816] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  994.622824] CR2: 0000000000000074 CR3: 00000001781d3000 CR4: 00000000003407e0
[  994.622833] Stack:
[  994.622837]  ffffffff8b1a438f 00000000000028a0 ffff88007858ea00 0000000000000000
[  994.622851]  ffffffff8af9a8c1 ffff88017a2a2460 0000000000000000 ffff88016c011b88
[  994.622866]  000000000e231466 ffff8801536910e0 ffff88006ae27a00 ffff880153691008
[  994.622880] Call Trace:
[  994.622890]  [<ffffffff8af9a8c1>] ? printk+0x5e/0x7a
[  994.622902]  [<ffffffff8ad03372>] intel_set_mode+0x14/0x2a
[  994.622913]  [<ffffffff8ad03d28>] intel_crtc_set_config+0x89c/0x95a
[  994.622924]  [<ffffffff8acc20ae>] drm_mode_set_config_internal+0x5b/0xe5
[  994.622936]  [<ffffffff8accef78>] commit_crtc_state+0x165/0x21c
[  994.622947]  [<ffffffff8acceb23>] atomic_commit.isra.3+0x54/0xae
[  994.622958]  [<ffffffff8acceb8e>] drm_atomic_commit+0x11/0x13
[  994.622968]  [<ffffffff8acc59f1>] drm_mode_setcrtc+0x2f2/0x392
[  994.622979]  [<ffffffff8acb7403>] drm_ioctl+0x2f2/0x421
[  994.622989]  [<ffffffff8acc56ff>] ? drm_mode_setplane+0x9c/0x9c
[  994.623001]  [<ffffffff8ab203d3>] do_vfs_ioctl+0x355/0x416
[  994.623011]  [<ffffffff8ab28b92>] ? __fget+0x6f/0x79
[  994.623021]  [<ffffffff8ab204eb>] SyS_ioctl+0x57/0x79
[  994.623031]  [<ffffffff8afa055d>] tracesys+0xda/0xdf
[  994.623039] Code: a8 03 75 09 83 c8 02 89 83 5c 01 00 00 8b 83 5c 01 00 00 a8 0c 75 09 83 c8 08 89 83 5c 01 00 00 48 8b 85 78 ff ff ff 4d 8b 34 24 <44> 8b 68 74 41 81 fd 41 42 32 34 0f 84 a3 00 00 00 77 40 41 81 
[  994.623157] RIP  [<ffffffff8ad0039a>] __intel_set_mode+0x320/0x11ba
[  994.623182]  RSP <ffff88016c011b40>
[  994.623188] CR2: 0000000000000074
[  994.623200] ---[ end trace e0c92fdd410ae3a0 ]---
[  994.629638] Kernel panic - not syncing: Fatal exception
[  994.629649] Kernel Offset: 0x9a00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
[  994.629757] gsmi: Log Shutdown Reason 0x02
[  994.633716] ACPI MEMORY or I/O RESET_REG.

Well, from my observation, it is technically not the act (to set UDL display as primary) per se that causes the black screen. The problem only repros when one sets UDL display as primary while the two displays have identical resolution.

However, one can successfully set UDL primary as display while still using the same resolution as internal display, by following these steps:

(1) set two displays to different resolution (e.g. 1920x1080 for internal and 1280x720 for UDL)
(2) set UDL as primary
(3) set two displays to the same resolution (e.g. 1920x1080 for both)

The key is that step (2) must happen when the two displays have different resolutions.

Seems to be a fairly serious problem, and I agree it is likely in Chrome and not in the kernel/driver.We probably didn't see a lot of reports so far, because typically Chromebooks internal display resolution is different from UDL, but the 19x10 devices such as lulu/yuna do encounter it.

CC oshima

CC alexst as well

Under ui/ozone there's a few places where we check buffer size before deciding if we need to create a new GbmBuffer. From logs it definitely looks like we're not calling buffer generator to re-allocate buffers when switching primary display

Hmm, there should be some checks that the buffer is showing on the same device as it was allocated on. The only thing I can think of is that there is an in-flight buffer.

The check I'm referring to is in: https://code.google.com/p/chromium/codesearch#chromium/src/ui/ozone/platform/drm/gpu/drm_window.cc&l=132

In particular, I think that if the buffers in |planes| have a different DrmDevice than what is in |controller_| the call to HardwareDisplayController::SchedulePageFlip() should be skipped until the forced buffer re-allocation propagates to the browser process.

Does that make sense?

Re:#9 yes that makes sense, but unless I'm missing something, we currently don't seem to track on which DrmDevice (or controller) are each GbmBuffer created. Would you suggest that we keep a reference to the DrmDevice in each buffer, or perform a lookup on the |controller_| to make sure the buffers in |planes| actually have the same device?

GbmBufferBase is keeping track of the allocation device, so we can get the device from there. I think it is just a matter of exposing the device via the ScanoutBuffer interface.

Re:#9,#11 thanks, and I have experimented as suggested, but it doesn't appear to work as intended. Can you elaborate how the "forced buffer re-allocation" is supposed to propagate to the browser process?

From my debug logs, browser process receives DrmWindow::SetController() call first and sets forced_buffer_reallocation_ flag to true. After that I start to receive schedulePageFlip() where the buffers of |planes| are on the wrong connector, so we keep skipping these.

(For reference, my local patch is https://codereview.chromium.org/1780013002/)

The SchedulePageFlip() should have came via GLSurfaceOzoneSurfaceless::SwapBuffersAsync() (or if it is a deferred swap buffers via GLSurfaceOzoneSurfaceless::SubmitFrame()). Regardless, there is a callback associated with the call. The callback takes a SwapResult (in our case SWAP_NAK_RECREATE_BUFFERS) which should be propagated to the browser process all the way into GpuSurfacelessBrowserCompositorOutputSurface::OnGpuSwapBuffersCompleted() which should be calling BufferQueue::RecreateBuffers(): https://code.google.com/p/chromium/codesearch#chromium/src/content/browser/compositor/gpu_surfaceless_browser_compositor_output_surface.cc&rcl=1457598942&l=103

In BufferQueue::RecreateBuffers() new buffers are allocated, which should be allocated on the correct DrmDevice. (The allocation IPCs back to the GPU process into GbmSurfaceFactory::CreateNativePixmap() to allocate the new buffers.)

You should be seeing the correct result with your patch. There must be a regression somewhere in the re-allocation path.

Are you seeing any buffer re-allocations around the time the DrmDevice changes?

Bump :) Any chance of getting this fixed anytime soon? I understand the patch from comment #13 not really the solution we're after?

Sorry this has been on the back burner for a while. I haven't had any luck finding the problem in the re-allocation path, but will give it another try.

I'm going to investigate one level higher and start tracing how ash WindowTreeHostManager handles setting primary display ID when the two displays have same size bounds.

My suspicious is that a check needs to happen earlier and not as late as SchedulePageFlip.

I also noticed that both buffer queues (that belongs to the internal display and UDL) report the same pointer to the GPU memory buffer manager.

It is not yet clear to me how we ensure that BufferQueue::RecreateBuffers would be allocating on the correct DrmDevice.

(Please ignore #18 - it seems to be a result of a crash earlier and did not recur after a reboot)

Re:#14 yes I think there's something broken in the re-allocation path.

After a DrmDevice change I do see two calls to BufferQueue::RecreateBuffers (presumably for the two devices respectively). This eventually reaches GbmSurfaceFactory::CreateNativePixmap but both are calling the same factory. This shouldn't be the case as we need a separate gbm factory for the UDL device, right?

Re: #21 By calling the same factory do you mean the same GbmSurfaceFactory? If so, then that is correct, there is only one GbmSurfaceFactory.

A couple of things that you might want to check:
1) What is the widget passed in GbmSurfaceFactory::CreateNativePixmap()?
2) In DrmThread::CreateBuffer() there's a call to DrmDeviceManager::GetDrmDevice(widget). That's where the widget <-> device mapping is kept. Make sure it is as expected. The mapping within DrmDeviceManager is updated whenever the display configuration changes or when the window's bounds changes.

Re:#22 correct, they are using the same GbmSurfaceFactory, but different widgets are passed in GbmSurfaceFactory::CreateNativePixmap().

At SchedulePageFlip the sequence of events are:

[12496:12504:0506/101800:ERROR:drm_window.cc(130)] **** SchedulePageFlip forcing buffer reallocation
[12380:12380:0506/101800:ERROR:buffer_queue.cc(135)] **** BufferQueue::RecreateBuffers called with # in flight=1 and manager = 0x2af7c5d20500
[12496:12503:0506/101800:ERROR:gbm_surface_factory.cc(105)] **** GbmSurfaceFactory::CreateNativePixmap for 1920x1080 on 1
[12496:12503:0506/101800:ERROR:gbm_surface_factory.cc(105)] **** GbmSurfaceFactory::CreateNativePixmap for 1920x1080 on 1
[12496:12503:0506/101800:ERROR:gbm_surface_factory.cc(105)] **** GbmSurfaceFactory::CreateNativePixmap for 1920x1080 on 2
[12496:12503:0506/101800:ERROR:gbm_surface_factory.cc(105)] **** GbmSurfaceFactory::CreateNativePixmap for 1920x1080 on 1
[12380:12380:0506/101800:ERROR:buffer_queue.cc(135)] **** BufferQueue::RecreateBuffers called with # in flight=1 and manager = 0x2af7c5d20500
[12496:12503:0506/101800:ERROR:gbm_surface_factory.cc(105)] **** GbmSurfaceFactory::CreateNativePixmap for 1920x1080 on 2
[12496:12503:0506/101800:ERROR:gbm_surface_factory.cc(105)] **** GbmSurfaceFactory::CreateNativePixmap for 1920x1080 on 2
[12496:12503:0506/101800:ERROR:gbm_surface_factory.cc(105)] **** GbmSurfaceFactory::CreateNativePixmap for 1920x1080 on 2

Let's back off slightly and look at how switching primary is handled when the size of the two displays are NOT the same.

In case of 1920x1080 internal and 1280x720 on UDL, when we switch primary the GbmSurfaceFactory::CreateNativePixmap gets called from ScreenManager::GetModesetBuffer:

OverlayPlane ScreenManager::GetModesetBuffer(
    HardwareDisplayController* controller,
    const gfx::Rect& bounds) {
  DrmWindow* window = FindWindowAt(bounds);
  if (window) {
    const OverlayPlane* primary = window->GetLastModesetBuffer();
    if (primary && primary->buffer->GetSize() == bounds.size())            <===== this size check fails because bounds have changed
      return *primary;
  }

  scoped_refptr<DrmDevice> drm = controller->GetAllocationDrmDevice();
  scoped_refptr<ScanoutBuffer> buffer = buffer_generator_->Create(
      drm, gfx::BufferFormat::BGRA_8888, bounds.size());
...

From debug log:

[30462:30470:0506/112248:ERROR:screen_manager.cc(342)] **** ScreenManager::GetModesetBuffer creating new buffer at 0,1140 1280x800
[30462:30470:0506/112248:ERROR:screen_manager.cc(342)] **** ScreenManager::GetModesetBuffer creating new buffer at 0,0 1920x1080
[30462:30469:0506/112248:ERROR:gbm_surface_factory.cc(110)] **** CreateNativePixmap 1280x800 with widget=1
[30462:30469:0506/112248:ERROR:gbm_surface_factory.cc(110)] **** CreateNativePixmap 1280x800 with widget=1
[30462:30469:0506/112248:ERROR:gbm_surface_factory.cc(110)] **** CreateNativePixmap 1920x1080 with widget=1
[30462:30469:0506/112248:ERROR:gbm_surface_factory.cc(110)] **** CreateNativePixmap 1920x1080 with widget=1
[30462:30469:0506/112248:ERROR:gbm_surface_factory.cc(110)] **** CreateNativePixmap 1920x1080 with widget=1
[30462:30469:0506/112248:ERROR:gbm_surface_factory.cc(110)] **** CreateNativePixmap 1280x800 with widget=2
[30462:30469:0506/112248:ERROR:gbm_surface_factory.cc(110)] **** CreateNativePixmap 1280x800 with widget=2
[30462:30469:0506/112248:ERROR:gbm_surface_factory.cc(110)] **** CreateNativePixmap 1280x800 with widget=2
[30462:30469:0506/112248:ERROR:gbm_surface_factory.cc(110)] **** CreateNativePixmap 1920x1080 with widget=1
[30462:30469:0506/112248:ERROR:gbm_surface_factory.cc(110)] **** CreateNativePixmap 1280x800 with widget=2

This is working now, PTAL again at https://codereview.chromium.org/1780013002/, thanks

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/28c0dd4fc82d8834c0508492fc693204da39e21b

commit 28c0dd4fc82d8834c0508492fc693204da39e21b
Author: hshi <hshi@chromium.org>
Date: Fri May 06 21:40:08 2016

Fix black screen when switching primary display without bounds change

In ScreenManager::GetModesetBuffer() we need to check controller's
DrmDevice and only re-use primary buffer if it matches the DrmDevice
on which the buffer is allocated.

Also in DrmWindow::SchedulePageFlip(), we need to force buffer
reallocation when the buffer's DrmDevice doesn't match that of the
hardware display controller.

BUG= 591368 
TEST=verify on auron_yuna with UDL resolution at 1920x1080 and switch primary

Review-Url: https://codereview.chromium.org/1780013002
Cr-Commit-Position: refs/heads/master@{#392165}

[modify] https://crrev.com/28c0dd4fc82d8834c0508492fc693204da39e21b/ui/ozone/platform/drm/gpu/drm_buffer.cc
[modify] https://crrev.com/28c0dd4fc82d8834c0508492fc693204da39e21b/ui/ozone/platform/drm/gpu/drm_buffer.h
[modify] https://crrev.com/28c0dd4fc82d8834c0508492fc693204da39e21b/ui/ozone/platform/drm/gpu/drm_window.cc
[modify] https://crrev.com/28c0dd4fc82d8834c0508492fc693204da39e21b/ui/ozone/platform/drm/gpu/gbm_buffer_base.cc
[modify] https://crrev.com/28c0dd4fc82d8834c0508492fc693204da39e21b/ui/ozone/platform/drm/gpu/gbm_buffer_base.h
[modify] https://crrev.com/28c0dd4fc82d8834c0508492fc693204da39e21b/ui/ozone/platform/drm/gpu/mock_scanout_buffer.cc
[modify] https://crrev.com/28c0dd4fc82d8834c0508492fc693204da39e21b/ui/ozone/platform/drm/gpu/mock_scanout_buffer.h
[modify] https://crrev.com/28c0dd4fc82d8834c0508492fc693204da39e21b/ui/ozone/platform/drm/gpu/scanout_buffer.h
[modify] https://crrev.com/28c0dd4fc82d8834c0508492fc693204da39e21b/ui/ozone/platform/drm/gpu/screen_manager.cc

Bulk verified