During the first Flame test run on Eideticker the camera appears to have become unavailable. The error in the console log (attached) states "Failed to get the camera from the index." This caused the build to fail, and the subsequent job to stall when running getdimensions.py
I couldn't see any processes related to the camera still running, so I've initiated a reboot on the server to see if that resolves the issue.
Rebooting the server doesn't appear to have helped. I wonder if there's something up with the USB cable. Zac: Could you perhaps try unplugging the USB cable from eideticker-london-2 and then reconnecting it? I'm in the office tomorrow, but it would be great if we can get this up and running today.
I had a look, unplugged the usb, the phone was active. Try again now.
This was regarding the blue USB cable attaching the camera. Did you check this or the phone USB cable?
Zac has now detached and reattached the camera, and the following build appears to be working. I'll leave this bug open as we need to be able to either prevent or recover from such a failure.
It's happened again, around an hour into the build. Any ideas what might be causing this Will?
Spent the bulk of the day looking at this. Findings: 1. Running this recipe (as root) fixes the camera: http://askubuntu.com/questions/645/how-do-you-reset-a-usb-device-from-the-command-line/290519#290519 2. This has only happened with the "action" tests (e.g. the ones where you do a bunch of gestures) where, for some reason, running the set of actions takes an unusually long amount of time (40 seconds in the one case I most recently looked at) and the pointgrey capture program exits after having captured the maximum # of frames. Theory: It may be the capture program in this case reaching a point of memory exhaustion which means the camera can't be shut down properly. Need to test this and see if we can handle this more gracefully. Most likely we can. Regardless though, these tests should only take 5-6 seconds to run. Why are they taking 40 seconds (according to the logs?). There are only a few things happening between the capture starting and it ending: creating a set of actions, pushing it to the device, running it, and cleaning it up. I'd bet anything that it's the "running the set of actions" part that's taking so long. But why? Could this be related to the touch input problems we're seeing in bug 1026527? For now, I've disabled the scrolling tests on the flame. I will look into this some more when I come back from pto on Wednesday.
Assignee: nobody → wlachance
Summary: Failed to get the camera from the index on eideticker-london-2 during tests → Camera gets into unusable state sometimes with FirefoxOS scrolling tests on Flame
I've replicated this locally running Eideticker CI. The failure was on the first scrolling test (contacts) and the phone appeared in the state of the Contacts app opened but did not appear to have performed any scrolling.
(In reply to William Lachance (:wlach) from comment #7) > For now, I've disabled the scrolling tests on the flame. I will look into > this some more when I come back from pto on Wednesday. I've made this change to the eideticker-ci repository. Due to a typo I also needed a followup commit: https://github.com/mozilla/eideticker-ci/commit/0d0ebf3f5a8cc7d00e7c9640b148e9f99cb36b7a https://github.com/mozilla/eideticker-ci/commit/1b0ce8fe1a59882b3423918c9c9f8b4b0927dbe7
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.