From: Jeff Garzik <jgarzik@mandrakesoft.com>
To: Russell King <rmk@arm.linux.org.uk>
Cc: Ben LaHaise <bcrl@redhat.com>, Andrew Morton <andrewm@uow.edu.au>,
linux-kernel@vger.kernel.org, netdev@oss.sgi.com
Subject: Re: 3C905b partial lockup in 2.4.5-pre5 and up to 2.4.6-pre1
Date: Sun, 10 Jun 2001 12:47:55 -0400 [thread overview]
Message-ID: <3B23A4BB.7B4567A3@mandrakesoft.com> (raw)
In-Reply-To: <20010610093838.A13074@flint.arm.linux.org.uk> <Pine.LNX.4.33.0106101201490.9384-100000@toomuch.toronto.redhat.com> <20010610173419.B13164@flint.arm.linux.org.uk>
Russell King wrote:
> Indeed. However, I don't believe user space should _rely_ on the flag.
> The reason is that there are network cards out there where the only way
> to get the link status _is_ to transmit a packet, even on 10baseT.
>
> PCNET is one example - the "oh my god my link is down" status bit is in
> the transmit ring headers, not in an easily accessible register.
>
> The only interpretation user space can place on IFF_RUNNING for these
> cards is that if its not set, packets will get dropped by the interface.
> If its set, packets _may_ be dropped by the interface.
These are the exception not the rule, though, so I don't think we should
design primarily for them. On most decent cards, we can not only ask
for link status from a register, but also get interrupts when link
change occurs [though we may still need a timer for certain link
states].
> [note I've not found anything in 2.4.5 where netif_carrier_ok prevents
> the net layers queueing packets for an interface, and forwarding them
> on for transmission].
we want netif_carrier_{on,off} to emit netlink messages. I don't know
how DaveM would feel about such getting implemented in 2.4.x though,
even if well tested.
Note we went over netif_carrier_xxx and related issues not a week ago,
IIRC
Jeff
P.S. netdev@oss.sgi.com added to cc. please cc there on net
interface/driver issues...
--
Jeff Garzik | Andre the Giant has a posse.
Building 1024 |
MandrakeSoft |
next prev parent reply other threads:[~2001-06-10 16:48 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-06-09 17:45 3C905b partial lockup in 2.4.5-pre5 and up to 2.4.6-pre1 Glenn C. Hofmann
2001-06-10 1:35 ` Andrew Morton
2001-06-10 4:56 ` Glenn C. Hofmann
2001-06-10 5:08 ` Glenn C. Hofmann
2001-06-10 5:54 ` Ben LaHaise
2001-06-10 8:38 ` Russell King
2001-06-10 9:39 ` arjan
2001-06-10 16:06 ` Ben LaHaise
2001-06-10 16:34 ` Russell King
2001-06-10 16:47 ` Jeff Garzik [this message]
2001-06-10 22:23 ` Ben LaHaise
2001-06-11 0:53 ` David S. Miller
2001-06-11 13:03 ` Andrew Morton
2001-06-11 13:27 ` David S. Miller
2001-06-11 13:49 ` Jeff Garzik
2001-06-11 14:21 ` Andrew Morton
2001-06-11 16:05 ` Jeff Garzik
2001-06-11 3:17 ` Glenn C. Hofmann
2001-06-11 3:25 ` Jeff Garzik
2001-06-12 3:17 ` Glenn C. Hofmann
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=3B23A4BB.7B4567A3@mandrakesoft.com \
--to=jgarzik@mandrakesoft.com \
--cc=andrewm@uow.edu.au \
--cc=bcrl@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@oss.sgi.com \
--cc=rmk@arm.linux.org.uk \
/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.