Starting subtest: common-hpd-after-suspend
Subtest common-hpd-after-suspend: SUCCESS (36.272s)
(kms_chamelium:3059) igt_chamelium-CRITICAL: Test assertion failure function chamelium_rpc, file ../lib/igt_chamelium.c:303:
(kms_chamelium:3059) igt_chamelium-CRITICAL: Failed assertion: !chamelium->env.fault_occurred
(kms_chamelium:3059) igt_chamelium-CRITICAL: Last errno: 113, No route to host
(kms_chamelium:3059) igt_chamelium-CRITICAL: Chamelium RPC call failed: libcurl failed to execute the HTTP POST transaction, explaining: Failed to connect to 192.168.1.220 port 9992: No route to host
"The story for it is that the test suspends a couple of times and then reports success, and chamelium's atexit handlers attempt to reset the chamelium to a good default state for other tests, and that fails with "No route to host". To be investigated: Is the theory correct that the DUT doesn't have an IP when that happens, or the link is down still? If the dut's network interface is still down from the suspend, can a wait (using netlink) be added to chamelium_rpc() if the interface is coming up, or if this can be made more robust in some other way."
Turns out, fi-skl-6700k2's network interface is just prone to completely disappearing on suspend. Work is ongoing to make IGT instead check for working network connectivity after suspending to mitigate this.
Another example of this issue. The watchdog just randomly killed the platform before it was done:
IGT infrastructure issue rather than driver issue.
Dropping to low as feature request.
CI failures on CI due to broken HW or driver on NIC.
(In reply to Jani Saarinen from comment #5)
> Dropping to low as feature request.
> CI failures on CI due to broken HW or driver on NIC.
Even perfectly-functioning platforms may hit this issue, so raising the priority a bit.
(In reply to Martin Peres from comment #6)
> (In reply to Jani Saarinen from comment #5)
> > Dropping to low as feature request.
> > CI failures on CI due to broken HW or driver on NIC.
> Even perfectly-functioning platforms may hit this issue, so raising the
> priority a bit.
But the story as stated by the bug title is bogus, as the network is not coming up. It's dead, a late network. If it wasn't nailed to the perch it would be pushing up the daisies.
In other words, this bug cannot be solved.
Only thing CI can do is have a solution for bug #108767.
*** This bug has been marked as a duplicate of bug 108767 ***