Bug 108680

Summary:	[CI][BAT] igt@kms_chamelium may need to wait a little bit for the network to come back up before connecting to chamelium
Product:	DRI	Reporter:	Martin Peres <martin.peres>
Component:	IGT	Assignee:	Petri Latvala <petri.latvala>
Status:	CLOSED DUPLICATE	QA Contact:
Severity:	normal
Priority:	medium
Version:	XOrg git
Hardware:	Other
OS:	All
Whiteboard:	ReadyForDev
i915 platform:		i915 features:

Description Martin Peres 2018-11-06 12:07:32 UTC

https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5091/fi-skl-6700k2/igt@kms_chamelium@common-hpd-after-suspend.html

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

Comment 1 Jani Saarinen 2018-11-09 08:37:18 UTC

From Petri:
"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."

Comment 2 Petri Latvala 2018-11-09 10:55:14 UTC

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.

Comment 3 Martin Peres 2018-11-09 11:35:00 UTC

Another example of this issue. The watchdog just randomly killed the platform before it was done:

https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5110/fi-skl-6700k2/igt@drv_selftest@live_execlists.html

Comment 4 Lakshmi 2018-11-12 12:12:47 UTC

IGT infrastructure issue rather than driver issue.

Comment 5 Jani Saarinen 2018-11-16 11:15:52 UTC

Dropping to low as feature request. 
CI failures on CI due to broken HW or driver on NIC.

Comment 6 Martin Peres 2018-11-16 12:17:30 UTC

(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.

Comment 7 Petri Latvala 2018-11-28 11:18:46 UTC

(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.

Comment 8 Lakshmi 2018-12-07 16:19:58 UTC


*** This bug has been marked as a duplicate of bug 108767 ***

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.