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

Joe Hershberger joe.hershberger at gmail.com
Thu Feb 5 21:48:12 CET 2015


On Thu, Feb 5, 2015 at 2:39 PM, Jörg Krause <jkrause at 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 at 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.

Cheers,
-Joe


More information about the U-Boot mailing list