Bug 819705 (tegra-309)

tegra-309 problem tracking

RESOLVED FIXED

Status

Release Engineering
Buildduty
P3
normal
RESOLVED FIXED
5 years ago
4 years ago

People

(Reporter: Callek, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [buildduty][buildslaves][capacity], URL)

(Reporter)

Description

5 years ago
Unable to connect on SUT Port even after multiple powercycles.
(Reporter)

Updated

5 years ago
Depends on: 822038

Comment 1

5 years ago
Tegra reimaged. No SD card swap.
ran start_cp
Still didn't come back up, back to recovery.
Depends on: 825335

Comment 4

5 years ago
reimaged, no card swap as the last card swap was done on 12/17/12.

Comment 5

5 years ago
Unable to connect to SUT port 20701.
Depends on: 830739
(Reporter)

Comment 6

5 years ago
(mass change: filter on tegraCallek02reboot2013)

I just rebooted this device, hoping that many of the ones I'm doing tonight come back automatically. I'll check back in tomorrow to see if it did, if it does not I'll triage next step manually on a per-device basis.

---
Command I used (with a manual patch to the fabric script to allow this command)

(fabric)[jwood@dev-master01 fabric]$  python manage_foopies.py -j15 -f devices.json `for i in 021 032 036 039 046  048 061 064 066 067 071 074 079 081 082 083 084 088 093 104 106 108 115 116 118 129 152 154 164 168 169 174 179 182 184 187 189 200 207 217 223 228 234 248 255 264 270 277 285 290 294 295 297 298 300 302 304 305 306 307 308 309 310 311 312 314 315 316 319 320 321 322 323 324 325 326 328 329 330 331 332 333 335 336 337 338 339 340 341 342 343 345 346 347 348 349 350 354 355 356 358 359 360 361 362 363 364 365 367 368 369; do echo '-D' tegra-$i; done` reboot_tegra

The command does the reboot, one-at-a-time from the foopy the device is connected from. with one ssh connection per foopy
(Reporter)

Updated

5 years ago
Depends on: 838687
Managed two jobs, both with result 5 before failing. Time for recovery ?
Depends on: 858134
(Reporter)

Updated

5 years ago
Depends on: 865749
Ran one build on 2013-04-26 (the day after recovery) which failed with result 5.
Depends on: 877709
Depends on: 877722
(Reporter)

Updated

5 years ago
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
(Assignee)

Updated

5 years ago
Product: mozilla.org → Release Engineering
Power cycled, waited a day.

last status: Automation Error: Unable to connect to device after 5 attempts

SD card reformat failed:

$>exec newfs_msdos -F 32 /dev/block/vold/179:9
/dev/block/vold/179:9: 31100416 sectors in 485944 FAT32 clusters (32768 bytes/cluster)
bps=512 spc=64 res=32 nft=2 mid=0xf0 spt=16 hds=4 hid=0 bsec=31108096 bspf=3797 rdcl=2 infs=1 bkbs=2
newfs_msdos: warning, /dev/block/vold/179:9 is not a character device
newfs_msdos: Skipping mount checks
newfs_msdos: /dev/block/vold/179:9: I/O error
return code [1]
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Depends on: 991259
running very green bar one robocop RETRY.

http://buildbot-master99.srv.releng.scl3.mozilla.com:8201/builders/Android%202.2%20Tegra%20mozilla-inbound%20opt%20test%20robocop-2/builds/1046/steps/install%20app%20on%20device/logs/stdio

it seems like robocop in m-c and m-i often has a RETRY so I am marking this as resolved under the assumption this is normal.
Status: REOPENED → RESOLVED
Last Resolved: 5 years ago4 years ago
Resolution: --- → FIXED
Nothing on tegras really routinely retries, unlike pandas, but... 99% of the time it's way nicer to look at logs on buildbot rather than chase them down on tbpl, but for the other 1%, you find your job was out at the end of https://tbpl.mozilla.org/?tree=Mozilla-Inbound&rev=6e1d2814d4db, where a bad patch left us infinitely retrying. Nothing to do with the poor innocent slaves.
(In reply to Phil Ringnalda (:philor) from comment #11)
> Nothing to do with the poor innocent slaves.

Thank you. This helps a lot. :)
You need to log in before you can comment on or make changes to this bug.