Logs are present here: https://pantheon.corp.google.com/storage/browser/chromiumos-test-logs/bugfiles/cr/852177

Dominik, is this in your jurisdiction?

This sounds familiar, but I am not immediately seeing another bug. This is currently marked as a 68 stable blocker which gives us only a couple weeks to fix it or reclassify it.

This bug needs to be fixed and merged back within the next week or it will start blocking our R68 stable release.

Any chance this is related to https://bugs.chromium.org/p/chromium/issues/detail?id=819692 ?

If we need to do anything about this, it needs to be done by Monday afternoon, our stable RC builds on Monday night. 

This is currently blocking the 68 stable release, we intend to build tonight, so if at all possible this should be resolved in the next few hours.

Raising priority.

I see a lot of messages like
[drm:intel_pipe_update_start] *ERROR* Potential atomic update failure on pipe A
In kernel log. Maybe that is related to it. It may be related to b/109823283

Could be related. 

Looks like a pretty huge backport though, for bringing into 68.

Do you think a bisection might help here? Presumably this used to work.

I am hesitant to push Eve stable out with this, even though a typical CrOS user does not use an external display at all, given the types of users that use Eve I suspect we would get complaints if this went out.

Prasanthi, can you try doing some bisection on this? If we can narrow down where exactly it broke we might be able to find a revert.

This scenario is tested once each milestone, and bisecting would take long time to (recover and test eve board) find what build this started from.

pgangishetty, can you check if it is reproduced in the latest M68-10718.70.0 / 68.0.3440.85 build?

Tested on M67 Stable & M68 latest beta build and below are the 
results :

M68 - 10718.69.0/68.0.3440.83 beta build:
Reproducible with below combinations on ASUS & 4K monitors:
1. Apple dongle & HoHo
2. HooToo type C hub & Apple dongle
3. Apple & CharJen Pro type C adapter

Not able to reproduce with below:
1. Apple dongle & HP Type C docking station

M67 - 10575.58.0/67.0.3396.99 - Stable build
Able to reproduce with:
1. HoHo & HooToo

Not reproducible with:
1. HoHo & Apple dongle

Thanks pgangishetty@ for the update. 
It seems the low-priced(-quality) adapters like HooToo are problematic for such scenario.
The good ones(Apple + HoHo) seems to regressed

Can you try Apple and Google(HoHo) adapter units that you did not see failing before, in the following combination

1) HoHo +Apple
2) HoHo + HoHo
3) Apple + Apple

Re #11

I. Apple + HoHo results:
Reproducible:
1. Apple dongle + ASUS 1080 + right side port
   HoHo + 4K + left side port 


Not reproducible:
1. Apple dongle + ASUS 1080 monitor + left side port
   HoHo + 4K + Right side port

2. HoHo + ASUS 1080 + left side type C port
   Apple dongle + 4K _ Right side

For below combinations, any monitor that's connected on the right side port does not come up after resume.

II. HoHo + HoHo - Reproducible 

III. Apple + Apple dongle - Reproducible

One more question, is this really only on Eve, or has this been seen on other KBL-Y systems like Soraka or Nautilus?

It is really strange that the ports behave differently, it makes me wonder if there is any sort of signal integrity thing going on here. We may need to bring in the Eve HW folks if we can prove that out.

I am afraid this may have been around for a very long time with some dock connection combinations, and we may be looking at some level of flake. 

Tested on Soraka with M68 build and below are the results.

4K - Acer 4k external monitor
1080 - Asus 1080

HoHo - has inconsistent behavior with external monitor(s)

	
       Left Side Port	Right Side Port	Result

1	Apple (4K)	HoHo (1080)	Good
2	Apple (1080)	HoHo (4K)	Inconsistent
3	HooToo	        HoHo	        Good
4	HoHo (4K)	Apple (1080)	Bad
5	HooToo (1080)	Apple (4K)	Good
6	HooToo (4k)	Apple (1080)	Good
7	Apple 	        Apple 	        Good
8	HoHo 	        HoHo	        Bad

 

Re: #13 - Tested on Nautilus with beta build version 68.0.3440.87/10718.71.2 and below are the results.

   	Top Port	Bottom Port	Results

1	Apple (4K)	HoHo (1080)	Good
2	HoHo (1080)	Apple (4K)	Good
3	HoHo (4K)	Apple (1080)	Good
4	Apple (1080)	HoHo (4K)	Good
5	Apple (1080) 	Apple (4K)	Good
6	Apple (4K)	Apple (1080) 	Good
7	HoHo (4K)	HoHo (1080)	Good
8	HoHo (1080)	HoHo (4K)	Good

Pri-0 bugs are critical regressions or serious emergencies, and this bug has not been updated in three days. Could you please provide an update, or adjust the priority to a more appropriate level if applicable?

If a fix is in active development, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

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

It looks like we will get to do another spin of 68 due to https://bugs.chromium.org/p/chromium/issues/detail?id=874063 so if there is any chance we can find a fix for this today we can bring it in.

Any update on this?

this bug is next on my plate...

Pri-0 bugs are critical regressions or serious emergencies, and this bug has not been updated in three days. Could you please provide an update, or adjust the priority to a more appropriate level if applicable?

If a fix is in active development, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

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

Given the lateness of 68, the relatively low impact here with the low usage of external displays, dropping the RBS label, we can still take in a fix if we find one, but this is probably more of a 69 thing.

The problem is happening not only after suspend resume. It also can be reproduced if both adapters were connected before chromebook was powered on.

I found the reason why Ho-Ho isn't waking up, but it looks like the problem is more complicated than I expected...

According to my investigation, the problem is happening somewhere inside Ho-Ho or between HoHo and a monitor because dpcd connection is broken after resume. In my case, problem was solved by using a high quality cable, especially if your monitor supports hdmi 2.0 (btw, Apple dongle doesn't support hdmi 2.0, but ho-ho does). So, probably, it could be the reason).