Bob Clary's ramblings about Mozilla, everything and nothing
My T1 line went down during a thunderstorm on Sunday afternoon and has only just now been repaired. During this time Autophone was not able to test builds. I have restarted Autophone and initiated retesting of all tinderbox box builds from 2013-07-28 12:00:00 PM PT.
nexus-one-2 Found dead sdcard; replaced 11:50AM PT
The Kingston 4G Class 4 cards continue to fail. I have a number of them remaining, but will place an order for microsdcards equivalent to those used in releng tegras and pandas.
nexus-s-1 Found wifi disabled; reenabled 11:40AM PT.
The wifi router relocation didn’t solve all of the wifi disconnection/disabling issues unfortunately.
nexus-s-2 Found Firefox hung, SUTAgent dead; restarted SUTAgent.
nexus-s-2 continually suffers low memory conditions running the Mochitest-Canvas tests which results in Android killing off many processes which leaves the phone requiring a restart of the SUTAgent. I don’t know why nexus-s-2 can’t recover while nexus-s-1 can.
On 2013-07-17, several changes were made to Autophone Haxxor Virginia:
The Wireless router used to communicate with the phones was repositioned to be next to the phones. This was done in an attempt to eliminate cases where the phones would lose communication with the router and disable the Wifi connection. So far, this appears to have helped.
The Autophone Mochitest-Canvas tests were enabled. These tests run only the content/canvas Mochitests with the preferences gfx.canvas.azure.backends=skia
gfx.canvas.azure.accelerated=true enabled.
To determine if the relocation of the router and the addition of the Mochitest-Canvas tests changed the overall, I retested the tinderbox nightly builds from 2013-07-15. This resulted in the testing of additional tinderbox builds which were missed in the original runs as well as expanded the number of Mochitest-Canvas results for the period.
The “After” results are a bit smoother than the “Before” particularly on July 16. The “regression” in the throbber start time on July 16 is consistent in both sets of results and is a bit clearer in the “After” results. It appears the relocation of the router may have been helpful and that the addition of the Mochitest-Canvas tests did not have a detrimental effect.
samsung-gs2-3 (Android 4.0.3/Mali-400 MP4), samsung-gs3-1 (Android 4.0.4/Mali-400 MP), samsung-gs3-2 (Android 4.0.4/Mali-400 MP) and atrix-1 (Android 4.0.4/Adreno 225)> are all green with the Mochitest-Canvas tests with SkiaGL enabled.
The droid-pro-1(8132,0,230), nexus-one-1 (8068,0,232), appears orange on the autolog display due to a failure in pulling files from the phone, but inspecting the log shows it actually passed the Mochitest-Canvas tests.
The samsung-gs2-1 (8132,0,230)and samsung-gs2-2 (8132,0,230) both appear orange on the autolog display due to a failure in pulling files from the phones, but inspecting the logs show they actually pass the Mochitest-Canvas tests.
The nexus-one-2 (8068,1,231), again fails to pull files. When it does have data on the test results it fails 1 test but due to the incomplete logs it is not possible to determine which test.
nexus-s-1, nexus-s-2 fail to complete the tests due to Android and SUTAgent crashes due to low memory.
lg-revolution-1 fails to complete due to SIGSEGVs at Crash address: 0xdeadbaad with stack libc.so@0x15cb4,libEGL.so@0x8d0e.
Failures due to the inability to pull files from devices is a known issue that has been seen elsewhere. In Autophone’s case, it may be partly due to the network shaping using ipfw which may cause issues retrieving the files. If a solution to the failure to pull files could be found, then all of the galaxy s2 phones and at least one of the nexus one phones would be green.
It would be possible to skip the Mochitest-Canvas tests on the phones which are known to fail for whatever reason.
The following phones are under test at Haxxor Virginia.
| Device | Name | Serial | Device Name | IP | Mac | Android | GPU | Notes |
|---|---|---|---|---|---|---|---|---|
| Motorola Atrix HD | atrix-1 | ta300018fe | 80_96_b1_ee_55_e0_atrix | 192.168.1.16 | 80:96:b1:ee:55:e0 | 4.0.4 | Adreno 225 | |
| Motorola Atrix 4G MB860 | atrix-4g-1 | ta20709vkh | 40_fc_89_4c_95_3f_atrix-4g | 192.168.1.28 | 40:fc:89:4c:95:3f | 2.3.7 | ULP GeForce | Cyanogen Mod 7, SanDisk Pro |
| Motorola Droid | droid-1 | 040373c41800b021 | a4_ed_4e_59_6c_b2_droid | 192.168.1.38 | a4:ed:4e:59:6c:b2 | 2.1 | PowerVR SGX 530 | SanDisk Pro |
| Motorola Droid Pro | droid-pro-1 | 015f13050c03201f | c8_aa_21_ac_0c_b5_droid-pro | 192.168.1.3 | c8:aa:21:ac:0c:b5 | 2.3.3 | PowerVR SGX530 | Kingston class 4 4G |
| Motorola Droid Pro | droid-pro-2 | 0a3aa1fd1402e01d | 98_4b_4a_2c_e4_89_droid-pro | 192.168.1.18 | 98:4b:4a:2c:e4:89 | 2.3.4 | PowerVR SGX530 | Dead |
| Motorola Droid Pro | droid-pro-3 | 0a3a86d70a010012 | f8_7b_7a_8b_12_84_droid-pro | 192.168.1.19 | f8:7b:7a:8b:12:84 | 2.2.1 | PowerVR SGX530 | Dead |
| Motorola Droid Pro | droid-pro-4 | 0a3a8eb60d02201d | 98_4b_4a_13_01_84_droid-pro | 192.168.1.39 | 98:4b:4a:13:01:84 | 2.3.3 | PowerVR SGX530 | SanDisk Pro |
| HTC Sensation 4G | htc-sensation-4g-1 | sh1apt506663 | 18_87_96_a7_89_70_htc-sensation-4g | 192.168.1.30 | 18:87:96:a7:89:70 | 2.3.4 | Adreno 220 | SanDisk Pro, SUTAgent rebt does not work. |
| HTC Sensation 4G | htc-sensation-4g-2 | sh1cft502258 | c0_3f_0e_ba_5f_34_htc-sensation-4g | 192.168.1.31 | c0:3f:0e:ba:5f:34 | 2.3.4 | Adreno 220 | SanDisk Pro |
| LG Revolution | lg-revolution-1 | 99000044157141 | 44_a7_cf_ea_f9_73_lg-revolution | 192.168.1.7 | 44:a7:cf:ea:f9:73 | 2.3.4 | Adreno 205 | |
| Google Nexus One | nexus-one-1 | ht018p800097 | 00_23_76_b1_92_39_nexus-one | 192.168.1.9 | 00:23:76:b1:92:39 | 2.3.6 | Adreno 200 | |
| Google Nexus One | nexus-one-2 | ht9cpp809750 | 00_23_76_96_cc_6f_nexus-one | 192.168.1.27 | 00:23:76:96:cc:6f | 2.3.6 | Adreno 200 | |
| Google Nexus One | nexus-one-3 | ht09ap802284 | 90_21_55_09_87_95_nexus-one | 192.168.1.40 | 90:21:55:09:87:95 | 2.3.7 | Adreno 200 | SanDisk Pro |
| Google Nexus S | nexus-s-1 | 32318e41c58f00ec | 78_d6_f0_cf_d2_17_nexus-s | 192.168.1.11 | 78:d6:f0:cf:d2:17 | 2.3.6 | PowerVR SGX540 | |
| Google Nexus S | nexus-s-2 | 3833f770946f00ec | 78_d6_f0_cf_8d_11_nexus-s | 192.168.1.15 | 78:d6:f0:cf:8d:11 | 2.3.6 | PowerVR SGX540 | |
| Samsung Galaxy S2 I9100 | samsung-gs2-1 | 304d19d2c307be8e | 98_0c_82_33_ec_8d_samsung-gs2 | 192.168.1.4 | 98:0c:82:33:ec:8d | 2.3.6 | Mali-400 MP4 | |
| Samsung Galaxy S2 I9100 | samsung-gs2-2 | 304d097f6e5add6f | 20_64_32_4f_e9_4f_samsung-gs2 | 192.168.1.6 | 20:64:32:4f:e9:4f | 4.0.3 | Mali-400 MP4 | |
| Samsung Galaxy S2 I9100 | samsung-gs2-3 | 0009cfb9411b4f | 20_64_32_21_35_70_samsung-gs2 | 192.168.1.5 | 20:64:32:21:35:70 | 4.0.4 | Mali-400 MP4 | Not rooted |
| Samsung Galaxy S2 I9100 | samsung-gs2-4 | 304d19c38653ed7e | 14_7d_c5_af_c8_e3_samsung-gs2 | 192.168.1.26 | 14:7d:c5:af:c8:e3 | 2.3.5 | Mali-400 MP4 | |
| Samsung Galaxy S2 I9100 | samsung-gs2-5 | 304d19fec32a7f9e | 04_46_65_fd_2f_e1_samsung-gs2 | 192.168.1.41 | 04:46:65:fd:2f:e1 | 2.3.4 | Mali-400 MP4 | |
| Samsung Galaxy S3 SCH 0I535 | samsung-gs3-1 | b313b945 | 5c_0a_5b_b4_31_32_samsung-gs3 | 192.168.1.14 | 5c:0a:5b:b4:31:32 | 4.0.4 | Mali-400 MP | |
| Samsung Galaxy S3 SCH 0I535 | samsung-gs3-2 | 98095208 | 38_aa_3c_1e_a8_ee_samsung-gs3 | 192.168.1.12 | 38:aa:3c:1e:a8:ee | 4.0.4 | Mali-400 MP | |
| Samsung Galaxy S3 SCH 0I535 | samsung-gs3-3 | 501a2aa7 | 38_aa_3c_1c_f6_94_samsung-gs3 | 192.168.1.42 | 38:aa:3c:1e:a8:ee | 4.0.4 | Mali-400 MP |
Again had to restart the OSX 10.8 mac mini hosting the Autophone server due to it becoming unresponsive via vnc. I have switched back to running the phonedash and autophone servers via ssh and screen; however my previous experience with running Autophone using ssh and screen leads me to believe this may be a reoccurring issue. This behavior is new since the switch from a Macbook running OSX 10.7 to a Mac Mini running OSX 10.8.