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 DeviceOne 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!