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

Issue 911243 link

Starred by 1 user
Status: Assigned
Owner:
haddowk@chromium.org
Cc:
mqg@chromium.org
tbroch@chromium.org
█ mattmallett@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 3
Type: Bug

Blocking:
issue 913145



Sign in to add a comment

DUT stuck in "pending" status

Reported by chasing....@gmail.com, Dec 3 
What I did:
1. Use Autotest UI to run power_LoadTest.1hour. I chose "skip verify" "skip reset" options. (AC power not required with these options).
2. I hit "submit job" and then I realized that the DUT *is* connected to AC, so I unplugged AC from DUT.
3. Then I realized the queued job did not proceed and DUT is stuck in "pending" state. (See Sona in screenshot)

What I tried to remedy the problem but hasn't worked yet:
1. reboot
2. change from wifi to physical connection between moblab and DUT. DUT then shows up as "ready" with a new ip address, but would not proceed with any new jobs. (See Vayne in screenshot)
3. reverify, repair (DUT does not proceed with the job)
4. remove DUT from moblab network, then add DUT to moblab network again.

What I think the problem is:
I think there is a flag internal to the DUT that I triggered and marked DUT as "pending". Just like the boot loop problem I had a while back. This is my educated guess. 

What I will try next:
manually flash the DUT

In the attachment:
screenshot of DUT status
logs from Sona by "generate_logs"
Screenshot 2018-12-03 at 12.16.51 PM.png
192 KB View Download
debug-logs_20181203-122308.tgz
27.8 MB Download

Comment 1 by mqg@chromium.org, Dec 3

Cc: mqg@chromium.org tbroch@chromium.org mattmallett@chromium.org
Owner: haddowk@chromium.org

Comment 2 by mqg@chromium.org, Dec 3 

New development: 

I originally thought the problem might be on DUT side, now I think it might be on moblab side. 

Evidence 1:

I flashed my vayne with new image, but it still shows "pending"

Evidence 2: 

I connected a new nocturne to moblab, which shows up as "ready". I then submitted a test job to the new moblab via the autotest UI, and the job stays at "queued" status and never started. 

I suspect that something is off on moblab. Still investigating.

Comment 3 by chasing....@gmail.com, Dec 3 

Attaching moblab logs.
moblab_logs_Ig3hBz.tgz
4.2 MB Download

Comment 4 by mqg@chromium.org, Dec 4 

Update - I went through the moblab logs in #3 but I wasn't able to associate anything with my bug specifically. I did see a ton of warnings in "apache_errors". 

I ended up flashing my moblab (with ToT image containing my CLs), and I was able to run a test on my vayne. 

Still curious what the bug was.

Comment 5 by mqg@chromium.org, Dec 8

Blocking: 913145

Comment 6 by mqg@chromium.org, Dec 11 

This is by far the most bizzare bug we had with moblab

Comment 7 by benhenry@google.com, Jan 11

Status: Assigned (was: Untriaged)
This issue has an owner, a component and a priority, but is still listed as untriaged or unconfirmed. By definition, this bug is triaged. Changing status to "assigned". Please reach out to me if you disagree with how I've done this.
►

Sign in to add a comment