New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 890692 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner:
OOO
Closed: Oct 1
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 1
Type: Bug



Sign in to add a comment

reef-paladin failing to provision

Project Member Reported by yamaguchi@chromium.org, Oct 1

Issue description

The builders below are constantly failing since master-paladin/19722.

- eve-paladin, coral-palain
 AC power is not plugged in (crbug.com/890446)
- reef-paladin
 Found 0 successfully provisioned duts
- coral-paladin
 Could not find any test in module. (crbug.com/890663)

"test in module" is not necessarily infra, but started to fail at similar timing.
 
Cc: kinaba@chromium.org
Blockedon: 890446 890663
crbug.com/890663 is about Grunt, if coral-paladin is failing in "Could not find any test in module", then it is a different bug. Coral cannot hit the case of crbug.com/890663.
coral-paladin failure is "AC power is not plugged in" 
https://uberchromegw.corp.google.com/i/chromeos/builders/coral-paladin
as already listed in the first report.

I guess the latter coral-paladin is a typo of grunt-paladin.
Then it is crbug.com/890663, not an infra bug but purely ARC's bug. It's an experimental builder hence I believe it is not urgent as others.
Blockedon: -890446 -890663
Components: -Infra>Client>ChromeOS>CI Infra>Client>ChromeOS>Test
Owner: gu...@chromium.org
Summary: reef-paladin failing to provision (was: 4 builders constantly failing by infrastructure errors)
Status update:

grunt-paladin is crbug.com/890663 and is still pending. We'll use that bug to track taht.

coral-paladin is crbug.com/890446 and is fixed.

reef-paladin is still failing provision. Over to Infra deputy for that. https://cros-goldeneye.corp.google.com/chromeos/legoland/builderHistory?buildConfig=reef-paladin&buildBranch=master

The provision failed seems still caused by the "AC Power not pluggin" issue.
https://chromeos-swarming.appspot.com/task?id=404a528a2f4e3f10&refresh=10&show_raw=1

Scanning swarming-404a528a2f4e3f11/provision_chromeos6-row3-rack12-host13 (/usr/local/autotest/results/swarming-404a528a2f4e3f11/provision_chromeos6-row3-rack12-host13)
tko parser: {'drone': 'cros-skylab-drone-1.hot.corp.google.com', 'user': 'chromeos-test', 'job_started': 1538428848, 'hostname': 'chromeos6-row3-rack12-host13', 'status_version': 1, 'label': ''}
tko parser: MACHINE NAME: chromeos6-row3-rack12-host13
tko parser: Unable to parse host keyval for chromeos6-row3-rack12-host13
tko parser: MACHINE GROUP: 
tko parser: + Parsing dir=/usr/local/autotest/results/swarming-404a528a2f4e3f11/provision_chromeos6-row3-rack12-host13, jobname=swarming-404a528a2f4e3f11/provision_chromeos6-row3-rack12-host13
tko parser: parsing partial test ---- SERVER_JOB
tko parser: parsing partial test None provision
tko parser: RUNNING: RUNNING
Subdir: None
Testname: provision

tko parser: update RUNNING reason: completed successfully
tko parser: update RUNNING reason: AC power is not plugged in
tko parser: parsing test provision_AutoUpdate provision
tko parser: ADD: FAIL
Subdir: provision_AutoUpdate
Testname: provision
AC power is not plugged in, completed successfully
tko parser: parsing test ---- SERVER_JOB

This might because the build had been started when the CL chumped in. Will wait to see the result of next one.
If you're looking at this:

https://cros-goldeneye.corp.google.com/chromeos/healthmonitoring/buildDetails?buildbucketId=8933840540549305152

It still is using the bad CL:

  <project name="chromiumos/third_party/kernel" path="src/third_party/kernel/v4.4" revision="7a2e8bf0887e99c3115bba318001eb5f5ad3cedc" upstream="refs/heads/chromeos-4.4"/>


commit 7a2e8bf0887e99c3115bba318001eb5f5ad3cedc (m/master, cros/chromeos-4.4)
Author: Enrico Granata <egranata@chromium.org>
Date:   Thu Sep 27 16:35:40 2018 -0700

    cros-ec: improve IRQ timestamping jitter
    
    This commit enables the ability for the kernel to receive synchronization
    events from the EC over a GPIO IRQ. This is done in order to improve the
    jitter with which sensor events are received by the sensor ring.
    
    BUG=b:112111610
    TEST=collect sensor events on Nocturne
    
    Change-Id: I3b28589c3d238b9f6f82a71321eaf6aa75743e6e
    Signed-off-by: Enrico Granata <egranata@chromium.org>
    Reviewed-on: https://chromium-review.googlesource.com/1229593
    Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
    Reviewed-by: Dmitry Torokhov <dtor@chromium.org>


I chumped the fix near the beginning of that run, but I don't think it made it:

commit dcadfbc359fb57bcbbdc072b7642e171e61e7293 (m/master, cros/chromeos-4.4)
Author:     Brian Norris <briannorris@chromium.org>
AuthorDate: Mon Oct 1 20:18:19 2018 +0000
Commit:     Brian Norris <briannorris@chromium.org>
CommitDate: Mon Oct 1 20:37:10 2018 +0000

    Revert "cros-ec: improve IRQ timestamping jitter"
Status: Fixed (was: Untriaged)
Calling this Fixed. We still haven't gotten runs with the chump fix in:

https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1255842

FWIW, my tryjob (w/ HWTest) is past provision stage (on coral/astronaut, but still):

https://cros-goldeneye.corp.google.com/chromeos/healthmonitoring/buildDetails?buildbucketId=8933837962369650192

Sign in to add a comment