* Re: [PATCH] pktgen: Fix delay handling
From: David Miller @ 2009-10-01 16:29 UTC (permalink / raw)
To: eric.dumazet; +Cc: shemminger, jdb, robert, netdev
In-Reply-To: <4AC47EB9.6070809@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 01 Oct 2009 12:04:41 +0200
> But it appears net/core/pktgen.c is different on net-next-2.6
>
> Stephen, David, I am a bit lost here, something went wrong in a merge process ?
>
net-next-2.6 is just a stale old tree, there is no new networking
work in there and it is simply Linus's tree as of a few weeks
ago.
It's only there so Stephen Rothwell has something to do a 'nop'
pull from into his linux-next tree.
I'll apply your fix, thanks!
^ permalink raw reply
* Re: [PATCH] Use sk_mark for routing lookup in more places
From: Eric Dumazet @ 2009-10-01 16:30 UTC (permalink / raw)
To: Atis Elsts; +Cc: Laszlo Attila Toth, David S. Miller, netdev
In-Reply-To: <200910011814.47689.atis@mikrotik.com>
Atis Elsts a écrit :
> This patch against v2.6.31 adds support for route lookup using sk_mark in some
> more places. The benefits from this patch are the following.
> First, SO_MARK option now has effect on UDP sockets too.
> Second, ip_queue_xmit() and inet_sk_rebuild_header() could fail to do routing
> lookup correctly if TCP sockets with SO_MARK were used.
>
> Signed-off-by: Atis Elsts <atis@mikrotik.com>
Good catch, thanks !
I used SO_MARK on connected UDP sockets so did not notice the lack
of functionality. (ip_route_connect() does use sk->sk_mark)
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
> ---
> net/ipv4/af_inet.c | 1 +
> net/ipv4/ip_output.c | 1 +
> net/ipv4/udp.c | 1 +
> 3 files changed, 3 insertions(+)
>
> diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
> index 566ea6c..7917963 100644
> --- a/net/ipv4/af_inet.c
> +++ b/net/ipv4/af_inet.c
> @@ -1103,6 +1103,7 @@ int inet_sk_rebuild_header(struct sock *sk)
> {
> struct flowi fl = {
> .oif = sk->sk_bound_dev_if,
> + .mark = sk->sk_mark,
> .nl_u = {
> .ip4_u = {
> .daddr = daddr,
> diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
> index 7ffcd96..e088a97 100644
> --- a/net/ipv4/ip_output.c
> +++ b/net/ipv4/ip_output.c
> @@ -335,6 +335,7 @@ int ip_queue_xmit(struct sk_buff *skb, int ipfragok)
>
> {
> struct flowi fl = { .oif = sk->sk_bound_dev_if,
> + .mark = sk->sk_mark,
> .nl_u = { .ip4_u =
> { .daddr = daddr,
> .saddr = inet->saddr,
> diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
> index 80e3812..f90cdcc 100644
> --- a/net/ipv4/udp.c
> +++ b/net/ipv4/udp.c
> @@ -688,6 +688,7 @@ int udp_sendmsg(struct kiocb *iocb, struct sock *sk,
> struct msghdr *msg,
>
> if (rt == NULL) {
> struct flowi fl = { .oif = ipc.oif,
> + .mark = sk->sk_mark,
> .nl_u = { .ip4_u =
> { .daddr = faddr,
> .saddr = saddr,
> --
^ permalink raw reply
* Re: [PATCH] pktgen: Fix delay handling
From: Eric Dumazet @ 2009-10-01 16:32 UTC (permalink / raw)
To: David Miller; +Cc: shemminger, jdb, robert, netdev
In-Reply-To: <20091001.092920.246088613.davem@davemloft.net>
David Miller a écrit :
> net-next-2.6 is just a stale old tree, there is no new networking
> work in there and it is simply Linus's tree as of a few weeks
> ago.
>
> It's only there so Stephen Rothwell has something to do a 'nop'
> pull from into his linux-next tree.
>
> I'll apply your fix, thanks!
Thanks for the explanation David.
^ permalink raw reply
* Re: r8169c: Support for Realtek 8168DP chip?
From: David Miller @ 2009-10-01 16:42 UTC (permalink / raw)
To: dave; +Cc: Rainer.Koenig, netdev
In-Reply-To: <1254404310.24972.4.camel@obelisk.thedillows.org>
From: David Dillow <dave@thedillows.org>
Date: Thu, 01 Oct 2009 09:38:30 -0400
> Hmm, patchwork doesn't seem to have picked it up, yet.
It's there, I just marked it in "RFC" state since that's exactly what
that patch is.
The default patchwork page for a project only lists patches that in a
state other than one which means the patch won't be applied in it's
current form.
If you want to see "all patches in all states" click on "filter"
and set it to your needs.
^ permalink raw reply
* Re: [PATCH] make TLLAO option for NA packets configurable
From: David Miller @ 2009-10-01 16:43 UTC (permalink / raw)
To: shemminger; +Cc: cratiu, netdev, opurdila
In-Reply-To: <20091001092100.14ea024b@s6510>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Thu, 1 Oct 2009 09:21:00 -0700
>> Signed-off-by: Cosmin Ratiu <cratiu@ixiacom.com>
>> --- //packages/linux_2.6.7/main/src/include/linux/sysctl.h
>> +++ /home/z/w1/packages/linux_2.6.7/main/src/include/linux/sysctl.h
>> @@ -444,6 +444,7 @@
>> NET_IPV6_IP6FRAG_TIME=23,
>> NET_IPV6_IP6FRAG_SECRET_INTERVAL=24,
>> NET_IPV6_MLD_MAX_MSF=25,
>> + NET_IPV6_NDISC_FORCE_TLLAO=26,
>
> Since numbered sysctl values are deprecated, can you use CTL_UNNUMBERED
> to avoid having to add yet another value?
Using CLT_UNNUMBERED is a must these days.
Also, please fix the prefixing of the paths in your patch.
See Documentation/SubmittingPatches in the kernel tree.
^ permalink raw reply
* Re: [PATCH] make TLLAO option for NA packets configurable
From: Cosmin Ratiu @ 2009-10-01 16:43 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, Octavian Purdila
In-Reply-To: <20091001092100.14ea024b@s6510>
On Thursday 01 October 2009 19:21:00 Stephen Hemminger wrote:
> On Thu, 1 Oct 2009 19:16:40 +0300
>
> Cosmin Ratiu <cratiu@ixiacom.com> wrote:
> > Hello,
> >
> > This is a patch that adds a sysctl to control the sending of the Target
> > Link Layer Address Option (TLLAO) with Neighbor Advertisements responding
> > to unicast NS. The patch was made for kernel 2.6.7 (yes it is ancient),
> > but the code is similar with the current kernel and I can rework it if
> > you want it in.
> >
> > RFC 2461, page 24 suggests that this option should be included with NAs
> > to avoid a race with the sender clearing its cache after sending an
> > unicast NS, but before receiving a NA.
> >
> > It seems there are some Juniper routers (MX series) that expect this
> > option to be included with all NAs.
> >
> > Another solution is to always send this option, as it has little
> > overhead.
> >
> > Please let me know what you think,
> > Cosmin.
> >
> > Signed-off-by: Cosmin Ratiu <cratiu@ixiacom.com>
> > --- //packages/linux_2.6.7/main/src/include/linux/sysctl.h
> > +++ /home/z/w1/packages/linux_2.6.7/main/src/include/linux/sysctl.h
> > @@ -444,6 +444,7 @@
> > NET_IPV6_IP6FRAG_TIME=23,
> > NET_IPV6_IP6FRAG_SECRET_INTERVAL=24,
> > NET_IPV6_MLD_MAX_MSF=25,
> > + NET_IPV6_NDISC_FORCE_TLLAO=26,
>
> Since numbered sysctl values are deprecated, can you use CTL_UNNUMBERED
> to avoid having to add yet another value?
Of course, but that is a detail.
If you decide on the sysctl solution, I'll do it.
If you decide on making this the default behavior, it's even better.
Cosmin.
^ permalink raw reply
* [PATCHv3] IPv4 TCP fails to send window scale option when window scale is zero
From: Gilad Ben-Yossef @ 2009-10-01 16:41 UTC (permalink / raw)
To: netdev; +Cc: ori, ilpo.jarvinen, eric.dumazet
From: Ori Finkelman <ori@comsleep.com>
Acknowledge TCP window scale support by inserting the proper option in SYN/ACK
and SYN headers even if our window scale is zero.
This fixes the following observed behavior:
1. Client sends a SYN with TCP window scaling option and non zero window scale
value to a Linux box.
2. Linux box notes large receive window from client.
3. Linux decides on a zero value of window scale for its part.
4. Due to compare against requested window scale size option, Linux does not to
send windows scale TCP option header on SYN/ACK at all.
With the following result:
Client box thinks TCP window scaling is not supported, since SYN/ACK had no
TCP window scale option, while Linux thinks that TCP window scaling is
supported (and scale might be non zero), since SYN had TCP window scale
option and we have a mismatched idea between the client and server
regarding window sizes.
Probably it also fixes up the following bug (not observed in practice):
1. Linux box opens TCP connection to some server.
2. Linux decides on zero value of window scale.
3. Due to compare against computed window scale size option, Linux does
not to set windows scale TCP option header on SYN.
With the expected result that the server OS does not use window scale option
due to not receiving such an option in the SYN headers, leading to suboptimal
performance.
Signed-off-by: Gilad Ben-Yossef <gilad@codefidence.com>
Signed-off-by: Ori Finkelman <ori@comsleep.com>
---
Original bug reported and patch written by Ori Finkelman from Comsleep Ltd.
I've fixed the SYN header case based on feedback from Eric Dumazet and Ilpo
Jarvinen, as part of trying to get the patch mainlined.
The SYN/ACK behavior was observed with a Windows box as the client and latest
Debian kernel but for the best of my understanding this can happen with latest
kernel versions and other client OS (probably also Linux) as well.
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 5200aab..fcd278a 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -361,6 +361,7 @@ static inline int tcp_urg_mode(const struct tcp_sock *tp)
#define OPTION_SACK_ADVERTISE (1 << 0)
#define OPTION_TS (1 << 1)
#define OPTION_MD5 (1 << 2)
+#define OPTION_WSCALE (1 << 3)
struct tcp_out_options {
u8 options; /* bit field of OPTION_* */
@@ -427,7 +428,7 @@ static void tcp_options_write(__be32 *ptr, struct tcp_sock *tp,
TCPOLEN_SACK_PERM);
}
- if (unlikely(opts->ws)) {
+ if (unlikely(OPTION_WSCALE & opts->options)) {
*ptr++ = htonl((TCPOPT_NOP << 24) |
(TCPOPT_WINDOW << 16) |
(TCPOLEN_WINDOW << 8) |
@@ -494,8 +495,8 @@ static unsigned tcp_syn_options(struct sock *sk, struct sk_buff *skb,
}
if (likely(sysctl_tcp_window_scaling)) {
opts->ws = tp->rx_opt.rcv_wscale;
- if (likely(opts->ws))
- size += TCPOLEN_WSCALE_ALIGNED;
+ opts->options |= OPTION_WSCALE;
+ size += TCPOLEN_WSCALE_ALIGNED;
}
if (likely(sysctl_tcp_sack)) {
opts->options |= OPTION_SACK_ADVERTISE;
@@ -537,8 +538,8 @@ static unsigned tcp_synack_options(struct sock *sk,
if (likely(ireq->wscale_ok)) {
opts->ws = ireq->rcv_wscale;
- if (likely(opts->ws))
- size += TCPOLEN_WSCALE_ALIGNED;
+ opts->options |= OPTION_WSCALE;
+ size += TCPOLEN_WSCALE_ALIGNED;
}
if (likely(doing_ts)) {
opts->options |= OPTION_TS;
^ permalink raw reply related
* Re: [PATCH] skge: use unique IRQ name
From: Stephen Hemminger @ 2009-10-01 16:50 UTC (permalink / raw)
To: Michal Schmidt, David Miller; +Cc: netdev
In-Reply-To: <20091001122720.3822bdd3@leela>
(revised to use pci:)
From: Michal Schmidt <mschmidt@redhat.com>
Most network drivers request their IRQ when the interface is activated.
skge does it in ->probe() instead, because it can work with two-port
cards where the two net_devices use the same IRQ. This works fine most
of the time, except in some situations when the interface gets renamed.
Consider this example:
1. modprobe skge
The card is detected as eth0 and requests IRQ 17. Directory
/proc/irq/17/eth0 is created.
2. There is an udev rule which says this interface should be called
eth1, so udev renames eth0 -> eth1.
3. modprobe 8139too
The Realtek card is detected as eth0. It will be using IRQ 17 too.
4. ip link set eth0 up
Now 8139too requests IRQ 17.
The result is:
WARNING: at fs/proc/generic.c:590 proc_register ...
proc_dir_entry '17/eth0' already registered
...
And "ls /proc/irq/17" shows two subdirectories, both called eth0.
Fix it by using a unique name for skge's IRQ, based on the PCI address.
The naming from the example then looks like this:
$ grep skge /proc/interrupts
17: 169 IO-APIC-fasteoi skge@pci:0000:00:0a.0, eth0
irqbalance daemon will have to be taught to recognize "skge" as an
Ethernet interrupt. This will be a one-liner addition in classify.c. I
will send a patch to irqbalance if this change is accepted.
Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
Acked-by: Stephen Hemminger <shemminger@vyatta.com>
--- a/drivers/net/skge.c 2009-10-01 09:36:21.893095582 -0700
+++ b/drivers/net/skge.c 2009-10-01 09:46:22.064555679 -0700
@@ -3895,6 +3895,7 @@ static int __devinit skge_probe(struct p
struct net_device *dev, *dev1;
struct skge_hw *hw;
int err, using_dac = 0;
+ size_t irq_name_len;
err = pci_enable_device(pdev);
if (err) {
@@ -3935,11 +3936,14 @@ static int __devinit skge_probe(struct p
#endif
err = -ENOMEM;
- hw = kzalloc(sizeof(*hw), GFP_KERNEL);
+ /* space for skge@pci:0000:04:00.0 */
+ irq_name_len = strlen(DRV_NAME) + strlen(dev_name(&pdev->dev)) + 6;
+ hw = kzalloc(sizeof(*hw) + irq_name_len, GFP_KERNEL);
if (!hw) {
dev_err(&pdev->dev, "cannot allocate hardware struct\n");
goto err_out_free_regions;
}
+ sprintf(hw->irq_name, DRV_NAME "@pci:%s", pci_name(pdev));
hw->pdev = pdev;
spin_lock_init(&hw->hw_lock);
@@ -3974,7 +3978,7 @@ static int __devinit skge_probe(struct p
goto err_out_free_netdev;
}
- err = request_irq(pdev->irq, skge_intr, IRQF_SHARED, dev->name, hw);
+ err = request_irq(pdev->irq, skge_intr, IRQF_SHARED, hw->irq_name, hw);
if (err) {
dev_err(&pdev->dev, "%s: cannot assign irq %d\n",
dev->name, pdev->irq);
--- a/drivers/net/skge.h 2009-10-01 09:34:51.036505545 -0700
+++ b/drivers/net/skge.h 2009-10-01 09:47:38.096558002 -0700
@@ -2423,6 +2423,8 @@ struct skge_hw {
u16 phy_addr;
spinlock_t phy_lock;
struct tasklet_struct phy_task;
+
+ char irq_name[0]; /* skge@pci:000:04:00.0 */
};
enum pause_control {
^ permalink raw reply
* Re: [PATCH 0/2] cfg80211: firmware and hardware version
From: John W. Linville @ 2009-10-01 16:56 UTC (permalink / raw)
To: Ben Hutchings
Cc: Kalle Valo, Luis R. Rodriguez,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1254411199.2735.4.camel@achroite>
On Thu, Oct 01, 2009 at 04:33:19PM +0100, Ben Hutchings wrote:
> On Thu, 2009-10-01 at 11:18 -0400, John W. Linville wrote:
> [...]
> > > But here are the features which I doubt we will ever use:
> > >
> > > ethtool -s|--change DEVNAME Change generic options
> > > [ speed %%d ]
> > > [ duplex half|full ]
> > > [ port tp|aui|bnc|mii|fibre ]
> > > [ autoneg on|off ]
> > > [ advertise %%x ]
> > > [ phyad %%d ]
> > > [ xcvr internal|external ]
> > > [ wol p|u|m|b|a|g|s|d... ]
> > > [ sopass %%x:%%x:%%x:%%x:%%x:%%x ]
> > > [ msglvl %%d ]
> > > ethtool -a|--show-pause DEVNAME Show pause options
> > > ethtool -A|--pause DEVNAME Set pause options
> > > [ autoneg on|off ]
> > > [ rx on|off ]
> > > [ tx on|off ]
> >
> > I agree that the above are ethernet-specific.
> [...]
>
> Message level isn't and WoL arguably isn't. It's a shame that these
> original ethtool settings are still bundled together...
Oh, yes! Missed those in the noise...
John
--
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
* [PATCH] sky2: irqname based on pci address
From: Stephen Hemminger @ 2009-10-01 17:11 UTC (permalink / raw)
To: Michal Schmidt, David Miller; +Cc: netdev
In-Reply-To: <20091001122720.3822bdd3@leela>
This is based on Michal Schmidt fix for skge.
Most network drivers request their IRQ when the interface is activated.
sky2 does it in ->probe() instead, because it can work with two-port
cards where the two net_devices use the same IRQ. This works fine most
of the time, except in some situations when the interface gets renamed.
Consider this example:
1. modprobe sky2
The card is detected as eth0 and requests IRQ 17. Directory
/proc/irq/17/eth0 is created.
2. There is an udev rule which says this interface should be called
eth1, so udev renames eth0 -> eth1.
3. modprobe 8139too
The Realtek card is detected as eth0. It will be using IRQ 17 too.
4. ip link set eth0 up
Now 8139too requests IRQ 17.
The result is:
WARNING: at fs/proc/generic.c:590 proc_register ...
proc_dir_entry '17/eth0' already registered
The fix is for sky2 to name the irq based on the pci device, as is done
by some other devices DRM, infiniband, ... ie. sky2@pci:0000:00:00
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
--- a/drivers/net/sky2.c 2009-10-01 09:51:30.604556725 -0700
+++ b/drivers/net/sky2.c 2009-10-01 09:56:38.893342161 -0700
@@ -4487,13 +4487,16 @@ static int __devinit sky2_probe(struct p
wol_default = device_may_wakeup(&pdev->dev) ? WAKE_MAGIC : 0;
err = -ENOMEM;
- hw = kzalloc(sizeof(*hw), GFP_KERNEL);
+
+ hw = kzalloc(sizeof(*hw) + strlen(DRV_NAME "@pci:")
+ + strlen(pci_name(pdev)) + 1, GFP_KERNEL);
if (!hw) {
dev_err(&pdev->dev, "cannot allocate hardware struct\n");
goto err_out_free_regions;
}
hw->pdev = pdev;
+ sprintf(hw->irq_name, DRV_NAME "@pci:%s", pci_name(pdev));
hw->regs = ioremap_nocache(pci_resource_start(pdev, 0), 0x4000);
if (!hw->regs) {
@@ -4539,7 +4542,7 @@ static int __devinit sky2_probe(struct p
err = request_irq(pdev->irq, sky2_intr,
(hw->flags & SKY2_HW_USE_MSI) ? 0 : IRQF_SHARED,
- dev->name, hw);
+ hw->irq_name, hw);
if (err) {
dev_err(&pdev->dev, "cannot assign irq %d\n", pdev->irq);
goto err_out_unregister;
--- a/drivers/net/sky2.h 2009-10-01 09:51:17.553559116 -0700
+++ b/drivers/net/sky2.h 2009-10-01 09:51:42.069510492 -0700
@@ -2085,6 +2085,8 @@ struct sky2_hw {
struct timer_list watchdog_timer;
struct work_struct restart_work;
wait_queue_head_t msi_wait;
+
+ char irq_name[0];
};
static inline int sky2_is_copper(const struct sky2_hw *hw)
^ permalink raw reply
* Re: [PATCH] sky2: irqname based on pci address
From: Stephen Hemminger @ 2009-10-01 17:14 UTC (permalink / raw)
To: Michal Schmidt; +Cc: David Miller, netdev
In-Reply-To: <20091001101146.3368b4a4@s6510>
On Thu, 1 Oct 2009 10:11:46 -0700
Stephen Hemminger <shemminger@vyatta.com> wrote:
> This is based on Michal Schmidt fix for skge.
>
> Most network drivers request their IRQ when the interface is activated.
> sky2 does it in ->probe() instead, because it can work with two-port
> cards where the two net_devices use the same IRQ. This works fine most
> of the time, except in some situations when the interface gets renamed.
> Consider this example:
>
> 1. modprobe sky2
> The card is detected as eth0 and requests IRQ 17. Directory
> /proc/irq/17/eth0 is created.
> 2. There is an udev rule which says this interface should be called
> eth1, so udev renames eth0 -> eth1.
> 3. modprobe 8139too
> The Realtek card is detected as eth0. It will be using IRQ 17 too.
> 4. ip link set eth0 up
> Now 8139too requests IRQ 17.
One other note, the issue is less of a problem for most usage of sky2
because the drive is used mostly on systems that support MSI interrupts
which can never be shared.
^ permalink raw reply
* Re: [PATCH 0/2] cfg80211: firmware and hardware version
From: John W. Linville @ 2009-10-01 17:07 UTC (permalink / raw)
To: Kalle Valo; +Cc: Luis R. Rodriguez, linux-wireless, netdev
In-Reply-To: <873a63qe6e.fsf@purkki.valot.fi>
On Thu, Oct 01, 2009 at 07:20:09PM +0300, Kalle Valo wrote:
> "John W. Linville" <linville@tuxdriver.com> writes:
>
> > On Thu, Oct 01, 2009 at 05:18:33PM +0300, Kalle Valo wrote:
> > Anyway, adding a couple of ioctl calls isn't a big deal.
>
> Sure, but we need to support this forever. If, say after two years, we
> decide that ethtool is not the way to go, it's very difficult to
> remove it. The less interfaces we have, the easier it is to maintain
> them.
Just to be clear, I was taling about adding ioctl calls to a
userland application (if you didn't want to use the ethtool utility).
The required ioctls are already defined for ethtool in the kernel.
> >> ethtool -r|--negotiate DEVNAME Restart N-WAY negotation
> >
> > Ethernet-specific...might could be overloaded for wireless to trigger
> > reassoc...?
>
> Please no, I don't want to see any reassociation or anything else
> 802.11 state related in ethtool, nl80211 was created for this. This is
> something I would object loudly :)
Well, it was just a thought... :-)
> > Anyway, between the link detection and making distro scripts work
> > plus enabling a familiar tool for basic driver info I think this is
> > a win. So much the better if some drivers move to ethtool for register
> > dumping, setting message verbosity, querying/changing eeprom values,
> > etc, etc...
>
> Sounds good enough. As I said in my earlier email, I'm not going argue
> about this for too long. You know this better than I do. So let's go
> forward with ethtool.
>
> Thanks for listening to my concerns.
Sure, np. And FWIW, I don't predict a huge problem if there are
valid extensions required for use by wireless drivers in the future.
But for now, I'd like to see us make use of some of the debugging
facilities available in the ethtool API -- hopefully the iwlwifi guys
are listening... ;-)
John
--
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: [PATCH] TI DaVinci EMAC: Minor macro related updates
From: David Miller @ 2009-10-01 17:16 UTC (permalink / raw)
To: chaithrika; +Cc: netdev, davinci-linux-open-source
In-Reply-To: <1254428719-13960-1-git-send-email-chaithrika@ti.com>
Date: Thu, 1 Oct 2009 16:25:19 -0400
Please fix the time on your computer.
^ permalink raw reply
* Re: [PATCHv3] IPv4 TCP fails to send window scale option when window scale is zero
From: Eric Dumazet @ 2009-10-01 17:20 UTC (permalink / raw)
To: Gilad Ben-Yossef; +Cc: netdev, ori, ilpo.jarvinen
In-Reply-To: <1254413613.665110.11357.nullmailer@tron.codefidence.com>
Gilad Ben-Yossef a écrit :
> From: Ori Finkelman <ori@comsleep.com>
>
> Acknowledge TCP window scale support by inserting the proper option in SYN/ACK
> and SYN headers even if our window scale is zero.
>
> This fixes the following observed behavior:
>
> 1. Client sends a SYN with TCP window scaling option and non zero window scale
> value to a Linux box.
> 2. Linux box notes large receive window from client.
> 3. Linux decides on a zero value of window scale for its part.
> 4. Due to compare against requested window scale size option, Linux does not to
> send windows scale TCP option header on SYN/ACK at all.
>
> With the following result:
>
> Client box thinks TCP window scaling is not supported, since SYN/ACK had no
> TCP window scale option, while Linux thinks that TCP window scaling is
> supported (and scale might be non zero), since SYN had TCP window scale
> option and we have a mismatched idea between the client and server
> regarding window sizes.
>
> Probably it also fixes up the following bug (not observed in practice):
>
> 1. Linux box opens TCP connection to some server.
> 2. Linux decides on zero value of window scale.
> 3. Due to compare against computed window scale size option, Linux does
> not to set windows scale TCP option header on SYN.
>
> With the expected result that the server OS does not use window scale option
> due to not receiving such an option in the SYN headers, leading to suboptimal
> performance.
>
> Signed-off-by: Gilad Ben-Yossef <gilad@codefidence.com>
> Signed-off-by: Ori Finkelman <ori@comsleep.com>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Note, to reproduce the wscale set to 0 on active connections,
you have to play with /proc/sys/net settings :
echo 65535 >/proc/sys/net/core/rmem_max
echo "4096 16384 32768" >/proc/sys/net/ipv4/tcp_rmem
-> wscale 0 -> SYN packet without WSCALE option (on non patched kernels)
^ permalink raw reply
* [PATCHv3] IPv4 TCP fails to send window scale option when window scale is zero
From: Gilad Ben-Yossef @ 2009-10-01 16:24 UTC (permalink / raw)
To: netdev; +Cc: ori, ilpo.jarvinen, eric.dumazet
From: Ori Finkelman <ori@comsleep.com>
Acknowledge TCP window scale support by inserting the proper option in SYN/ACK
and SYN headers even if our window scale is zero.
This fixes the following observed behavior:
1. Client sends a SYN with TCP window scaling option and non zero window scale
value to a Linux box.
2. Linux box notes large receive window from client.
3. Linux decides on a zero value of window scale for its part.
4. Due to compare against requested window scale size option, Linux does not to
send windows scale TCP option header on SYN/ACK at all.
With the following result:
Client box thinks TCP window scaling is not supported, since SYN/ACK had no
TCP window scale option, while Linux thinks that TCP window scaling is
supported (and scale might be non zero), since SYN had TCP window scale
option and we have a mismatched idea between the client and server
regarding window sizes.
Probably it also fixes up the following bug (not observed in practice):
1. Linux box opens TCP connection to some server.
2. Linux decides on zero value of window scale.
3. Due to compare against computed window scale size option, Linux does
not to set windows scale TCP option header on SYN.
With the expected result that the server OS does not use window scale option
due to not receiving such an option in the SYN headers, leading to suboptimal
performance.
Signed-off-by: Gilad Ben-Yossef <gilad@codefidence.com>
Signed-off-by: Ori Finkelman <ori@comsleep.com>
---
Original bug reported and patch written by Ori Finkelman from Comsleep Ltd.
I've fixed the SYN header case based on feedback from Eric Dumazet and Ilpo
Jarvinen, as part of trying to get the patch mainlined.
The SYN/ACK behavior was observed with a Windows box as the client and latest
Debian kernel but for the best of my understanding this can happen with latest
kernel versions and other client OS (probably also Linux) as well.
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 5200aab..fcd278a 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -361,6 +361,7 @@ static inline int tcp_urg_mode(const struct tcp_sock *tp)
#define OPTION_SACK_ADVERTISE (1 << 0)
#define OPTION_TS (1 << 1)
#define OPTION_MD5 (1 << 2)
+#define OPTION_WSCALE (1 << 3)
struct tcp_out_options {
u8 options; /* bit field of OPTION_* */
@@ -427,7 +428,7 @@ static void tcp_options_write(__be32 *ptr, struct tcp_sock *tp,
TCPOLEN_SACK_PERM);
}
- if (unlikely(opts->ws)) {
+ if (unlikely(OPTION_WSCALE & opts->options)) {
*ptr++ = htonl((TCPOPT_NOP << 24) |
(TCPOPT_WINDOW << 16) |
(TCPOLEN_WINDOW << 8) |
@@ -494,8 +495,8 @@ static unsigned tcp_syn_options(struct sock *sk, struct sk_buff *skb,
}
if (likely(sysctl_tcp_window_scaling)) {
opts->ws = tp->rx_opt.rcv_wscale;
- if (likely(opts->ws))
- size += TCPOLEN_WSCALE_ALIGNED;
+ opts->options |= OPTION_WSCALE;
+ size += TCPOLEN_WSCALE_ALIGNED;
}
if (likely(sysctl_tcp_sack)) {
opts->options |= OPTION_SACK_ADVERTISE;
@@ -537,8 +538,8 @@ static unsigned tcp_synack_options(struct sock *sk,
if (likely(ireq->wscale_ok)) {
opts->ws = ireq->rcv_wscale;
- if (likely(opts->ws))
- size += TCPOLEN_WSCALE_ALIGNED;
+ opts->options |= OPTION_WSCALE;
+ size += TCPOLEN_WSCALE_ALIGNED;
}
if (likely(doing_ts)) {
opts->options |= OPTION_TS;
^ permalink raw reply related
* [PATCHv3] IPv4 TCP fails to send window scale option when window scale is zero
From: Gilad Ben-Yossef @ 2009-10-01 16:13 UTC (permalink / raw)
To: netdev; +Cc: ori, ilpo.jarvinen, eric.dumazet
From: Ori Finkelman <ori@comsleep.com>
Acknowledge TCP window scale support by inserting the proper option in SYN/ACK
and SYN headers even if our window scale is zero.
This fixes the following observed behavior:
1. Client sends a SYN with TCP window scaling option and non zero window scale
value to a Linux box.
2. Linux box notes large receive window from client.
3. Linux decides on a zero value of window scale for its part.
4. Due to compare against requested window scale size option, Linux does not to
send windows scale TCP option header on SYN/ACK at all.
With the following result:
Client box thinks TCP window scaling is not supported, since SYN/ACK had no
TCP window scale option, while Linux thinks that TCP window scaling is
supported (and scale might be non zero), since SYN had TCP window scale
option and we have a mismatched idea between the client and server
regarding window sizes.
Probably it also fixes up the following bug (not observed in practice):
1. Linux box opens TCP connection to some server.
2. Linux decides on zero value of window scale.
3. Due to compare against computed window scale size option, Linux does
not to set windows scale TCP option header on SYN.
With the expected result that the server OS does not use window scale option
due to not receiving such an option in the SYN headers, leading to suboptimal
performance.
Signed-off-by: Gilad Ben-Yossef <gilad@codefidence.com>
Signed-off-by: Ori Finkelman <ori@comsleep.com>
---
Original bug reported and patch written by Ori Finkelman from Comsleep Ltd.
I've fixed the SYN header case based on feedback from Eric Dumazet and Ilpo
Jarvinen, as part of trying to get the patch mainlined.
The SYN/ACK behavior was observed with a Windows box as the client and latest
Debian kernel but for the best of my understanding this can happen with latest
kernel versions and other client OS (probably also Linux) as well.
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 5200aab..fcd278a 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -361,6 +361,7 @@ static inline int tcp_urg_mode(const struct tcp_sock *tp)
#define OPTION_SACK_ADVERTISE (1 << 0)
#define OPTION_TS (1 << 1)
#define OPTION_MD5 (1 << 2)
+#define OPTION_WSCALE (1 << 3)
struct tcp_out_options {
u8 options; /* bit field of OPTION_* */
@@ -427,7 +428,7 @@ static void tcp_options_write(__be32 *ptr, struct tcp_sock *tp,
TCPOLEN_SACK_PERM);
}
- if (unlikely(opts->ws)) {
+ if (unlikely(OPTION_WSCALE & opts->options)) {
*ptr++ = htonl((TCPOPT_NOP << 24) |
(TCPOPT_WINDOW << 16) |
(TCPOLEN_WINDOW << 8) |
@@ -494,8 +495,8 @@ static unsigned tcp_syn_options(struct sock *sk, struct sk_buff *skb,
}
if (likely(sysctl_tcp_window_scaling)) {
opts->ws = tp->rx_opt.rcv_wscale;
- if (likely(opts->ws))
- size += TCPOLEN_WSCALE_ALIGNED;
+ opts->options |= OPTION_WSCALE;
+ size += TCPOLEN_WSCALE_ALIGNED;
}
if (likely(sysctl_tcp_sack)) {
opts->options |= OPTION_SACK_ADVERTISE;
@@ -537,8 +538,8 @@ static unsigned tcp_synack_options(struct sock *sk,
if (likely(ireq->wscale_ok)) {
opts->ws = ireq->rcv_wscale;
- if (likely(opts->ws))
- size += TCPOLEN_WSCALE_ALIGNED;
+ opts->options |= OPTION_WSCALE;
+ size += TCPOLEN_WSCALE_ALIGNED;
}
if (likely(doing_ts)) {
opts->options |= OPTION_TS;
^ permalink raw reply related
* Re: [PATCH 00/31] Swap over NFS -v20
From: Christoph Hellwig @ 2009-10-01 17:42 UTC (permalink / raw)
To: Suresh Jayaraman
Cc: Linus Torvalds, Andrew Morton, linux-kernel, linux-mm, netdev,
Neil Brown, Miklos Szeredi, Wouter Verhelst, Peter Zijlstra,
trond.myklebust
In-Reply-To: <1254405858-15651-1-git-send-email-sjayaraman@suse.de>
On Thu, Oct 01, 2009 at 07:34:18PM +0530, Suresh Jayaraman wrote:
> Hi,
>
> Here's the latest version of swap over NFS series since -v19 last October by
> Peter Zijlstra. Peter does not have time to pursue this further (though he has
> not lost interest) and that led me to take over this patchset and try merging
> upstream.
>
> The patches are against the current mmotm. It does not support SLQB, yet.
> These patches can also be found online here:
> http://www.suse.de/~sjayaraman/patches/swap-over-nfs/
My advise again that I already gave to Peter long ago. It's almost
impossible to get a patchset that large and touching many subsystems in.
Split it into smaller series that make sense of their own. One of them
would be the whole VM/net work to just make swap over nbd/iscsi safe.
The other really big one is adding a proper method for safe, page-backed
kernelspace I/O on files. That is not something like the grotty
swap-tied address_space operations in this patch, but more something in
the direction of the kernel direct I/O patches from Jenx Axboe he did
for using in the loop driver. But even those aren't complete as they
don't touch the locking issue yet.
Especially the latter is an absolutely essential step to make any
progress here, and an excellent patch series of it's own as there are
multiple users for this, like making swap safe on btrfs files, making
the MD bitmap code actually safe or improving the loop driver.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH] skge: use unique IRQ name
From: Michal Schmidt @ 2009-10-01 18:02 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, netdev
In-Reply-To: <20091001095032.17271dcc@s6510>
Dne Thu, 1 Oct 2009 09:50:32 -0700 Stephen Hemminger napsal:
> err = -ENOMEM;
> - hw = kzalloc(sizeof(*hw), GFP_KERNEL);
> + /* space for skge@pci:0000:04:00.0 */
> + irq_name_len = strlen(DRV_NAME) +
> strlen(dev_name(&pdev->dev)) + 6;
You replaced "dev_name(&pdev->dev)" with "pci_name(pdev)" below.
That's nice, so we should replace it here too for consistency.
> + hw = kzalloc(sizeof(*hw) + irq_name_len, GFP_KERNEL);
> if (!hw) {
> dev_err(&pdev->dev, "cannot allocate hardware
> struct\n"); goto err_out_free_regions;
> }
> + sprintf(hw->irq_name, DRV_NAME "@pci:%s", pci_name(pdev));
Michal
^ permalink raw reply
* Re: [PATCH] sky2: irqname based on pci address
From: Michal Schmidt @ 2009-10-01 18:03 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, netdev
In-Reply-To: <20091001101146.3368b4a4@s6510>
Dne Thu, 1 Oct 2009 10:11:46 -0700 Stephen Hemminger napsal(a):
> This is based on Michal Schmidt fix for skge.
>
> Most network drivers request their IRQ when the interface is
> activated. sky2 does it in ->probe() instead, because it can work
> with two-port cards where the two net_devices use the same IRQ. This
> works fine most of the time, except in some situations when the
> interface gets renamed. Consider this example:
>
> 1. modprobe sky2
> The card is detected as eth0 and requests IRQ 17. Directory
> /proc/irq/17/eth0 is created.
> 2. There is an udev rule which says this interface should be called
> eth1, so udev renames eth0 -> eth1.
> 3. modprobe 8139too
> The Realtek card is detected as eth0. It will be using IRQ 17 too.
> 4. ip link set eth0 up
> Now 8139too requests IRQ 17.
>
> The result is:
> WARNING: at fs/proc/generic.c:590 proc_register ...
> proc_dir_entry '17/eth0' already registered
>
> The fix is for sky2 to name the irq based on the pci device, as is
> done by some other devices DRM, infiniband, ... ie.
> sky2@pci:0000:00:00
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Reviewed-by: Michal Schmidt <mschmidt@redhat.com>
^ permalink raw reply
* Re: [PATCH] make TLLAO option for NA packets configurable
From: Cosmin Ratiu @ 2009-10-01 18:08 UTC (permalink / raw)
To: David Miller; +Cc: shemminger, netdev, opurdila
In-Reply-To: <20091001.094356.95174955.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 409 bytes --]
On Thursday 01 October 2009 19:43:56 David Miller wrote:
> Using CLT_UNNUMBERED is a must these days.
>
> Also, please fix the prefixing of the paths in your patch.
> See Documentation/SubmittingPatches in the kernel tree.
Here is the new variant. Please let me know what you think.
And I apologize for using [PATCH] instead of [RFC] in the subject, I don't
know much about netdev protocol (yet).
Cosmin.
[-- Attachment #2: 0001-ipv6-new-sysctl-for-sending-TLLAO-with-NAs.patch --]
[-- Type: text/x-patch, Size: 2274 bytes --]
From 1911a98df800cedf4c3a63b897163e2935c5f602 Mon Sep 17 00:00:00 2001
From: Cosmin Ratiu <cratiu@ixiacom.com>
Date: Thu, 1 Oct 2009 20:27:39 +0300
Subject: [PATCH] ipv6: new sysctl for sending TLLAO with NAs
Neighbor advertisements responding to unicast Neighbor Solicitations did
not include the TLLAO option. This patch makes this configurable via
/proc/sys/net/ipv6/ndisc_force_tllao, which by default is off.
The need for this arose because certain routers expect the TLLAO in some
situations even as a response to unicast NS packets.
Moreover, RFC 2461 recommends on page 24 sending this to avoid a race.
Signed-off-by: Cosmin Ratiu <cratiu@ixiacom.com>
---
include/net/netns/ipv6.h | 1 +
net/ipv6/ndisc.c | 1 +
net/ipv6/sysctl_net_ipv6.c | 8 ++++++++
3 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/include/net/netns/ipv6.h b/include/net/netns/ipv6.h
index dfeb2d7..dd0a95b 100644
--- a/include/net/netns/ipv6.h
+++ b/include/net/netns/ipv6.h
@@ -16,6 +16,7 @@ struct netns_sysctl_ipv6 {
struct ctl_table_header *frags_hdr;
#endif
int bindv6only;
+ int ndisc_force_tllao;
int flush_delay;
int ip6_rt_max_size;
int ip6_rt_gc_min_interval;
diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
index f74e4e2..f08cf65 100644
--- a/net/ipv6/ndisc.c
+++ b/net/ipv6/ndisc.c
@@ -598,6 +598,7 @@ static void ndisc_send_na(struct net_device *dev, struct neighbour *neigh,
icmp6h.icmp6_solicited = solicited;
icmp6h.icmp6_override = override;
+ inc_opt |= dev_net(dev)->ipv6.sysctl.ndisc_force_tllao;
__ndisc_send(dev, neigh, daddr, src_addr,
&icmp6h, solicited_addr,
inc_opt ? ND_OPT_TARGET_LL_ADDR : 0);
diff --git a/net/ipv6/sysctl_net_ipv6.c b/net/ipv6/sysctl_net_ipv6.c
index 0dc6a4e..fb423ce 100644
--- a/net/ipv6/sysctl_net_ipv6.c
+++ b/net/ipv6/sysctl_net_ipv6.c
@@ -37,6 +37,14 @@ static ctl_table ipv6_table_template[] = {
.mode = 0644,
.proc_handler = proc_dointvec
},
+ {
+ .ctl_name = CTL_UNNUMBERED,
+ .procname = "ndisc_force_tllao",
+ .data = &init_net.ipv6.sysctl.ndisc_force_tllao,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec
+ },
{ .ctl_name = 0 }
};
--
1.6.3.3
^ permalink raw reply related
* [PATCH v3] skge: use unique IRQ name
From: Stephen Hemminger @ 2009-10-01 18:13 UTC (permalink / raw)
To: Michal Schmidt; +Cc: David Miller, netdev
In-Reply-To: <20091001200208.2907b8ff@leela>
From: Michal Schmidt <mschmidt@redhat.com>
Most network drivers request their IRQ when the interface is activated.
skge does it in ->probe() instead, because it can work with two-port
cards where the two net_devices use the same IRQ. This works fine most
of the time, except in some situations when the interface gets renamed.
Consider this example:
1. modprobe skge
The card is detected as eth0 and requests IRQ 17. Directory
/proc/irq/17/eth0 is created.
2. There is an udev rule which says this interface should be called
eth1, so udev renames eth0 -> eth1.
3. modprobe 8139too
The Realtek card is detected as eth0. It will be using IRQ 17 too.
4. ip link set eth0 up
Now 8139too requests IRQ 17.
The result is:
WARNING: at fs/proc/generic.c:590 proc_register ...
proc_dir_entry '17/eth0' already registered
...
And "ls /proc/irq/17" shows two subdirectories, both called eth0.
Fix it by using a unique name for skge's IRQ, based on the PCI address.
The naming from the example then looks like this:
$ grep skge /proc/interrupts
17: 169 IO-APIC-fasteoi skge@0000:00:0a.0, eth0
irqbalance daemon will have to be taught to recognize "skge@" as an
Ethernet interrupt. This will be a one-liner addition in classify.c. I
will send a patch to irqbalance if this change is accepted.
Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
Acked-by: Stephen Hemminger <shemminger@vyatta.com>
---
Changes:
v2 use pci: in irq name
v3 simplify calculation of string length
--- a/drivers/net/skge.c 2009-10-01 11:09:19.057676199 -0700
+++ b/drivers/net/skge.c 2009-10-01 11:10:45.786382284 -0700
@@ -3935,11 +3935,14 @@ static int __devinit skge_probe(struct p
#endif
err = -ENOMEM;
- hw = kzalloc(sizeof(*hw), GFP_KERNEL);
+ /* space for skge@pci:0000:04:00.0 */
+ hw = kzalloc(sizeof(*hw) + strlen(DRV_NAME "@pci:" )
+ + strlen(pci_name(pdev)) + 1, GFP_KERNEL);
if (!hw) {
dev_err(&pdev->dev, "cannot allocate hardware struct\n");
goto err_out_free_regions;
}
+ sprintf(hw->irq_name, DRV_NAME "@pci:%s", pci_name(pdev));
hw->pdev = pdev;
spin_lock_init(&hw->hw_lock);
@@ -3974,7 +3977,7 @@ static int __devinit skge_probe(struct p
goto err_out_free_netdev;
}
- err = request_irq(pdev->irq, skge_intr, IRQF_SHARED, dev->name, hw);
+ err = request_irq(pdev->irq, skge_intr, IRQF_SHARED, hw->irq_name, hw);
if (err) {
dev_err(&pdev->dev, "%s: cannot assign irq %d\n",
dev->name, pdev->irq);
--- a/drivers/net/skge.h 2009-10-01 11:09:19.067695070 -0700
+++ b/drivers/net/skge.h 2009-10-01 11:09:34.147674089 -0700
@@ -2423,6 +2423,8 @@ struct skge_hw {
u16 phy_addr;
spinlock_t phy_lock;
struct tasklet_struct phy_task;
+
+ char irq_name[0]; /* skge@pci:000:04:00.0 */
};
enum pause_control {
^ permalink raw reply
* Re: [PATCH] make TLLAO option for NA packets configurable
From: Stephen Hemminger @ 2009-10-01 18:14 UTC (permalink / raw)
To: Cosmin Ratiu; +Cc: David Miller, netdev, opurdila
In-Reply-To: <200910012108.41071.cratiu@ixiacom.com>
On Thu, 1 Oct 2009 21:08:40 +0300
Cosmin Ratiu <cratiu@ixiacom.com> wrote:
> On Thursday 01 October 2009 19:43:56 David Miller wrote:
> > Using CLT_UNNUMBERED is a must these days.
> >
> > Also, please fix the prefixing of the paths in your patch.
> > See Documentation/SubmittingPatches in the kernel tree.
>
> Here is the new variant. Please let me know what you think.
>
> And I apologize for using [PATCH] instead of [RFC] in the subject, I don't
> know much about netdev protocol (yet).
>
> Cosmin.
Probably this should be a per interface property rather than per namespace.
^ permalink raw reply
* pull request: wireless-2.6 2009-10-01
From: John W. Linville @ 2009-10-01 18:24 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev, linux-kernel
Dave,
A small collection of fixes for 2.6.32...
One is a brown paper bag fix for an uninitialized variable, another is a
USB ID. There is a beaconing fix for the mac80211_hwsim "fake" driver,
and a bug fix for AP mode related to buffering frames for stations in
power save mode.
The b43 fix looks a bit long, but it is more-or-less the same simple
fix applied in multiple places. It addresses a bug where "the last
bytes of data sent/received to/from PIO FIFOs on SDIO-based cards get
'swizzled' when its length is not multiple of 4 bytes."
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 eb1cf0f8f7a9e5a6d573d5bd72c015686a042db0:
David S. Miller (1):
Merge branch 'master' of ssh://master.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
Christian Lamparter (1):
ar9170: fix bug in iq-auto calibration value calculation
Igor Perminov (1):
mac80211: Fix [re]association power saving issue on AP side
Jouni Malinen (1):
mac80211_hwsim: Fix initial beacon timer configuration
Michael Buesch (1):
b43: Always use block-I/O for the PIO data registers
Michal Szalata (1):
rt2x00: Thrustmaster FunAccess WIFI USB and rt73usb
drivers/net/wireless/ath/ar9170/phy.c | 6 +--
drivers/net/wireless/b43/pio.c | 60 +++++++++++++++++++++------------
drivers/net/wireless/mac80211_hwsim.c | 3 ++
drivers/net/wireless/rt2x00/rt73usb.c | 1 +
net/mac80211/tx.c | 5 ++-
5 files changed, 48 insertions(+), 27 deletions(-)
diff --git a/drivers/net/wireless/ath/ar9170/phy.c b/drivers/net/wireless/ath/ar9170/phy.c
index b3e5cf3..dbd488d 100644
--- a/drivers/net/wireless/ath/ar9170/phy.c
+++ b/drivers/net/wireless/ath/ar9170/phy.c
@@ -1141,7 +1141,8 @@ static int ar9170_set_freq_cal_data(struct ar9170 *ar,
u8 vpds[2][AR5416_PD_GAIN_ICEPTS];
u8 pwrs[2][AR5416_PD_GAIN_ICEPTS];
int chain, idx, i;
- u8 f;
+ u32 phy_data = 0;
+ u8 f, tmp;
switch (channel->band) {
case IEEE80211_BAND_2GHZ:
@@ -1208,9 +1209,6 @@ static int ar9170_set_freq_cal_data(struct ar9170 *ar,
}
for (i = 0; i < 76; i++) {
- u32 phy_data;
- u8 tmp;
-
if (i < 25) {
tmp = ar9170_interpolate_val(i, &pwrs[0][0],
&vpds[0][0]);
diff --git a/drivers/net/wireless/b43/pio.c b/drivers/net/wireless/b43/pio.c
index e96091b..9c13979 100644
--- a/drivers/net/wireless/b43/pio.c
+++ b/drivers/net/wireless/b43/pio.c
@@ -340,10 +340,15 @@ static u16 tx_write_2byte_queue(struct b43_pio_txqueue *q,
q->mmio_base + B43_PIO_TXDATA,
sizeof(u16));
if (data_len & 1) {
+ u8 tail[2] = { 0, };
+
/* Write the last byte. */
ctl &= ~B43_PIO_TXCTL_WRITEHI;
b43_piotx_write16(q, B43_PIO_TXCTL, ctl);
- b43_piotx_write16(q, B43_PIO_TXDATA, data[data_len - 1]);
+ tail[0] = data[data_len - 1];
+ ssb_block_write(dev->dev, tail, 2,
+ q->mmio_base + B43_PIO_TXDATA,
+ sizeof(u16));
}
return ctl;
@@ -386,26 +391,31 @@ static u32 tx_write_4byte_queue(struct b43_pio_txqueue *q,
q->mmio_base + B43_PIO8_TXDATA,
sizeof(u32));
if (data_len & 3) {
- u32 value = 0;
+ u8 tail[4] = { 0, };
/* Write the last few bytes. */
ctl &= ~(B43_PIO8_TXCTL_8_15 | B43_PIO8_TXCTL_16_23 |
B43_PIO8_TXCTL_24_31);
- data = &(data[data_len - 1]);
switch (data_len & 3) {
case 3:
- ctl |= B43_PIO8_TXCTL_16_23;
- value |= (u32)(*data) << 16;
- data--;
+ ctl |= B43_PIO8_TXCTL_16_23 | B43_PIO8_TXCTL_8_15;
+ tail[0] = data[data_len - 3];
+ tail[1] = data[data_len - 2];
+ tail[2] = data[data_len - 1];
+ break;
case 2:
ctl |= B43_PIO8_TXCTL_8_15;
- value |= (u32)(*data) << 8;
- data--;
+ tail[0] = data[data_len - 2];
+ tail[1] = data[data_len - 1];
+ break;
case 1:
- value |= (u32)(*data);
+ tail[0] = data[data_len - 1];
+ break;
}
b43_piotx_write32(q, B43_PIO8_TXCTL, ctl);
- b43_piotx_write32(q, B43_PIO8_TXDATA, value);
+ ssb_block_write(dev->dev, tail, 4,
+ q->mmio_base + B43_PIO8_TXDATA,
+ sizeof(u32));
}
return ctl;
@@ -693,21 +703,25 @@ data_ready:
q->mmio_base + B43_PIO8_RXDATA,
sizeof(u32));
if (len & 3) {
- u32 value;
- char *data;
+ u8 tail[4] = { 0, };
/* Read the last few bytes. */
- value = b43_piorx_read32(q, B43_PIO8_RXDATA);
- data = &(skb->data[len + padding - 1]);
+ ssb_block_read(dev->dev, tail, 4,
+ q->mmio_base + B43_PIO8_RXDATA,
+ sizeof(u32));
switch (len & 3) {
case 3:
- *data = (value >> 16);
- data--;
+ skb->data[len + padding - 3] = tail[0];
+ skb->data[len + padding - 2] = tail[1];
+ skb->data[len + padding - 1] = tail[2];
+ break;
case 2:
- *data = (value >> 8);
- data--;
+ skb->data[len + padding - 2] = tail[0];
+ skb->data[len + padding - 1] = tail[1];
+ break;
case 1:
- *data = value;
+ skb->data[len + padding - 1] = tail[0];
+ break;
}
}
} else {
@@ -715,11 +729,13 @@ data_ready:
q->mmio_base + B43_PIO_RXDATA,
sizeof(u16));
if (len & 1) {
- u16 value;
+ u8 tail[2] = { 0, };
/* Read the last byte. */
- value = b43_piorx_read16(q, B43_PIO_RXDATA);
- skb->data[len + padding - 1] = value;
+ ssb_block_read(dev->dev, tail, 2,
+ q->mmio_base + B43_PIO_RXDATA,
+ sizeof(u16));
+ skb->data[len + padding - 1] = tail[0];
}
}
diff --git a/drivers/net/wireless/mac80211_hwsim.c b/drivers/net/wireless/mac80211_hwsim.c
index 896f532..38cfd79 100644
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -631,6 +631,9 @@ static void mac80211_hwsim_bss_info_changed(struct ieee80211_hw *hw,
data->beacon_int = 1024 * info->beacon_int / 1000 * HZ / 1000;
if (WARN_ON(!data->beacon_int))
data->beacon_int = 1;
+ if (data->started)
+ mod_timer(&data->beacon_timer,
+ jiffies + data->beacon_int);
}
if (changed & BSS_CHANGED_ERP_CTS_PROT) {
diff --git a/drivers/net/wireless/rt2x00/rt73usb.c b/drivers/net/wireless/rt2x00/rt73usb.c
index 1cbd9b4..b8f5ee3 100644
--- a/drivers/net/wireless/rt2x00/rt73usb.c
+++ b/drivers/net/wireless/rt2x00/rt73usb.c
@@ -2381,6 +2381,7 @@ static struct usb_device_id rt73usb_device_table[] = {
/* Huawei-3Com */
{ USB_DEVICE(0x1472, 0x0009), USB_DEVICE_DATA(&rt73usb_ops) },
/* Hercules */
+ { USB_DEVICE(0x06f8, 0xe002), USB_DEVICE_DATA(&rt73usb_ops) },
{ USB_DEVICE(0x06f8, 0xe010), USB_DEVICE_DATA(&rt73usb_ops) },
{ USB_DEVICE(0x06f8, 0xe020), USB_DEVICE_DATA(&rt73usb_ops) },
/* Linksys */
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 5143d20..fd40282 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -367,7 +367,10 @@ ieee80211_tx_h_unicast_ps_buf(struct ieee80211_tx_data *tx)
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)tx->skb->data;
u32 staflags;
- if (unlikely(!sta || ieee80211_is_probe_resp(hdr->frame_control)))
+ if (unlikely(!sta || ieee80211_is_probe_resp(hdr->frame_control)
+ || ieee80211_is_auth(hdr->frame_control)
+ || ieee80211_is_assoc_resp(hdr->frame_control)
+ || ieee80211_is_reassoc_resp(hdr->frame_control)))
return TX_CONTINUE;
staflags = get_sta_flags(sta);
--
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 related
* Re: [PATCH] make TLLAO option for NA packets configurable
From: Octavian Purdila @ 2009-10-01 18:39 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Cosmin Ratiu, David Miller, netdev
In-Reply-To: <20091001111450.221969cc@s6510>
On Thursday 01 October 2009 21:14:50 you wrote:
>
> Probably this should be a per interface property rather than per namespace.
In our case, where we have lots of interfaces active, it would be nice to have
the per namespace property as well.
But, as Cosmin suggested, perhaps it would be better to just send this options
by default? (its a RFC SHOULD after all...)
Thanks,
tavi
^ permalink raw reply
* Re: [PATCH] net: fix NOHZ: local_softirq_pending 08
From: Johannes Berg @ 2009-10-01 18:42 UTC (permalink / raw)
To: Michael Buesch
Cc: David Miller, oliver-fJ+pQTUTwRTk1uMJSBkQmQ,
kalle.valo-X3B1VOXEql0, linville-2XuSBdqkA4R54TAoqtyWWQ,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <200910011604.42916.mb-fseUSCV1ubazQB+pC5nmwQ@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 460 bytes --]
On Thu, 2009-10-01 at 16:04 +0200, Michael Buesch wrote:
> On Thursday 01 October 2009 01:33:33 David Miller wrote:
>
> > I'm not applying this until all of these details are sorted out
>
> John, please apply my fix to wireless-testing to get rid of the regression.
> You can revert it later, if there's a better fix available.
I agree with davem, don't. Just fix the driver to local_bh_disable()
around the rx function if necessary.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ 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