* 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
* Re: pull request: wireless-2.6 2009-11-06
From: David Miller @ 2009-11-07 2:22 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20091106204034.GI2782@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Fri, 6 Nov 2009 15:40:34 -0500
> 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!
Pulled, thanks a lot John.
^ permalink raw reply
* TC-HTB issue : low throughput
From: Jean Tourrilhes @ 2009-11-07 2:43 UTC (permalink / raw)
To: netdev
Hi,
I'm playing with a TC-HTB. I'm noticing that the throughput is
low. As the LARTC mailing list seems to be dead, I would welcome
suggestions...
The example below may seem contrived, but I reduced it to
a simple testcase to make it easier to reproduce.
System :
------
Debian Lenny with 2.6.30.9
Quad Core 2.5 GHz Q9300
Intel 1Gb/s NIC, e1000e driver
Setup :
-----
# brctl addbr br0
# brctl addif br0 eth5.33
# brctl addif br0 eth6.34
# brctl addif br0 eth7.38
#iptables -A FORWARD -t mangle -s 10.10.32.38 -j CLASSIFY --set-class 1:2
#tc qdisc add dev eth6.34 root handle 1: htb default 3
#tc class add dev eth6.34 parent 1: classid 1:1 htb rate 1000mbit ceil 1000mbit
#tc class add dev eth6.34 parent 1:1 classid 1:2 htb rate 3kbit ceil 1000mbit prio 1
#tc class add dev eth6.34 parent 1:1 classid 1:3 htb rate 3kbit ceil 1000mbit prio 2
Topology :
--------
Four PCs with Linux :
10.10.10.32 on br0
10.10.10.33 connected to eth5.33 (sender)
10.10.10.38 connected to eth7.38 (sender)
10.10.10.34 connected to eth6.34 (receiver)
Behaviour :
---------
If I set only qdisc 1: and class 1:1, but *NOT* 1:2 and 1:3 :
Each host independantly : ~935 Mb/s
Both host together, for 10.10.10.38 : ~527 Mb/s ;
Both host together, for 10.10.10.33 : ~443 Mb/s
If I add classes 1:2 and 1:3 :
Each host independantly : ~170 Mb/s.
Both host together, for 10.10.10.38 : ~106 Mb/s ;
Both host together, for 10.10.10.33 : ~135 Mb/s
So, not only performance did drop significantely, but
prioritisation did not happen as expected.
Weird detail :
------------
I've noticed that /sbin/tc calculates a very low burst
value. This is due to the content of /proc/net/psched. I'm wondering
if the burst calculation is what causes the issue here.
However, I tried with "burst 50kb" and saw no difference...
Dump of TC
----------
# tc -s class show dev eth6.34
class htb 1:1 root rate 1000Mbit ceil 1000Mbit burst 1375b cburst 1375b
Sent 770653596 bytes 509070 pkt (dropped 0, overlimits 0 requeues 0)
rate 82776Kbit 6835pps backlog 0b 0p requeues 0
lended: 509026 borrowed: 0 giants: 0
tokens: 11 ctokens: 11
class htb 1:2 parent 1:1 prio 1 rate 3000bit ceil 1000Mbit burst 1599b cburst 13
75b
Sent 369190389 bytes 243876 pkt (dropped 3239, overlimits 0 requeues 0)
rate 44781Kbit 3698pps backlog 0b 0p requeues 0
lended: 20 borrowed: 243856 giants: 0
tokens: -1384355 ctokens: 11
class htb 1:3 parent 1:1 prio 2 rate 3000bit ceil 1000Mbit burst 1599b cburst 13
75b
Sent 401463207 bytes 265194 pkt (dropped 3005, overlimits 0 requeues 0)
rate 37996Kbit 3137pps backlog 0b 0p requeues 0
lended: 24 borrowed: 265170 giants: 0
tokens: -3719389 ctokens: 11
# tc -s qdisc show dev eth6.34
qdisc htb 1: root r2q 10 default 3 direct_packets_stat 0
Sent 770653852 bytes 509071 pkt (dropped 6244, overlimits 25973 requeues 0)
rate 0bit 0pps backlog 0b 0p requeues 0
Thanks in advance for any help...
Jean
^ permalink raw reply
* Re: [PATCH 1/2] be2net: fix to set proper flow control on resume
From: David Miller @ 2009-11-07 4:26 UTC (permalink / raw)
To: ajitk; +Cc: netdev
In-Reply-To: <20091106120445.GA19181@serverengines.com>
From: Ajit Khaparde <ajitk@serverengines.com>
Date: Fri, 6 Nov 2009 17:36:59 +0530
> If be2 goes into suspend after a user changes the flow control settings,
> we are not programming them back after resume. This patch takes care of it.
> We now get the flow control settings before going to suspend mode and
> then apply them during resume.
>
> Signed-off-by: Ajit Khaparde <ajitk@serverengines.com>
Applied to net-2.6
^ permalink raw reply
* Re: [PATCH 2/2] be2net: Bug fix to send config commands to hardware after netdev_register
From: David Miller @ 2009-11-07 4:26 UTC (permalink / raw)
To: ajitk; +Cc: netdev
In-Reply-To: <20091106120720.GA19198@serverengines.com>
From: Ajit Khaparde <ajitk@serverengines.com>
Date: Fri, 6 Nov 2009 17:37:32 +0530
> Sending config commands to be2 hardware before netdev_register is
> completed, is sometimes causing the async link notification to arrive
> even before the driver is ready to handle it. The commands for vlan
> config and flow control settings can infact wait till be_open.
> This patch takes care of that.
>
> Signed-off-by: Ajit Khaparde <ajitk@serverengines.com>
Applied to net-2.6
^ permalink raw reply
* Re: [PATCH] ems_usb: Fix byte order issues on big endian machines
From: David Miller @ 2009-11-07 4:26 UTC (permalink / raw)
To: haas; +Cc: netdev, socketcan-core
In-Reply-To: <20091104154824.18199.15573.stgit@localhost.localdomain>
From: Sebastian Haas <haas@ems-wuensche.com>
Date: Wed, 04 Nov 2009 16:48:24 +0100
> CPC-USB is using a ARM7 core with little endian byte order. The "id" field
> in can_msg needs byte order conversion from/to CPU byte order.
>
> Signed-off-by: Sebastian Haas <haas@ems-wuensche.com>
Applied to net-2.6
^ permalink raw reply
* Re: [PATCH 1/1] NET: cassini, fix lock imbalance
From: David Miller @ 2009-11-07 4:26 UTC (permalink / raw)
To: jirislaby; +Cc: netdev, linux-kernel
In-Reply-To: <1257498869-4374-1-git-send-email-jirislaby@gmail.com>
From: Jiri Slaby <jirislaby@gmail.com>
Date: Fri, 6 Nov 2009 10:14:29 +0100
> Stanse found that one error path in cas_open omits to unlock pm_mutex.
> Fix that.
>
> Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
Applied to net-2.6
^ 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