+++ This bug was initially created as a clone of Bug #964681 +++ It seems b2gperf is still unable to get the machine name (MAC address) from a Tarako device. I am able to get it using an interactive Python shell on a node with a Tarako attached though. I suspect this will be much easier to investigate with a device. For now, we can use the --dz-machine command line argument and specify a unique identifier. As we can determine the MAC address through other means, I've used this in our CI for now.

(Not /strictly/ blocking bug 964588, but since we're tracking most/all Tarako issues there, I think this fits.)

adb shell netcfg should get the MAC address for the tarako device. Would that help?

(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #2) > adb shell netcfg should get the MAC address for the tarako device. Would > that help? Possibly, but our current method also works when used interactively. Without having a device it's hard for me to troubleshoot this. It's possible that for some reason we're requesting the MAC address too soon, but I'm just speculating. I could add some debug statements to b2gperf to see if I can work out what's going on.

I received a Tarako device today and found this to be working for me. The device in Mountain View has an older firmware revision though, so perhaps that's part of the issue. Works (locally): device_firmware_date: 1396231910 (31 Mar 2014) device_firmware_version_incremental: 215 Fails (Mountain View): device_firmware_date: 1394787456 (14 Mar 2014) device_firmware_version_incremental: 78 Raymond: You mentioned having a device with a later build. Could you swap this in and try running b2g.tarako.mozilla-b2g28_v1_3t.perf after removing the --dz-machine argument from the command line? Leaving this line is will force the machine name to the MAC address of the currently connected device, which will be misleading and mask this issue.

(In reply to Dave Hunt (:davehunt) from comment #4) > I received a Tarako device today and found this to be working for me. The > device in Mountain View has an older firmware revision though, so perhaps > that's part of the issue. > > Works (locally): > device_firmware_date: 1396231910 (31 Mar 2014) > device_firmware_version_incremental: 215 > > Fails (Mountain View): > device_firmware_date: 1394787456 (14 Mar 2014) > device_firmware_version_incremental: 78 > > Raymond: You mentioned having a device with a later build. Could you swap > this in and try running b2g.tarako.mozilla-b2g28_v1_3t.perf after removing > the --dz-machine argument from the command line? Leaving this line is will > force the machine name to the MAC address of the currently connected device, > which will be misleading and mask this issue. The spare tarako we have is broken (ie stuk on the spreadtrum screen). I spent most of today trying to fix it with no luck. I'll update this bug when i find a replacement or if I'm able to fix this.

If we can't swap in the other Tarako, can we update the firmware on the existing one? Compared to running locally we see this MAC address issue and frequent timeouts when restarting, so I suspect we need later firmware in order to make these results stable.

I fixed the problematic Tarako device and swapped it in. I've kicked of this build build 83 with the --dz-machine="00:2c:19:dc:83:ab" argument removed. http://selenium.qa.mtv2.mozilla.com:8080/job/b2g.tarako.mozilla-b2g28_v1_3t.perf/83/ I'm waiting for John Hammink to get in so he can help me flash the old Tarako.

Yep, that looks like it's resolved it. Thanks Raymond!