NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: PR/51531 CVS commit: src/usr.sbin/sysinst

On 2016-12-14 08:30, Andreas Gustafsson wrote:
The following reply was made to PR kern/51531; it has been noted by GNATS.

From: Andreas Gustafsson <>
Subject: Re: PR/51531 CVS commit: src/usr.sbin/sysinst
Date: Wed, 14 Dec 2016 10:28:05 +0200

 Roy Marples wrote:
> ping is not a reliable means of testing if connectivity to download sets
 >  actually works, so remove it.

 As I said in an earlier comment to this PR, I support this change,
 but I don't think it is related to the present issue.

 >  Hopefully fixes PR kern/51531.

 It did not.  Console log:

 Timestamped log:

 Some observations based on the timestamped log:

 The "ifconfig -w 15 -W 5" command runs in five seconds.  The ftp
 command then takes some 74 seconds to time out.

 Then, a diagnostic "ifconfig -a" is run, and it shows a TENTATIVE flag
 even though 83 seconds (!) have now elapsed since the "ifconfig
 -w 15 -W 5" started.

 Ten seconds later, a second diagnostic "ifconfig -a" is run, and then,
 the TENTATIVE flag is gone.

 When reading the timestamped log, note that the console output is not
 being read during the 10-second sleep between the two "ifconfig -a"
 commands, so the output from the first "ifconfig -a" only appears in
the log after the second "ifconfig -a" has been sent, and its timestamp
 is not meaningful.  The timestamps on the "send(..., 'ifconfig -a\n')"
 lines are correct.

This sounds like one of two things:
1) there is a timing issue
2) the link status is flapping

Because at the point of the ifconfig -w command there are no futher interface changes, nothing should be resetting the PHY at all so one of the above must be true. I say this because the maximum length from DETACHED -> TENTATIVE -> ready to go is 10 seconds once the link is active and your logs show it's at TENTATIVE way beyond that which implies link state is flapping or 10 seconds is not 10 seconds on this device.

Some idea of how to solve this are
1) Implement RFC4429 and apply it to IPv4 as well
   (needs a toggle like ifconfig bge0 inet optimistic)
2) Add a toggle to sysinst to disable DaD

I don't suppose you could try swapping the interfacec out with another one?


Home | Main Index | Thread Index | Old Index