All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Christopher Friesen" <cfriesen@nortelnetworks.com>
To: Ben Greear <greearb@candelatech.com>
Cc: Andi Kleen <ak@suse.de>, linux-kernel@vger.kernel.org
Subject: Re: RFC: ethernet links should remember routes the same as addresses
Date: Thu, 29 Nov 2001 16:18:34 -0500	[thread overview]
Message-ID: <3C06A62A.1F7A34D2@nortelnetworks.com> (raw)
In-Reply-To: <3C068ED1.D5E2F536@nortelnetworks.com.suse.lists.linux.kernel> <p73r8qhqrmi.fsf@amdsim2.suse.de> <3C06A1C8.C133F725@nortelnetworks.com> <3C06A294.4070906@candelatech.com>

Ben Greear wrote:
> 
> Christopher Friesen wrote:
> 
> > If the driver re-init is totally separate from the routing code, is there any
> > real reason why shutting down the driver *should* remove all routes to that
> > device?  Maybe the simplest solution would be a new ioctl that would be a link
> > *reset*...just down/up the link without affecting anything else....
> 
> What would want want the down/up to do?  The reason I ask is that there is
> an MII-DIAG option to reset the transceiver, if that's all you want to do.
> 
> If you want to remove/re-install the driver, then you have to clean up
> all the links pointing to it (ie the routes associated with the
> device), or you will have all kinds of nasty dangling pointers (logical
> or otherwise) to clean up...

We've got what looks like a bug in the tulip driver (or maybe buggy hardware)
that under certain circumstances can block with what looks like a problem in the
ring buffer.  Someone is looking at the driver, but in the meantime the only way
to fix it is to do "ip link set dev ethX down" followed by "ip link set dev ethX
up".  Whatever code path this causes in the driver is enough to fix the issue. 
I assume its due to the re-initialization of the buffer descriptors.

On some consideration, maybe it would make more sense in this case to add
something to the driver itself to re-initialize itself rather than involving the
rest of the kernel.  However, I do think that taking down a link and bringing it
back up should be inverse procedures.  If there were routes associated with a
link before taking it down, then they should be associated with it after
bringing it back up, whether or not they stick around when the link is actually
down.  This is how addresses behave, so I think routes should be similar.

Chris

-- 
Chris Friesen                    | MailStop: 043/33/F10  
Nortel Networks                  | work: (613) 765-0557
3500 Carling Avenue              | fax:  (613) 765-2986
Nepean, ON K2H 8E9 Canada        | email: cfriesen@nortelnetworks.com

  reply	other threads:[~2001-11-29 21:15 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <3C068ED1.D5E2F536@nortelnetworks.com.suse.lists.linux.kernel>
2001-11-29 19:55 ` RFC: ethernet links should remember routes the same as addresses Andi Kleen
2001-11-29 20:59   ` Christopher Friesen
2001-11-29 21:03     ` Ben Greear
2001-11-29 21:18       ` Christopher Friesen [this message]
2001-11-29 21:18     ` Andi Kleen
2001-11-29 23:04 Julian Anastasov
  -- strict thread matches above, loose matches on Subject: below --
2001-11-29 19:38 Christopher Friesen
     [not found] ` <9u64q7$46m$1@phoenix.clouddancer.com>
2001-11-29 20:58   ` Colonel

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=3C06A62A.1F7A34D2@nortelnetworks.com \
    --to=cfriesen@nortelnetworks.com \
    --cc=ak@suse.de \
    --cc=greearb@candelatech.com \
    --cc=linux-kernel@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.