power_SuspendStress.bare: ValueError: min() arg is an empty sequence |
||||
Issue description
START power_SuspendStress.bare power_SuspendStress.bare timestamp=1541421683 localtime=Nov 05 04:41:23
FAIL power_SuspendStress.bare power_SuspendStress.bare timestamp=1541425181 localtime=Nov 05 05:39:41 Unhandled ValueError: min() arg is an empty sequence
Traceback (most recent call last):
File "/usr/local/autotest/common_lib/test.py", line 800, in _call_test_function
return func(*args, **dargs)
File "/usr/local/autotest/common_lib/test.py", line 464, in execute
postprocess_profiled_run, args, dargs)
File "/usr/local/autotest/common_lib/test.py", line 371, in _call_run_once
self.run_once(*args, **dargs)
File "/usr/local/autotest/tests/power_SuspendStress/power_SuspendStress.py", line 75, in run_once
iface = interface.Interface(min(interface_choices))
ValueError: min() arg is an empty sequence
END FAIL power_SuspendStress.bare power_SuspendStress.bare timestamp=1541425181 localtime=Nov 05 05:39:41
,
Jan 11
Still occurring quite regularly. Brian, can you have a look or suggest someone else?
,
Jan 11
Taking a look. It looks like ethernet is not coming back up right, and the network device detection code doesn't handle the empty resulting dictionary correctly. I can at least fix up the corner case code (and probably report a proper failure instead?), but I can't exactly fix the USB/ethernet flakiness. Side note: some of these failures are even on Chromeboxes with built-in Ethernet. Dunno why the lab doesn't use the built-in ethernet, which should be much more stable (I hope).
,
Jan 12
I wonder if a short timeout on this step would also help. It looks like there are cases where the next phase of testing is working just fine within 10-20 seconds of the ethernet failure. I'll try to add that as well.
,
Jan 15
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/autotest/+/a39ab37691ae46680c93b971c5c5df60a1634dde commit a39ab37691ae46680c93b971c5c5df60a1634dde Author: Brian Norris <briannorris@chromium.org> Date: Tue Jan 15 17:42:55 2019 [autotest] power_SuspendStress: make net-dev detection more forgiving This code had several problems: (1) it didn't handle the condition of "no devices" -- it would produce an error in min() instead (2) it doesn't do a good job of sorting our interfaces by metric (min(my_dictionary) sorts by keys, not the values) (3) it's not forgiving for thte case of a network device that comes back soon after this test starts For (1): short-circuit the detection when the dictionary is empty For (2): add a 'key=' parameter to the use of min() (i.e., look at the dictionary values, not the keys) and convert the 'Flags' field from a string to int for better sorting. For (3): add a polling loop. If we can't find a device after 10 seconds, we're probably in bad shape and can bail out with an informative Error. BUG= chromium:901876 TEST=power_SuspendStress, with and without good connectivity, and while forcing the eth0 link to go down Change-Id: I91e6ab9dbf4162483c96adf953853752eb203da2 Reviewed-on: https://chromium-review.googlesource.com/c/1407804 Tested-by: Brian Norris <briannorris@chromium.org> Reviewed-by: Todd Broch <tbroch@chromium.org> Reviewed-by: Ravi Chandra Sadineni <ravisadineni@chromium.org> Reviewed-by: Gwendal Grignou <gwendal@chromium.org> [modify] https://crrev.com/a39ab37691ae46680c93b971c5c5df60a1634dde/client/site_tests/power_SuspendStress/power_SuspendStress.py
,
Jan 15
Should be Fixed, in that we won't see $subject error. If the network device is recoverable within a few seconds, then we should be in better shape. Otherwise, we'll just quite the test with an Error, but at least it will be an informative one. Let me know if you still see problems here. |
||||
►
Sign in to add a comment |
||||
Comment 1 by tbroch@google.com
, Nov 5