* Re: [RFC] [PATCH] udp: optimize lookup of UDP sockets to by including destination address in the hash key
From: Eric Dumazet @ 2009-11-06 18:34 UTC (permalink / raw)
To: Octavian Purdila, Lucian Adrian Grijincu; +Cc: netdev
In-Reply-To: <4AF2FF22.2000805@gmail.com>
Eric Dumazet a écrit :
> Octavian Purdila a écrit :
>
>> IIRC, we first saw this issue in VoIP tests with up to 16000 sockets bound on a
>> certain port and IP addresses (each IP address is assigned to a particular
>> interface). We need this setup in order to emulate lots of VoIP users each
>> with a different IP address and possible a different L2 encapsulation.
>
> Interesting case indeed, is it SIP 5060 port or RTP ports ?
> (I want to know how many messages per second you want to receive)
>
> An rbtree with 16000 elements has 15 levels, its a lot, but OK
> for small trafic.
>
>> Now, as a general note I should say that our usecases can seem absurd if you
>> take them out of the network testing field :) but my _personal_ opinion is that
>> a better integration between our code base and upstream code may benefit both
>> upstream and us:
>>
>> - for us it gives the ability to stay close to upstream and get all of the new
>> shiny features without painful upgrades
>>
>> - for upstream, even if most systems don't run into these scalability issues
>> now, I see that some people are moving in that direction (see the recent PPP
>> problems); also, stressing Linux in that regard can only make the code better
>> - as long as the approach taken is clean and sound
>>
>> - we (or our customers) use a plethora of networking devices for testing so
>> exposing Linux early to those devices can only help catching issues earlier
>>
>> In short: expect more absurd patches from us :)
>
> I might cook something too :)
>
I tried the rbtree thing and suddenly realized it was not possible at all.
This is not possible because of all wildcards we have in UDP.
1) You can for example bind a socket s1 on address X, port p, dev eth0
2) You can bind socket s2 on adress X, port p (same values as previous socket), and dev eth1
As bindtodevice can be called after bind() itself, we can get several sockets with same
rbtree key (port, address), but rbtree doesnt allow duplicates.
I'll try hash based extent.
(Ie allocate an hash extent for given primary hash slot in case number of sockets
in this hash chain exceeds 10 or some threshold)
key hash would be function_of(port, address), duplicates allowed.
allocating 4096 bytes secondary hashes would divide per 1024 or 512 time of lookups, but keeping
rcu lookup might be difficult.
^ permalink raw reply
* RFC 5482
From: Anirban Sinha @ 2009-11-06 18:49 UTC (permalink / raw)
To: netdev; +Cc: davem
Hi:
I am just wondering if the linux TCP/IP stack supports the RFF 5482 (TCP user
timeout option)?
http://www.faqs.org/rfcs/rfc5482.html
A grep across the source and a search in the git repository does not yield any
useful information.
Also as a side question, i am wondering if it's possible to change/control the
TCP three-way handshake timeout (reception of the last SYN_ACK) on a
per-connection basis.
Thanks,
Ani
^ permalink raw reply
* [PATCH] net/fsl_pq_mdio: add module license GPL
From: Sebastian Andrzej Siewior @ 2009-11-06 18:50 UTC (permalink / raw)
To: Andy Fleming; +Cc: netdev
or it will taint the kernel and fail to load becuase
of_address_to_resource() is GPL only.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
drivers/net/fsl_pq_mdio.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/fsl_pq_mdio.c b/drivers/net/fsl_pq_mdio.c
index d167090..947a02b 100644
--- a/drivers/net/fsl_pq_mdio.c
+++ b/drivers/net/fsl_pq_mdio.c
@@ -426,3 +426,4 @@ void fsl_pq_mdio_exit(void)
of_unregister_platform_driver(&fsl_pq_mdio_driver);
}
module_exit(fsl_pq_mdio_exit);
+MODULE_LICENSE("GPL");
--
1.6.2.5
^ permalink raw reply related
* RFC: ethtool support for n-tuple filter programming
From: Peter P Waskiewicz Jr @ 2009-11-06 18:57 UTC (permalink / raw)
To: netdev@vger.kernel.org
All,
I'm looking to add support to ethtool that would allow programming of
full n-tuple filters into underlying devices. Currently, ixgbe has
support for these types of perfect match or mostly match (masked)
filters. I imagine other hardware exists that also has support for
this, so I'd like to make this interface usable for everyone.
Note that this is similar behavior in the iproute2 tools, but it's
different enough, in my opinion, to warrant being in ethtool. The
iproute2 tools (specifically tc) manipulate the qdiscs to add filters in
the kernel packet schedulers. This proposed solution is managing the
hardware in the underlying device, which iproute2 tools currently don't
touch. Hopefully this is obvious for those reviewing this proposal.
What I currently have as possible inputs to ethtool are:
- src/dst IP address: 32-bits each, 128-bits each for IPv6
- src/dst port: 16-bits each (TCP/UDP)
- VLAN tag: 15-bits
- L4 type: 8-bits (TCP/UDP/SCTP currently, can grow later)
- User specified field: currently 32-bits, can be anything a driver
wants to use
- Action: signed 16-bits (-1 indicates drop, any other value is the Rx
queue to steer the flow to)
Now all of these fields, except action, can also have a mask supplied to
them, but it's not mandatory.
An example ethtool command with this support could be:
# ethtool -F ethX dst-ip 0x0101a8c0 src-ip 0x0001a8c0 0x00ffffff
dst-port 0x1600 src-port 0x0000 0x0000 usr 0x8906 act 5
This will program a filter that will filter traffic coming from
192.168.1.0/24 to 192.168.1.1, port 22, from any source port, and will
place all those matches packets into Rx queue 5. It also specified a
user-defined field of 0x8906, which a driver can use at its own
discretion (or omit completely).
Then running the ethtool -f ethX command could dump all currently
programmed filters.
Any comments, thoughts, suggestions, or ideas are welcome.
Cheers,
-PJ Waskiewicz
^ permalink raw reply
* Re: [announce] new rt2800 drivers for Ralink wireless & project tree
From: John W. Linville @ 2009-11-06 18:59 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: Ivo van Doorn, Pavel Machek, Ingo Molnar, linux-wireless,
linux-kernel, netdev, Randy Dunlap, Luis Correia, Johannes Berg,
Jarek Poplawski, Pekka Enberg, David Miller
In-Reply-To: <200911061930.13069.bzolnier@gmail.com>
On Fri, Nov 06, 2009 at 07:30:13PM +0100, Bartlomiej Zolnierkiewicz wrote:
> On Friday 06 November 2009 18:58:56 Ivo van Doorn wrote:
> > the merged for those drivers after the asurance that it was only merged
> > to please the users so developers could focus on the rt2x00 version of
> > the driver.
>
> Could somebody please explain me (in the public or in the private) what is
> the reason behind whole affair about staging drivers because all the time
> I feel like I'm missing some important detail here.
I'm not 100% sure what you are asking, but I think you want to know
the basis for general objections from the people that hang-out on
linux-wireless and/or the rt2x00 team specifically?
I don't think anyone[1] has overwhelming objections to drivers in
staging for devices that have no other driver available. The main
objection is that drivers/staging steals users and (and often
developers) from the non-staging drivers, reducing the amount of
testing and development they get. In the effort to help some users,
drivers/staging effectively prolongs the amount of time those users
have to go without properly supported drivers. Much worse, none of
the wireless drivers in drivers/staging seem to have generated an
actual mergeable[2] wireless driver.
Further, the wireless drivers in drivers/staging are completely
isolated from the wireless infrastructure developments we've been
making over the past few years. The longer they live, the longer
wireless extensions will linger, the longer custom rfkill solutions
persist, and the longer we have multiple 802.11 stack implementations.
Finally, bug reports from drivers/staging are an unwelcome distraction
in bugzilla and the wireless mailing lists. Not only do those drivers
generate (often wierd) bugs, we get the privilege of looking like
jerks for refusing to deal with those reports even though we objected
to including the drivers in the first place.
It is little wonder to me why the linux-wireless folks oppose
drivers/staging...
Hth!
John
[1] Actually, I _know_ there are people who object to all of
drivers/staging, but few of those are actively and vigorously objecting
to it.
[2] A mergeable driver should respect and/or utilize existing wireless
infrastructure rather than duplicating it, as well as meeting general
standards of maintainability. Preferably it would have someone to
stand behind it as a maintainer as well.
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [BUILD-FAILURE] next-20091015 - vbus_enet driver breaks with allmodconfig
From: Gregory Haskins @ 2009-11-06 19:02 UTC (permalink / raw)
To: Gregory Haskins, Randy Dunlap
Cc: sfr, greg, Kamalesh Babulal, LKML, linux-next, netdev
In-Reply-To: <20091106093856.e9eac13e.randy.dunlap@oracle.com>
>>> On 11/6/2009 at 12:38 PM, in message
<20091106093856.e9eac13e.randy.dunlap@oracle.com>, Randy Dunlap
<randy.dunlap@oracle.com> wrote:
> On Thu, 15 Oct 2009 18:25:05 -0400 Gregory Haskins wrote:
>
>> Randy Dunlap wrote:
>> > On Thu, 15 Oct 2009 13:39:44 -0400 Gregory Haskins wrote:
>> >
>> >>
>> >> I am having difficulty reproducing the problem. When I look at the
>> >> Kconfig, I see that VBUS_ENET has a "select VBUS_PROXY" as I would
>> >> expect. Additionally, if I run allmodconfig I can confirm that I get
>> >> VBUS_ENET=m, VBUS_PROXY=y:
>> >
>> > Greg,
>> >
>> > Did you try to reproduce it with the ppc64 config file?
>> > allmodconfig on what arch?
>> >
>> > I think the problem is that arch/x86/Kconfig says:
>> >
>> > source "drivers/vbus/Kconfig"
>> >
>> > and that should actually be in drivers/Kconfig, so that it applies
>> > to ppc64 et al, not just x86.
>>
>> Ah, indeed. I only have/tried x86, and that is the issue. I will have
>> to fix this (and the create_irq() dependency you mention in the next mail).
>
> Hi Greg,
>
> I'm still getting
> pci-bridge.c:(.text+0x31b633): undefined reference to `create_irq'
>
> on today's linux-next-20091106.
> CONFIG_SMP=n
> CONFIG_X86_UP_APIC=n
>
> full config attached.
>
>
> ---
> ~Randy
Indeed. Looks like I need to be smarter about how the create_irq facility is used. I will fix this.
Thanks Randy,
-Greg
^ permalink raw reply
* Re: RFC: ethtool support for n-tuple filter programming
From: Caitlin Bestler @ 2009-11-06 19:12 UTC (permalink / raw)
To: Peter P Waskiewicz Jr; +Cc: netdev@vger.kernel.org
In-Reply-To: <1257533841.2610.12.camel@ppwaskie-mobl2>
The approach you are proposing assumes what type of packet filters
that L2 hardware could support.
Why not simply use existing filtering rules that overshoot the target,
such as netfilter, and ask the
device specific tool to indicate what set of these rules it can support?
On Fri, Nov 6, 2009 at 10:57 AM, Peter P Waskiewicz Jr
<peter.p.waskiewicz.jr@intel.com> wrote:
> All,
>
> I'm looking to add support to ethtool that would allow programming of
> full n-tuple filters into underlying devices. Currently, ixgbe has
> support for these types of perfect match or mostly match (masked)
> filters. I imagine other hardware exists that also has support for
> this, so I'd like to make this interface usable for everyone.
>
> Note that this is similar behavior in the iproute2 tools, but it's
> different enough, in my opinion, to warrant being in ethtool. The
> iproute2 tools (specifically tc) manipulate the qdiscs to add filters in
> the kernel packet schedulers. This proposed solution is managing the
> hardware in the underlying device, which iproute2 tools currently don't
> touch. Hopefully this is obvious for those reviewing this proposal.
>
> What I currently have as possible inputs to ethtool are:
>
> - src/dst IP address: 32-bits each, 128-bits each for IPv6
> - src/dst port: 16-bits each (TCP/UDP)
> - VLAN tag: 15-bits
> - L4 type: 8-bits (TCP/UDP/SCTP currently, can grow later)
> - User specified field: currently 32-bits, can be anything a driver
> wants to use
> - Action: signed 16-bits (-1 indicates drop, any other value is the Rx
> queue to steer the flow to)
>
> Now all of these fields, except action, can also have a mask supplied to
> them, but it's not mandatory.
>
> An example ethtool command with this support could be:
>
> # ethtool -F ethX dst-ip 0x0101a8c0 src-ip 0x0001a8c0 0x00ffffff
> dst-port 0x1600 src-port 0x0000 0x0000 usr 0x8906 act 5
>
> This will program a filter that will filter traffic coming from
> 192.168.1.0/24 to 192.168.1.1, port 22, from any source port, and will
> place all those matches packets into Rx queue 5. It also specified a
> user-defined field of 0x8906, which a driver can use at its own
> discretion (or omit completely).
>
> Then running the ethtool -f ethX command could dump all currently
> programmed filters.
>
> Any comments, thoughts, suggestions, or ideas are welcome.
>
> Cheers,
> -PJ Waskiewicz
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: RFC: ethtool support for n-tuple filter programming
From: Peter P Waskiewicz Jr @ 2009-11-06 19:31 UTC (permalink / raw)
To: Caitlin Bestler; +Cc: netdev@vger.kernel.org
In-Reply-To: <469958e00911061112y4d2d746cq93d90abfd6df7ec1@mail.gmail.com>
On Fri, 2009-11-06 at 11:12 -0800, Caitlin Bestler wrote:
> The approach you are proposing assumes what type of packet filters
> that L2 hardware could support.
>
> Why not simply use existing filtering rules that overshoot the target,
> such as netfilter, and ask the
> device specific tool to indicate what set of these rules it can support?
Are you proposing that netfilter is modified to pass the filters down to
the hardware if it supports it? netfilter doesn't steer flows though to
queues (or flow ID's in the kernel), plus that's putting HW-specific
capabilities into netfilter. I'm not sure we want to do that.
Please correct me if I'm wrong with interpreting your suggestion.
Thanks,
-PJ
>
>
> On Fri, Nov 6, 2009 at 10:57 AM, Peter P Waskiewicz Jr
> <peter.p.waskiewicz.jr@intel.com> wrote:
> > All,
> >
> > I'm looking to add support to ethtool that would allow programming of
> > full n-tuple filters into underlying devices. Currently, ixgbe has
> > support for these types of perfect match or mostly match (masked)
> > filters. I imagine other hardware exists that also has support for
> > this, so I'd like to make this interface usable for everyone.
> >
> > Note that this is similar behavior in the iproute2 tools, but it's
> > different enough, in my opinion, to warrant being in ethtool. The
> > iproute2 tools (specifically tc) manipulate the qdiscs to add filters in
> > the kernel packet schedulers. This proposed solution is managing the
> > hardware in the underlying device, which iproute2 tools currently don't
> > touch. Hopefully this is obvious for those reviewing this proposal.
> >
> > What I currently have as possible inputs to ethtool are:
> >
> > - src/dst IP address: 32-bits each, 128-bits each for IPv6
> > - src/dst port: 16-bits each (TCP/UDP)
> > - VLAN tag: 15-bits
> > - L4 type: 8-bits (TCP/UDP/SCTP currently, can grow later)
> > - User specified field: currently 32-bits, can be anything a driver
> > wants to use
> > - Action: signed 16-bits (-1 indicates drop, any other value is the Rx
> > queue to steer the flow to)
> >
> > Now all of these fields, except action, can also have a mask supplied to
> > them, but it's not mandatory.
> >
> > An example ethtool command with this support could be:
> >
> > # ethtool -F ethX dst-ip 0x0101a8c0 src-ip 0x0001a8c0 0x00ffffff
> > dst-port 0x1600 src-port 0x0000 0x0000 usr 0x8906 act 5
> >
> > This will program a filter that will filter traffic coming from
> > 192.168.1.0/24 to 192.168.1.1, port 22, from any source port, and will
> > place all those matches packets into Rx queue 5. It also specified a
> > user-defined field of 0x8906, which a driver can use at its own
> > discretion (or omit completely).
> >
> > Then running the ethtool -f ethX command could dump all currently
> > programmed filters.
> >
> > Any comments, thoughts, suggestions, or ideas are welcome.
> >
> > Cheers,
> > -PJ Waskiewicz
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe netdev" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* ipip: Fix handling of DF packets when pmtudisc is OFF
From: Herbert Xu @ 2009-11-06 20:37 UTC (permalink / raw)
To: David S. Miller, netdev
Hi Dave:
It appears that our tunnels are pretty much broken when pmtudisc
is turned off. It's never really showed up in the past as for
pure IP tunnels using pmtudisc is usually a better choice. But
now that we have raw Ethernet GRE tunnels that are incapable of
doing PMTU within the tunnel, people are running into these bugs
as they have to turn pmtudisc off.
I've got a number of patches that tries to address this but here
is a first to kick things off.
ipip: Fix handling of DF packets when pmtudisc is OFF
RFC 2003 requires the outer header to have DF set if DF is set
on the inner header, even when PMTU discovery is off for the
tunnel. Our implementation does exactly that.
For this to work properly the IPIP gateway also needs to engate
in PMTU when the inner DF bit is set. As otherwise the original
host would not be able to carry out its PMTU successfully since
part of the path is only visible to the gateway.
Unfortunately when the tunnel PMTU discovery setting is off, we
do not collect the necessary soft state, resulting in blackholes
when the original host tries to perform PMTU discovery.
This problem is not reproducible on the IPIP gateway itself as
the inner packet usually has skb->local_df set. This is not
correctly cleared (an unrelated bug) when the packet passes
through the tunnel, which allows fragmentation to occur. For
hosts behind the IPIP gateway it is readily visible with a simple
ping.
This patch fixes the problem by performing PMTU discovery for
all packets with the inner DF bit set, regardless of the PMTU
discovery setting on the tunnel itself.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
diff --git a/net/ipv4/ipip.c b/net/ipv4/ipip.c
index 08ccd34..ae40ed1 100644
--- a/net/ipv4/ipip.c
+++ b/net/ipv4/ipip.c
@@ -438,25 +438,27 @@ static netdev_tx_t ipip_tunnel_xmit(struct sk_buff *skb, struct net_device *dev)
goto tx_error;
}
- if (tiph->frag_off)
+ df |= old_iph->frag_off & htons(IP_DF);
+
+ if (df) {
mtu = dst_mtu(&rt->u.dst) - sizeof(struct iphdr);
- else
- mtu = skb_dst(skb) ? dst_mtu(skb_dst(skb)) : dev->mtu;
- if (mtu < 68) {
- stats->collisions++;
- ip_rt_put(rt);
- goto tx_error;
- }
- if (skb_dst(skb))
- skb_dst(skb)->ops->update_pmtu(skb_dst(skb), mtu);
+ if (mtu < 68) {
+ stats->collisions++;
+ ip_rt_put(rt);
+ goto tx_error;
+ }
- df |= (old_iph->frag_off&htons(IP_DF));
+ if (skb_dst(skb))
+ skb_dst(skb)->ops->update_pmtu(skb_dst(skb), mtu);
- if ((old_iph->frag_off&htons(IP_DF)) && mtu < ntohs(old_iph->tot_len)) {
- icmp_send(skb, ICMP_DEST_UNREACH, ICMP_FRAG_NEEDED, htonl(mtu));
- ip_rt_put(rt);
- goto tx_error;
+ if ((old_iph->frag_off & htons(IP_DF)) &&
+ mtu < ntohs(old_iph->tot_len)) {
+ icmp_send(skb, ICMP_DEST_UNREACH, ICMP_FRAG_NEEDED,
+ htonl(mtu));
+ ip_rt_put(rt);
+ goto tx_error;
+ }
}
if (tunnel->err_count > 0) {
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply related
* Re: [PATCH RFC] gianfar: Do not call skb recycling with disabled IRQs
From: Jon Loeliger @ 2009-11-06 20:38 UTC (permalink / raw)
To: avorontsov
Cc: Kumar Gopalpet-B05799, linuxppc-dev, Jason Wessel,
Fleming Andy-AFLEMING, David Miller, netdev, Lennert Buytenhek,
Stephen Hemminger
In-Reply-To: <20091105175316.GA27099@oksana.dev.rtsoft.ru>
>
> Here is the patch on top of the Linus' git tree, if you haven't
> already 'back-ported' the previous patch.
This back-ported patch has been running in my (2.6.31) kernel
for a couple days now without showing any sign of problem.
Maybe throw a
Tested-by: Jon Loeliger <jdl@jdl.com>
at it?
jdl
> diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
> index 5bf31f1..5dca99c 100644
> --- a/drivers/net/gianfar.c
> +++ b/drivers/net/gianfar.c
> @@ -1274,7 +1274,6 @@ static int gfar_start_xmit(struct sk_buff *skb, struct
> net_device *dev)
> u32 lstatus;
> int i;
> u32 bufaddr;
> - unsigned long flags;
> unsigned int nr_frags, length;
>
> base = priv->tx_bd_base;
> @@ -1298,14 +1297,11 @@ static int gfar_start_xmit(struct sk_buff *skb, struc
> t net_device *dev)
> /* total number of fragments in the SKB */
> nr_frags = skb_shinfo(skb)->nr_frags;
>
> - spin_lock_irqsave(&priv->txlock, flags);
> -
> /* check if there is space to queue this packet */
> if ((nr_frags+1) > priv->num_txbdfree) {
> /* no space, stop the queue */
> netif_stop_queue(dev);
> dev->stats.tx_fifo_errors++;
> - spin_unlock_irqrestore(&priv->txlock, flags);
> return NETDEV_TX_BUSY;
> }
>
> @@ -1403,9 +1399,6 @@ static int gfar_start_xmit(struct sk_buff *skb, struct
> net_device *dev)
> /* Tell the DMA to go go go */
> gfar_write(&priv->regs->tstat, TSTAT_CLEAR_THALT);
>
> - /* Unlock priv */
> - spin_unlock_irqrestore(&priv->txlock, flags);
> -
> return NETDEV_TX_OK;
> }
>
> @@ -1915,17 +1908,14 @@ static int gfar_poll(struct napi_struct *napi, int bu
> dget)
> struct net_device *dev = priv->ndev;
> int tx_cleaned = 0;
> int rx_cleaned = 0;
> - unsigned long flags;
>
> /* Clear IEVENT, so interrupts aren't called again
> * because of the packets that have already arrived */
> gfar_write(&priv->regs->ievent, IEVENT_RTX_MASK);
>
> - /* If we fail to get the lock, don't bother with the TX BDs */
> - if (spin_trylock_irqsave(&priv->txlock, flags)) {
> - tx_cleaned = gfar_clean_tx_ring(dev);
> - spin_unlock_irqrestore(&priv->txlock, flags);
> - }
> + netif_tx_lock_bh(priv->ndev);
> + tx_cleaned = gfar_clean_tx_ring(dev);
> + netif_tx_unlock_bh(priv->ndev);
>
> rx_cleaned = gfar_clean_rx_ring(dev, budget);
>
>
> --
> Anton Vorontsov
> email: cbouatmailru@gmail.com
> irc://irc.freenode.net/bd2
^ permalink raw reply
* pull request: wireless-2.6 2009-11-06
From: John W. Linville @ 2009-11-06 20:40 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Dave,
Three more intended for 2.6.32, two oops fixes and a revert of a patch
that traded one bug for another. One of the oops fixes reorders some
cancel_delayed_work_sync calls and the other does some bit testing to
avoid scheduling work after a device has been removed.
Please let me know if there are problems!
Thanks,
John
---
Individual patches are available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/
---
The following changes since commit bcfe3c2046fc4f16544f2b127f1b159dd1fcad8b:
David S. Miller (1):
Merge branch 'master' of git://git.kernel.org/.../linville/wireless-2.6
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git master
John W. Linville (1):
Revert "ipw2200: fix oops on missing firmware"
Larry Finger (1):
rtl8187: Fix kernel oops when device is removed when LEDS enabled
Sean Cross (1):
rt2x00: Don't queue ieee80211 work after USB removal
drivers/net/wireless/ipw2x00/ipw2100.c | 5 +----
drivers/net/wireless/ipw2x00/ipw2200.c | 2 --
drivers/net/wireless/ipw2x00/libipw.h | 1 -
drivers/net/wireless/ipw2x00/libipw_module.c | 14 +++++---------
drivers/net/wireless/rt2x00/rt2x00dev.c | 4 ++--
drivers/net/wireless/rt2x00/rt2x00link.c | 11 +++++++----
drivers/net/wireless/rt2x00/rt2x00usb.c | 9 ++++++++-
drivers/net/wireless/rtl818x/rtl8187_leds.c | 4 ++--
8 files changed, 25 insertions(+), 25 deletions(-)
diff --git a/drivers/net/wireless/ipw2x00/ipw2100.c b/drivers/net/wireless/ipw2x00/ipw2100.c
index a741d37..240cff1 100644
--- a/drivers/net/wireless/ipw2x00/ipw2100.c
+++ b/drivers/net/wireless/ipw2x00/ipw2100.c
@@ -6325,10 +6325,8 @@ static int ipw2100_pci_init_one(struct pci_dev *pci_dev,
fail:
if (dev) {
- if (registered) {
- unregister_ieee80211(priv->ieee);
+ if (registered)
unregister_netdev(dev);
- }
ipw2100_hw_stop_adapter(priv);
@@ -6385,7 +6383,6 @@ static void __devexit ipw2100_pci_remove_one(struct pci_dev *pci_dev)
/* Unregister the device first - this results in close()
* being called if the device is open. If we free storage
* first, then close() will crash. */
- unregister_ieee80211(priv->ieee);
unregister_netdev(dev);
/* ipw2100_down will ensure that there is no more pending work
diff --git a/drivers/net/wireless/ipw2x00/ipw2200.c b/drivers/net/wireless/ipw2x00/ipw2200.c
index 04341a2..8d58e6e 100644
--- a/drivers/net/wireless/ipw2x00/ipw2200.c
+++ b/drivers/net/wireless/ipw2x00/ipw2200.c
@@ -11821,7 +11821,6 @@ static int __devinit ipw_pci_probe(struct pci_dev *pdev,
if (err) {
IPW_ERROR("Failed to register promiscuous network "
"device (error %d).\n", err);
- unregister_ieee80211(priv->ieee);
unregister_netdev(priv->net_dev);
goto out_remove_sysfs;
}
@@ -11872,7 +11871,6 @@ static void __devexit ipw_pci_remove(struct pci_dev *pdev)
mutex_unlock(&priv->mutex);
- unregister_ieee80211(priv->ieee);
unregister_netdev(priv->net_dev);
if (priv->rxq) {
diff --git a/drivers/net/wireless/ipw2x00/libipw.h b/drivers/net/wireless/ipw2x00/libipw.h
index f42ade6..bf45391 100644
--- a/drivers/net/wireless/ipw2x00/libipw.h
+++ b/drivers/net/wireless/ipw2x00/libipw.h
@@ -1020,7 +1020,6 @@ static inline int libipw_is_cck_rate(u8 rate)
/* ieee80211.c */
extern void free_ieee80211(struct net_device *dev, int monitor);
extern struct net_device *alloc_ieee80211(int sizeof_priv, int monitor);
-extern void unregister_ieee80211(struct libipw_device *ieee);
extern int libipw_change_mtu(struct net_device *dev, int new_mtu);
extern void libipw_networks_age(struct libipw_device *ieee,
diff --git a/drivers/net/wireless/ipw2x00/libipw_module.c b/drivers/net/wireless/ipw2x00/libipw_module.c
index be5b809..a0e9f6a 100644
--- a/drivers/net/wireless/ipw2x00/libipw_module.c
+++ b/drivers/net/wireless/ipw2x00/libipw_module.c
@@ -235,19 +235,16 @@ void free_ieee80211(struct net_device *dev, int monitor)
libipw_networks_free(ieee);
/* free cfg80211 resources */
- if (!monitor)
+ if (!monitor) {
+ wiphy_unregister(ieee->wdev.wiphy);
+ kfree(ieee->a_band.channels);
+ kfree(ieee->bg_band.channels);
wiphy_free(ieee->wdev.wiphy);
+ }
free_netdev(dev);
}
-void unregister_ieee80211(struct libipw_device *ieee)
-{
- wiphy_unregister(ieee->wdev.wiphy);
- kfree(ieee->a_band.channels);
- kfree(ieee->bg_band.channels);
-}
-
#ifdef CONFIG_LIBIPW_DEBUG
static int debug = 0;
@@ -333,4 +330,3 @@ module_init(libipw_init);
EXPORT_SYMBOL(alloc_ieee80211);
EXPORT_SYMBOL(free_ieee80211);
-EXPORT_SYMBOL(unregister_ieee80211);
diff --git a/drivers/net/wireless/rt2x00/rt2x00dev.c b/drivers/net/wireless/rt2x00/rt2x00dev.c
index 71761b3..73bbec5 100644
--- a/drivers/net/wireless/rt2x00/rt2x00dev.c
+++ b/drivers/net/wireless/rt2x00/rt2x00dev.c
@@ -815,6 +815,8 @@ int rt2x00lib_probe_dev(struct rt2x00_dev *rt2x00dev)
mutex_init(&rt2x00dev->csr_mutex);
+ set_bit(DEVICE_STATE_PRESENT, &rt2x00dev->flags);
+
/*
* Make room for rt2x00_intf inside the per-interface
* structure ieee80211_vif.
@@ -871,8 +873,6 @@ int rt2x00lib_probe_dev(struct rt2x00_dev *rt2x00dev)
rt2x00leds_register(rt2x00dev);
rt2x00debug_register(rt2x00dev);
- set_bit(DEVICE_STATE_PRESENT, &rt2x00dev->flags);
-
return 0;
exit:
diff --git a/drivers/net/wireless/rt2x00/rt2x00link.c b/drivers/net/wireless/rt2x00/rt2x00link.c
index c64db0b..c708d0b 100644
--- a/drivers/net/wireless/rt2x00/rt2x00link.c
+++ b/drivers/net/wireless/rt2x00/rt2x00link.c
@@ -362,8 +362,9 @@ void rt2x00link_start_tuner(struct rt2x00_dev *rt2x00dev)
rt2x00link_reset_tuner(rt2x00dev, false);
- ieee80211_queue_delayed_work(rt2x00dev->hw,
- &link->work, LINK_TUNE_INTERVAL);
+ if (test_bit(DEVICE_STATE_PRESENT, &rt2x00dev->flags))
+ ieee80211_queue_delayed_work(rt2x00dev->hw,
+ &link->work, LINK_TUNE_INTERVAL);
}
void rt2x00link_stop_tuner(struct rt2x00_dev *rt2x00dev)
@@ -469,8 +470,10 @@ static void rt2x00link_tuner(struct work_struct *work)
* Increase tuner counter, and reschedule the next link tuner run.
*/
link->count++;
- ieee80211_queue_delayed_work(rt2x00dev->hw,
- &link->work, LINK_TUNE_INTERVAL);
+
+ if (test_bit(DEVICE_STATE_PRESENT, &rt2x00dev->flags))
+ ieee80211_queue_delayed_work(rt2x00dev->hw,
+ &link->work, LINK_TUNE_INTERVAL);
}
void rt2x00link_register(struct rt2x00_dev *rt2x00dev)
diff --git a/drivers/net/wireless/rt2x00/rt2x00usb.c b/drivers/net/wireless/rt2x00/rt2x00usb.c
index 5015448..f02b48a 100644
--- a/drivers/net/wireless/rt2x00/rt2x00usb.c
+++ b/drivers/net/wireless/rt2x00/rt2x00usb.c
@@ -47,6 +47,8 @@ int rt2x00usb_vendor_request(struct rt2x00_dev *rt2x00dev,
(requesttype == USB_VENDOR_REQUEST_IN) ?
usb_rcvctrlpipe(usb_dev, 0) : usb_sndctrlpipe(usb_dev, 0);
+ if (!test_bit(DEVICE_STATE_PRESENT, &rt2x00dev->flags))
+ return -ENODEV;
for (i = 0; i < REGISTER_BUSY_COUNT; i++) {
status = usb_control_msg(usb_dev, pipe, request, requesttype,
@@ -60,8 +62,10 @@ int rt2x00usb_vendor_request(struct rt2x00_dev *rt2x00dev,
* -ENODEV: Device has disappeared, no point continuing.
* All other errors: Try again.
*/
- else if (status == -ENODEV)
+ else if (status == -ENODEV) {
+ clear_bit(DEVICE_STATE_PRESENT, &rt2x00dev->flags);
break;
+ }
}
ERROR(rt2x00dev,
@@ -161,6 +165,9 @@ int rt2x00usb_regbusy_read(struct rt2x00_dev *rt2x00dev,
{
unsigned int i;
+ if (!test_bit(DEVICE_STATE_PRESENT, &rt2x00dev->flags))
+ return -ENODEV;
+
for (i = 0; i < REGISTER_BUSY_COUNT; i++) {
rt2x00usb_register_read_lock(rt2x00dev, offset, reg);
if (!rt2x00_get_field32(*reg, field))
diff --git a/drivers/net/wireless/rtl818x/rtl8187_leds.c b/drivers/net/wireless/rtl818x/rtl8187_leds.c
index a1c670f..cf8a4a4 100644
--- a/drivers/net/wireless/rtl818x/rtl8187_leds.c
+++ b/drivers/net/wireless/rtl818x/rtl8187_leds.c
@@ -210,10 +210,10 @@ void rtl8187_leds_exit(struct ieee80211_hw *dev)
/* turn the LED off before exiting */
ieee80211_queue_delayed_work(dev, &priv->led_off, 0);
- cancel_delayed_work_sync(&priv->led_off);
- cancel_delayed_work_sync(&priv->led_on);
rtl8187_unregister_led(&priv->led_rx);
rtl8187_unregister_led(&priv->led_tx);
+ cancel_delayed_work_sync(&priv->led_off);
+ cancel_delayed_work_sync(&priv->led_on);
}
#endif /* def CONFIG_RTL8187_LED */
--
John W. Linville Someday the world will need a hero, and you
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org might be all we have. Be ready.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: PATCH: Network Device Naming mechanism and policy
From: Domsch, Matt @ 2009-11-06 22:05 UTC (permalink / raw)
To: K, Narendra
Cc: Bryan Kadzban, dannf, bhutchings, netdev, linux-hotplug,
Hargrave, Jordan, Rose, Charles, Shandilya, Sandeep K
In-Reply-To: <EDA0A4495861324DA2618B4C45DCB3EE5896D2@blrx3m08.blr.amer.dell.com>
On Wed, Nov 04, 2009 at 08:23:38AM -0600, K, Narendra wrote:
> Similarly, export an attribute named "smbios_name" to sysfs, i.e
> "/sys/class/net/eth0/smbios_name". "Cat /sys/class/net/eth0/smbios_name"
> would show "Embedded_NIC_1[23..]" and this can be used by udev in
> 70-persistent-net.rules as
>
> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
> ATTR{smbios_name}=="Embedded_NIC_1", ATTR{type}=="1", KERNEL=="eth*",
> NAME="eth0".
>
> I suppose this would not need any changes to the udev code and existing
> udev infrastructure can be used as udev is capable handling
> ATTR{something}.
>
> This would also ensure that whichever device is "Embedded_NIC_1" as per
> the BIOS, will also be "eth0" in the os.
We can grab the smbios_name value using biosdevname in a PROGRAM= part
of the udev rule. But it doesn't actually solve the problem. We
haven't changed the network device naming scheme from "eth%d" to
something else. Therefore, by having rules which simply try to
re-order names within that scheme, when they're being enumerated in
parallel and racing, we get collisions. Take for example, this which
tries to rename the 4 onboard NICs in a particular order, in the
absence of any other rules:
PROGRAM="/sbin/biosdevname --policy=smbios_names -i %k", RESULT=="Embedded NIC 1", NAME="eth0"
PROGRAM="/sbin/biosdevname --policy=smbios_names -i %k", RESULT=="Embedded NIC 2", NAME="eth1"
PROGRAM="/sbin/biosdevname --policy=smbios_names -i %k", RESULT=="Embedded NIC 3", NAME="eth2"
PROGRAM="/sbin/biosdevname --policy=smbios_names -i %k", RESULT=="Embedded NIC 4", NAME="eth3"
I wind up with instead this in ifconfig -a:
eth0 00:1B:21:42:66:30
eth1 00:1B:21:42:66:31
eth2 00:22:19:59:8E:5A
eth2_rename 00:22:19:59:8E:56
eth3 00:22:19:59:8E:5C
eth3_rename 00:22:19:59:8E:58
When what I would have expected would have been:
eth0 00:22:19:59:8E:56
eth1 00:22:19:59:8E:58
eth2 00:22:19:59:8E:5A
eth3 00:22:19:59:8E:5C
eth4 00:1B:21:42:66:30
eth5 00:1B:21:42:66:31
I can't use eth%d as the scheme - that's the kernel's scheme. I have
to switch the scheme to something else.
--
Matt Domsch
Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux
^ permalink raw reply
* Re: PATCH: Network Device Naming mechanism and policy
From: Matt Domsch @ 2009-11-06 22:06 UTC (permalink / raw)
To: Narendra_K, bryan, dannf, bhutchings, netdev, linux-hotplug,
Jordan_Hargrave, Charles_Ros
In-Reply-To: <20091106084921.GA16700@bongo.bofh.it>
On Fri, Nov 06, 2009 at 09:49:21AM +0100, Marco d'Itri wrote:
> On Nov 04, Narendra_K@Dell.com wrote:
>
> > SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
> > ATTR{smbios_name}=="Embedded_NIC_1", ATTR{type}=="1", KERNEL=="eth*",
> > NAME="eth0".
> As a distribution developer I highly value solutions like this which do
> not require patching every application which deals with interface names
> and then teaching users about aliases which only work in some places and
> are unknown to the kernel.
Fair enough - but would you object if we changed the naming scheme
from eth%d to something else?
--
Matt Domsch
Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux
^ permalink raw reply
* Re: wanPMC-CxT1E1
From: Greg KH @ 2009-11-06 22:05 UTC (permalink / raw)
To: Bob Beers; +Cc: netdev, Krzysztof Halasa
In-Reply-To: <4f6ba3b0911060725i574bbe63n10f169ed2641bf84@mail.gmail.com>
On Fri, Nov 06, 2009 at 10:25:36AM -0500, Bob Beers wrote:
> Hi Greg,
>
> I don't mean to seem impatient, but is cxt1e1 in staging yet?
Sorry, no, been swamped with -stable updates. I should get to it later
today, I'll email you then if I have any problems. If not, you'll get
an email saying the patch was added to the tree.
thanks,
greg k-h
^ permalink raw reply
* Re: PATCH: Network Device Naming mechanism and policy
From: Marco d'Itri @ 2009-11-06 22:35 UTC (permalink / raw)
To: Matt Domsch
Cc: Narendra_K, bryan, dannf, bhutchings, netdev, linux-hotplug,
Jordan_Hargrave, Charles_Rose, Sandeep_K_Shandilya
In-Reply-To: <20091106220637.GB15533@mock.linuxdev.us.dell.com>
[-- Attachment #1: Type: text/plain, Size: 1284 bytes --]
On Nov 06, Matt Domsch <Matt_Domsch@Dell.com> wrote:
> > As a distribution developer I highly value solutions like this which do
> > not require patching every application which deals with interface names
> > and then teaching users about aliases which only work in some places and
> > are unknown to the kernel.
> Fair enough - but would you object if we changed the naming scheme
> from eth%d to something else?
I suppose that this would depend on what else. :-)
Since you want radical changes I recommend that you design the new
persistent naming infrastructure in a way that will allow root to choose
to use the classic naming scheme, or many users will scream a lot and at
least some distributions will do it anyway.
I also expect that providing choice at the beginning of development may
lead to more acceptance later if and when the new scheme will have
proved itself to be superior (at least in some situations).
You have tought about this for a long time and if so far you have not
found a solution which is widely considered superior then I doubt that
one will appear soon. Providing your favourite naming scheme as an
optional add on will immediately benefit those who like it and greatly
reduce opposition from those who do not.
--
ciao,
Marco
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* [patch 03/16] net: Replace old style lock initializer
From: Thomas Gleixner @ 2009-11-06 22:41 UTC (permalink / raw)
To: LKML; +Cc: Ingo Molnar, Peter Zijlstra, netdev, David S. Miller
In-Reply-To: <20091106223547.784916750@linutronix.de>
[-- Attachment #1: net-replace-old-style-lock-init.patch --]
[-- Type: text/plain, Size: 747 bytes --]
SPIN_LOCK_UNLOCKED is deprecated. Use DEFINE_SPINLOCK instead.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: netdev@vger.kernel.org
Cc: David S. Miller <davem@davemloft.net>
---
net/core/drop_monitor.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6/net/core/drop_monitor.c
===================================================================
--- linux-2.6.orig/net/core/drop_monitor.c
+++ linux-2.6/net/core/drop_monitor.c
@@ -41,7 +41,7 @@ static void send_dm_alert(struct work_st
* netlink alerts
*/
static int trace_state = TRACE_OFF;
-static spinlock_t trace_state_lock = SPIN_LOCK_UNLOCKED;
+static DEFINE_SPINLOCK(trace_state_lock);
struct per_cpu_dm_data {
struct work_struct dm_alert_work;
^ permalink raw reply
* [net-2.6 PATCH 1/3] ixgbe: Fix gso_max_size for 82599 when DCB is enabled
From: Jeff Kirsher @ 2009-11-06 22:55 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, Yi Zou, Peter P Waskiewicz Jr, Jeff Kirsher
From: Yi Zou <yi.zou@intel.com>
The 32k gso_max_size when DCB is enabled is for 82598 only, not for 82599.
Signed-off-by: Yi Zou <yi.zou@intel.com>
Acked-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ixgbe/ixgbe_main.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_main.c b/drivers/net/ixgbe/ixgbe_main.c
index cbb143c..26fc1df 100644
--- a/drivers/net/ixgbe/ixgbe_main.c
+++ b/drivers/net/ixgbe/ixgbe_main.c
@@ -2471,7 +2471,10 @@ static void ixgbe_configure(struct ixgbe_adapter *adapter)
ixgbe_restore_vlan(adapter);
#ifdef CONFIG_IXGBE_DCB
if (adapter->flags & IXGBE_FLAG_DCB_ENABLED) {
- netif_set_gso_max_size(netdev, 32768);
+ if (hw->mac.type == ixgbe_mac_82598EB)
+ netif_set_gso_max_size(netdev, 32768);
+ else
+ netif_set_gso_max_size(netdev, 65536);
ixgbe_configure_dcb(adapter);
} else {
netif_set_gso_max_size(netdev, 65536);
^ permalink raw reply related
* [net-2.6 PATCH 2/3] ixgbe: Fix checking TFCS register for TXOFF status when DCB is enabled
From: Jeff Kirsher @ 2009-11-06 22:56 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, Yi Zou, Peter P Waskiewicz Jr, Jeff Kirsher
In-Reply-To: <20091106225526.28063.83720.stgit@localhost.localdomain>
From: Yi Zou <yi.zou@intel.com>
When DCB is enabled, the ixgbe_check_tx_hang() should check the corresponding
TC's TXOFF in TFCS based on the TC that the tx ring belongs to. Adds a
function to map from the tx_ring hw reg_idx to the correspodning TC and read
TFCS accordingly.
Signed-off-by: Yi Zou <yi.zou@intel.com>
Acked-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ixgbe/ixgbe_main.c | 52 +++++++++++++++++++++++++++++++++++++++-
1 files changed, 51 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_main.c b/drivers/net/ixgbe/ixgbe_main.c
index 26fc1df..2d0f618 100644
--- a/drivers/net/ixgbe/ixgbe_main.c
+++ b/drivers/net/ixgbe/ixgbe_main.c
@@ -226,6 +226,56 @@ static void ixgbe_unmap_and_free_tx_resource(struct ixgbe_adapter *adapter,
/* tx_buffer_info must be completely set up in the transmit path */
}
+/**
+ * ixgbe_tx_is_paused - check if the tx ring is paused
+ * @adapter: the ixgbe adapter
+ * @tx_ring: the corresponding tx_ring
+ *
+ * If not in DCB mode, checks TFCS.TXOFF, otherwise, find out the
+ * corresponding TC of this tx_ring when checking TFCS.
+ *
+ * Returns : true if paused
+ */
+static inline bool ixgbe_tx_is_paused(struct ixgbe_adapter *adapter,
+ struct ixgbe_ring *tx_ring)
+{
+ int tc;
+ u32 txoff = IXGBE_TFCS_TXOFF;
+
+#ifdef CONFIG_IXGBE_DCB
+ if (adapter->flags & IXGBE_FLAG_DCB_ENABLED) {
+ int reg_idx = tx_ring->reg_idx;
+ int dcb_i = adapter->ring_feature[RING_F_DCB].indices;
+
+ if (adapter->hw.mac.type == ixgbe_mac_82598EB) {
+ tc = reg_idx >> 2;
+ txoff = IXGBE_TFCS_TXOFF0;
+ } else if (adapter->hw.mac.type == ixgbe_mac_82599EB) {
+ tc = 0;
+ txoff = IXGBE_TFCS_TXOFF;
+ if (dcb_i == 8) {
+ /* TC0, TC1 */
+ tc = reg_idx >> 5;
+ if (tc == 2) /* TC2, TC3 */
+ tc += (reg_idx - 64) >> 4;
+ else if (tc == 3) /* TC4, TC5, TC6, TC7 */
+ tc += 1 + ((reg_idx - 96) >> 3);
+ } else if (dcb_i == 4) {
+ /* TC0, TC1 */
+ tc = reg_idx >> 6;
+ if (tc == 1) {
+ tc += (reg_idx - 64) >> 5;
+ if (tc == 2) /* TC2, TC3 */
+ tc += (reg_idx - 96) >> 4;
+ }
+ }
+ }
+ txoff <<= tc;
+ }
+#endif
+ return IXGBE_READ_REG(&adapter->hw, IXGBE_TFCS) & txoff;
+}
+
static inline bool ixgbe_check_tx_hang(struct ixgbe_adapter *adapter,
struct ixgbe_ring *tx_ring,
unsigned int eop)
@@ -237,7 +287,7 @@ static inline bool ixgbe_check_tx_hang(struct ixgbe_adapter *adapter,
adapter->detect_tx_hung = false;
if (tx_ring->tx_buffer_info[eop].time_stamp &&
time_after(jiffies, tx_ring->tx_buffer_info[eop].time_stamp + HZ) &&
- !(IXGBE_READ_REG(&adapter->hw, IXGBE_TFCS) & IXGBE_TFCS_TXOFF)) {
+ !ixgbe_tx_is_paused(adapter, tx_ring)) {
/* detected Tx unit hang */
union ixgbe_adv_tx_desc *tx_desc;
tx_desc = IXGBE_TX_DESC_ADV(*tx_ring, eop);
^ permalink raw reply related
* [net-2.6 PATCH 3/3] ixgbe: fix traffic hangs on Tx with ioatdma loaded
From: Jeff Kirsher @ 2009-11-06 22:56 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, Don Skidmore, Peter P Waskiewicz Jr, Jeff Kirsher
In-Reply-To: <20091106225526.28063.83720.stgit@localhost.localdomain>
From: Don Skidmore <donald.c.skidmore@intel.com>
When ioatdma was loaded we we were unable to transmit traffic. We weren't
using the correct registers in ixgbe_update_tx_dca for 82599 systems.
Likewise in ixgbe_configure_tx() we weren't disabling the arbiter before
modifying MTQC.
Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com>
Acked-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ixgbe/ixgbe_main.c | 27 +++++++++++++++++++++++----
1 files changed, 23 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_main.c b/drivers/net/ixgbe/ixgbe_main.c
index 2d0f618..5bd9e6b 100644
--- a/drivers/net/ixgbe/ixgbe_main.c
+++ b/drivers/net/ixgbe/ixgbe_main.c
@@ -44,6 +44,7 @@
#include "ixgbe.h"
#include "ixgbe_common.h"
+#include "ixgbe_dcb_82599.h"
char ixgbe_driver_name[] = "ixgbe";
static const char ixgbe_driver_string[] =
@@ -462,19 +463,23 @@ static void ixgbe_update_tx_dca(struct ixgbe_adapter *adapter,
u32 txctrl;
int cpu = get_cpu();
int q = tx_ring - adapter->tx_ring;
+ struct ixgbe_hw *hw = &adapter->hw;
if (tx_ring->cpu != cpu) {
- txctrl = IXGBE_READ_REG(&adapter->hw, IXGBE_DCA_TXCTRL(q));
if (adapter->hw.mac.type == ixgbe_mac_82598EB) {
+ txctrl = IXGBE_READ_REG(hw, IXGBE_DCA_TXCTRL(q));
txctrl &= ~IXGBE_DCA_TXCTRL_CPUID_MASK;
txctrl |= dca3_get_tag(&adapter->pdev->dev, cpu);
+ txctrl |= IXGBE_DCA_TXCTRL_DESC_DCA_EN;
+ IXGBE_WRITE_REG(hw, IXGBE_DCA_TXCTRL(q), txctrl);
} else if (adapter->hw.mac.type == ixgbe_mac_82599EB) {
+ txctrl = IXGBE_READ_REG(hw, IXGBE_DCA_TXCTRL_82599(q));
txctrl &= ~IXGBE_DCA_TXCTRL_CPUID_MASK_82599;
txctrl |= (dca3_get_tag(&adapter->pdev->dev, cpu) <<
- IXGBE_DCA_TXCTRL_CPUID_SHIFT_82599);
+ IXGBE_DCA_TXCTRL_CPUID_SHIFT_82599);
+ txctrl |= IXGBE_DCA_TXCTRL_DESC_DCA_EN;
+ IXGBE_WRITE_REG(hw, IXGBE_DCA_TXCTRL_82599(q), txctrl);
}
- txctrl |= IXGBE_DCA_TXCTRL_DESC_DCA_EN;
- IXGBE_WRITE_REG(&adapter->hw, IXGBE_DCA_TXCTRL(q), txctrl);
tx_ring->cpu = cpu;
}
put_cpu();
@@ -1963,11 +1968,25 @@ static void ixgbe_configure_tx(struct ixgbe_adapter *adapter)
break;
}
}
+
if (hw->mac.type == ixgbe_mac_82599EB) {
+ u32 rttdcs;
+
+ /* disable the arbiter while setting MTQC */
+ rttdcs = IXGBE_READ_REG(hw, IXGBE_RTTDCS);
+ rttdcs |= IXGBE_RTTDCS_ARBDIS;
+ IXGBE_WRITE_REG(hw, IXGBE_RTTDCS, rttdcs);
+
/* We enable 8 traffic classes, DCB only */
if (adapter->flags & IXGBE_FLAG_DCB_ENABLED)
IXGBE_WRITE_REG(hw, IXGBE_MTQC, (IXGBE_MTQC_RT_ENA |
IXGBE_MTQC_8TC_8TQ));
+ else
+ IXGBE_WRITE_REG(hw, IXGBE_MTQC, IXGBE_MTQC_64Q_1PB);
+
+ /* re-eable the arbiter */
+ rttdcs &= ~IXGBE_RTTDCS_ARBDIS;
+ IXGBE_WRITE_REG(hw, IXGBE_RTTDCS, rttdcs);
}
}
^ permalink raw reply related
* Re: RFC 5482
From: Anirban Sinha @ 2009-11-06 23:08 UTC (permalink / raw)
To: netdev; +Cc: davem
In-Reply-To: <Pine.LNX.4.64.0911061041540.30985@sleet.zeugmasystems.local>
oops, sorry. Typo.
> Also as a side question, i am wondering if it's possible to change/control the
> TCP three-way handshake timeout (reception of the last SYN_ACK) on a
> per-connection basis.
It will be the timeout on the server side between SYN-ACK and the last ACK
from the peer.
^ permalink raw reply
* Re: PATCH: Network Device Naming mechanism and policy
From: dann frazier @ 2009-11-06 23:17 UTC (permalink / raw)
To: Matt Domsch, Narendra_K, bryan, bhutchings, netdev, linux-hotplug,
Jordan_Hargrave
In-Reply-To: <20091106223524.GA27121@bongo.bofh.it>
On Fri, Nov 06, 2009 at 11:35:24PM +0100, Marco d'Itri wrote:
> On Nov 06, Matt Domsch <Matt_Domsch@Dell.com> wrote:
>
> > > As a distribution developer I highly value solutions like this which do
> > > not require patching every application which deals with interface names
> > > and then teaching users about aliases which only work in some places and
> > > are unknown to the kernel.
> > Fair enough - but would you object if we changed the naming scheme
> > from eth%d to something else?
> I suppose that this would depend on what else. :-)
> Since you want radical changes I recommend that you design the new
> persistent naming infrastructure in a way that will allow root to choose
> to use the classic naming scheme, or many users will scream a lot and at
> least some distributions will do it anyway.
> I also expect that providing choice at the beginning of development may
> lead to more acceptance later if and when the new scheme will have
> proved itself to be superior (at least in some situations).
> You have tought about this for a long time and if so far you have not
> found a solution which is widely considered superior then I doubt that
> one will appear soon. Providing your favourite naming scheme as an
> optional add on will immediately benefit those who like it and greatly
> reduce opposition from those who do not.
This seems to me like a good installer feature - give the user an
option to enter a name for an interface, with the default option
to use the eth* names. To illustrate by example, I imagine an
installer flow that looks like this:
[Do Hardware Discovery]
[Automatically reorder kernel names for reasonable defaults;
eth0-eth{n-1} map to n onboard nics]
Sample user interface for network configuration:
------------Choose an interface to configure --------------
| Multiple unconfigured interfaces detected. |
| Select an interface to configure by: |
| 1. Kernel name (eth0, eth1, etc) |
| 2. Mac Address |
| 3. Chassis name |
| 4. PCI Slot |
-----------------------------------------------------------
----Choose an interface to configure (by chassis name)-----
| 1. LOM0 |
| 2. LOM1 |
| 3. Undefined |
| 4. Undefined |
-----------------------------------------------------------
----------------Name interface - (chassis name LOM0)-------
| Name to use for this interface [eth0]: __mynet0_ |
-----------------------------------------------------------
-----------------------------------------------------------
| Configure interface - mynet0 |
| 1. DHCP |
| 2. Static |
| ... |
-----------------------------------------------------------
[Generate udev rules that bind the user-selected name to
the user-selected attribute]
^ permalink raw reply
* hisax: remove bad udelay call to fix build error on ARM
From: Martin Michlmayr @ 2009-11-07 0:52 UTC (permalink / raw)
To: Karsten Keil, Tilman Schmidt, David Miller; +Cc: netdev
The hisax ISDN driver fails to build on ARM with CONFIG_HISAX_ELSA:
| drivers/built-in.o: In function `modem_set_dial':
| drivers/isdn/hisax/elsa_ser.c:535: undefined reference to `__bad_udelay'
| drivers/isdn/hisax/elsa_ser.c:544: undefined reference to `__bad_udelay'
| drivers/built-in.o: In function `modem_set_init':
| drivers/isdn/hisax/elsa_ser.c:486: undefined reference to `__bad_udelay'
| [...]
According to the comment in arch/arm/include/asm/delay.h, __bad_udelay
is specifically designed on ARM to produce a build failure when udelay
is called with a value > 2000.
Signed-off-by: Martin Michlmayr <tbm@cyrius.com>
diff --git a/drivers/isdn/hisax/elsa_ser.c b/drivers/isdn/hisax/elsa_ser.c
index f181db4..1657bba 100644
--- a/drivers/isdn/hisax/elsa_ser.c
+++ b/drivers/isdn/hisax/elsa_ser.c
@@ -477,62 +477,62 @@ static void
modem_set_init(struct IsdnCardState *cs) {
int timeout;
-#define RCV_DELAY 20000
+#define RCV_DELAY 20
modem_write_cmd(cs, MInit_1, strlen(MInit_1));
timeout = 1000;
while(timeout-- && cs->hw.elsa.transcnt)
udelay(1000);
debugl1(cs, "msi tout=%d", timeout);
- udelay(RCV_DELAY);
+ mdelay(RCV_DELAY);
modem_write_cmd(cs, MInit_2, strlen(MInit_2));
timeout = 1000;
while(timeout-- && cs->hw.elsa.transcnt)
udelay(1000);
debugl1(cs, "msi tout=%d", timeout);
- udelay(RCV_DELAY);
+ mdelay(RCV_DELAY);
modem_write_cmd(cs, MInit_3, strlen(MInit_3));
timeout = 1000;
while(timeout-- && cs->hw.elsa.transcnt)
udelay(1000);
debugl1(cs, "msi tout=%d", timeout);
- udelay(RCV_DELAY);
+ mdelay(RCV_DELAY);
modem_write_cmd(cs, MInit_4, strlen(MInit_4));
timeout = 1000;
while(timeout-- && cs->hw.elsa.transcnt)
udelay(1000);
debugl1(cs, "msi tout=%d", timeout);
- udelay(RCV_DELAY );
+ mdelay(RCV_DELAY);
modem_write_cmd(cs, MInit_5, strlen(MInit_5));
timeout = 1000;
while(timeout-- && cs->hw.elsa.transcnt)
udelay(1000);
debugl1(cs, "msi tout=%d", timeout);
- udelay(RCV_DELAY);
+ mdelay(RCV_DELAY);
modem_write_cmd(cs, MInit_6, strlen(MInit_6));
timeout = 1000;
while(timeout-- && cs->hw.elsa.transcnt)
udelay(1000);
debugl1(cs, "msi tout=%d", timeout);
- udelay(RCV_DELAY);
+ mdelay(RCV_DELAY);
modem_write_cmd(cs, MInit_7, strlen(MInit_7));
timeout = 1000;
while(timeout-- && cs->hw.elsa.transcnt)
udelay(1000);
debugl1(cs, "msi tout=%d", timeout);
- udelay(RCV_DELAY);
+ mdelay(RCV_DELAY);
}
static void
modem_set_dial(struct IsdnCardState *cs, int outgoing) {
int timeout;
-#define RCV_DELAY 20000
+#define RCV_DELAY 20
modem_write_cmd(cs, MInit_speed28800, strlen(MInit_speed28800));
timeout = 1000;
while(timeout-- && cs->hw.elsa.transcnt)
udelay(1000);
debugl1(cs, "msi tout=%d", timeout);
- udelay(RCV_DELAY);
+ mdelay(RCV_DELAY);
if (outgoing)
modem_write_cmd(cs, MInit_dialout, strlen(MInit_dialout));
else
@@ -541,7 +541,7 @@ modem_set_dial(struct IsdnCardState *cs, int outgoing) {
while(timeout-- && cs->hw.elsa.transcnt)
udelay(1000);
debugl1(cs, "msi tout=%d", timeout);
- udelay(RCV_DELAY);
+ mdelay(RCV_DELAY);
}
static void
--
Martin Michlmayr
http://www.cyrius.com/
^ permalink raw reply related
* Re: [NEXT PULL 00/17] IEEE 802.15.4 stack updates.
From: David Miller @ 2009-11-07 2:02 UTC (permalink / raw)
To: dbaryshkov; +Cc: netdev, slapin
In-Reply-To: <1257511181-19403-1-git-send-email-dbaryshkov@gmail.com>
aFrom: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Date: Fri, 6 Nov 2009 15:39:24 +0300
> Please pull into net-next an update for IEEE 802.15.4
>
> The following changes since commit 6a2a2d6bf8581216e08be15fcb563cfd6c430e1e:
> Gilad Ben-Yossef (1):
> tcp: Use defaults when no route options are available
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/lowpan/lowpan.git for-next
Looks good, pulled, thanks a lot!
^ permalink raw reply
* Re: [PATCH net-next] Phonet: use rwlock for sockets list
From: David Miller @ 2009-11-07 2:03 UTC (permalink / raw)
To: remi.denis-courmont; +Cc: eric.dumazet, netdev
In-Reply-To: <200911061629.42911.remi.denis-courmont@nokia.com>
From: "Rémi Denis-Courmont" <remi.denis-courmont@nokia.com>
Date: Fri, 6 Nov 2009 16:29:42 +0200
> So if you say R/W locks suck, screw this patch.
They do, so I'm tossing it :-)
^ permalink raw reply
* Re: netfilter 02/02: xt_connlimit: fix regression caused by zero family value
From: David Miller @ 2009-11-07 2:08 UTC (permalink / raw)
To: kaber; +Cc: jengelh, netfilter-devel, netdev
In-Reply-To: <4AF43782.50604@trash.net>
From: Patrick McHardy <kaber@trash.net>
Date: Fri, 06 Nov 2009 15:49:38 +0100
> Jan Engelhardt wrote:
>> On Thursday 2009-11-05 19:23, Patrick McHardy wrote:
>>> netfilter: xt_connlimit: fix regression caused by zero family value
>>>
>>> Commit v2.6.28-rc1~7172~1092~2 was slightly incomplete; not all
>>> instances of par->match->family were changed to par->family.
>>>
>>> Netfilter bugzilla #610.
>>
>> Hold it.
>> git would never output ~7172~1092~2 because ~8266 would be much simpler.
>>
>> I originally wrote "Commit v2.6.28-rc1~717^2~109^2~2", but one of your
>> programs seems to eat commit messages or more.
>
> Indeed, my email client displays ^2 as ², which cut and paste transforms
> to 2 :)
Ok, so I'll apply Jan's fixed up version, thanks!
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox