Move to VT2 on cyan whole system hangs have to reboot the device

Crash Id - 3308180a00000000 
Crash ID -  b1b0abec00000000

hread 0 CRASHED [SIGABRT @ 0x00000000 ] MAGIC SIGNATURE THREAD
0x00007f2c914c1c93	(libc-2.19.so + 0x000f9c93 )	__epoll_wait_nocancel
0x00007f2c93a37153	(chrome + 0x00c77153 )	
0x00007f2c93a36ae1	(chrome + 0x00c76ae1 )	
0x00007f2c93a11508	(chrome + 0x00c51508 )	
0x00007f2c9433b527	(chrome + 0x0157b527 )	
0x00007f2c97834ee4	(chrome + 0x04a74ee4 )	
0x00007f2c9667d4aa	(chrome + 0x038bd4aa )	
0x00007f2c964b7584	(chrome + 0x036f7584 )	
0x00007f2c964b7462	(chrome + 0x036f7462 )	
0x00007f2c942ea030	(chrome + 0x0152a030 )	
0x00007f2c942e8b1a	(chrome + 0x01528b1a )	
0x00007f2c93f73f1e	(chrome + 0x011b3f1e )	
0x00007f2c913e7fb5	(libc-2.19.so -libc-start.c:292 )	__libc_start_main
0x00007f2c93f73d76	(chrome + 0x011b3d76 )	

 https://storage.cloud.google.com/chromiumos-test-logs/cr_610790

Since this is in Frecon, is this something you can take a look at Dominik?

probably same as  crbug.com/588425 

Issue not reproducible on 8350.7.0, 52.0.2743.0

Please ignore #7. Issue still reproducible on 8350.7.0, 52.0.2743.0 after sign-out and sign-in

sdantuluri@: is this only see on cyan and edgar?

Moving this to release-block dev for M53 as it mostly affects developers.

dbehr@ Can you please confirm this is a dupe of  crbug.com/588425 . If yes, I will close this one out.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform/frecon/+/da3c010e2a84a30c0cc1dcaa6472012abcaffde8

commit da3c010e2a84a30c0cc1dcaa6472012abcaffde8
Author: Dominik Behr <dbehr@chromium.org>
Date: Wed Jun 08 22:05:38 2016

frecon: keep master while frecon is active

This change switches back to old frecon behavior where it would keep
DRM master for whole time it was active. I thought we could only keep
it for mode switch but it is also needed for framebuffer invalidation
which is necessary on some hardware so we would need to set and drop it
on every screen update.
This change also centralizes DRM master set and drop in term foreground
and background functions making it clear where it is set and dropped.
There was also a case where when Chrome is under high load it becomes
confused and still sends page flip requests even though frecon is active.
In this case, if when frecon dropped master page flip succeeds and it
appears the system is hanging (frecon is still processing keyboard events
but static Chrome window is visible).

BUG= chromium:610790 , chromium:588425 , chromium:616594 ,chrome-os-partner:51058
TEST=quickly switch between Chrome and frecon using ctrl-alt-< and ctrl-alt->\
while system is under high load.

Change-Id: I651a89b307dcf31396ba52e2dcb605d2a7617cd9
Signed-off-by: Dominik Behr <dbehr@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/351010
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>

[modify] https://crrev.com/da3c010e2a84a30c0cc1dcaa6472012abcaffde8/main.c
[modify] https://crrev.com/da3c010e2a84a30c0cc1dcaa6472012abcaffde8/term.c
[modify] https://crrev.com/da3c010e2a84a30c0cc1dcaa6472012abcaffde8/drm.h
[modify] https://crrev.com/da3c010e2a84a30c0cc1dcaa6472012abcaffde8/fb.c
[modify] https://crrev.com/da3c010e2a84a30c0cc1dcaa6472012abcaffde8/drm.c

kalin@/bmahadev@ can we please verify these CLs and confirm this fixes the issue at hand so we can close it?

sdantuluri@ Verified and the issue is still reproducible on 8438.0.0, 53.0.2764.0

sdantuluri@ can you please confirm it is fixed in the build that has this fix?

CL says it has landed in build 8437.0.0. But there are no builds available in golden eye for 8437.0.0

So I used build 8438.0.0 and I could still reproduce the bug on edgar.

This bug was reproduced on another strago board and bug filed at  issue 616594 . The dev team insisted it is not even P1 bug. To me it is P1 RBB or at least RBS, but not a dev blocker.

kalin@ We should fix and resolve these issues now during Dev rather than push them out to Beta/Stable. But i do see why you would say that. let us move it to RBB and get a fix out asap.

dbehr@ can you please look into why this fix didn't work?

Aww, it looks like Chrome uses CRTC 27 and frecon uses CRTC 32. So when frecon does a mode set kernel tries to steal connector/encoder from CRTC 27 to 32 and it doesnt work well at all.
It seems we need to backport 40616a26d1c68e4c80e2358a02297ba492f4cc17 from upstream to kernel 3.18.

We are hitting this condition in drm_atomic_crtc_check

if (state->active && !state->enable) {
                DRM_DEBUG_ATOMIC("[CRTC:%d] active without enabled\n",
                                 crtc->base.id);
                return -EINVAL;
}

 Issue 611540  has been merged into this issue.

Issue still repro's on 8530.11.0, 53.0.2785.13 edgar, cyan.

This blocks test team from capturing android logs on cyan.

We should still be able to get logs using ctrl+alt+t, shell, sudo bash?

ctrl+alt+t, shell, sudo bash works. Thanks bhthompson@

This patchset from Sean https://chromium-review.googlesource.com/#/c/352216/ among other things fixes connector stealing and solves the problem.

dbehr@ can we merge this patchset from Sean into m53 asap?

removing beta blocker since this is not an end user facing scenario.

Moving this nonessential bug to the next milestone.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform/frecon/+/51a4da5207489adf201d1371eb29c6efaf93b6ea

commit 51a4da5207489adf201d1371eb29c6efaf93b6ea
Author: Dominik Behr <dbehr@chromium.org>
Date: Thu Jul 28 21:18:48 2016

frecon: disable other CRTCs before setting video mode

Kernel 3.18 has trouble when one CRTC steals connector from another even though
it is a legal operation. The internal state becomes inconsistent and it returns
EINVAL from SetCrtc call. This change disables other CRTCs first instead after
setting video mode so there is no need to steal a connector if Chrome used
another CRTC to drive the connector we are using.

BUG= chromium:610790 ,chrome-os-partner:51782
TEST=login and logout on Cyan, switch to console using ctrl-alt-f2

Change-Id: Ic458a33307ce0c2b31f2c90a1d7cfd30a4e5ea3f
Signed-off-by: Dominik Behr <dbehr@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/364212
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>

[modify] https://crrev.com/51a4da5207489adf201d1371eb29c6efaf93b6ea/drm.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform/frecon/+/ee6df454cfa71859022f38eefb9b8ad0be54e6ff

commit ee6df454cfa71859022f38eefb9b8ad0be54e6ff
Author: Dominik Behr <dbehr@chromium.org>
Date: Thu Jul 28 21:18:48 2016

CHERRY-PICK: frecon: disable other CRTCs before setting video mode

Kernel 3.18 has trouble when one CRTC steals connector from another even though
it is a legal operation. The internal state becomes inconsistent and it returns
EINVAL from SetCrtc call. This change disables other CRTCs first instead after
setting video mode so there is no need to steal a connector if Chrome used
another CRTC to drive the connector we are using.

BUG= chromium:610790 ,chrome-os-partner:51782,chrome-os-partner:53437
TEST=login and logout on Cyan, switch to console using ctrl-alt-f2

Change-Id: Ic458a33307ce0c2b31f2c90a1d7cfd30a4e5ea3f
Signed-off-by: Dominik Behr <dbehr@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/364212
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
(cherry picked from commit 51a4da5207489adf201d1371eb29c6efaf93b6ea)
Reviewed-on: https://chromium-review.googlesource.com/365271
Tested-by: David Wu <david_wu@quantatw.com>
Reviewed-by: Vincent Wang <vwang@chromium.org>
Reviewed-by: Mohammed Habibulla <moch@google.com>
Commit-Queue: David Wu <david_wu@quantatw.com>

[modify] https://crrev.com/ee6df454cfa71859022f38eefb9b8ad0be54e6ff/drm.c

Able to switch to VT2 with no keyboard/mouse issue on cyan in ChromeOS build 8743.44.0 / 54.0.2840.43. 

However switch between VT2-VT1 several times, frecon crash experienced as  issue 640082 . 

Close this one as crash issue still is tracking in  issue 640082 .