* Re: [PATCH] can: fix SJA1000 dlc for RTR packets
From: David Miller @ 2011-05-05 18:02 UTC (permalink / raw)
To: kurt.van.dijck; +Cc: socketcan-core, netdev
In-Reply-To: <20110502145048.GF338@e-circ.dyndns.org>
From: Kurt Van Dijck <kurt.van.dijck@eia.be>
Date: Mon, 2 May 2011 16:50:48 +0200
> RTR frames do have a valid data length code on CAN.
> The driver for SJA1000 did not handle that situation properly.
>
> Signed-off-by: Kurt Van Dijck <kurt.van.dijck@eia.be>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] Removed unnecessary assignments , gotos and goto labels
From: David Miller @ 2011-05-05 18:00 UTC (permalink / raw)
To: sasikanth.v19; +Cc: netdev
In-Reply-To: <1304187809-7887-1-git-send-email-sasikanth.v19@gmail.com>
From: Sasikanth V <sasikanth.v19@gmail.com>
Date: Sat, 30 Apr 2011 23:53:29 +0530
> @@ -1779,15 +1770,15 @@ static int packet_getname(struct socket *sock, struct sockaddr *uaddr,
> sll->sll_ifindex = po->ifindex;
> sll->sll_protocol = po->num;
> sll->sll_pkttype = 0;
> + sll->sll_hatype = 0;
> + sll->sll_halen = 0;
> +
> rcu_read_lock();
> dev = dev_get_by_index_rcu(sock_net(sk), po->ifindex);
> if (dev) {
> sll->sll_hatype = dev->type;
> sll->sll_halen = dev->addr_len;
> memcpy(sll->sll_addr, dev->dev_addr, dev->addr_len);
> - } else {
> - sll->sll_hatype = 0; /* Bad: we have no ARPHRD_UNSPEC */
> - sll->sll_halen = 0;
> }
> rcu_read_unlock();
This is completely bogus.
In the dev != NULL case, we'll now write to sll_hatype and sll_halen
twice, which is less inefficient than making sure we write to these
fields only one.
And outside of this part, I really don't like the cleanups you made
here, and they don't improve the code in any way in my eyes.
Sorry.
^ permalink raw reply
* Re: [patch net-next-2.6] net: call dev_alloc_name from register_netdevice
From: David Miller @ 2011-05-05 17:58 UTC (permalink / raw)
To: jpirko; +Cc: netdev, eric.dumazet, mirqus, xemul
In-Reply-To: <1304162492-6606-1-git-send-email-jpirko@redhat.com>
From: Jiri Pirko <jpirko@redhat.com>
Date: Sat, 30 Apr 2011 13:21:32 +0200
> Force dev_alloc_name() to be called from register_netdevice() by
> dev_get_valid_name(). That allows to remove multiple explicit
> dev_alloc_name() calls.
>
> The possibility to call dev_alloc_name in advance remains.
>
> This also fixes veth creation regresion caused by
> 84c49d8c3e4abefb0a41a77b25aa37ebe8d6b743
>
> Signed-off-by: Jiri Pirko <jpirko@redhat.com>
I like this change, and if some real legitimate hole is found
in it we can either quickly fix that or revert this simply.
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 2/2 net-next] net: drivers: set TSO/UFO offload option explicitly
From: David Miller @ 2011-05-05 17:54 UTC (permalink / raw)
To: shanwei
Cc: netdev, rusty, mst, eric.dumazet, mirq-linux, mirqus, bhutchings,
dm
In-Reply-To: <4DBA4DF5.5020101@cn.fujitsu.com>
From: Shan Wei <shanwei@cn.fujitsu.com>
Date: Fri, 29 Apr 2011 13:34:45 +0800
> The device drivers should not use NETIF_F_ALL_TSO mask to set hw_features(or features),
> but have to explicitly set offload option. Because, This would make drivers automatically
> clain to support any new TSO feature an the moment of NETIF_F_ALL_TSO is expanded.
>
> Some code style tuning. Just compile test.
>
> Signed-off-by: Shan Wei <shanwei@cn.fujitsu.com>
But loopback is special. It can support anything the kernel stack can emit.
So for loopback, using NETIF_F_ALL_TSO is in fact appropriate.
^ permalink raw reply
* Re: [PATCH 1/2] net: use NETIF_F_ALL_TSO for vlan features
From: David Miller @ 2011-05-05 17:53 UTC (permalink / raw)
To: shanwei; +Cc: netdev, eilong, dm, leedom, mirqus, bhutchings
In-Reply-To: <4DBA4AB4.5000802@cn.fujitsu.com>
From: Shan Wei <shanwei@cn.fujitsu.com>
Date: Fri, 29 Apr 2011 13:20:52 +0800
>
> As Dimitris Michailidis suggested, use NETIF_F_ALL_TSO for vlan_features,
> which is a mask, but not hw_features.
>
> Compile test.
>
>
> Signed-off-by: Shan Wei <shanwei@cn.fujitsu.com>
I do not understand why we want to advertise a set of ->vlan_features
TSO flags that are different from the flags advertised in ->hw_features.
Why do we want to do this?
^ permalink raw reply
* Re: [PATCHv2 1/2] net: Export dev_queue_xmit_nit for use by macvlan driver
From: David Miller @ 2011-05-05 17:50 UTC (permalink / raw)
To: david.ward; +Cc: netdev, kaber
In-Reply-To: <1304036552-1589-2-git-send-email-david.ward@ll.mit.edu>
From: David Ward <david.ward@ll.mit.edu>
Date: Thu, 28 Apr 2011 20:22:31 -0400
> @@ -1521,11 +1521,13 @@ static inline int deliver_skb(struct sk_buff *skb,
> }
>
> /*
> - * Support routine. Sends outgoing frames to any network
> - * taps currently in use.
> + * dev_queue_xmit_nit - send outgoing frame to AF_PACKET sockets
> + *
> + * @skb: buffer to send
> + * @dev: network device that AF_PACKET sockets are attached to (if any)
> */
Your change to this comment is inaccurate.
AF_PACKET is only one of several types of entities that register these
kinds of taps.
Also, I really don't like exposing these kinds of internals for what is
largely a macvlan internal issue. Please find a less intrustive way
to solve this problem.
Thanks.
^ permalink raw reply
* Re: [PATCHv4 2/2] tg3: Allow ethtool to enable/disable loopback.
From: Mahesh Bandewar @ 2011-05-05 17:47 UTC (permalink / raw)
To: Michał Mirosław
Cc: Matt Carlson, David Miller, netdev, Michael Chan, Tom Herbert
In-Reply-To: <BANLkTi=1Nw6A8cMNyVGnASOA_VF018ooxA@mail.gmail.com>
On Wed, May 4, 2011 at 11:59 PM, Michał Mirosław <mirqus@gmail.com> wrote:
> 2011/5/5 Mahesh Bandewar <maheshb@google.com>:
>> This patch adds tg3_set_features() to handle loopback mode. Currently the
>> capability is added for the devices which support internal MAC loopback mode.
>> So when enabled, it enables internal-MAC loopback.
>>
>> Signed-off-by: Mahesh Bandewar <maheshb@google.com>
>> ---
>> Changes since v3:
>> (a) Corrected the condition (|| => &&) where loopback capability is added.
>> (b) set_features() always returns 0.
>> (c) Clear the loopback bit in ndo_open callback to avoid discrepancy.
>>
>> Changes since v2:
>> Implemtned Joe Perches's style change.
>>
>> Changes since v1:
>> Implemented Matt Carlson's suggestions.
>> (a) Enable this capability on the devices which are capable of MAC-loopback
>> mode.
>> (b) check if the device is running before making changes.
>> (c) check bits before making changes.
>>
>> drivers/net/tg3.c | 69 +++++++++++++++++++++++++++++++++++++++++++++++++++++
>> 1 files changed, 69 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
>> index 7c7c9a8..7f7a290 100644
>> --- a/drivers/net/tg3.c
>> +++ b/drivers/net/tg3.c
>> @@ -6309,6 +6309,44 @@ dma_error:
>> return NETDEV_TX_OK;
>> }
>>
>> +static int tg3_set_loopback(struct net_device *dev, u32 features)
>> +{
>> + struct tg3 *tp = netdev_priv(dev);
>> + u32 cur_mode = 0;
>> + int retval = 0;
>
> void? You always return zero and don't check it in callers.
>
> [...]
>> @@ -9485,6 +9533,15 @@ static int tg3_open(struct net_device *dev)
>>
>> netif_tx_start_all_queues(dev);
>>
>> + /*
>> + * Reset loopback feature if it was turned on while the device was down
>> + * to avoid and any discrepancy in features reporting.
>> + */
>> + if (dev->features & NETIF_F_LOOPBACK) {
>> + dev->features &= ~NETIF_F_LOOPBACK;
>> + dev->wanted_features &= ~NETIF_F_LOOPBACK;
>> + }
>> +
>
> if (dev->features & NETIF_F_LOOPBACK)
> tg3_set_loopback(dev, dev->features);
>
Unfortunately at this stage device will not be able to set-loopback so
I resorted to clearing the bit(s).
> Whatever you do, don't modify wanted_features in drivers.
>
Since just clearing the 'features' would leave wanted_features in
discrepant state, I thought this will bring it to a sane state. So
what is a preferred way?
> BTW, similar problems (also like in previous versions) are in
> forcedeth implementation.
Yes, whatever we decide about the state of the wanted_features, I'll
implement similarly for forcedeth. Which previous problem you are
referring to? Is it the return value? There is a different kind of
failure (error while writing the register). Since update_features()
cant handle return value, I'm ignoring the return value. As far as the
correct return code is concerned, I wasn't sure what is appropriate
return code here (may be PHY_ERROR would be appropriate there) but
again I could ignore it just the way rest of the code is ignoring.
>
> Best Regards,
> Michał Mirosław
> --
> 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: [net-next v3 0/6] bnx2x enhancements and date update
From: David Miller @ 2011-05-05 17:45 UTC (permalink / raw)
To: dmitry; +Cc: netdev, eilong, vladz, bhutchings
In-Reply-To: <1304589516.17528.11.camel@lb-tlvb-dmitry>
From: "Dmitry Kravkov" <dmitry@broadcom.com>
Date: Thu, 5 May 2011 12:58:36 +0300
> Another re-spin with format fixes as reported by Ben Hutchings
> <bhutchings@solarflare.com>
All applied, thanks for fixing things up.
^ permalink raw reply
* Re: [PATCH] stmmac: removed not used definitions
From: David Miller @ 2011-05-05 17:43 UTC (permalink / raw)
To: peppe.cavallaro; +Cc: netdev
In-Reply-To: <1304590250-9434-1-git-send-email-peppe.cavallaro@st.com>
From: Giuseppe CAVALLARO <peppe.cavallaro@st.com>
Date: Thu, 5 May 2011 12:10:50 +0200
> Reported-by: Karim Hamiti <karim.hamiti@st.com>
> Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Applied to net-next-2.6, thanks.
^ permalink raw reply
* Re: [PATCH] usbnet: runtime pm: fix out of memory
From: David Miller @ 2011-05-05 17:39 UTC (permalink / raw)
To: oneukum-l3A5Bk7waGM
Cc: tom.leiming-Re5JQEeQqe8AvxtiuMwx3w, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <201105040926.12355.oneukum-l3A5Bk7waGM@public.gmane.org>
From: Oliver Neukum <oneukum-l3A5Bk7waGM@public.gmane.org>
Date: Wed, 4 May 2011 09:26:12 +0200
> Am Mittwoch, 4. Mai 2011, 08:59:41 schrieb Ming Lei:
>> Hi,
>>
>> 2011/5/3 Oliver Neukum <oneukum-l3A5Bk7waGM@public.gmane.org>:
>>
>> > Do the devices in question use cdc_ether?
>>
>> No, the device is smsc95xx, which is compound device and is
>> integrated into pandaboard.
>
> OK,
>
> in this case:
>
> Acked-by: Oliver Neukum <oneukum-l3A5Bk7waGM@public.gmane.org>
Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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
* Re: [PATCH] mlx4_en: Setting RSS hash result to skb->rxhash field
From: David Miller @ 2011-05-05 17:34 UTC (permalink / raw)
To: eric.dumazet; +Cc: yevgenyp, bhutchings, netdev
In-Reply-To: <1304578518.32152.794.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 05 May 2011 08:55:18 +0200
> Really, we better use the linux/software full 32bit rxhash in this case,
> and wait for your 32bit full support.
Agreed.
^ permalink raw reply
* Re: [PATCH 0/4] [RFC] virtio-net: Improve small packet performance
From: Michael S. Tsirkin @ 2011-05-05 15:42 UTC (permalink / raw)
To: Krishna Kumar2; +Cc: davem, eric.dumazet, kvm, netdev, rusty
In-Reply-To: <OFB1ACC9EB.4567C1B1-ON65257887.0050044B-65257887.0054A5CE@in.ibm.com>
On Thu, May 05, 2011 at 08:57:13PM +0530, Krishna Kumar2 wrote:
> "Michael S. Tsirkin" <mst@redhat.com> wrote on 05/05/2011 02:34:39 PM:
>
> > > Do I need to apply all the patches and simply test?
> > >
> > > Thanks,
> > >
> > > - KK
> >
> > Exactly. You can also try to tune the threshold
> > for interrupts as well.
>
> I haven't tuned the threshhold, it is left it at 3/4. I ran
> the new qemu/vhost/guest, and the results for 1K, 2K and 16K
> are below. Note this is a different kernel version from my
> earlier test results. So, f.e., BW1 represents 2.6.39-rc2,
> the original kernel; while BW2 represents 2.6.37-rc5 (MST's
> kernel). This also isn't with the fixes you have sent just
> now. I will get a run with that either late tonight or
> tomorrow.
One thing I'd suggest is merging v2.6.39-rc6 into that tree.
rc2 is still pretty early, reason I use it is because that is
what net-next is.
--
MST
^ permalink raw reply
* Re: [PATCH 0/4] [RFC] virtio-net: Improve small packet performance
From: Michael S. Tsirkin @ 2011-05-05 15:37 UTC (permalink / raw)
To: Krishna Kumar2; +Cc: davem, eric.dumazet, kvm, netdev, netdev-owner, rusty
In-Reply-To: <OF32D1B981.C4616456-ON65257887.00552498-65257887.00555A3C@in.ibm.com>
On Thu, May 05, 2011 at 09:06:00PM +0530, Krishna Kumar2 wrote:
> Krishna Kumar wrote on 05/05/2011 08:57:13 PM:
>
> Oops, I sent my patch's test results for the 16K case.
> The correct one is:
>
> ________________________________________________________
> I/O size: 16K
> # BW1 BW2 (%) SD1 SD2 (%)
> ________________________________________________________
> 1 6684 6670 (-.2) 1.1 .6 (-45.4)
> 2 7674 7859 (2.4) 5.0 2.6 (-48.0)
> 4 7358 7421 (.8) 21.3 11.6 (-45.5)
> 8 7393 7289 (-1.4) 82.7 44.8 (-45.8)
> 16 7958 7280 (-8.5) 283.2 166.3 (-41.2)
> 32 7792 7163 (-8.0) 1257.5 692.4 (-44.9)
> 64 7673 7096 (-7.5) 5723.1 2870.3 (-49.8)
> 96 7462 6963 (-6.6) 12731.8 6475.6 (-49.1)
> 128 7338 6919 (-5.7) 21331.7 12345.7 (-42.1)
> ________________________________________________________
> Summary: BW: (-3.9) SD: (-45.4)
>
> Sorry for the confusion.
>
> Regards,
>
> - KK
Interesting. So which is which?
> > ________________________________________________________
> > I/O size: 16K
> > # BW1 BW2 (%) SD1 SD2 (%)
> > ________________________________________________________
> > 1 6684 7019 (5.0) 1.1 1.1 (0)
> > 2 7674 7196 (-6.2) 5.0 4.8 (-4.0)
> > 4 7358 8032 (9.1) 21.3 20.4 (-4.2)
> > 8 7393 8015 (8.4) 82.7 82.0 (-.8)
> > 16 7958 8366 (5.1) 283.2 310.7 (9.7)
> > 32 7792 8113 (4.1) 1257.5 1363.0 (8.3)
> > 64 7673 8040 (4.7) 5723.1 5812.4 (1.5)
> > 96 7462 7883 (5.6) 12731.8 12119.8 (-4.8)
> > 128 7338 7800 (6.2) 21331.7 21094.7 (-1.1)
> > ________________________________________________________
> > Summary: BW: (4.6) SD: (-1.5)
^ permalink raw reply
* Re: [PATCH 0/4] [RFC] virtio-net: Improve small packet performance
From: Michael S. Tsirkin @ 2011-05-05 15:34 UTC (permalink / raw)
To: Krishna Kumar2; +Cc: davem, eric.dumazet, kvm, netdev, rusty
In-Reply-To: <OFB1ACC9EB.4567C1B1-ON65257887.0050044B-65257887.0054A5CE@in.ibm.com>
On Thu, May 05, 2011 at 08:57:13PM +0530, Krishna Kumar2 wrote:
> "Michael S. Tsirkin" <mst@redhat.com> wrote on 05/05/2011 02:34:39 PM:
>
> > > Do I need to apply all the patches and simply test?
> > >
> > > Thanks,
> > >
> > > - KK
> >
> > Exactly. You can also try to tune the threshold
> > for interrupts as well.
>
> I haven't tuned the threshhold, it is left it at 3/4. I ran
> the new qemu/vhost/guest, and the results for 1K, 2K and 16K
> are below. Note this is a different kernel version from my
> earlier test results. So, f.e., BW1 represents 2.6.39-rc2,
> the original kernel; while BW2 represents 2.6.37-rc5 (MST's
> kernel).
Weird. My kernel is actually 2.6.39-rc2. So which is which?
> This also isn't with the fixes you have sent just
> now. I will get a run with that either late tonight or
> tomorrow.
Shouldn't affect anything performance-wise.
> ________________________________________________________
> I/O size: 1K
> # BW1 BW2 (%) SD1 SD2 (%)
> ________________________________________________________
> 1 1723 3016 (75.0) 4.7 2.6 (-44.6)
> 2 3223 6712 (108.2) 18.0 7.1 (-60.5)
> 4 7223 8258 (14.3) 36.5 24.3 (-33.4)
> 8 8689 7943 (-8.5) 131.5 101.6 (-22.7)
> 16 8059 7398 (-8.2) 578.3 406.4 (-29.7)
> 32 7758 7208 (-7.0) 2281.4 1574.7 (-30.9)
> 64 7503 7155 (-4.6) 9734.0 6368.0 (-34.5)
> 96 7496 7078 (-5.5) 21980.9 15477.6 (-29.5)
> 128 7389 6900 (-6.6) 40467.5 26031.9 (-35.6)
> ________________________________________________________
> Summary: BW: (4.4) SD: (-33.5)
>
> ________________________________________________________
> I/O size: 2K
> # BW1 BW2 (%) SD1 SD2 (%)
> ________________________________________________________
> 1 1608 4968 (208.9) 5.0 1.3 (-74.0)
> 2 3354 6974 (107.9) 18.6 4.9 (-73.6)
> 4 8234 8344 (1.3) 35.6 17.9 (-49.7)
> 8 8427 7818 (-7.2) 103.5 71.2 (-31.2)
> 16 7995 7491 (-6.3) 410.1 273.9 (-33.2)
> 32 7863 7149 (-9.0) 1678.6 1080.4 (-35.6)
> 64 7661 7092 (-7.4) 7245.3 4717.2 (-34.8)
> 96 7517 6984 (-7.0) 15711.2 9838.9 (-37.3)
> 128 7389 6851 (-7.2) 27121.6 18255.7 (-32.6)
> ________________________________________________________
> Summary: BW: (6.0) SD: (-34.5)
>
> ________________________________________________________
> I/O size: 16K
> # BW1 BW2 (%) SD1 SD2 (%)
> ________________________________________________________
> 1 6684 7019 (5.0) 1.1 1.1 (0)
> 2 7674 7196 (-6.2) 5.0 4.8 (-4.0)
> 4 7358 8032 (9.1) 21.3 20.4 (-4.2)
> 8 7393 8015 (8.4) 82.7 82.0 (-.8)
> 16 7958 8366 (5.1) 283.2 310.7 (9.7)
> 32 7792 8113 (4.1) 1257.5 1363.0 (8.3)
> 64 7673 8040 (4.7) 5723.1 5812.4 (1.5)
> 96 7462 7883 (5.6) 12731.8 12119.8 (-4.8)
> 128 7338 7800 (6.2) 21331.7 21094.7 (-1.1)
> ________________________________________________________
> Summary: BW: (4.6) SD: (-1.5)
>
> Thanks,
>
> - KK
^ permalink raw reply
* Re: [PATCH 0/4] [RFC] virtio-net: Improve small packet performance
From: Krishna Kumar2 @ 2011-05-05 15:36 UTC (permalink / raw)
To: Krishna Kumar2
Cc: davem, eric.dumazet, kvm, Michael S. Tsirkin, netdev,
netdev-owner, rusty
In-Reply-To: <OFB1ACC9EB.4567C1B1-ON65257887.0050044B-65257887.0054A5CE@in.ibm.com>
Krishna Kumar wrote on 05/05/2011 08:57:13 PM:
Oops, I sent my patch's test results for the 16K case.
The correct one is:
________________________________________________________
I/O size: 16K
# BW1 BW2 (%) SD1 SD2 (%)
________________________________________________________
1 6684 6670 (-.2) 1.1 .6 (-45.4)
2 7674 7859 (2.4) 5.0 2.6 (-48.0)
4 7358 7421 (.8) 21.3 11.6 (-45.5)
8 7393 7289 (-1.4) 82.7 44.8 (-45.8)
16 7958 7280 (-8.5) 283.2 166.3 (-41.2)
32 7792 7163 (-8.0) 1257.5 692.4 (-44.9)
64 7673 7096 (-7.5) 5723.1 2870.3 (-49.8)
96 7462 6963 (-6.6) 12731.8 6475.6 (-49.1)
128 7338 6919 (-5.7) 21331.7 12345.7 (-42.1)
________________________________________________________
Summary: BW: (-3.9) SD: (-45.4)
Sorry for the confusion.
Regards,
- KK
> ________________________________________________________
> I/O size: 16K
> # BW1 BW2 (%) SD1 SD2 (%)
> ________________________________________________________
> 1 6684 7019 (5.0) 1.1 1.1 (0)
> 2 7674 7196 (-6.2) 5.0 4.8 (-4.0)
> 4 7358 8032 (9.1) 21.3 20.4 (-4.2)
> 8 7393 8015 (8.4) 82.7 82.0 (-.8)
> 16 7958 8366 (5.1) 283.2 310.7 (9.7)
> 32 7792 8113 (4.1) 1257.5 1363.0 (8.3)
> 64 7673 8040 (4.7) 5723.1 5812.4 (1.5)
> 96 7462 7883 (5.6) 12731.8 12119.8 (-4.8)
> 128 7338 7800 (6.2) 21331.7 21094.7 (-1.1)
> ________________________________________________________
> Summary: BW: (4.6) SD: (-1.5)
^ permalink raw reply
* Re: tap/bridge: Dropping NETIF_F_GSO/NETIF_F_SG
From: Michał Mirosław @ 2011-05-05 15:26 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: netdev, Ben Hutchings, herbert
In-Reply-To: <20110504181813.GA17547@redhat.com>
On Wed, May 04, 2011 at 09:18:14PM +0300, Michael S. Tsirkin wrote:
> BTW, I just noticed that net-next spits out
> many of the following when I run any VMs:
[...]
> tap0: Features changed: 0x40004040 -> 0x401b4849
Before this message, userspace called ioctl(TIOCSETOFFLOAD)
turning offloads on.
> tap0: Dropping NETIF_F_SG since no checksum feature.
> tap0: Dropping NETIF_F_GSO since no SG feature.
> tap0: Features changed: 0x401b4849 -> 0x40004040
And then it probably called ioctl(TIOCSETOFFLOAD) again, disabling them.
Best Regards,
Michał Mirosław
^ permalink raw reply
* Re: [PATCH 0/4] [RFC] virtio-net: Improve small packet performance
From: Krishna Kumar2 @ 2011-05-05 15:27 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: davem, eric.dumazet, kvm, netdev, rusty
In-Reply-To: <20110505090439.GD17647@redhat.com>
"Michael S. Tsirkin" <mst@redhat.com> wrote on 05/05/2011 02:34:39 PM:
> > Do I need to apply all the patches and simply test?
> >
> > Thanks,
> >
> > - KK
>
> Exactly. You can also try to tune the threshold
> for interrupts as well.
I haven't tuned the threshhold, it is left it at 3/4. I ran
the new qemu/vhost/guest, and the results for 1K, 2K and 16K
are below. Note this is a different kernel version from my
earlier test results. So, f.e., BW1 represents 2.6.39-rc2,
the original kernel; while BW2 represents 2.6.37-rc5 (MST's
kernel). This also isn't with the fixes you have sent just
now. I will get a run with that either late tonight or
tomorrow.
________________________________________________________
I/O size: 1K
# BW1 BW2 (%) SD1 SD2 (%)
________________________________________________________
1 1723 3016 (75.0) 4.7 2.6 (-44.6)
2 3223 6712 (108.2) 18.0 7.1 (-60.5)
4 7223 8258 (14.3) 36.5 24.3 (-33.4)
8 8689 7943 (-8.5) 131.5 101.6 (-22.7)
16 8059 7398 (-8.2) 578.3 406.4 (-29.7)
32 7758 7208 (-7.0) 2281.4 1574.7 (-30.9)
64 7503 7155 (-4.6) 9734.0 6368.0 (-34.5)
96 7496 7078 (-5.5) 21980.9 15477.6 (-29.5)
128 7389 6900 (-6.6) 40467.5 26031.9 (-35.6)
________________________________________________________
Summary: BW: (4.4) SD: (-33.5)
________________________________________________________
I/O size: 2K
# BW1 BW2 (%) SD1 SD2 (%)
________________________________________________________
1 1608 4968 (208.9) 5.0 1.3 (-74.0)
2 3354 6974 (107.9) 18.6 4.9 (-73.6)
4 8234 8344 (1.3) 35.6 17.9 (-49.7)
8 8427 7818 (-7.2) 103.5 71.2 (-31.2)
16 7995 7491 (-6.3) 410.1 273.9 (-33.2)
32 7863 7149 (-9.0) 1678.6 1080.4 (-35.6)
64 7661 7092 (-7.4) 7245.3 4717.2 (-34.8)
96 7517 6984 (-7.0) 15711.2 9838.9 (-37.3)
128 7389 6851 (-7.2) 27121.6 18255.7 (-32.6)
________________________________________________________
Summary: BW: (6.0) SD: (-34.5)
________________________________________________________
I/O size: 16K
# BW1 BW2 (%) SD1 SD2 (%)
________________________________________________________
1 6684 7019 (5.0) 1.1 1.1 (0)
2 7674 7196 (-6.2) 5.0 4.8 (-4.0)
4 7358 8032 (9.1) 21.3 20.4 (-4.2)
8 7393 8015 (8.4) 82.7 82.0 (-.8)
16 7958 8366 (5.1) 283.2 310.7 (9.7)
32 7792 8113 (4.1) 1257.5 1363.0 (8.3)
64 7673 8040 (4.7) 5723.1 5812.4 (1.5)
96 7462 7883 (5.6) 12731.8 12119.8 (-4.8)
128 7338 7800 (6.2) 21331.7 21094.7 (-1.1)
________________________________________________________
Summary: BW: (4.6) SD: (-1.5)
Thanks,
- KK
^ permalink raw reply
* Re: ath5k regression associating with APs in 2.6.38
From: Nick Kossifidis @ 2011-05-05 15:15 UTC (permalink / raw)
To: Justin P. Mattock
Cc: John W. Linville, Jiri Slaby, Luis R. Rodriguez, Bob Copeland,
linux-wireless, ath5k-devel, netdev, linux-kernel
In-Reply-To: <4DC2BBBE.1090607@gmail.com>
2011/5/5 Justin P. Mattock <justinmattock@gmail.com>:
> On 05/05/2011 07:30 AM, Nick Kossifidis wrote:
>>
>> 2011/5/5 Seth Forshee<seth.forshee@canonical.com>:
>>>
>>> On Wed, May 04, 2011 at 11:09:03PM +0300, Nick Kossifidis wrote:
>>>>
>>>> 2011/5/4 Seth Forshee<seth.forshee@canonical.com>:
>>>>>
>>>>> On Wed, May 04, 2011 at 01:27:17PM -0400, John W. Linville wrote:
>>>>>>
>>>>>> On Wed, May 04, 2011 at 10:38:19AM -0500, Seth Forshee wrote:
>>>>>>>
>>>>>>> I've been investigating some reports of a regression in associating
>>>>>>> with
>>>>>>> APs with AR2413 in 2.6.38. Association repeatedly fails with some
>>>>>>> "direct probe to x timed out" messages (see syslog excerpt below),
>>>>>>> although it will generally associate eventually, after many tries.
>>>>>>>
>>>>>>> Bisection identifies 8aec7af (ath5k: Support synth-only channel
>>>>>>> change
>>>>>>> for AR2413/AR5413) as offending commit. Prior to this commit there
>>>>>>> are
>>>>>>> no direct probe messages at all in the logs. I've also found that
>>>>>>> forcing fast to false at the top of ath5k_hw_reset() fixes the issue.
>>>>>>> I'm not sure what the connection is between this commit and the
>>>>>>> timeouts. Any suggestions?
>>>>>>
>>>>>> Have you tried reverting that commit on top of 2.6.38? Can you
>>>>>> recreate the issue with 2.6.39-rc6 (or later)?
>>>>>
>>>>> I started to revert that commit, but it wasn't straight-forward due to
>>>>> later changes. Forcing fast to false in ath5k_hw_reset() acts as a
>>>>> functional revert of sorts since that should force it back to a full
>>>>> reset for all channel changes, and it's much simpler than working out
>>>>> the right way to revert the commit. I think the results suggest
>>>>> strongly
>>>>> that a revert is likely to fix the problem. I can finish the work to
>>>>> revert if you'd still like to see the results.
>>>>>
>>>>> Testing a previous .39-rc kernel still exhibited the failure. I don't
>>>>> recall which one it was and apparently forgot to make note of it. I'll
>>>>> request testing against rc6.
>>>>>
>>>>> Thanks,
>>>>> Seth
>>>>>
>>>>
>>>> Do you get scan results ?
>>>> Can you enable ATH5K_DEBUG_RESET and see what you get ?
>>>
>>> 2.6.39-rc6 still fails. A more comprehensive log with ATH5K_DEBUG_RESET
>>> enabled is below.
>>>
>>> Scanning looks to be failing according to this log. I was thinking that
>>> I saw successfull scans in some of the previous logs, but I'll have to
>>> go back and check to be sure.
>>>
>>> Thanks,
>>> Seth
>>>
>>>
>>> kernel: [ 23.421242] ath5k 0000:06:02.0: PCI INT A -> GSI 22 (level,
>>> low) -> IRQ 22
>>> kernel: [ 23.421312] ath5k 0000:06:02.0: registered as 'phy0'
>>> kernel: [ 24.132959] ath: EEPROM regdomain: 0x63
>>> kernel: [ 24.132962] ath: EEPROM indicates we should expect a direct
>>> regpair map
>>> kernel: [ 24.132967] ath: Country alpha2 being used: 00
>>> kernel: [ 24.132969] ath: Regpair used: 0x63
>>> kernel: [ 24.136125] cfg80211: Updating information on frequency 2412
>>> MHz for a 20 MHz width channel with regulatory rule:
>>> kernel: [ 24.136131] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (N/A
>>> mBi, 2000 mBm)
>>> kernel: [ 24.136134] cfg80211: Updating information on frequency 2417
>>> MHz for a 20 MHz width channel with regulatory rule:
>>> kernel: [ 24.136137] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (N/A
>>> mBi, 2000 mBm)
>>> kernel: [ 24.136140] cfg80211: Updating information on frequency 2422
>>> MHz for a 20 MHz width channel with regulatory rule:
>>> kernel: [ 24.136143] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (N/A
>>> mBi, 2000 mBm)
>>> kernel: [ 24.136146] cfg80211: Updating information on frequency 2427
>>> MHz for a 20 MHz width channel with regulatory rule:
>>> kernel: [ 24.136149] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (N/A
>>> mBi, 2000 mBm)
>>> kernel: [ 24.136151] cfg80211: Updating information on frequency 2432
>>> MHz for a 20 MHz width channel with regulatory rule:
>>> kernel: [ 24.136155] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (N/A
>>> mBi, 2000 mBm)
>>> kernel: [ 24.136157] cfg80211: Updating information on frequency 2437
>>> MHz for a 20 MHz width channel with regulatory rule:
>>> kernel: [ 24.136160] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (N/A
>>> mBi, 2000 mBm)
>>> kernel: [ 24.136163] cfg80211: Updating information on frequency 2442
>>> MHz for a 20 MHz width channel with regulatory rule:
>>> kernel: [ 24.136166] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (N/A
>>> mBi, 2000 mBm)
>>> kernel: [ 24.136168] cfg80211: Updating information on frequency 2447
>>> MHz for a 20 MHz width channel with regulatory rule:
>>> kernel: [ 24.136172] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (N/A
>>> mBi, 2000 mBm)
>>> kernel: [ 24.136174] cfg80211: Updating information on frequency 2452
>>> MHz for a 20 MHz width channel with regulatory rule:
>>> kernel: [ 24.136177] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (N/A
>>> mBi, 2000 mBm)
>>> kernel: [ 24.136180] cfg80211: Updating information on frequency 2457
>>> MHz for a 20 MHz width channel with regulatory rule:
>>> kernel: [ 24.136183] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (N/A
>>> mBi, 2000 mBm)
>>> kernel: [ 24.136186] cfg80211: Updating information on frequency 2462
>>> MHz for a 20 MHz width channel with regulatory rule:
>>> kernel: [ 24.136189] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (N/A
>>> mBi, 2000 mBm)
>>> kernel: [ 24.136191] cfg80211: Updating information on frequency 2467
>>> MHz for a 20 MHz width channel with regulatory rule:
>>> kernel: [ 24.136195] cfg80211: 2457000 KHz - 2482000 KHz @ KHz), (N/A
>>> mBi, 2000 mBm)
>>> kernel: [ 24.136197] cfg80211: Updating information on frequency 2472
>>> MHz for a 20 MHz width channel with regulatory rule:
>>> kernel: [ 24.136200] cfg80211: 2457000 KHz - 2482000 KHz @ KHz), (N/A
>>> mBi, 2000 mBm)
>>> kernel: [ 24.136203] cfg80211: Disabling freq 2484 MHz as custom regd
>>> has no rule that fits a 20 MHz wide channel
>>> kernel: [ 24.136404] cfg80211: Ignoring regulatory request Set by core
>>> since the driver uses its own custom regulatory domain
>>> kernel: [ 24.393924] ieee80211 phy0: Selected rate control algorithm
>>> 'minstrel_ht'
>>> kernel: [ 24.394588] ath5k phy0: Atheros AR2413 chip found (MAC: 0x78,
>>> PHY: 0x45)
>>> ...
>>> NetworkManager[725]:<info> (wlan0): driver supports SSID scans
>>> (scan_capa 0x01).
>>> NetworkManager[725]:<info> (wlan0): new 802.11 WiFi device (driver:
>>> 'ath5k' ifindex: 3)
>>> NetworkManager[725]:<info> (wlan0): exported as
>>> /org/freedesktop/NetworkManager/Devices/1
>>> NetworkManager[725]:<info> (wlan0): now managed
>>> NetworkManager[725]:<info> (wlan0): device state change: 1 -> 2 (reason
>>> 2)
>>> NetworkManager[725]:<info> (wlan0): bringing up device.
>>> NetworkManager[725]:<info> (wlan0): preparing device.
>>> NetworkManager[725]:<info> (wlan0): deactivating device (reason: 2).
>>> NetworkManager[725]: supplicant_interface_acquire: assertion `mgr_state
>>> == NM_SUPPLICANT_MANAGER_STATE_IDLE' failed
>>> kernel: [ 25.149294] ADDRCONF(NETDEV_UP): wlan0: link is not ready
>>> ...
>>> NetworkManager[725]:<info> Trying to start the supplicant...
>>> ...
>>> NetworkManager[725]:<info> (wlan0): supplicant manager state: down ->
>>> idle
>>> NetworkManager[725]:<info> (wlan0): device state change: 2 -> 3 (reason
>>> 0)
>>> NetworkManager[725]:<info> (wlan0): supplicant interface state:
>>> starting -> ready
>>> ...
>>> NetworkManager[725]:<info> (wlan0): device state change: 3 -> 2 (reason
>>> 0)
>>> NetworkManager[725]:<info> (wlan0): deactivating device (reason: 0).
>>> NetworkManager[725]:<info> (wlan0): taking down device.
>>> NetworkManager[725]:<info> (wlan0): bringing up device.
>>> kernel: [ 104.430292] ath5k phy0: (ath5k_init_hw:2522): mode 2
>>> kernel: [ 104.430297] ath5k phy0: (ath5k_stop_locked:2481): invalid 0
>>> kernel: [ 104.431000] ath5k phy0: (ath5k_reset:2648): resetting
>>> kernel: [ 104.434475] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32
>>> rx_bufsize 2368
>>> kernel: [ 104.434683] ath5k phy0: (ath5k_rfkill_disable:42): rfkill
>>> disable (gpio:0 polarity:0)
>>> kernel: [ 104.435759] ath5k phy0: (ath5k_chan_set:434): channel set,
>>> resetting (2412 -> 2412 MHz)
>>> kernel: [ 104.435762] ath5k phy0: (ath5k_reset:2648): resetting
>>> kernel: [ 104.436845] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32
>>> rx_bufsize 2368
>>> kernel: [ 104.437191] ath5k phy0: (ath5k_conf_tx:602): Configure tx
>>> [queue 0], aifs: 2, cw_min: 7, cw_max: 15, txop: 102
>>> kernel: [ 104.437212] ath5k phy0: (ath5k_conf_tx:602): Configure tx
>>> [queue 1], aifs: 2, cw_min: 15, cw_max: 31, txop: 188
>>> kernel: [ 104.438337] ADDRCONF(NETDEV_UP): wlan0: link is not ready
>>> NetworkManager[725]:<info> (wlan0): supplicant interface state:
>>> starting -> ready
>>> NetworkManager[725]:<info> (wlan0): device state change: 2 -> 3 (reason
>>> 42)
>>> wpa_supplicant[745]: Failed to initiate AP scan.
>>> kernel: [ 125.188087] net_ratelimit: 41 callbacks suppressed
>>> kernel: [ 125.188100] ath5k phy0: (ath5k_chan_set:434): channel set,
>>> resetting (2412 -> 2417 MHz)
>>> kernel: [ 125.188109] ath5k phy0: (ath5k_reset:2648): resetting
>>> kernel: [ 125.291007] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32
>>> rx_bufsize 2368
>>> kernel: [ 125.344076] ath5k phy0: (ath5k_chan_set:434): channel set,
>>> resetting (2417 -> 2422 MHz)
>>> kernel: [ 125.344090] ath5k phy0: (ath5k_reset:2648): resetting
>>> kernel: [ 125.447014] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32
>>> rx_bufsize 2368
>>> kernel: [ 125.500078] ath5k phy0: (ath5k_chan_set:434): channel set,
>>> resetting (2422 -> 2427 MHz)
>>> kernel: [ 125.500091] ath5k phy0: (ath5k_reset:2648): resetting
>>> kernel: [ 125.602999] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32
>>> rx_bufsize 2368
>>> kernel: [ 125.656070] ath5k phy0: (ath5k_chan_set:434): channel set,
>>> resetting (2427 -> 2432 MHz)
>>> kernel: [ 155.188052] net_ratelimit: 29 callbacks suppressed
>>> kernel: [ 155.188058] ath5k phy0: (ath5k_chan_set:434): channel set,
>>> resetting (2412 -> 2417 MHz)
>>> kernel: [ 155.188061] ath5k phy0: (ath5k_reset:2648): resetting
>>> kernel: [ 155.290844] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32
>>> rx_bufsize 2368
>>> kernel: [ 155.344032] ath5k phy0: (ath5k_chan_set:434): channel set,
>>> resetting (2417 -> 2422 MHz)
>>> kernel: [ 155.344038] ath5k phy0: (ath5k_reset:2648): resetting
>>> kernel: [ 155.446810] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32
>>> rx_bufsize 2368
>>> kernel: [ 155.500031] ath5k phy0: (ath5k_chan_set:434): channel set,
>>> resetting (2422 -> 2427 MHz)
>>> kernel: [ 155.500036] ath5k phy0: (ath5k_reset:2648): resetting
>>> kernel: [ 155.602811] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32
>>> rx_bufsize 2368
>>> kernel: [ 155.656033] ath5k phy0: (ath5k_chan_set:434): channel set,
>>> resetting (2427 -> 2432 MHz)
>>> kernel: [ 195.184088] net_ratelimit: 29 callbacks suppressed
>>> kernel: [ 195.184102] ath5k phy0: (ath5k_chan_set:434): channel set,
>>> resetting (2412 -> 2417 MHz)
>>> kernel: [ 195.184110] ath5k phy0: (ath5k_reset:2648): resetting
>>> kernel: [ 195.287022] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32
>>> rx_bufsize 2368
>>> kernel: [ 195.340066] ath5k phy0: (ath5k_chan_set:434): channel set,
>>> resetting (2417 -> 2422 MHz)
>>> kernel: [ 195.340079] ath5k phy0: (ath5k_reset:2648): resetting
>>> kernel: [ 195.442967] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32
>>> rx_bufsize 2368
>>> kernel: [ 195.496076] ath5k phy0: (ath5k_chan_set:434): channel set,
>>> resetting (2422 -> 2427 MHz)
>>> kernel: [ 195.496088] ath5k phy0: (ath5k_reset:2648): resetting
>>> kernel: [ 195.599009] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32
>>> rx_bufsize 2368
>>> kernel: [ 195.652078] ath5k phy0: (ath5k_chan_set:434): channel set,
>>> resetting (2427 -> 2432 MHz)
>>> kernel: [ 245.188077] net_ratelimit: 29 callbacks suppressed
>>> kernel: [ 245.188091] ath5k phy0: (ath5k_chan_set:434): channel set,
>>> resetting (2412 -> 2417 MHz)
>>> kernel: [ 245.188100] ath5k phy0: (ath5k_reset:2648): resetting
>>> kernel: [ 245.290997] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32
>>> rx_bufsize 2368
>>> kernel: [ 245.344084] ath5k phy0: (ath5k_chan_set:434): channel set,
>>> resetting (2417 -> 2422 MHz)
>>> kernel: [ 245.344092] ath5k phy0: (ath5k_reset:2648): resetting
>>> kernel: [ 245.446882] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32
>>> rx_bufsize 2368
>>> kernel: [ 245.500053] ath5k phy0: (ath5k_chan_set:434): channel set,
>>> resetting (2422 -> 2427 MHz)
>>> kernel: [ 245.500058] ath5k phy0: (ath5k_reset:2648): resetting
>>> kernel: [ 245.602808] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32
>>> rx_bufsize 2368
>>> kernel: [ 245.656046] ath5k phy0: (ath5k_chan_set:434): channel set,
>>> resetting (2427 -> 2432 MHz)
>>> kernel: [ 305.188050] net_ratelimit: 29 callbacks suppressed
>>> kernel: [ 305.188063] ath5k phy0: (ath5k_chan_set:434): channel set,
>>> resetting (2412 -> 2417 MHz)
>>> kernel: [ 305.188071] ath5k phy0: (ath5k_reset:2648): resetting
>>> kernel: [ 305.290945] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32
>>> rx_bufsize 2368
>>> kernel: [ 305.344070] ath5k phy0: (ath5k_chan_set:434): channel set,
>>> resetting (2417 -> 2422 MHz)
>>> kernel: [ 305.344082] ath5k phy0: (ath5k_reset:2648): resetting
>>> kernel: [ 305.446943] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32
>>> rx_bufsize 2368
>>> kernel: [ 305.500047] ath5k phy0: (ath5k_chan_set:434): channel set,
>>> resetting (2422 -> 2427 MHz)
>>> kernel: [ 305.500058] ath5k phy0: (ath5k_reset:2648): resetting
>>> kernel: [ 305.602967] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32
>>> rx_bufsize 2368
>>> kernel: [ 305.656090] ath5k phy0: (ath5k_chan_set:434): channel set,
>>> resetting (2427 -> 2432 MHz)
>>> NetworkManager[725]:<info> (wlan0): device state change: 3 -> 2 (reason
>>> 0)
>>> NetworkManager[725]:<info> (wlan0): deactivating device (reason: 0).
>>> NetworkManager[725]:<info> (wlan0): taking down device.
>>> kernel: [ 310.887530] net_ratelimit: 29 callbacks suppressed
>>> kernel: [ 310.887535] ath5k phy0: (ath5k_stop_locked:2481): invalid 0
>>> kernel: [ 310.990264] ath5k phy0: (ath5k_stop_hw:2619): putting device
>>> to sleep
>>> kernel: [ 310.990554] ath5k phy0: (ath5k_rfkill_enable:51): rfkill
>>> enable (gpio:0 polarity:0)
>>> NetworkManager[725]:<info> (wlan0): bringing up device.
>>> kernel: [ 315.755891] ath5k phy0: (ath5k_init_hw:2522): mode 2
>>> kernel: [ 315.755903] ath5k phy0: (ath5k_stop_locked:2481): invalid 0
>>> kernel: [ 315.756624] ath5k phy0: (ath5k_reset:2648): resetting
>>> kernel: [ 315.760236] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32
>>> rx_bufsize 2368
>>> kernel: [ 315.760474] ath5k phy0: (ath5k_rfkill_disable:42): rfkill
>>> disable (gpio:0 polarity:0)
>>> kernel: [ 315.762566] ath5k phy0: (ath5k_chan_set:434): channel set,
>>> resetting (2412 -> 2412 MHz)
>>> kernel: [ 315.762574] ath5k phy0: (ath5k_reset:2648): resetting
>>> kernel: [ 315.764972] ADDRCONF(NETDEV_UP): wlan0: link is not ready
>>> NetworkManager[725]:<info> (wlan0): supplicant interface state:
>>> starting -> ready
>>> NetworkManager[725]:<info> (wlan0): device state change: 2 -> 3 (reason
>>> 42)
>>> wpa_supplicant[745]: Failed to initiate AP scan.
>>> kernel: [ 316.036068] net_ratelimit: 8 callbacks suppressed
>>> kernel: [ 316.036080] ath5k phy0: (ath5k_chan_set:434): channel set,
>>> resetting (2417 -> 2422 MHz)
>>> kernel: [ 316.036089] ath5k phy0: (ath5k_reset:2648): resetting
>>> kernel: [ 316.140039] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32
>>> rx_bufsize 2368
>>> kernel: [ 316.196067] ath5k phy0: (ath5k_chan_set:434): channel set,
>>> resetting (2422 -> 2427 MHz)
>>> kernel: [ 316.196079] ath5k phy0: (ath5k_reset:2648): resetting
>>> kernel: [ 316.298940] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32
>>> rx_bufsize 2368
>>> kernel: [ 316.352063] ath5k phy0: (ath5k_chan_set:434): channel set,
>>> resetting (2427 -> 2432 MHz)
>>> kernel: [ 316.352071] ath5k phy0: (ath5k_reset:2648): resetting
>>> kernel: [ 316.455003] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32
>>> rx_bufsize 2368
>>> kernel: [ 316.508080] ath5k phy0: (ath5k_chan_set:434): channel set,
>>> resetting (2432 -> 2437 MHz)
>>> kernel: [ 336.188067] net_ratelimit: 26 callbacks suppressed
>>> kernel: [ 336.188080] ath5k phy0: (ath5k_chan_set:434): channel set,
>>> resetting (2412 -> 2417 MHz)
>>> kernel: [ 336.188088] ath5k phy0: (ath5k_reset:2648): resetting
>>> kernel: [ 336.290966] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32
>>> rx_bufsize 2368
>>> kernel: [ 336.344059] ath5k phy0: (ath5k_chan_set:434): channel set,
>>> resetting (2417 -> 2422 MHz)
>>> kernel: [ 336.344068] ath5k phy0: (ath5k_reset:2648): resetting
>>> kernel: [ 336.446912] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32
>>> rx_bufsize 2368
>>> kernel: [ 336.500068] ath5k phy0: (ath5k_chan_set:434): channel set,
>>> resetting (2422 -> 2427 MHz)
>>> kernel: [ 336.500077] ath5k phy0: (ath5k_reset:2648): resetting
>>> kernel: [ 336.602937] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32
>>> rx_bufsize 2368
>>> kernel: [ 336.656058] ath5k phy0: (ath5k_chan_set:434): channel set,
>>> resetting (2427 -> 2432 MHz)
>>> kernel: [ 366.188084] net_ratelimit: 29 callbacks suppressed
>>> kernel: [ 366.188097] ath5k phy0: (ath5k_chan_set:434): channel set,
>>> resetting (2412 -> 2417 MHz)
>>> kernel: [ 366.188105] ath5k phy0: (ath5k_reset:2648): resetting
>>> kernel: [ 366.290999] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32
>>> rx_bufsize 2368
>>> kernel: [ 366.344099] ath5k phy0: (ath5k_chan_set:434): channel set,
>>> resetting (2417 -> 2422 MHz)
>>> kernel: [ 366.344112] ath5k phy0: (ath5k_reset:2648): resetting
>>> kernel: [ 366.447030] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32
>>> rx_bufsize 2368
>>> kernel: [ 366.500094] ath5k phy0: (ath5k_chan_set:434): channel set,
>>> resetting (2422 -> 2427 MHz)
>>> kernel: [ 366.500106] ath5k phy0: (ath5k_reset:2648): resetting
>>> kernel: [ 366.603008] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32
>>> rx_bufsize 2368
>>> kernel: [ 366.656103] ath5k phy0: (ath5k_chan_set:434): channel set,
>>> resetting (2427 -> 2432 MHz)
>>>
>>>
>>
>> Hmm I don't see any errors from reset/phy code, can you disable
>> Network Manager/wpa-supplicant and test connection on an open network
>> using iw ? It 'll give us a better picture...
>>
>> If iw doesn't return any scan results we are probably hitting a PHY/RF
>> error specific to your device (not all vendors follow the reference
>> design). Maybe we should follow a blacklist/whitelist approach for
>> this feature.
>>
>
> yeah Im getting this over here with my macbook pro. all of a sudden internet
> craps out, unable to reconnect.. reboot is the only way to get back online.
> dmesg here:
> http://fpaste.org/mwGn/
>
> I can try bisecting, but might take a while due to this occuring every few
> days or so.
>
> Justin P. Mattock
>
[ 26.219909] ath9k 0000:03:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
Different card, different driver...
--
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick
^ permalink raw reply
* [PATCH 3/3] virtio_ring: need_event api comment fix
From: Michael S. Tsirkin @ 2011-05-05 15:08 UTC (permalink / raw)
To: linux-kernel
Cc: Rusty Russell, Carsten Otte, Christian Borntraeger, linux390,
Martin Schwidefsky, Heiko Carstens, Shirley Ma, lguest,
linux-kernel, virtualization, netdev, linux-s390, kvm,
Krishna Kumar, Tom Lendacky, steved, habanero
In-Reply-To: <cover.1304605816.git.mst@redhat.com>
fix typo in a comment: size -> side
Reported-by: Stefan Hajnoczi <stefanha@gmail.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
include/linux/virtio_ring.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/linux/virtio_ring.h b/include/linux/virtio_ring.h
index 089cbf2..0a45c6e 100644
--- a/include/linux/virtio_ring.h
+++ b/include/linux/virtio_ring.h
@@ -131,7 +131,7 @@ static inline unsigned vring_size(unsigned int num, unsigned long align)
}
/* The following is used with USED_EVENT_IDX and AVAIL_EVENT_IDX */
-/* Assuming a given event_idx value from the other size, if
+/* Assuming a given event_idx value from the other side, if
* we have just incremented index from old to new_idx,
* should we trigger an event? */
static inline int vring_need_event(__u16 event_idx, __u16 new_idx, __u16 old)
--
1.7.5.53.gc233e
^ permalink raw reply related
* [PATCH 2/3] virtio_ring: check used_event offset
From: Michael S. Tsirkin @ 2011-05-05 15:08 UTC (permalink / raw)
To: linux-kernel
Cc: Rusty Russell, Carsten Otte, Christian Borntraeger, linux390,
Martin Schwidefsky, Heiko Carstens, Shirley Ma, lguest,
linux-kernel, virtualization, netdev, linux-s390, kvm,
Krishna Kumar, Tom Lendacky, steved, habanero
In-Reply-To: <cover.1304605816.git.mst@redhat.com>
Nothing's wrong with vring_size as is, but it's nice
to check that the new field in the avail ring
won't overlow into the used ring.
Reported-by: Tom Lendacky <tahm@linux.vnet.ibm.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
include/linux/virtio_ring.h | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/include/linux/virtio_ring.h b/include/linux/virtio_ring.h
index 2a3b0ea..089cbf2 100644
--- a/include/linux/virtio_ring.h
+++ b/include/linux/virtio_ring.h
@@ -119,7 +119,13 @@ static inline void vring_init(struct vring *vr, unsigned int num, void *p,
static inline unsigned vring_size(unsigned int num, unsigned long align)
{
- return ((sizeof(struct vring_desc) * num + sizeof(__u16) * (2 + num)
+#ifdef __KERNEL__
+ /* Older versions did not have used_event field at the end of the
+ * avail ring. Used ring offset must be compatible with such devices. */
+ size_t s = sizeof(struct vring_desc) * num + sizeof(__u16) * (2 + num);
+ BUG_ON(ALIGN(s, align) != ALIGN(s + sizeof(__u16), align));
+#endif
+ return ((sizeof(struct vring_desc) * num + sizeof(__u16) * (3 + num)
+ align - 1) & ~(align - 1))
+ sizeof(__u16) * 3 + sizeof(struct vring_used_elem) * num;
}
--
1.7.5.53.gc233e
^ permalink raw reply related
* [PATCH 1/3] virtio: fix avail event support
From: Michael S. Tsirkin @ 2011-05-05 15:08 UTC (permalink / raw)
To: linux-kernel
Cc: Rusty Russell, Carsten Otte, Christian Borntraeger, linux390,
Martin Schwidefsky, Heiko Carstens, Shirley Ma, lguest,
linux-kernel, virtualization, netdev, linux-s390, kvm,
Krishna Kumar, Tom Lendacky, steved, habanero
In-Reply-To: <cover.1304605816.git.mst@redhat.com>
make valid flag false, not true, on overrun
Reported-by: Tom Lendacky <tahm@linux.vnet.ibm.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
drivers/virtio/virtio_ring.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
index 57bf9d5..0ea0781 100644
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
@@ -242,7 +242,7 @@ add_head:
* kicked_avail index we stored. TODO: make sure all drivers
* kick at least once in 2^16 and remove this. */
if (unlikely(vq->vring.avail->idx == vq->kicked_avail))
- vq->kicked_avail_valid = true;
+ vq->kicked_avail_valid = false;
pr_debug("Added buffer head %i to %p\n", head, vq);
END_USE(vq);
--
1.7.5.53.gc233e
^ permalink raw reply related
* [PATCH 0/3] virtio and vhost-net performance enhancements
From: Michael S. Tsirkin @ 2011-05-05 15:07 UTC (permalink / raw)
To: linux-kernel
Cc: Rusty Russell, Carsten Otte, Christian Borntraeger, linux390,
Martin Schwidefsky, Heiko Carstens, Shirley Ma, lguest,
linux-kernel, virtualization, netdev, linux-s390, kvm,
Krishna Kumar, Tom Lendacky, steved, habanero
In-Reply-To: <cover.1304541918.git.mst@redhat.com>
Here are a couple of minor fixes suggested on list.
Applies on top of the previous patchset.
As before result pushed here:
git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git vhost-net-next-event-idx-v1
Michael S. Tsirkin (3):
virtio: fix avail event support
virtio_ring: check used_event offset
virtio_ring: need_event api comment fix
drivers/virtio/virtio_ring.c | 2 +-
include/linux/virtio_ring.h | 10 ++++++++--
2 files changed, 9 insertions(+), 3 deletions(-)
--
1.7.5.53.gc233e
^ permalink raw reply
* Re: ath5k regression associating with APs in 2.6.38
From: Justin P. Mattock @ 2011-05-05 15:01 UTC (permalink / raw)
To: Nick Kossifidis
Cc: John W. Linville, Jiri Slaby, Luis R. Rodriguez, Bob Copeland,
linux-wireless, ath5k-devel, netdev, linux-kernel
In-Reply-To: <BANLkTinkiTQU2k7vBEc0JPGa01AUVCvp2Q@mail.gmail.com>
On 05/05/2011 07:30 AM, Nick Kossifidis wrote:
> 2011/5/5 Seth Forshee<seth.forshee@canonical.com>:
>> On Wed, May 04, 2011 at 11:09:03PM +0300, Nick Kossifidis wrote:
>>> 2011/5/4 Seth Forshee<seth.forshee@canonical.com>:
>>>> On Wed, May 04, 2011 at 01:27:17PM -0400, John W. Linville wrote:
>>>>> On Wed, May 04, 2011 at 10:38:19AM -0500, Seth Forshee wrote:
>>>>>> I've been investigating some reports of a regression in associating with
>>>>>> APs with AR2413 in 2.6.38. Association repeatedly fails with some
>>>>>> "direct probe to x timed out" messages (see syslog excerpt below),
>>>>>> although it will generally associate eventually, after many tries.
>>>>>>
>>>>>> Bisection identifies 8aec7af (ath5k: Support synth-only channel change
>>>>>> for AR2413/AR5413) as offending commit. Prior to this commit there are
>>>>>> no direct probe messages at all in the logs. I've also found that
>>>>>> forcing fast to false at the top of ath5k_hw_reset() fixes the issue.
>>>>>> I'm not sure what the connection is between this commit and the
>>>>>> timeouts. Any suggestions?
>>>>>
>>>>> Have you tried reverting that commit on top of 2.6.38? Can you
>>>>> recreate the issue with 2.6.39-rc6 (or later)?
>>>>
>>>> I started to revert that commit, but it wasn't straight-forward due to
>>>> later changes. Forcing fast to false in ath5k_hw_reset() acts as a
>>>> functional revert of sorts since that should force it back to a full
>>>> reset for all channel changes, and it's much simpler than working out
>>>> the right way to revert the commit. I think the results suggest strongly
>>>> that a revert is likely to fix the problem. I can finish the work to
>>>> revert if you'd still like to see the results.
>>>>
>>>> Testing a previous .39-rc kernel still exhibited the failure. I don't
>>>> recall which one it was and apparently forgot to make note of it. I'll
>>>> request testing against rc6.
>>>>
>>>> Thanks,
>>>> Seth
>>>>
>>>
>>> Do you get scan results ?
>>> Can you enable ATH5K_DEBUG_RESET and see what you get ?
>>
>> 2.6.39-rc6 still fails. A more comprehensive log with ATH5K_DEBUG_RESET
>> enabled is below.
>>
>> Scanning looks to be failing according to this log. I was thinking that
>> I saw successfull scans in some of the previous logs, but I'll have to
>> go back and check to be sure.
>>
>> Thanks,
>> Seth
>>
>>
>> kernel: [ 23.421242] ath5k 0000:06:02.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
>> kernel: [ 23.421312] ath5k 0000:06:02.0: registered as 'phy0'
>> kernel: [ 24.132959] ath: EEPROM regdomain: 0x63
>> kernel: [ 24.132962] ath: EEPROM indicates we should expect a direct regpair map
>> kernel: [ 24.132967] ath: Country alpha2 being used: 00
>> kernel: [ 24.132969] ath: Regpair used: 0x63
>> kernel: [ 24.136125] cfg80211: Updating information on frequency 2412 MHz for a 20 MHz width channel with regulatory rule:
>> kernel: [ 24.136131] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (N/A mBi, 2000 mBm)
>> kernel: [ 24.136134] cfg80211: Updating information on frequency 2417 MHz for a 20 MHz width channel with regulatory rule:
>> kernel: [ 24.136137] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (N/A mBi, 2000 mBm)
>> kernel: [ 24.136140] cfg80211: Updating information on frequency 2422 MHz for a 20 MHz width channel with regulatory rule:
>> kernel: [ 24.136143] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (N/A mBi, 2000 mBm)
>> kernel: [ 24.136146] cfg80211: Updating information on frequency 2427 MHz for a 20 MHz width channel with regulatory rule:
>> kernel: [ 24.136149] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (N/A mBi, 2000 mBm)
>> kernel: [ 24.136151] cfg80211: Updating information on frequency 2432 MHz for a 20 MHz width channel with regulatory rule:
>> kernel: [ 24.136155] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (N/A mBi, 2000 mBm)
>> kernel: [ 24.136157] cfg80211: Updating information on frequency 2437 MHz for a 20 MHz width channel with regulatory rule:
>> kernel: [ 24.136160] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (N/A mBi, 2000 mBm)
>> kernel: [ 24.136163] cfg80211: Updating information on frequency 2442 MHz for a 20 MHz width channel with regulatory rule:
>> kernel: [ 24.136166] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (N/A mBi, 2000 mBm)
>> kernel: [ 24.136168] cfg80211: Updating information on frequency 2447 MHz for a 20 MHz width channel with regulatory rule:
>> kernel: [ 24.136172] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (N/A mBi, 2000 mBm)
>> kernel: [ 24.136174] cfg80211: Updating information on frequency 2452 MHz for a 20 MHz width channel with regulatory rule:
>> kernel: [ 24.136177] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (N/A mBi, 2000 mBm)
>> kernel: [ 24.136180] cfg80211: Updating information on frequency 2457 MHz for a 20 MHz width channel with regulatory rule:
>> kernel: [ 24.136183] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (N/A mBi, 2000 mBm)
>> kernel: [ 24.136186] cfg80211: Updating information on frequency 2462 MHz for a 20 MHz width channel with regulatory rule:
>> kernel: [ 24.136189] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (N/A mBi, 2000 mBm)
>> kernel: [ 24.136191] cfg80211: Updating information on frequency 2467 MHz for a 20 MHz width channel with regulatory rule:
>> kernel: [ 24.136195] cfg80211: 2457000 KHz - 2482000 KHz @ KHz), (N/A mBi, 2000 mBm)
>> kernel: [ 24.136197] cfg80211: Updating information on frequency 2472 MHz for a 20 MHz width channel with regulatory rule:
>> kernel: [ 24.136200] cfg80211: 2457000 KHz - 2482000 KHz @ KHz), (N/A mBi, 2000 mBm)
>> kernel: [ 24.136203] cfg80211: Disabling freq 2484 MHz as custom regd has no rule that fits a 20 MHz wide channel
>> kernel: [ 24.136404] cfg80211: Ignoring regulatory request Set by core since the driver uses its own custom regulatory domain
>> kernel: [ 24.393924] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
>> kernel: [ 24.394588] ath5k phy0: Atheros AR2413 chip found (MAC: 0x78, PHY: 0x45)
>> ...
>> NetworkManager[725]:<info> (wlan0): driver supports SSID scans (scan_capa 0x01).
>> NetworkManager[725]:<info> (wlan0): new 802.11 WiFi device (driver: 'ath5k' ifindex: 3)
>> NetworkManager[725]:<info> (wlan0): exported as /org/freedesktop/NetworkManager/Devices/1
>> NetworkManager[725]:<info> (wlan0): now managed
>> NetworkManager[725]:<info> (wlan0): device state change: 1 -> 2 (reason 2)
>> NetworkManager[725]:<info> (wlan0): bringing up device.
>> NetworkManager[725]:<info> (wlan0): preparing device.
>> NetworkManager[725]:<info> (wlan0): deactivating device (reason: 2).
>> NetworkManager[725]: supplicant_interface_acquire: assertion `mgr_state == NM_SUPPLICANT_MANAGER_STATE_IDLE' failed
>> kernel: [ 25.149294] ADDRCONF(NETDEV_UP): wlan0: link is not ready
>> ...
>> NetworkManager[725]:<info> Trying to start the supplicant...
>> ...
>> NetworkManager[725]:<info> (wlan0): supplicant manager state: down -> idle
>> NetworkManager[725]:<info> (wlan0): device state change: 2 -> 3 (reason 0)
>> NetworkManager[725]:<info> (wlan0): supplicant interface state: starting -> ready
>> ...
>> NetworkManager[725]:<info> (wlan0): device state change: 3 -> 2 (reason 0)
>> NetworkManager[725]:<info> (wlan0): deactivating device (reason: 0).
>> NetworkManager[725]:<info> (wlan0): taking down device.
>> NetworkManager[725]:<info> (wlan0): bringing up device.
>> kernel: [ 104.430292] ath5k phy0: (ath5k_init_hw:2522): mode 2
>> kernel: [ 104.430297] ath5k phy0: (ath5k_stop_locked:2481): invalid 0
>> kernel: [ 104.431000] ath5k phy0: (ath5k_reset:2648): resetting
>> kernel: [ 104.434475] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32 rx_bufsize 2368
>> kernel: [ 104.434683] ath5k phy0: (ath5k_rfkill_disable:42): rfkill disable (gpio:0 polarity:0)
>> kernel: [ 104.435759] ath5k phy0: (ath5k_chan_set:434): channel set, resetting (2412 -> 2412 MHz)
>> kernel: [ 104.435762] ath5k phy0: (ath5k_reset:2648): resetting
>> kernel: [ 104.436845] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32 rx_bufsize 2368
>> kernel: [ 104.437191] ath5k phy0: (ath5k_conf_tx:602): Configure tx [queue 0], aifs: 2, cw_min: 7, cw_max: 15, txop: 102
>> kernel: [ 104.437212] ath5k phy0: (ath5k_conf_tx:602): Configure tx [queue 1], aifs: 2, cw_min: 15, cw_max: 31, txop: 188
>> kernel: [ 104.438337] ADDRCONF(NETDEV_UP): wlan0: link is not ready
>> NetworkManager[725]:<info> (wlan0): supplicant interface state: starting -> ready
>> NetworkManager[725]:<info> (wlan0): device state change: 2 -> 3 (reason 42)
>> wpa_supplicant[745]: Failed to initiate AP scan.
>> kernel: [ 125.188087] net_ratelimit: 41 callbacks suppressed
>> kernel: [ 125.188100] ath5k phy0: (ath5k_chan_set:434): channel set, resetting (2412 -> 2417 MHz)
>> kernel: [ 125.188109] ath5k phy0: (ath5k_reset:2648): resetting
>> kernel: [ 125.291007] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32 rx_bufsize 2368
>> kernel: [ 125.344076] ath5k phy0: (ath5k_chan_set:434): channel set, resetting (2417 -> 2422 MHz)
>> kernel: [ 125.344090] ath5k phy0: (ath5k_reset:2648): resetting
>> kernel: [ 125.447014] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32 rx_bufsize 2368
>> kernel: [ 125.500078] ath5k phy0: (ath5k_chan_set:434): channel set, resetting (2422 -> 2427 MHz)
>> kernel: [ 125.500091] ath5k phy0: (ath5k_reset:2648): resetting
>> kernel: [ 125.602999] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32 rx_bufsize 2368
>> kernel: [ 125.656070] ath5k phy0: (ath5k_chan_set:434): channel set, resetting (2427 -> 2432 MHz)
>> kernel: [ 155.188052] net_ratelimit: 29 callbacks suppressed
>> kernel: [ 155.188058] ath5k phy0: (ath5k_chan_set:434): channel set, resetting (2412 -> 2417 MHz)
>> kernel: [ 155.188061] ath5k phy0: (ath5k_reset:2648): resetting
>> kernel: [ 155.290844] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32 rx_bufsize 2368
>> kernel: [ 155.344032] ath5k phy0: (ath5k_chan_set:434): channel set, resetting (2417 -> 2422 MHz)
>> kernel: [ 155.344038] ath5k phy0: (ath5k_reset:2648): resetting
>> kernel: [ 155.446810] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32 rx_bufsize 2368
>> kernel: [ 155.500031] ath5k phy0: (ath5k_chan_set:434): channel set, resetting (2422 -> 2427 MHz)
>> kernel: [ 155.500036] ath5k phy0: (ath5k_reset:2648): resetting
>> kernel: [ 155.602811] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32 rx_bufsize 2368
>> kernel: [ 155.656033] ath5k phy0: (ath5k_chan_set:434): channel set, resetting (2427 -> 2432 MHz)
>> kernel: [ 195.184088] net_ratelimit: 29 callbacks suppressed
>> kernel: [ 195.184102] ath5k phy0: (ath5k_chan_set:434): channel set, resetting (2412 -> 2417 MHz)
>> kernel: [ 195.184110] ath5k phy0: (ath5k_reset:2648): resetting
>> kernel: [ 195.287022] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32 rx_bufsize 2368
>> kernel: [ 195.340066] ath5k phy0: (ath5k_chan_set:434): channel set, resetting (2417 -> 2422 MHz)
>> kernel: [ 195.340079] ath5k phy0: (ath5k_reset:2648): resetting
>> kernel: [ 195.442967] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32 rx_bufsize 2368
>> kernel: [ 195.496076] ath5k phy0: (ath5k_chan_set:434): channel set, resetting (2422 -> 2427 MHz)
>> kernel: [ 195.496088] ath5k phy0: (ath5k_reset:2648): resetting
>> kernel: [ 195.599009] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32 rx_bufsize 2368
>> kernel: [ 195.652078] ath5k phy0: (ath5k_chan_set:434): channel set, resetting (2427 -> 2432 MHz)
>> kernel: [ 245.188077] net_ratelimit: 29 callbacks suppressed
>> kernel: [ 245.188091] ath5k phy0: (ath5k_chan_set:434): channel set, resetting (2412 -> 2417 MHz)
>> kernel: [ 245.188100] ath5k phy0: (ath5k_reset:2648): resetting
>> kernel: [ 245.290997] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32 rx_bufsize 2368
>> kernel: [ 245.344084] ath5k phy0: (ath5k_chan_set:434): channel set, resetting (2417 -> 2422 MHz)
>> kernel: [ 245.344092] ath5k phy0: (ath5k_reset:2648): resetting
>> kernel: [ 245.446882] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32 rx_bufsize 2368
>> kernel: [ 245.500053] ath5k phy0: (ath5k_chan_set:434): channel set, resetting (2422 -> 2427 MHz)
>> kernel: [ 245.500058] ath5k phy0: (ath5k_reset:2648): resetting
>> kernel: [ 245.602808] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32 rx_bufsize 2368
>> kernel: [ 245.656046] ath5k phy0: (ath5k_chan_set:434): channel set, resetting (2427 -> 2432 MHz)
>> kernel: [ 305.188050] net_ratelimit: 29 callbacks suppressed
>> kernel: [ 305.188063] ath5k phy0: (ath5k_chan_set:434): channel set, resetting (2412 -> 2417 MHz)
>> kernel: [ 305.188071] ath5k phy0: (ath5k_reset:2648): resetting
>> kernel: [ 305.290945] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32 rx_bufsize 2368
>> kernel: [ 305.344070] ath5k phy0: (ath5k_chan_set:434): channel set, resetting (2417 -> 2422 MHz)
>> kernel: [ 305.344082] ath5k phy0: (ath5k_reset:2648): resetting
>> kernel: [ 305.446943] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32 rx_bufsize 2368
>> kernel: [ 305.500047] ath5k phy0: (ath5k_chan_set:434): channel set, resetting (2422 -> 2427 MHz)
>> kernel: [ 305.500058] ath5k phy0: (ath5k_reset:2648): resetting
>> kernel: [ 305.602967] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32 rx_bufsize 2368
>> kernel: [ 305.656090] ath5k phy0: (ath5k_chan_set:434): channel set, resetting (2427 -> 2432 MHz)
>> NetworkManager[725]:<info> (wlan0): device state change: 3 -> 2 (reason 0)
>> NetworkManager[725]:<info> (wlan0): deactivating device (reason: 0).
>> NetworkManager[725]:<info> (wlan0): taking down device.
>> kernel: [ 310.887530] net_ratelimit: 29 callbacks suppressed
>> kernel: [ 310.887535] ath5k phy0: (ath5k_stop_locked:2481): invalid 0
>> kernel: [ 310.990264] ath5k phy0: (ath5k_stop_hw:2619): putting device to sleep
>> kernel: [ 310.990554] ath5k phy0: (ath5k_rfkill_enable:51): rfkill enable (gpio:0 polarity:0)
>> NetworkManager[725]:<info> (wlan0): bringing up device.
>> kernel: [ 315.755891] ath5k phy0: (ath5k_init_hw:2522): mode 2
>> kernel: [ 315.755903] ath5k phy0: (ath5k_stop_locked:2481): invalid 0
>> kernel: [ 315.756624] ath5k phy0: (ath5k_reset:2648): resetting
>> kernel: [ 315.760236] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32 rx_bufsize 2368
>> kernel: [ 315.760474] ath5k phy0: (ath5k_rfkill_disable:42): rfkill disable (gpio:0 polarity:0)
>> kernel: [ 315.762566] ath5k phy0: (ath5k_chan_set:434): channel set, resetting (2412 -> 2412 MHz)
>> kernel: [ 315.762574] ath5k phy0: (ath5k_reset:2648): resetting
>> kernel: [ 315.764972] ADDRCONF(NETDEV_UP): wlan0: link is not ready
>> NetworkManager[725]:<info> (wlan0): supplicant interface state: starting -> ready
>> NetworkManager[725]:<info> (wlan0): device state change: 2 -> 3 (reason 42)
>> wpa_supplicant[745]: Failed to initiate AP scan.
>> kernel: [ 316.036068] net_ratelimit: 8 callbacks suppressed
>> kernel: [ 316.036080] ath5k phy0: (ath5k_chan_set:434): channel set, resetting (2417 -> 2422 MHz)
>> kernel: [ 316.036089] ath5k phy0: (ath5k_reset:2648): resetting
>> kernel: [ 316.140039] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32 rx_bufsize 2368
>> kernel: [ 316.196067] ath5k phy0: (ath5k_chan_set:434): channel set, resetting (2422 -> 2427 MHz)
>> kernel: [ 316.196079] ath5k phy0: (ath5k_reset:2648): resetting
>> kernel: [ 316.298940] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32 rx_bufsize 2368
>> kernel: [ 316.352063] ath5k phy0: (ath5k_chan_set:434): channel set, resetting (2427 -> 2432 MHz)
>> kernel: [ 316.352071] ath5k phy0: (ath5k_reset:2648): resetting
>> kernel: [ 316.455003] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32 rx_bufsize 2368
>> kernel: [ 316.508080] ath5k phy0: (ath5k_chan_set:434): channel set, resetting (2432 -> 2437 MHz)
>> kernel: [ 336.188067] net_ratelimit: 26 callbacks suppressed
>> kernel: [ 336.188080] ath5k phy0: (ath5k_chan_set:434): channel set, resetting (2412 -> 2417 MHz)
>> kernel: [ 336.188088] ath5k phy0: (ath5k_reset:2648): resetting
>> kernel: [ 336.290966] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32 rx_bufsize 2368
>> kernel: [ 336.344059] ath5k phy0: (ath5k_chan_set:434): channel set, resetting (2417 -> 2422 MHz)
>> kernel: [ 336.344068] ath5k phy0: (ath5k_reset:2648): resetting
>> kernel: [ 336.446912] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32 rx_bufsize 2368
>> kernel: [ 336.500068] ath5k phy0: (ath5k_chan_set:434): channel set, resetting (2422 -> 2427 MHz)
>> kernel: [ 336.500077] ath5k phy0: (ath5k_reset:2648): resetting
>> kernel: [ 336.602937] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32 rx_bufsize 2368
>> kernel: [ 336.656058] ath5k phy0: (ath5k_chan_set:434): channel set, resetting (2427 -> 2432 MHz)
>> kernel: [ 366.188084] net_ratelimit: 29 callbacks suppressed
>> kernel: [ 366.188097] ath5k phy0: (ath5k_chan_set:434): channel set, resetting (2412 -> 2417 MHz)
>> kernel: [ 366.188105] ath5k phy0: (ath5k_reset:2648): resetting
>> kernel: [ 366.290999] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32 rx_bufsize 2368
>> kernel: [ 366.344099] ath5k phy0: (ath5k_chan_set:434): channel set, resetting (2417 -> 2422 MHz)
>> kernel: [ 366.344112] ath5k phy0: (ath5k_reset:2648): resetting
>> kernel: [ 366.447030] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32 rx_bufsize 2368
>> kernel: [ 366.500094] ath5k phy0: (ath5k_chan_set:434): channel set, resetting (2422 -> 2427 MHz)
>> kernel: [ 366.500106] ath5k phy0: (ath5k_reset:2648): resetting
>> kernel: [ 366.603008] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32 rx_bufsize 2368
>> kernel: [ 366.656103] ath5k phy0: (ath5k_chan_set:434): channel set, resetting (2427 -> 2432 MHz)
>>
>>
>
> Hmm I don't see any errors from reset/phy code, can you disable
> Network Manager/wpa-supplicant and test connection on an open network
> using iw ? It 'll give us a better picture...
>
> If iw doesn't return any scan results we are probably hitting a PHY/RF
> error specific to your device (not all vendors follow the reference
> design). Maybe we should follow a blacklist/whitelist approach for
> this feature.
>
yeah Im getting this over here with my macbook pro. all of a sudden
internet craps out, unable to reconnect.. reboot is the only way to get
back online.
dmesg here:
http://fpaste.org/mwGn/
I can try bisecting, but might take a while due to this occuring every
few days or so.
Justin P. Mattock
^ permalink raw reply
* Re: ARM, AF_PACKET: caching problems on Marvell Kirkwood
From: Eric Dumazet @ 2011-05-05 14:56 UTC (permalink / raw)
To: Phil Sutter
Cc: linux-arm-kernel, netdev, ne, Johann Baudy, Lennert Buytenhek,
Nicolas Pitre
In-Reply-To: <20110505141107.GC30443@orbit.nwl.cc>
Le jeudi 05 mai 2011 à 16:11 +0200, Phil Sutter a écrit :
> Hi,
>
> Hasn't anyone experienced this bug but me? Can anyone reproduce the
> described behaviour on his Kirkwood-based (or even generic ARM) machine?
> I am still not sure if this is a problem of just my CPU or common
> amongst Kirkwood/VIPT/ARM machines.
>
> My workaround looks like this:
> | diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
> | index b5362e9..0672f50 100644
> | --- a/net/packet/af_packet.c
> | +++ b/net/packet/af_packet.c
> | @@ -1298,10 +1298,13 @@ static int packet_sendmsg(struct kiocb *iocb, struct socket *sock,
> | {
> | struct sock *sk = sock->sk;
> | struct packet_sock *po = pkt_sk(sk);
> | - if (po->tx_ring.pg_vec)
> | - return tpacket_snd(po, msg);
> | - else
> | - return packet_snd(sock, msg, len);
> | + int rc;
> | +
> | + flush_cache_all();
> | + rc = po->tx_ring.pg_vec ? tpacket_snd(po, msg) :
> | + packet_snd(sock, msg, len);
> | + flush_cache_all();
> | + return rc;
> | }
> |
> | /*
>
> Greetings, Phil
>
> (Full-quoting here because I've added the TX ring author and the Kirkwood
> maintainers to Cc.)
>
> On Fri, Apr 08, 2011 at 03:06:43PM +0200, Phil Sutter wrote:
> > Dear lists,
> >
> > I am experiencing severe caching issues using the TX_RING feature of
> > AF_PACKET on a Kirkwood-based system (i.e., OpenRD). This may likely be
> > a bug of the CPU/SoC itself, at least it reacts a bit picky when using
> > the preload data instruction (pld) in rather useless cases (but that's a
> > different story).
> >
> > There is simple testing code at the end of this email, effectively just
> > preparing a packet in the TX_RING and triggering it's delivery once per
> > second. The experienced symptom is that sporadically nothing goes out in
> > one iteration, and two packets in the following one.
> >
> > It looks like the kernel doesn't get the changed value of tp_status in
> > time, although userspace sees the correct value. Note that moving the
> > sleep(1) from the end of the loop to just before calling sendto() fixes
> > the problem.
> >
> > Another (more useful) workaround is to call flush_cache_all() at the
> > beginning of packet_sendmsg() in net/packet/af_packet.c. I was not able
> > to fix this with some more specific flushing at that place. Anyway, the
> > call to flush_dcache_page() from __packet_get_status() in the same
> > source file is meant to do the trick I guess. But somehow doesn't.
> >
> > Feedback regardles of which kind is highly appreciated, of course!
> >
> > Greetings, Phil
> >
> > ------------------[start of packet_mmap_test.c]--------------------
> > #include <stdint.h>
> > #include <stdio.h>
> > #include <stdlib.h>
> > #include <string.h>
> > #include <linux/if_ether.h>
> > #include <linux/if_packet.h>
> > #include <net/if.h>
> > #include <sys/ioctl.h>
> > #include <sys/mman.h>
> > #include <sys/socket.h>
> > #include <sys/types.h>
> >
> > #define PERROR_EXIT(rc, mesg) { \
> > perror(mesg); \
> > return rc; \
> > }
> >
> > int main(void)
> > {
> > uint32_t size;
> > struct sockaddr_ll sa;
> > struct ifreq ifr;
> > int index;
> > int tmp;
> > int fd;
> > struct tpacket_req packet_req;
> > struct tpacket2_hdr * ps_header_start, *ps_header;
> >
> > if ((fd = socket(AF_PACKET, SOCK_DGRAM, htons(ETH_P_ALL))) < 0)
> > PERROR_EXIT(EXIT_FAILURE, "socket");
> >
> > /* retrieve eth0's interface index number */
> > strncpy (ifr.ifr_name, "eth0", sizeof(ifr.ifr_name));
> > if (ioctl(fd, SIOCGIFINDEX, &ifr) < 0)
> > PERROR_EXIT(EXIT_FAILURE, "ioctl(SIOCGIFINDEX)");
> >
> > /* set sockaddr info */
> > memset(&sa, 0, sizeof(sa));
> > sa.sll_family = AF_PACKET;
> > sa.sll_protocol = ETH_P_ALL;
> > sa.sll_ifindex = ifr.ifr_ifindex;
> >
> > /* bind port */
> > if (bind(fd, (struct sockaddr *)&sa, sizeof(sa)) < 0)
> > PERROR_EXIT(EXIT_FAILURE, "bind()");
> >
> > tmp = TPACKET_V2;
> > if (setsockopt(fd, SOL_PACKET, PACKET_VERSION, &tmp, sizeof(tmp)) < 0)
> > PERROR_EXIT(EXIT_FAILURE, "setsockopt(PACKET_VERSION)");
> >
> > /* set packet loss option */
> > tmp = 1;
> > if (setsockopt(fd, SOL_PACKET, PACKET_LOSS, &tmp, sizeof(tmp)) < 0)
> > PERROR_EXIT(EXIT_FAILURE, "setsockopt(PACKET_LOSS)");
> >
> > /* prepare Tx ring request */
> > packet_req.tp_block_size = 1024 * 8;
> > packet_req.tp_frame_size = 1024 * 8;
> > packet_req.tp_block_nr = 1024;
> > packet_req.tp_frame_nr = 1024;
> >
> > /* send TX ring request */
> > if (setsockopt(fd, SOL_PACKET, PACKET_TX_RING,
> > &packet_req, sizeof(packet_req)) < 0)
> > PERROR_EXIT(EXIT_FAILURE, "setsockopt: PACKET_TX_RING");
> >
> > /* calculate memory to mmap in the kernel */
> > size = packet_req.tp_block_size * packet_req.tp_block_nr;
> >
> > /* mmap Tx ring buffers memory */
> > ps_header_start = mmap(0, size,
> > PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
> > if (ps_header_start < 0)
> > PERROR_EXIT(EXIT_FAILURE, "mmap");
> >
> > /* fill peer sockaddr for SOCK_DGRAM */
> > sa.sll_family = AF_PACKET;
> > sa.sll_protocol = htons(ETH_P_IP);
> > sa.sll_ifindex = ifr.ifr_ifindex;
> > sa.sll_halen = ETH_ALEN;
> > memset(&sa.sll_addr, 0xff, ETH_ALEN);
> >
> > ps_header = ps_header_start;
> > while (1) {
> > int sendlen, j;
> >
> > char *data = (void*)ps_header + TPACKET_HDRLEN
> > - sizeof(struct sockaddr_ll);
> >
> > switch((volatile uint32_t)ps_header->tp_status)
> > {
> > case TP_STATUS_AVAILABLE:
> > memset(data, 0x23, 150);
> > break;
> >
> > case TP_STATUS_WRONG_FORMAT:
> > printf("An error has occured during transfer\n");
> > exit(EXIT_FAILURE);
> > break;
> >
> > default:
> > printf("Buffer is not available, aborting\n");
> > exit(1);
> > break;
> > }
> > ps_header->tp_len = 150;
> > ps_header->tp_status = TP_STATUS_SEND_REQUEST;
> >
> > sendlen = sendto(fd, NULL, 0, 0,
> > (struct sockaddr *)&sa, sizeof(sa));
> > if (sendlen < 0)
> > perror("sendto");
> > else if (sendlen == 0)
> > printf("sendto(): nothing sent!\n");
> > else
> > printf("sendto(): sent %d bytes out\n", sendlen);
> >
> > #define ST_IS(x) ((volatile uint32_t)ps_header->tp_status == x)
> > printf("tp_status after sending: %s\n",
> > ST_IS(TP_STATUS_AVAILABLE) ? "AVAILABLE" :
> > ST_IS(TP_STATUS_SEND_REQUEST) ? "SEND_REQUEST" :
> > ST_IS(TP_STATUS_WRONG_FORMAT) ? "WRONG_FORMAT" :
> > "unknown");
> > #undef ST_IS
> >
> > ps_header = (void *)ps_header + packet_req.tp_frame_size;
> > if (ps_header >= ps_header_start + size)
> > ps_header = ps_header_start;
> >
> > sleep(1);
> > }
> > return 0;
> > }
> > --------------------[end of packet_mmap_test.c]--------------------
Hi Phil
I assume you use latest linux-2.6 or net-next-2.6 ?
Could you try to force vmalloc() use ?
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index b5362e9..0b5a89c 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -2383,7 +2383,7 @@ static inline char *alloc_one_pg_vec_page(unsigned long order)
gfp_t gfp_flags = GFP_KERNEL | __GFP_COMP |
__GFP_ZERO | __GFP_NOWARN | __GFP_NORETRY;
- buffer = (char *) __get_free_pages(gfp_flags, order);
+ buffer = NULL;
if (buffer)
return buffer;
^ permalink raw reply related
* Re: ath5k regression associating with APs in 2.6.38
From: Seth Forshee @ 2011-05-05 14:54 UTC (permalink / raw)
To: Nick Kossifidis
Cc: John W. Linville, Jiri Slaby, Luis R. Rodriguez, Bob Copeland,
linux-wireless, ath5k-devel, netdev, linux-kernel
In-Reply-To: <BANLkTinkiTQU2k7vBEc0JPGa01AUVCvp2Q@mail.gmail.com>
On Thu, May 05, 2011 at 05:30:42PM +0300, Nick Kossifidis wrote:
> Hmm I don't see any errors from reset/phy code, can you disable
> Network Manager/wpa-supplicant and test connection on an open network
> using iw ? It 'll give us a better picture...
>
> If iw doesn't return any scan results we are probably hitting a PHY/RF
> error specific to your device (not all vendors follow the reference
> design). Maybe we should follow a blacklist/whitelist approach for
> this feature.
Will do. I just got another log from my tester, which is more typical of
what he's been getting. I've pasted a portion of it below. The full log
can be viewed at
https://launchpadlibrarian.net/71137619/20110504_020639rc6%23201105050227_boot4_syslog
Thanks,
Seth
May 5 08:57:16 AcerAspire5100 NetworkManager[703]: <info> (wlan0): new 802.11 WiFi device (driver: 'ath5k' ifindex: 3)
May 5 08:57:16 AcerAspire5100 NetworkManager[703]: <info> (wlan0): exported as /org/freedesktop/NetworkManager/Devices/1
May 5 08:57:16 AcerAspire5100 NetworkManager[703]: <info> (wlan0): now managed
May 5 08:57:16 AcerAspire5100 NetworkManager[703]: <info> (wlan0): device state change: 1 -> 2 (reason 2)
May 5 08:57:16 AcerAspire5100 NetworkManager[703]: <info> (wlan0): bringing up device.
May 5 08:57:16 AcerAspire5100 NetworkManager[703]: <info> (wlan0): preparing device.
May 5 08:57:16 AcerAspire5100 NetworkManager[703]: <info> (wlan0): deactivating device (reason: 2).
May 5 08:57:16 AcerAspire5100 NetworkManager[703]: supplicant_interface_acquire: assertion `mgr_state == NM_SUPPLICANT_MANAGER_STATE_IDLE' failed
May 5 08:57:16 AcerAspire5100 kernel: [ 25.844302] ADDRCONF(NETDEV_UP): wlan0: link is not ready
May 5 08:57:16 AcerAspire5100 NetworkManager[703]: <info> modem-manager is now available
May 5 08:57:16 AcerAspire5100 NetworkManager[703]: <warn> bluez error getting default adapter: The name org.bluez was not provided by any .service files
May 5 08:57:16 AcerAspire5100 NetworkManager[703]: <info> Trying to start the supplicant...
May 5 08:57:16 AcerAspire5100 NetworkManager[703]: <info> (wlan0): supplicant manager state: down -> idle
May 5 08:57:16 AcerAspire5100 NetworkManager[703]: <info> (wlan0): device state change: 2 -> 3 (reason 0)
May 5 08:57:16 AcerAspire5100 NetworkManager[703]: <info> (wlan0): supplicant interface state: starting -> ready
...
May 5 08:57:38 AcerAspire5100 NetworkManager[703]: <info> Activation (wlan0) starting connection 'Auto aureola'
May 5 08:57:38 AcerAspire5100 NetworkManager[703]: <info> (wlan0): device state change: 3 -> 4 (reason 0)
May 5 08:57:38 AcerAspire5100 NetworkManager[703]: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) scheduled...
May 5 08:57:38 AcerAspire5100 NetworkManager[703]: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) started...
May 5 08:57:38 AcerAspire5100 NetworkManager[703]: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) scheduled...
May 5 08:57:38 AcerAspire5100 NetworkManager[703]: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) complete.
May 5 08:57:38 AcerAspire5100 NetworkManager[703]: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) starting...
May 5 08:57:38 AcerAspire5100 NetworkManager[703]: <info> (wlan0): device state change: 4 -> 5 (reason 0)
May 5 08:57:38 AcerAspire5100 NetworkManager[703]: <info> Activation (wlan0/wireless): access point 'Auto aureola' has security, but secrets are required.
May 5 08:57:38 AcerAspire5100 NetworkManager[703]: <info> (wlan0): device state change: 5 -> 6 (reason 0)
May 5 08:57:38 AcerAspire5100 NetworkManager[703]: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) complete.
May 5 08:57:39 AcerAspire5100 NetworkManager[703]: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) scheduled...
May 5 08:57:39 AcerAspire5100 NetworkManager[703]: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) started...
May 5 08:57:39 AcerAspire5100 NetworkManager[703]: <info> (wlan0): device state change: 6 -> 4 (reason 0)
May 5 08:57:39 AcerAspire5100 NetworkManager[703]: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) scheduled...
May 5 08:57:39 AcerAspire5100 NetworkManager[703]: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) complete.
May 5 08:57:39 AcerAspire5100 NetworkManager[703]: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) starting...
May 5 08:57:39 AcerAspire5100 NetworkManager[703]: <info> (wlan0): device state change: 4 -> 5 (reason 0)
May 5 08:57:39 AcerAspire5100 NetworkManager[703]: <info> Activation (wlan0/wireless): connection 'Auto aureola' has security, and secrets exist. No new secrets needed.
May 5 08:57:39 AcerAspire5100 NetworkManager[703]: <info> Config: added 'ssid' value 'aureola'
May 5 08:57:39 AcerAspire5100 NetworkManager[703]: <info> Config: added 'scan_ssid' value '1'
May 5 08:57:39 AcerAspire5100 NetworkManager[703]: <info> Config: added 'key_mgmt' value 'WPA-PSK'
May 5 08:57:39 AcerAspire5100 NetworkManager[703]: <info> Config: added 'psk' value '<omitted>'
May 5 08:57:39 AcerAspire5100 NetworkManager[703]: nm_setting_802_1x_get_pkcs11_engine_path: assertion `NM_IS_SETTING_802_1X (setting)' failed
May 5 08:57:39 AcerAspire5100 NetworkManager[703]: nm_setting_802_1x_get_pkcs11_module_path: assertion `NM_IS_SETTING_802_1X (setting)' failed
May 5 08:57:39 AcerAspire5100 NetworkManager[703]: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) complete.
May 5 08:57:39 AcerAspire5100 NetworkManager[703]: <info> Config: set interface ap_scan to 1
May 5 08:57:39 AcerAspire5100 NetworkManager[703]: <info> (wlan0): supplicant connection state: inactive -> scanning
May 5 08:57:41 AcerAspire5100 wpa_supplicant[734]: Trying to associate with c0:3f:0e:b9:f3:b2 (SSID='aureola' freq=2452 MHz)
May 5 08:57:41 AcerAspire5100 NetworkManager[703]: <info> (wlan0): supplicant connection state: scanning -> associating
May 5 08:57:41 AcerAspire5100 kernel: [ 51.261113] wlan0: direct probe to c0:3f:0e:b9:f3:b2 (try 1/3)
May 5 08:57:41 AcerAspire5100 kernel: [ 51.460049] wlan0: direct probe to c0:3f:0e:b9:f3:b2 (try 2/3)
May 5 08:57:41 AcerAspire5100 kernel: [ 51.660091] wlan0: direct probe to c0:3f:0e:b9:f3:b2 (try 3/3)
May 5 08:57:42 AcerAspire5100 kernel: [ 51.860048] wlan0: direct probe to c0:3f:0e:b9:f3:b2 timed out
May 5 08:57:51 AcerAspire5100 wpa_supplicant[734]: Authentication with c0:3f:0e:b9:f3:b2 timed out.
May 5 08:57:51 AcerAspire5100 NetworkManager[703]: <info> (wlan0): supplicant connection state: associating -> disconnected
May 5 08:57:51 AcerAspire5100 NetworkManager[703]: <info> (wlan0): supplicant connection state: disconnected -> scanning
May 5 08:57:51 AcerAspire5100 kernel: [ 61.396045] ath5k phy0: (ath5k_chan_set:434): channel set, resetting (2452 -> 2412 MHz)
May 5 08:57:51 AcerAspire5100 kernel: [ 61.396051] ath5k phy0: (ath5k_reset:2648): resetting
May 5 08:57:51 AcerAspire5100 kernel: [ 61.397135] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32 rx_bufsize 2368
May 5 08:57:51 AcerAspire5100 kernel: [ 61.452053] ath5k phy0: (ath5k_chan_set:434): channel set, resetting (2412 -> 2417 MHz)
May 5 08:57:51 AcerAspire5100 kernel: [ 61.452059] ath5k phy0: (ath5k_reset:2648): resetting
May 5 08:57:51 AcerAspire5100 kernel: [ 61.453143] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32 rx_bufsize 2368
May 5 08:57:51 AcerAspire5100 kernel: [ 61.508053] ath5k phy0: (ath5k_chan_set:434): channel set, resetting (2417 -> 2422 MHz)
May 5 08:57:51 AcerAspire5100 kernel: [ 61.508059] ath5k phy0: (ath5k_reset:2648): resetting
May 5 08:57:51 AcerAspire5100 kernel: [ 61.509143] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32 rx_bufsize 2368
May 5 08:57:51 AcerAspire5100 kernel: [ 61.564045] ath5k phy0: (ath5k_chan_set:434): channel set, resetting (2422 -> 2427 MHz)
May 5 08:57:52 AcerAspire5100 wpa_supplicant[734]: Trying to associate with c0:3f:0e:b9:f3:b2 (SSID='aureola' freq=2452 MHz)
May 5 08:57:52 AcerAspire5100 NetworkManager[703]: <info> (wlan0): supplicant connection state: scanning -> associating
May 5 08:57:52 AcerAspire5100 kernel: [ 62.364741] wlan0: direct probe to c0:3f:0e:b9:f3:b2 (try 1/3)
May 5 08:57:52 AcerAspire5100 kernel: [ 62.564061] wlan0: direct probe to c0:3f:0e:b9:f3:b2 (try 2/3)
May 5 08:57:53 AcerAspire5100 kernel: [ 62.764058] wlan0: direct probe to c0:3f:0e:b9:f3:b2 (try 3/3)
May 5 08:57:53 AcerAspire5100 kernel: [ 62.964061] wlan0: direct probe to c0:3f:0e:b9:f3:b2 timed out
May 5 08:58:02 AcerAspire5100 wpa_supplicant[734]: Authentication with c0:3f:0e:b9:f3:b2 timed out.
May 5 08:58:02 AcerAspire5100 NetworkManager[703]: <info> (wlan0): supplicant connection state: associating -> disconnected
^ 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