On Do, 2015-02-05 at 14:48 -0600, Joe Hershberger wrote: > > > On Thu, Feb 5, 2015 at 2:39 PM, Jörg Krause <jkra...@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 <jkra...@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! _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
