public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: "Jörg Krause" <jkrause@posteo.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] netconsole: USB Ethernet connection dropping with ping or tftpboot
Date: Thu, 05 Feb 2015 21:39:31 +0100	[thread overview]
Message-ID: <1423168771.1232.15.camel@posteo.de> (raw)
In-Reply-To: <CANr=Z=ao1kOJOYM9rpORZfH8NxtBdZ3O8wU5QCufY9ZVWK+4Aw@mail.gmail.com>

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?

Best regards
J?rg

  reply	other threads:[~2015-02-05 20:39 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-03 21:44 [U-Boot] netconsole: USB Ethernet connection dropping with ping or tftpboot Jörg Krause
2015-02-05 11:21 ` Jörg Krause
2015-02-05 15:33   ` Stephen Warren
2015-02-05 22:10     ` Jörg Krause
2015-02-05 22:23       ` Stephen Warren
2015-02-05 23:19         ` Jörg Krause
2015-02-06  1:06         ` Jörg Krause
2015-02-06 18:06           ` Stephen Warren
2015-02-08 21:25             ` Jörg Krause
2015-02-09 17:38               ` Stephen Warren
2015-02-11 22:08                 ` Jörg Krause
2015-02-05 19:20 ` Joe Hershberger
2015-02-05 20:39   ` Jörg Krause [this message]
2015-02-05 20:48     ` Joe Hershberger
2015-02-05 22:28       ` Jörg Krause

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1423168771.1232.15.camel@posteo.de \
    --to=jkrause@posteo.de \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox