Issue metadata
Sign in to add a comment
|
eve display briefly turns off after resume in M64 |
||||||||||||||||||||||
Issue descriptionGoogle Chrome 64.0.3282.190 (Official Build) (64-bit) Platform 10176.76.0 (Official Build) stable-channel eve Firmware Version Google_Eve.9584.107.0 I've been seeing the screen briefly turn off for a second or so after this eve device resumes, starting sometime around when this device got M64, I think. It doesn't happen every time, but I've seen it 3-4 times now. The sequence of events is: 1. I suspend the system by closing its lid. 2. Much later, I open the lid. 3. I initially see the lock screen (as expected). 4. About one second later, the screen goes black. 5. One or two seconds after that, the screen turns back on and I can again see the lock screen. http://feedback/#/Report/85185092078 is a feedback report that I filed immediately after seeing this yesterday. It happened again this morning (at 8:41 PDT, but some logs are two hours ahead since the system booted in CDT): ---- powerd.LATEST: ... [0315/104152:INFO:daemon.cc(687)] powerd_suspend returned 0 [0315/104152:INFO:suspender.cc(414)] Finishing request 71893005 successfully [0315/104152:INFO:internal_backlight_controller.cc(677)] Setting brightness to 1583 (18.75%) over 0 ms [0315/104152:INFO:keyboard_backlight_controller.cc(519)] Setting brightness to 60 (60%) over 200 ms [0315/104153:INFO:daemon.cc(515)] Lid opened [0315/104153:INFO:input_device_controller.cc(292)] Configuring devices for mode "laptop" [0315/104153:INFO:input_device_controller.cc(223)] Un-inhibiting /sys/devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-6/i2c-WCOM50C1:00/0018:2D1F:5143.0001/input/input4 [0315/104153:INFO:input_device_controller.cc(223)] Un-inhibiting /sys/devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-6/i2c-WCOM50C1:00/0018:2D1F:5143.0001/input/input5 [0315/104153:INFO:input_device_controller.cc(223)] Un-inhibiting /sys/devices/pci0000:00/0000:00:15.2/i2c_designware.2/i2c-8/i2c-ACPI0C50:00/0018:18D1:5028.0004/input/input9 [0315/104153:WARNING:input_device_controller.cc(207)] No power/wakeup sysattr available for /sys/devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-6/i2c-WCOM50C1:00/0018:2D1F:5143.0001/input/input4 [0315/104153:WARNING:input_device_controller.cc(207)] No power/wakeup sysattr available for /sys/devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-6/i2c-WCOM50C1:00/0018:2D1F:5143.0001/input/input5 [0315/104153:WARNING:input_device_controller.cc(207)] No power/wakeup sysattr available for /sys/devices/pci0000:00/0000:00:15.2/i2c_designware.2/i2c-8/i2c-ACPI0C50:00/0018:18D1:5028.0004/input/input9 [0315/104153:INFO:input_device_controller.cc(211)] Enabling wakeup for /sys/devices/platform/i8042/serio0/input/input3 through /sys/devices/platform/i8042/serio0 [0315/104153:INFO:input_device_controller.cc(211)] Enabling wakeup for /sys/devices/platform/i8042/serio0/input/input3/event3 through /sys/devices/platform/i8042/serio0 [0315/104153:INFO:daemon.cc(776)] On AC (USB_PD, 0.000A at 20.3V, max 2.2A at 20.0V) with battery at 100%, 5.529/5.529Ah at 0.492A, full [0315/104153:INFO:state_controller.cc(833)] Updated settings: dim=1m screen_off=1m10s lock=1m20s idle_warn=0s idle=30m30s (suspend) lid_closed=suspend use_audio=1 use_video=1 [0315/104153:INFO:state_controller.cc(845)] Wake locks: system [0315/104153:INFO:daemon.cc(1418)] Chrome is using normal display mode [0315/104155:INFO:daemon.cc(1418)] Chrome is using normal display mode ... ---- chrome: [1208:1208:0315/084153.006632:VERBOSE1:display_configurator.cc(902)] SetDisplayPower: power_state=ALL_ON flags=0, configure timer=Stopped ... [1208:1208:0315/084153.062793:VERBOSE1:update_display_configuration_task.cc(69)] OnDisplaysUpdated: new_display_state=SINGLE new_power_state=ALL_ON flags=0 force_configure=0 display_count=1 [1208:1208:0315/084153.062862:VERBOSE1:display_configurator.cc(212)] EnterState: display=SINGLE power=ALL_ON ... [1208:1208:0315/084153.233055:VERBOSE1:display_configurator.cc(1054)] OnConfigured: success=1 new_display_state=SINGLE new_power_state=ALL_ON ... [1208:1377:0315/084154.558009:VERBOSE1:drm_device_handle.cc(83)] Succeeded authenticating /dev/dri/card0 in 0 ms with 1 attempt(s) [1208:1208:0315/084154.587615:VERBOSE1:drm_display_host_manager.cc(247)] Got display event ADD for /dev/dri/card0 [1208:1208:0315/084154.597097:VERBOSE1:drm_display_host_manager.cc(247)] Got display event ADD for /dev/dri/card1 [1208:31249:0315/084154.597806:VERBOSE1:drm_device_handle.cc(83)] Succeeded authenticating /dev/dri/card1 in 0 ms with 1 attempt(s) [1208:1208:0315/084154.608766:ERROR:gpu_process_transport_factory.cc(1009)] Lost UI shared context. ... [1208:1208:0315/084155.717929:VERBOSE1:display_configurator.cc(950)] Display snapshots invalidated. [1208:1208:0315/084155.718100:VERBOSE1:update_display_configuration_task.cc(69)] OnDisplaysUpdated: new_display_state=SINGLE new_power_state=ALL_ON flags=0 force_configure=1 display_count=1 [1208:1208:0315/084155.718181:VERBOSE1:display_configurator.cc(212)] EnterState: display=SINGLE power=ALL_ON [1208:1208:0315/084155.885809:VERBOSE1:display_configurator.cc(1054)] OnConfigured: success=1 new_display_state=SINGLE new_power_state=ALL_ON ... [1208:1208:0315/084158.823227:ERROR:views_screen_locker.cc(112)] Not implemented reached in virtual void chromeos::ViewsScreenLocker::SetPasswordInputEnabled(bool) [1208:1208:0315/084158.828514:VERBOSE1:screen_locker.cc(272)] Authentication success: 0.005274 second(s) ---- The multiple "Chrome is using normal display mode" messages that powerd received from Chrome (suggesting that displays were configured) seem a bit weird, as does the "Lost UI shared context." error. (Sorry for the wide distribution, but I'm not sure of the cause of this.)
,
Mar 15 2018
This should be fixed in 65 and later. If we want to fix this in 64, I think we should just turn on the modifiers in the kernel, which should revert back to the old behavior.
,
Mar 15 2018
Thanks for investigating. Would the kernel change be risky? Does this affect additional devices, or just eve? Are there any other factors that contribute to it, or will everyone using an eve device see it as often as I do (maybe half the time the system resumes)?
,
Mar 15 2018
M64 is closed out given the M65 schedule.
,
Mar 15 2018
Yes, I thought 64 was close. For the record, we would be reverting 10d5f23e8e3a29e6b4f9a7bd2de20f12dcee5df6, which advertises a new feature to Chrome. On the kernel side it's very low risk, in Chrome it triggers a different allocation path for framebuffers, which we use on other devices.
,
Mar 16 2018
,
Mar 23 2018
Closing based on #4 (too late for M64) and #2 (fixed in M65). Please re-open if you still see failure in M65. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by dnicoara@chromium.org
, Mar 15 2018