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

[Roy Marples <roy%marples.name@localhost>]

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 <gson%gson.org@localhost>
> To: roy%NetBSD.org@localhost
> Cc: gnats-bugs%NetBSD.org@localhost
> 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:
>
>
> http://www.gson.org/netbsd/bugs/build/amd64-baremetal/2016/2016.12.13.19.03.49/install.log
>
>  Timestamped log:
>
>    
> http://www.gson.org/netbsd/bugs/51531/install-2016.12.13.19.03.49-slog.txt
>
>  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 1.2.3.4/24 optimistic)
2) Add a toggle to sysinst to disable DaD

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

Roy