Closed
Bug 876518
(t-w732-ix-100)
Opened 11 years ago
Closed 7 years ago
t-w732-ix-100 problem tracking
Categories
(Infrastructure & Operations Graveyard :: CIDuty, task, P3)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: armenzg, Unassigned)
References
Details
(Whiteboard: [buildduty][buildslaves][capacity][xperf_q3_disabled])
I can't reboot it.
Comment 1•11 years ago
|
||
Host is powered on, dep bug seems to indicate that its back up properly. but its still pinned to your dev master, do the jobs look good?
Flags: needinfo?(armenzg)
Reporter | ||
Comment 2•11 years ago
|
||
It's actually not ready. I checked on it and it was ping down and using the ipmitool did not cycle it.
Flags: needinfo?(armenzg)
Assignee | ||
Updated•11 years ago
|
Product: mozilla.org → Release Engineering
Reporter | ||
Comment 3•11 years ago
|
||
I've rebooted it into production.
This machine has never taken a job so let's see how it turns out:
https://secure.pub.build.mozilla.org/buildapi/recent/t-w732-ix-100
Comment 4•11 years ago
|
||
Incredibly poorly - like all the other win7-ix slaves that have been disabled all summer due to graphics/resolution troubles, it's unable to run webgl tests.
Disabled in slavealloc.
Reporter | ||
Comment 5•11 years ago
|
||
Rebooted into production.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Comment 6•11 years ago
|
||
8 attempts to run xperf since it came back, 8 failures. Disabled in slavealloc.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Updated•11 years ago
|
Whiteboard: [buildduty][buildslaves][capacity] → [buildduty][buildslaves][capacity][xperf_q3_disabled]
Comment 7•11 years ago
|
||
Joel: I'm unclear about the [xperf_q3_disabled] whiteboard tag: has xperf been turned off, i.e. can this slave be re-enabled?
Flags: needinfo?(jmaher)
Reporter | ||
Comment 8•11 years ago
|
||
FTR I've started working on re-imaging another machine like this to put it on staging.
I'm doing this with 016 in bug 872915.
I don't yet know the way to victory.
Comment 9•11 years ago
|
||
I am not sure what others use the xperf_q3_disabled flag for, I used it for all machines (w7) which have have history of failing xperf and we shouldn't be running on unless it is fixed and verified in testing.
I would be happy to help where I can. IIRC I had a loaner (002?) which didn't run successfully in automation, but ran just fine when I had it as a loaner. This difference between running in automation and on a loaner machine needs to get resolved, so people can help solve these issues.
Flags: needinfo?(jmaher)
Comment 10•11 years ago
|
||
(In reply to Joel Maher (:jmaher) from comment #9)
> I am not sure what others use the xperf_q3_disabled flag for, I used it for
> all machines (w7) which have have history of failing xperf and we shouldn't
> be running on unless it is fixed and verified in testing.
>
> I would be happy to help where I can. IIRC I had a loaner (002?) which
> didn't run successfully in automation, but ran just fine when I had it as a
> loaner. This difference between running in automation and on a loaner
> machine needs to get resolved, so people can help solve these issues.
Which bug is tracking xperf failures/fixing?
Flags: needinfo?(jmaher)
Flags: needinfo?(armenzg)
Comment 12•11 years ago
|
||
I don't have a specific bug for it- do we need one?
Flags: needinfo?(jmaher)
Comment 13•11 years ago
|
||
(In reply to Joel Maher (:jmaher) from comment #12)
> I don't have a specific bug for it- do we need one?
Well, it would be good to track it somewhere. Then we could block bugs like this on it at least. Right now it's hard to be sure where this slave stands without deep reading. Or, if we're not going to do anything about it we can just junk these slaves...
Reporter | ||
Comment 14•11 years ago
|
||
Oh sorry... I had been assigning them to myself.
I will be releasing them as I fix them.
Assignee: nobody → armenzg
Reporter | ||
Comment 15•11 years ago
|
||
I'm putting it back into production as it has not failed any jobs on staging (including xperf).
FTR I didn't even re-format the machine, I'm surprised it can take xperf jobs.
Reporter | ||
Comment 16•11 years ago
|
||
I've seen it fail a try debug test mochitest-2 job but not an xperf job.
09:30:48 INFO - 429 ERROR TEST-UNEXPECTED-FAIL | /tests/docshell/test/test_bug668513.html | /tests/docshell/test/test_bug384014.html finished in a non-clean fashion, probably because it didn't call SimpleTest.finish()
Reporter | ||
Comment 17•11 years ago
|
||
It's looking good.
Status: REOPENED → RESOLVED
Closed: 11 years ago → 11 years ago
Resolution: --- → FIXED
Reporter | ||
Updated•10 years ago
|
Assignee: armenzg → nobody
QA Contact: armenzg → bugspam.Callek
Comment 18•10 years ago
|
||
Needs a reimage according to bug 1104225, disabled in slavealloc.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 19•10 years ago
|
||
Re-imaged and returned to production.
Status: REOPENED → RESOLVED
Closed: 11 years ago → 10 years ago
Resolution: --- → FIXED
Updated•9 years ago
|
Comment 20•9 years ago
|
||
Re-imaged and enabled in slavealloc
Status: REOPENED → RESOLVED
Closed: 10 years ago → 9 years ago
Resolution: --- → FIXED
Comment 21•7 years ago
|
||
Attempting SSH reboot...Failed.
Attempting IPMI reboot...Failed.
Filed IT bug for reboot (bug 1364344)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Updated•7 years ago
|
Status: REOPENED → RESOLVED
Closed: 9 years ago → 7 years ago
Resolution: --- → FIXED
Updated•6 years ago
|
Product: Release Engineering → Infrastructure & Operations
Updated•5 years ago
|
Product: Infrastructure & Operations → Infrastructure & Operations Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•