kevin: No touchscreen on chromeos6-row2-rack24-host3 |
|||||||||||
Issue descriptionIn recent canary builds (>= R63-9969.0.0) touchscreen related tests often fail because the touchscreen is not detected. https://wmatrix.googleplex.com/platform/unfiltered?suites=bvt-perbuild&days_back=10&releases=tot&platforms=kevin&builds=R63-99[567].* An example is http://cautotest-prod.corp.google.com/afe/#tab_id=view_job&object_id=144526184 (R63-9971.0.0): 2017-09-24T20:40:31.739364+00:00 INFO kernel: [ 0.425805] rk3x-i2c ff130000.i2c: Initialized RK3xxx I2C bus at ffffff80001f8000 2017-09-24T20:40:31.739369+00:00 WARNING kernel: [ 0.426024] 3-004b supply vdd not found, using dummy regulator 2017-09-24T20:40:31.739374+00:00 WARNING kernel: [ 0.426078] 3-004b supply avdd not found, using dummy regulator 2017-09-24T20:40:31.739379+00:00 DEBUG kernel: [ 0.426116] atmel_mxt_ts 3-004b: GPIO lookup for consumer atmel,reset 2017-09-24T20:40:31.739383+00:00 DEBUG kernel: [ 0.426121] atmel_mxt_ts 3-004b: using device tree for GPIO lookup 2017-09-24T20:40:31.739388+00:00 DEBUG kernel: [ 0.426128] of_get_named_gpiod_flags: can't parse 'atmel,reset-gpios' property of node '/i2c@ff130000/touchscreen@4b[0]' 2017-09-24T20:40:31.739394+00:00 DEBUG kernel: [ 0.426134] of_get_named_gpiod_flags: can't parse 'atmel,reset-gpio' property of node '/i2c@ff130000/touchscreen@4b[0]' 2017-09-24T20:40:31.739407+00:00 DEBUG kernel: [ 0.426139] atmel_mxt_ts 3-004b: using lookup tables for GPIO lookup 2017-09-24T20:40:31.739412+00:00 DEBUG kernel: [ 0.426145] atmel_mxt_ts 3-004b: lookup for GPIO atmel,reset failed 2017-09-24T20:40:31.739417+00:00 INFO kernel: [ 0.426429] rk3x-i2c ff140000.i2c: Initialized RK3xxx I2C bus at ffffff80001fa000 2017-09-24T20:40:31.739421+00:00 WARNING kernel: [ 0.426610] 5-004a supply vdd not found, using dummy regulator 2017-09-24T20:40:31.739426+00:00 WARNING kernel: [ 0.426678] 5-004a supply avdd not found, using dummy regulator 2017-09-24T20:40:31.739431+00:00 DEBUG kernel: [ 0.426711] atmel_mxt_ts 5-004a: GPIO lookup for consumer atmel,reset 2017-09-24T20:40:31.739435+00:00 DEBUG kernel: [ 0.426717] atmel_mxt_ts 5-004a: using device tree for GPIO lookup 2017-09-24T20:40:31.739440+00:00 DEBUG kernel: [ 0.426726] of_get_named_gpiod_flags: can't parse 'atmel,reset-gpios' property of node '/i2c@ff140000/trackpad@4a[0]' 2017-09-24T20:40:31.739451+00:00 DEBUG kernel: [ 0.426732] of_get_named_gpiod_flags: can't parse 'atmel,reset-gpio' property of node '/i2c@ff140000/trackpad@4a[0]' 2017-09-24T20:40:31.739456+00:00 DEBUG kernel: [ 0.426737] atmel_mxt_ts 5-004a: using lookup tables for GPIO lookup 2017-09-24T20:40:31.739460+00:00 DEBUG kernel: [ 0.426743] atmel_mxt_ts 5-004a: lookup for GPIO atmel,reset failed 2017-09-24T20:40:31.739465+00:00 INFO kernel: [ 0.428188] tpm_i2c_infineon 0-0020: 1.2 TPM (device-id 0x1A) [gentle shutdown] 2017-09-24T20:40:31.739469+00:00 INFO kernel: [ 0.432518] atmel_mxt_ts 5-004a: Information Block Checksum = 9bd26b 2017-09-24T20:40:31.739474+00:00 INFO kernel: [ 0.432530] atmel_mxt_ts 5-004a: No platform data provided ... 2017-09-24T20:40:31.739961+00:00 INFO kernel: [ 0.633299] atmel_mxt_ts 5-004a: Family ID: 164 Variant ID: 17 Major.Minor.Build: 2.0.AA 2017-09-24T20:40:31.739965+00:00 INFO kernel: [ 0.633308] atmel_mxt_ts 5-004a: Matrix X Size: 24 Matrix Y Size: 14 Object Num: 31 2017-09-24T20:40:31.739970+00:00 INFO kernel: [ 0.636799] atmel_mxt_ts 5-004a: T100 Config: XSIZE 1920, YSIZE 1080, XLINE 19, YLINE 11 2017-09-24T20:40:31.739975+00:00 INFO kernel: [ 0.637193] atmel_mxt_ts 5-004a: T100 Config: SCRAUX : 0, TCHAUX : 17 2017-09-24T20:40:31.739979+00:00 INFO kernel: [ 0.639776] input: Atmel maXTouch Touchpad as /devices/platform/ff140000.i2c/i2c-5/5-004a/input/input2 2017-09-24T20:40:31.739986+00:00 INFO kernel: [ 0.647325] atmel_mxt_ts 5-004a: Status: 00 Config Checksum: 0af6ba Initialization of the touchscreen device (3-004b) starts but is not completed. So far I didn't have success with reproducing this locally. I didn't identify any specific CL that might be to blame, the issue could be related with the switch to clang kernel builds with R63-9967.0.0 (CL:673005).
,
Sep 25 2017
Yes, so far all the failures I've looked into are on chromeos6-row2-rack24-host3.
,
Sep 25 2017
My suggestion would be to pull that device and hand it off to adlr@ if he'll take it. For more details about connector problems, b/35775059
,
Sep 25 2017
...there's also a way to lock the device so the lab won't use it, then ssh over to it and confirm that the touchscreen just won't enumerate on that device...
,
Sep 26 2017
I've locked it. It's running this: CHROMEOS_RELEASE_DESCRIPTION=9974.0.0 (Official Build) dev-channel kevin test And it's consistently missing both touchscreen and digitizer: # evtest No device specified, trying to scan all of /dev/input/event* Available devices: /dev/input/event0: cros_ec /dev/input/event1: cros_ec_buttons /dev/input/event2: Atmel maXTouch Touchpad /dev/input/event3: rk3399-gru-sound Headset Jack /dev/input/event4: rk3399-gru-sound DP Jack /dev/input/event5: gpio-keys Select the device event number [0-5]: Anyone's free to try flashing old images to that DUT (to check for regressions?), or get the lab to pull it.
,
Sep 26 2017
BTW, locking is done in cautotest: http://cautotest/afe/#tab_id=view_host&object_id=7052
,
Sep 26 2017
Thanks, I tried two older images, 9962.0.0 and 9945.0.0, with both the touchscreen is missing.
,
Sep 26 2017
I _think_ the right thing here is to assign to current Infra Deputy to get the device pulled and replaced with a new Kevin. Feel free to deliver the bad Kevin to my desk and I'll walk around and poke people to find someone who wants to do a Failure Analysis.
,
Sep 26 2017
I move this DUT to pool:suites """ Removing labels ['pool:bvt'] from host chromeos6-row2-rack24-host3 Adding labels ['pool:suites'] to host chromeos6-row2-rack24-host3 """ But I don't know how to deliver it since it's supposed in englab. Any further actions you need? Or I will mark this as fixed or assign back?
,
Sep 26 2017
> I move this DUT to pool:suites I personally don't know what that means. Will it get used by the lab if I unlock it? Is it somehow flagged for eventual removal/investigation?
,
Sep 26 2017
> But I don't know how to deliver it since it's supposed in englab. I don't know quite what this means. Is englab not handled by the Infrastructure Deputy? I guess I must have gotten confused. Maybe John is the right person?
,
Sep 26 2017
When a DUT in serious pool (cq, bvt, cts, ...) is broken, deputy's work is to move it to pool:suites, and englab (experts who responsible for maintaining all these hardwares) will fix bad DUTs in this pool (pool:suites) on time. It may get used if its state is 'Ready'. But tests scheduled on pool:suites can be regarded as 'non-critical' tests, so it doesn't matter there're some bad DUTs in pool:suites that causes tests to fail.
,
Sep 26 2017
For future reference Request for DUT Repair/Logs - File a ticket for work on a device in either chromeos2 (Atlantis Lab), chromeos4 (Destiny Lab), or chromeos6 (Prometheus Lab). (go/cros-lab-device-repair) https://b.corp.google.com/u/0/issues/66950736
,
Sep 26 2017
,
Sep 26 2017
,
Sep 26 2017
DUT has been repaired and shows touchscreen and digitizer, on multiple reboots. I've unlocked the device. I guess it should go back in pool:bvt sometime? Or just close this, if we're fine as-is.
,
Sep 26 2017
Currently let's leave it in pool:suites since pool:bvt has enough working DUTs. Next time when there's shortage of DUTs in pool:bvt, it will be moved to pool:bvt then.
,
Jan 22 2018
,
Jan 23 2018
|
|||||||||||
►
Sign in to add a comment |
|||||||||||
Comment 1 by diand...@chromium.org
, Sep 25 2017