Bug 1520826
| Summary: | [NMCI] run_once_helper_for_localhost_localdomain test failed | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Beniamino Galvani <bgalvani> | ||||
| Component: | NetworkManager | Assignee: | Beniamino Galvani <bgalvani> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Desktop QE <desktop-qa-list> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 7.5 | CC: | atragler, bgalvani, fgiudici, lmiksik, lrintel, rkhan, sukulkar, thaller, vbenes | ||||
| Target Milestone: | rc | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2018-04-10 13:35:58 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Beniamino Galvani
2017-12-05 09:19:05 UTC
eth0 takes more than 5 seconds to establish the link: [ 9567.500248] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready [ 9572.988977] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx [ 9572.997228] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready NetworkManager wait at most 5 seconds and then declares 'startup-complete', which also quits the daemon when using configure-and-quit. A job from last week shows a ethernet bring-up delay of less than 4 seconds: [ 9587.836386] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready [ 9591.386913] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx [ 9591.395072] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready Vladimir, were there any changes in the hardware setup? In the last git version of NM it is possible to increase the wait-carrier timeout adding the following to a configuration snippet: [device] match-device=interface-name:eth0 carrier-wait-timeout=8000 Maybe we should consider doing that for CI tests? Sushil, we have workaround in place as suggested [device] match-device=interface-name:eth0 carrier-wait-timeout=8000 so it's not clear to me if this is bug or not The default setting (5 seconds) should work out of the box in most cases. If it doesn't work on test machines with standard HW and NICs, I think it would be better to increase the timeout. So, I think this is a bug (though I don't know why it used to work before). (In reply to Beniamino Galvani from comment #4) > The default setting (5 seconds) should work out of the box in most cases. If > it doesn't work on test machines with standard HW and NICs, I think it would > be better to increase the timeout. I mean, it would be better to increase the *default* timeout, and not using the workaround from comment 3. Created attachment 1377547 [details]
[PATCH] device: increase carrier wait time to 6 seconds
(In reply to Beniamino Galvani from comment #6) > Created attachment 1377547 [details] > [PATCH] device: increase carrier wait time to 6 seconds lgtm Applied to master: https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=156344b8beec88b68f335fe13c5db91d62fcb3fc and nm-1-10. Any idea what can be the cause of this failure? In case I have veth devices present in the test environment the test occasionally fails. Eth0 that is used is never veth. It is always real device. This has something to do with computer performance as it's mostly visible on older Pentium 4 based machines. This is fixed as the timeout is 6 seconds now. Should we track the device's delay via another bug as a future material? this delay was enlarged to 6 but sometimes it's even not enough for some devices, we think it's dependant on device to switch communication. This has nothing more to verify. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2018:0778 |