[U-Boot] netconsole: USB Ethernet connection dropping with ping or tftpboot

["Jörg Krause" <jkrause@posteo.de>]

On Do, 2015-02-05 at 14:48 -0600, Joe Hershberger wrote:
> 
> 
> On Thu, Feb 5, 2015 at 2:39 PM, J?rg Krause <jkrause@posteo.de> wrote:
> >
> > Hi Joe,
> >
> > On Do, 2015-02-05 at 13:20 -0600, Joe Hershberger wrote:
> > > On Tue, Feb 3, 2015 at 3:44 PM, J?rg Krause <jkrause@posteo.de>
> wrote:
> > > > But if I use 'ping 10.0.0.1' or 'tftpboot u-boot.sb' the network
> > > > connection drops. Both commands work fine if I switch back from
> > > > netconsole to serial in-/output.
> > > >
> > > > This is the output from dmesg:
> > > >         [31620.215354] usb 3-13: USB disconnect, device number
> 24
> > > >         [31620.215422] cdc_ether 3-13:1.0 enp0s20u13: unregister
> > > >         'cdc_ether' usb-0000:00:14.0-13, CDC Ethernet Device
> > >
> > > One thing to note is that the network stack generally is designed
> to
> > > sit in a state of inactive (i.e. devices halted / inactive). When
> a
> > > network command is issued, the driver is initialized, then the
> command
> > > runs, then the driver is halted again.
> > >
> > >
> > > NetConsole breaks this assumption, since the network stack needs
> to be
> > > up the whole time it is selected.  Net console used to bring the
> > > network driver up and down for every character it sent.  Naturally
> > > this was a huge problem on USB network adapters that don't come up
> > > fast or any other that doesn't.  As a workaround (and its current
> > > state) when net console is used, the network stack is lied to
> about
> > > the state of the driver (telling it the driver is halted or
> inited)
> > > when the current and previous packets are net console packets.
> When a
> > > different type (ping or tftp, etc) of network packet is sent, the
> > > driver is actually brought down and back up to ensure the
> assumptions
> > > about the network stack hold true.  With more work we can
> potentially
> > > make these better when net console is enabled.
> >
> > Thank you for the explanation! What do you mean with more work? Do
> you
> > have already some ideas in mind?
> 
> I think it might be possible to work through the reasons that these
> network functions assume the network interface should be down when
> they begin and for certain special cases not bring them down at all
> when net console is enabled.  I think this is likely to be
> non-trivial, though.  If you look in include/net.h you'll see
> eth_is_on_demand_init().  Changing the logic here would be the first
> step to testing.

I think I read sth about that the network interface should be down or in
a well-defined state for handling over the control to the Linux kernel.
There where some problems with the Linux drivers, if I remember rigthly.

I will take a closer look at eth_is_on_demand_init. Thank you!