* Re: [net-next-2.6 PATCH 0/6 v4] macvlan: MAC Address filtering support for passthru mode
From: Greg Rose @ 2011-11-21 17:41 UTC (permalink / raw)
To: Ben Hutchings
Cc: Roopa Prabhu, netdev@vger.kernel.org, davem@davemloft.net,
chrisw@redhat.com, sri@us.ibm.com, dragos.tatulea@gmail.com,
kvm@vger.kernel.org, arnd@arndb.de, mst@redhat.com,
mchan@broadcom.com, dwang2@cisco.com, shemminger@vyatta.com,
eric.dumazet@gmail.com, kaber@trash.net, benve@cisco.com
In-Reply-To: <1321638038.2883.28.camel@bwh-desktop>
On 11/18/2011 9:40 AM, Ben Hutchings wrote:
> On Fri, 2011-11-18 at 08:58 -0800, Greg Rose wrote:
>> On 11/17/2011 4:44 PM, Ben Hutchings wrote:
>>> On Thu, 2011-11-17 at 16:32 -0800, Greg Rose wrote:
>>>> On 11/17/2011 4:15 PM, Ben Hutchings wrote:
>>>>> Sorry to come to this rather late.
>>>>>
>>>>> On Tue, 2011-11-08 at 23:55 -0800, Roopa Prabhu wrote:
>>>>> [...]
>>>>>> v2 -> v3
>>>>>> - Moved set and get filter ops from rtnl_link_ops to netdev_ops
>>>>>> - Support for SRIOV VFs.
>>>>>> [Note: The get filters msg (in the way current get rtnetlink handles
>>>>>> it) might get too big for SRIOV vfs. This patch follows existing sriov
>>>>>> vf get code and tries to accomodate filters for all VF's in a PF.
>>>>>> And for the SRIOV case I have only tested the fact that the VF
>>>>>> arguments are getting delivered to rtnetlink correctly. The code
>>>>>> follows existing sriov vf handling code so rest of it should work fine]
>>>>> [...]
>>>>>
>>>>> This is already broken for large numbers of VFs, and increasing the
>>>>> amount of information per VF is going to make the situation worse. I am
>>>>> no netlink expert but I think that the current approach of bundling all
>>>>> information about an interface in a single message may not be
>>>>> sustainable.
>>>>>
>>>>> Also, I'm unclear on why this interface is to be used to set filtering
>>>>> for the (PF) net device as well as for related VFs. Doesn't that
>>>>> duplicate the functionality of ndo_set_rx_mode and
>>>>> ndo_vlan_rx_{add,kill}_vid?
>>>>
>>>> Functionally yes but contextually no. This allows the PF driver to know
>>>> that it is setting these filters in the context of the existence of VFs,
>>>> allowing it to take appropriate action. The other two functions may be
>>>> called without the presence of SR-IOV enablement and the existence of VFs.
>>>>
>>>> Anyway, that's why I asked Roopa to add that capability.
>>>
>>> I don't follow. The PF driver already knows whether it has enabled VFs.
>>>
>>> How do filters set this way interact with filters set through the
>>> existing operations? Should they override promiscuous mode? None of
>>> this has been specified.
>>
>> Promiscuous mode is exactly the issue this feature is intended for. I'm
>> not familiar with the solarflare device but Intel HW promiscuous mode is
>> only promiscuous on the physical port, not on the VEB. So a packet sent
>> from a VF will not be captured by the PF across the VEB unless the MAC
>> and VLAN filters have been programmed into the HW.
>
> Yes, I get it. The hardware bridge needs to know more about the address
> configuration on the host than the driver is getting at the moment.
>
>> So you may not need
>> the feature for your devices but it is required for Intel devices.
>
> Well we don't have the hardware bridge but that means each VF driver
> needs to know whether to fall back to the software bridge. The net
> driver needs much the same additional information.
>
>> And
>> it's a fairly simple request, just allow -1 to indicate that the target
>> of the filter requests is for the PF itself. Using the already existing
>> set_rx_mode function wont' work because the PF driver will look at it
>> and figure it's in promiscuous mode anyway, so it won't set the filters
>> into the HW. At least that is how it is in the case of our HW and
>> driver. Again, the behavior of your HW and driver is unknown to me and
>> thus you may not require this feature.
>
> What concerns me is that this seems to be a workaround rather than a fix
> for over-use of promiscuous mode, and it changes the semantics of
> filtering modes in ways that haven't been well-specified.
I feel the opposite is true. It allows a known set of receive filters
so that you don't have to use promiscuous mode, which cuts down on
overhead from processing packets the upper layer stack isn't really
interested in.
>
> What if there's a software bridge between two net devices corresponding
> to separate physical ports, so that they really need to be promiscuous?
> What if the administrator runs tcpdump and really wants the (PF) net
> device to be promiscuous?
I don't believe there is anything in this patch set that removes
promiscuous mode operation as it is commonly used. Perhaps I've missed
something.
>
> These cases shouldn't break because of VF acceleration.
I don't see how they would in the case of Intel HW. And these new ops
to set rx filters are something that Intel HW needs because it
implements a VEB that is *not* a learning bridge and we don't want it to
be a learning bridge because of security concerns. It is better for our
requirements to be allowed to set the MAC/VLAN filters that we want a VF
to be able to see.
> Or at least we
> should make a conscious and documented decision that 'promiscuous'
> doesn't mean that if you enable it on your network adapter.
Again, I don't know of any plans to change anything relating to putting
a device in promiscuous mode or changing the semantics of what
promiscuous mode means.
- Greg
^ permalink raw reply
* Re: MPLS for Linux kernel
From: Jorge Boncompte [DTI2] @ 2011-11-21 17:46 UTC (permalink / raw)
To: shemminger; +Cc: igorm, Linux Network Development list
In-Reply-To: <20111121091711.1be69369@nehalam.linuxnetplumber.net>
El 21/11/2011 18:17, Stephen Hemminger escribió:
> On Mon, 21 Nov 2011 16:01:26 +0100
> "Jorge Boncompte [DTI2]" <jorge@dti2.net> wrote:
>
>> El 20/11/2011 22:59, Igor Maravić escribió:
>>> Hi all,
>>> I've been working on implementation of MPLS for Linux kernel, for a
>>> some time now.
>>> I continued the work of James Leu
>>> (https://sourceforge.net/projects/mpls-linux/) and used some fixes of
>>> Jorge Boncompte
>>> (http://mpls-linux.git.sourceforge.net/git/gitweb.cgi?p=mpls-linux/net-next;a=shortlog;h=refs/heads/net-next-mpls).
>>>
>>> I fixed a lot of bugs, so now it can be compiled and run with all
>>> Kernel Hacking options enabled.
>>> My code could be found on this sites:
>>>
>>> https://github.com/i-maravic/MPLS-Linux
>>> https://github.com/i-maravic/iproute2
>>>
>>> Any feedback is appreciated :)
>>
>> Provide, clean, separated, and commented changes to the upstream project as we
>> have asked you several times to do.
>>
>> mpls-linux it is not ready to go upstream in my opinion.
>
> Out of tree is out of mind. Very few developers will bother with
> a kernel component not in the mainline tree.
Yes, I am well aware of it. I've been cleaning the code, as time permits, with
the intention of trying to submit it.
>
> Staging?
I have not really looked at it but I thought that staging is only for drivers?
The mpls-linux code has some (little) hooks in the core networking stuff but I
think that maybe we can remove them and make it almost stand alone.
I would be more than happy to move the code out of the shadows.
--
==============================================================
Jorge Boncompte - Ingenieria y Gestion de RED
DTI2 - Desarrollo de la Tecnologia de las Comunicaciones
--------------------------------------------------------------
C/ Abogado Enriquez Barrios, 5 14004 CORDOBA (SPAIN)
Tlf: +34 957 761395 / FAX: +34 957 450380
==============================================================
- There is only so much duct tape you can put on something
before it just becomes a giant ball of duct tape.
==============================================================
^ permalink raw reply
* [PATCH] dm9000: Fix check for disabled wake on LAN
From: Mark Brown @ 2011-11-21 17:51 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, patches, Mark Brown
We're trying to check if any options are defined which isn't wha the
existing code does due to confusing & and &&.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
---
drivers/net/ethernet/davicom/dm9000.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/davicom/dm9000.c b/drivers/net/ethernet/davicom/dm9000.c
index 26be1df..f801754 100644
--- a/drivers/net/ethernet/davicom/dm9000.c
+++ b/drivers/net/ethernet/davicom/dm9000.c
@@ -614,7 +614,7 @@ static int dm9000_set_wol(struct net_device *dev, struct ethtool_wolinfo *w)
if (!dm->wake_state)
irq_set_irq_wake(dm->irq_wake, 1);
- else if (dm->wake_state & !opts)
+ else if (dm->wake_state && !opts)
irq_set_irq_wake(dm->irq_wake, 0);
}
--
1.7.7.3
^ permalink raw reply related
* Re: Kernel v3.0.8 igb driver dies when pulling network cable
From: Stefan Priebe @ 2011-11-21 18:07 UTC (permalink / raw)
To: Alexander Duyck
Cc: Stable Tree, stable, Greg KH, LKML, Linux Netdev List,
Jeff Kirsher,
Jesse Brandeburg <jesse.brandeburg@intel.com> Bruce Allan,
Carolyn Wyborny, Don Skidmore, Greg Rose, PJ Waskiewicz,
John Ronciak
In-Reply-To: <4ECA884C.5010706@intel.com>
> You are going to need to clarify some things since as far as I know we
> never released a v3.0.8 driver, and the kernel in the bug below is a
> version 2.6.40.8 which sounds more like a modified and possibly
> backported Linux kernel since as far as I know Linus never released a
> 2.6.40 kernel version.
Sorry that my description was so inaccurate. I'm talking about a vanilla
v3.0.8 linux kernel. Just renamed to 2.6.40.8.
> In order to be able to assist you we will need some additional
> information. What Linux distro are your running? Do you have the
> latest updates from them? Also have you tried running the latest
> out-of-tree driver we provide at e1000.sf.net in order to verify if the
> same issue occurs with that driver?
Linux Distri is Debian Lenny but we're running a self compiled vanilla
3.0.X kernel. I haven't tried to use the up2date e1000.sf.net driver as
3.0 is a long time supported kernel by greg - so all needed fixes should
be backported or at least send to stable@ so that greg can have a look
at them.
Thanks!
Stefan
^ permalink raw reply
* Re: NFS TCP race condition with SOCK_ASYNC_NOSPACE
From: Andrew Cooper @ 2011-11-21 18:14 UTC (permalink / raw)
To: Trond Myklebust,
linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <4EC6B82B.3000701-Sxgqhf6Nn4DQT0dZR+AlfA@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 547 bytes --]
Following some debugging, I believe that the attached patch fixes the
problem.
Simply returning EAGAIN is not sufficient, as the task does not get
requeued, and times out 13 seconds later (as per our mount options).
Setting the SOCK_ASYNC_NOSPACE bit causes the requeue to happen.
I realize that this is a gross hack and I should probably not be using
SOCK_ASYNC_NOSPACE in that way. Is there a better way to achieve the
same solution?
--
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com
[-- Attachment #2: NFS-fix-async-nospace-race.patch --]
[-- Type: text/x-patch, Size: 1108 bytes --]
diff -r 69bd2176baf9 net/sunrpc/xprtsock.c
--- a/net/sunrpc/xprtsock.c Mon Nov 07 13:00:06 2011 +0000
+++ b/net/sunrpc/xprtsock.c Mon Nov 21 18:00:14 2011 +0000
@@ -503,17 +503,16 @@ static int xs_nospace(struct rpc_task *t
/* Don't race with disconnect */
if (xprt_connected(xprt)) {
- if (test_bit(SOCK_ASYNC_NOSPACE, &transport->sock->flags)) {
- ret = -EAGAIN;
- /*
- * Notify TCP that we're limited by the application
- * window size
- */
- set_bit(SOCK_NOSPACE, &transport->sock->flags);
- transport->inet->sk_write_pending++;
- /* ...and wait for more buffer space */
- xprt_wait_for_buffer_space(task, xs_nospace_callback);
- }
+ set_bit(SOCK_ASYNC_NOSPACE, &transport->sock->flags);
+ ret = -EAGAIN;
+ /*
+ * Notify TCP that we're limited by the application
+ * window size
+ */
+ set_bit(SOCK_NOSPACE, &transport->sock->flags);
+ transport->inet->sk_write_pending++;
+ /* ...and wait for more buffer space */
+ xprt_wait_for_buffer_space(task, xs_nospace_callback);
} else {
clear_bit(SOCK_ASYNC_NOSPACE, &transport->sock->flags);
ret = -ENOTCONN;
^ permalink raw reply
* Re: MPLS for Linux kernel
From: David Miller @ 2011-11-21 18:29 UTC (permalink / raw)
To: jorge; +Cc: igorm, netdev
In-Reply-To: <4ECA67C6.2080802@dti2.net>
From: "Jorge Boncompte [DTI2]" <jorge@dti2.net>
Date: Mon, 21 Nov 2011 16:01:26 +0100
> mpls-linux it is not ready to go upstream in my opinion.
And can arguably be implemented in terms of openvswitch and packet scheduler actions.
^ permalink raw reply
* Re: [patch] fix error handle in ip_mc_add_src()
From: David Miller @ 2011-11-21 18:30 UTC (permalink / raw)
To: mypopydev; +Cc: netdev
In-Reply-To: <1321887946.14281.27.camel@barry.pixelworks.com>
From: Jun Zhao <mypopydev@gmail.com>
Date: Mon, 21 Nov 2011 23:05:46 +0800
> When add sources to interface failure, need to roll back the sfcount[MODE]
> to before state. We need to match it corresponding.
You need to private a proper "Signed-off-by: " tag with your patch, please
read Documentation/SubmittingPatches.
DO not just reply to this email with the signoff tag, instead make a new,
fresh, clean posting of your patch with the necessary tag.
^ permalink raw reply
* Re: WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413
From: Eric Dumazet @ 2011-11-21 18:39 UTC (permalink / raw)
To: Markus Trippelsdorf, Andrew Bresticker
Cc: Alex,Shi, linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Christoph Lameter, Pekka Enberg, Matt Mackall,
netdev@vger.kernel.org, Tejun Heo
In-Reply-To: <20111121173556.GA1673@x4.trippels.de>
Le lundi 21 novembre 2011 à 18:35 +0100, Markus Trippelsdorf a écrit :
> New one:
...
I was just wondering if you were using CONFIG_CGROUPS=y, and if yes, if
you could try to disable it.
css_get_next() looks very buggy, the read_lock()/read_unlock() protects
nothing at all, RCU rules are not respected.
commit c1e2ee2dc43657 (memcg: replace ss->id_lock with a rwlock) missed
the point of doing a true RCU conversion to get even better results, and
fact that previous code was buggy as well.
[ After rcu lookup, we must get a stable reference, then recheck the
key , or else we can manipulate something that was queued for deletion.]
An example of a correct RCU conversion was done in commit 8af088710d1
(posix-timers: RCU conversion)
--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH 6/8] net/mlx4_en: allow setting number of rx rings for, RSS/TCP
From: David Miller @ 2011-11-21 18:43 UTC (permalink / raw)
To: bhutchings; +Cc: yevgenyp, netdev, ogerlitz, oren, amirv
In-Reply-To: <1321894651.2692.1.camel@bwh-desktop>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Mon, 21 Nov 2011 16:57:30 +0000
> On Mon, 2011-11-21 at 10:43 +0200, Yevgeny Petrilin wrote:
>> From: Amir Vadai <amirv@mellanox.co.il>
>>
>> Make RSS TCP divert packets only to part of the rx rings, other could be
>> accessed by using flow steering or RFS acceleration
> [...]
>
> The ethtool {get,set}_rxfh_indir operations are a standard and more
> flexible interface for configuring this.
Agreed, you should _NEVER_ add module options or private driver extensions
for such a common configuration setting.
^ permalink raw reply
* Re: Firmware errors and warnings with Centrino Advanced-N 6205
From: Udo Steinberg @ 2011-11-21 18:48 UTC (permalink / raw)
To: wwguy; +Cc: Linux Network Mailing List, linux-wireless
In-Reply-To: <1321889065.2258.5.camel@wwguy-ubuntu>
[-- Attachment #1: Type: text/plain, Size: 22499 bytes --]
Hi Wey,
Yes, I'm using a 40 Mhz channel. "iw wlan0 link" reports:
Connected to 00:24:fe:41:8d:0e (on wlan0)
freq: 2412
RX: 80815 bytes (507 packets)
TX: 3881 bytes (34 packets)
signal: -40 dBm
tx bitrate: 40.5 MBit/s MCS 2 40Mhz
Cheers,
- Udo
On Mon, 21 Nov 2011 07:24:25 -0800 wwguy (W) wrote:
W> Hi Udo,
W>
W> Are you using 40MHz?
W>
W> Thanks
W> Wey
W>
W> On Sun, 2011-11-20 at 12:00 -0800, Udo Steinberg wrote:
W> > Hi,
W> >
W> > I'm repeatedly getting firmware errors and warnings on my Centrino 6205 WiFi
W> > card with Linux 3.1. These warnings keep filling the logs at a rate that is
W> > not funny. Any idea how to fix this issue or at least rate-limit those
W> > messages?
W> >
W> > Cheers,
W> >
W> > - Udo
W> >
W> > Excerpt from syslog:
W> >
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: Microcode SW error detected. Restarting 0x82000000.
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: Loaded firmware version: 17.168.5.3 build 42301
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: Start IWL Error Log Dump:
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: Status: 0x000512E4, count: 6
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: 0x00002078 | ADVANCED_SYSASSERT
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: 0x00009514 | uPc
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: 0x00009496 | branchlink1
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: 0x00009496 | branchlink2
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: 0x0000D1F2 | interruptlink1
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: 0x00000000 | interruptlink2
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: 0x01008035 | data1
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: 0x0000C90F | data2
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: 0x000005A7 | line
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: 0x5080B520 | beacon time
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: 0xCC515AE0 | tsf low
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: 0x00000003 | tsf hi
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: 0x00000000 | time gp1
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: 0x29703BF0 | time gp2
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: 0x00000000 | time gp3
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: 0x000111A8 | uCode version
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: 0x000000B0 | hw version
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: 0x00480303 | board version
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: 0x09E8004E | hcmd
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR values:
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: (2nd byte of CSR_INT_COALESCING is CSR_INT_PERIODIC_REG)
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_HW_IF_CONFIG_REG: 0X00480303
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_INT_COALESCING: 0X0000ff40
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_INT: 0X00000000
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_INT_MASK: 0X00000000
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_FH_INT_STATUS: 0X00000000
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_GPIO_IN: 0X00000030
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_RESET: 0X00000000
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_GP_CNTRL: 0X080403c5
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_HW_REV: 0X000000b0
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_EEPROM_REG: 0X07d60ffd
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_EEPROM_GP: 0X90000001
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_OTP_GP_REG: 0X00030001
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_GIO_REG: 0X00080044
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_GP_UCODE_REG: 0X000093bb
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_GP_DRIVER_REG: 0X00000000
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_UCODE_DRV_GP1: 0X00000000
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_UCODE_DRV_GP2: 0X00000000
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_LED_REG: 0X00000078
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_DRAM_INT_TBL_REG: 0X88214dd2
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_GIO_CHICKEN_BITS: 0X27800200
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_ANA_PLL_CFG: 0X00000000
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_HW_REV_WA_REG: 0X0001001a
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_DBG_HPET_MEM_REG: 0Xffff0010
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: FH register values:
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: FH_RSCSR_CHNL0_STTS_WPTR_REG: 0X21316d00
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: FH_RSCSR_CHNL0_RBDCB_BASE_REG: 0X021479c0
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: FH_RSCSR_CHNL0_WPTR: 0X00000060
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: FH_MEM_RCSR_CHNL0_CONFIG_REG: 0X80819104
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: FH_MEM_RSSR_SHARED_CTRL_REG: 0X000000fc
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: FH_MEM_RSSR_RX_STATUS_REG: 0X07030000
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: FH_MEM_RSSR_RX_ENABLE_ERR_IRQ2DRV: 0X00000000
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: FH_TSSR_TX_STATUS_REG: 0X07ff0001
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: FH_TSSR_TX_ERROR_REG: 0X00000000
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: Start IWL Event Log Dump: display last 20 entries
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695219435:0x028a001c:0217
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695221022:0x028b001c:0206
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695221023:0x00000001:0204
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695221026:0x00000001:0214
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695221027:0x01001110:0205
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695221051:0x00000020:0208
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695221070:0x00000000:0302
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695221104:0x00000001:0203
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695221109:0x028b001c:0206
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695221110:0x00000040:0204
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695221113:0x01000110:0211
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695221117:0x00000000:0212
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695221159:0x00000000:0215
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695221162:0x00000008:0220
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695221179:0x00000000:0302
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695221211:0x000000d4:0303
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695221215:0x0000128c:0217
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695221215:0x028b001c:0217
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695221224:0x09e8004e:0401
W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695221234:0x00000000:0125
W> > Nov 20 20:47:42 x220 kernel: iwlagn 0000:03:00.0: Error sending REPLY_ADD_STA: time out after 2000ms.
W> > Nov 20 20:47:42 x220 kernel: iwlagn 0000:03:00.0: Adding station 00:24:fe:41:8d:0e failed.
W> > Nov 20 20:47:42 x220 kernel: iwlagn 0000:03:00.0: Unable to add station 00:24:fe:41:8d:0e (-110)
W> > Nov 20 20:47:42 x220 kernel: ------------[ cut here ]------------
W> > Nov 20 20:47:42 x220 kernel: WARNING: at net/mac80211/util.c:1208 ieee80211_reconfig+0x1f1/0x407()
W> > Nov 20 20:47:42 x220 kernel: Hardware name: 4290W4H
W> > Nov 20 20:47:42 x220 kernel: Pid: 1896, comm: kworker/0:0 Not tainted 3.1.0 #2
W> > Nov 20 20:47:42 x220 kernel: Call Trace:
W> > Nov 20 20:47:42 x220 kernel: [<ffffffff81036558>] ? warn_slowpath_common+0x73/0x87
W> > Nov 20 20:47:42 x220 kernel: [<ffffffff813b8966>] ? ieee80211_reconfig+0x1f1/0x407
W> > Nov 20 20:47:42 x220 kernel: [<ffffffff8139e8dc>] ? ieee80211_recalc_smps_work+0x32/0x32
W> > Nov 20 20:47:42 x220 kernel: [<ffffffff8139e95a>] ? ieee80211_restart_work+0x7e/0x87
W> > Nov 20 20:47:42 x220 kernel: [<ffffffff810472fa>] ? process_one_work+0x1c8/0x2e3
W> > Nov 20 20:47:42 x220 kernel: [<ffffffff810480c9>] ? worker_thread+0x17a/0x23a
W> > Nov 20 20:47:42 x220 kernel: [<ffffffff81047f4f>] ? manage_workers.clone.18+0x15b/0x15b
W> > Nov 20 20:47:42 x220 kernel: [<ffffffff81047f4f>] ? manage_workers.clone.18+0x15b/0x15b
W> > Nov 20 20:47:42 x220 kernel: [<ffffffff8104ba97>] ? kthread+0x7a/0x82
W> > Nov 20 20:47:42 x220 kernel: [<ffffffff813d21b4>] ? kernel_thread_helper+0x4/0x10
W> > Nov 20 20:47:42 x220 kernel: [<ffffffff8104ba1d>] ? kthread_flush_work_fn+0x11/0x11
W> > Nov 20 20:47:42 x220 kernel: [<ffffffff813d21b0>] ? gs_change+0xb/0xb
W> > Nov 20 20:47:42 x220 kernel: ---[ end trace c69a09b105aa81ab ]---
W> > Nov 20 20:47:42 x220 kernel: iwlagn 0000:03:00.0: Invalid station for AGG tid 0
W> > Nov 20 20:47:42 x220 kernel: iwlagn 0000:03:00.0: Attempting to modify non-existing station 0
W> > Nov 20 20:47:42 x220 kernel: ------------[ cut here ]------------
W> > Nov 20 20:47:42 x220 kernel: WARNING: at drivers/net/wireless/iwlwifi/iwl-sta.h:134 iwlagn_tx_skb+0xd2/0x68d()
W> > Nov 20 20:47:42 x220 kernel: Hardware name: 4290W4H
W> > Nov 20 20:47:42 x220 kernel: Pid: 3, comm: ksoftirqd/0 Tainted: G W 3.1.0 #2
W> > Nov 20 20:47:42 x220 kernel: Call Trace:
W> > Nov 20 20:47:42 x220 kernel: [<ffffffff81036558>] ? warn_slowpath_common+0x73/0x87
W> > Nov 20 20:47:42 x220 kernel: [<ffffffff8127ca3a>] ? iwlagn_tx_skb+0xd2/0x68d
W> > Nov 20 20:47:42 x220 kernel: [<ffffffff8102adde>] ? update_curr+0x77/0xd0
W> > Nov 20 20:47:42 x220 kernel: [<ffffffff81276029>] ? iwlagn_mac_tx+0xd/0x1c
W> > Nov 20 20:47:42 x220 kernel: [<ffffffff813b4360>] ? __ieee80211_tx+0x18c/0x1ea
W> > Nov 20 20:47:42 x220 kernel: [<ffffffff813b5f55>] ? ieee80211_tx_pending+0x14b/0x20a
W> > Nov 20 20:47:42 x220 kernel: [<ffffffff8103ab0a>] ? tasklet_action+0x67/0xa7
W> > Nov 20 20:47:42 x220 kernel: [<ffffffff8103ae64>] ? __do_softirq+0x7f/0x106
W> > Nov 20 20:47:42 x220 kernel: [<ffffffff8103af96>] ? run_ksoftirqd+0xab/0x193
W> > Nov 20 20:47:42 x220 kernel: [<ffffffff8103aeeb>] ? __do_softirq+0x106/0x106
W> > Nov 20 20:47:42 x220 kernel: [<ffffffff8104ba97>] ? kthread+0x7a/0x82
W> > Nov 20 20:47:42 x220 kernel: [<ffffffff813d21b4>] ? kernel_thread_helper+0x4/0x10
W> > Nov 20 20:47:42 x220 kernel: [<ffffffff8104ba1d>] ? kthread_flush_work_fn+0x11/0x11
W> > Nov 20 20:47:42 x220 kernel: [<ffffffff813d21b0>] ? gs_change+0xb/0xb
W> > Nov 20 20:47:42 x220 kernel: ---[ end trace c69a09b105aa81ac ]---
W> > Nov 20 20:47:43 x220 kernel: ------------[ cut here ]------------
W> > Nov 20 20:47:43 x220 kernel: WARNING: at drivers/net/wireless/iwlwifi/iwl-sta.h:134 iwlagn_tx_skb+0xd2/0x68d()
W> > Nov 20 20:47:43 x220 kernel: Hardware name: 4290W4H
W> > Nov 20 20:47:43 x220 kernel: Pid: 1902, comm: firefox Tainted: G W 3.1.0 #2
W> > Nov 20 20:47:43 x220 kernel: Call Trace:
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff81036558>] ? warn_slowpath_common+0x73/0x87
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff8127ca3a>] ? iwlagn_tx_skb+0xd2/0x68d
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff81276029>] ? iwlagn_mac_tx+0xd/0x1c
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff813b4360>] ? __ieee80211_tx+0x18c/0x1ea
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff813b54ba>] ? ieee80211_tx+0x95/0xad
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff813b5618>] ? ieee80211_xmit+0x146/0x159
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff813b5dbb>] ? ieee80211_subif_start_xmit+0x5b8/0x5d5
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff81330ef8>] ? dev_hard_start_xmit+0x3f2/0x4f0
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff81342978>] ? sch_direct_xmit+0x67/0x18d
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff813313b5>] ? dev_queue_xmit+0x2fe/0x4fc
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff8134f3b4>] ? ip_finish_output+0x216/0x267
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff8134ea04>] ? ip_queue_xmit+0x2c8/0x304
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff81051ff1>] ? getnstimeofday+0x54/0xa5
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff8136014b>] ? tcp_transmit_skb+0x6b4/0x6f4
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff813609d3>] ? tcp_write_xmit+0x7c8/0x8b0
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff81328188>] ? __alloc_skb+0x5f/0x114
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff81360b04>] ? __tcp_push_pending_frames+0x18/0x73
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff81356ab0>] ? tcp_close+0x157/0x390
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff81370c00>] ? inet_release+0x77/0x80
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff81322d65>] ? sock_release+0x10/0x54
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff81322dcb>] ? sock_close+0x22/0x29
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff810a89cf>] ? fput+0xea/0x194
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff810a6d0f>] ? filp_close+0x62/0x6a
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff810a6da8>] ? sys_close+0x91/0xd5
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff813d0e3b>] ? system_call_fastpath+0x16/0x1b
W> > Nov 20 20:47:43 x220 kernel: ---[ end trace c69a09b105aa81ad ]---
W> > Nov 20 20:47:43 x220 kernel: ------------[ cut here ]------------
W> > Nov 20 20:47:43 x220 kernel: WARNING: at drivers/net/wireless/iwlwifi/iwl-sta.h:134 iwlagn_tx_skb+0xd2/0x68d()
W> > Nov 20 20:47:43 x220 kernel: Hardware name: 4290W4H
W> > Nov 20 20:47:43 x220 kernel: Pid: 0, comm: swapper Tainted: G W 3.1.0 #2
W> > Nov 20 20:47:43 x220 kernel: Call Trace:
W> > Nov 20 20:47:43 x220 kernel: <IRQ> [<ffffffff81036558>] ? warn_slowpath_common+0x73/0x87
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff8127ca3a>] ? iwlagn_tx_skb+0xd2/0x68d
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff81276029>] ? iwlagn_mac_tx+0xd/0x1c
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff813b4360>] ? __ieee80211_tx+0x18c/0x1ea
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff813b54ba>] ? ieee80211_tx+0x95/0xad
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff813b5618>] ? ieee80211_xmit+0x146/0x159
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff813b5dbb>] ? ieee80211_subif_start_xmit+0x5b8/0x5d5
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff81330ef8>] ? dev_hard_start_xmit+0x3f2/0x4f0
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff81342978>] ? sch_direct_xmit+0x67/0x18d
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff813313b5>] ? dev_queue_xmit+0x2fe/0x4fc
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff8102adde>] ? update_curr+0x77/0xd0
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff8134f3b4>] ? ip_finish_output+0x216/0x267
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff8134ea04>] ? ip_queue_xmit+0x2c8/0x304
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff81051ff1>] ? getnstimeofday+0x54/0xa5
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff8136014b>] ? tcp_transmit_skb+0x6b4/0x6f4
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff8135a3f9>] ? tcp_fin.clone.31+0x5c/0x18f
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff8135a94e>] ? tcp_data_queue+0x2de/0xb46
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff8135dca3>] ? tcp_validate_incoming+0x1bb/0x28b
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff8135ec3b>] ? tcp_rcv_state_process+0x8f5/0x96e
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff81363d0d>] ? tcp_v4_do_rcv+0x240/0x284
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff8133f9f4>] ? sk_filter+0x6d/0x78
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff81365aa1>] ? tcp_v4_rcv+0x416/0x65e
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff8134b6b0>] ? ip_local_deliver+0xa5/0xfe
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff8132ee96>] ? __netif_receive_skb+0x279/0x2af
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff810b3a0a>] ? send_sigio_to_task+0xf6/0x108
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff81331f3c>] ? netif_receive_skb+0x7e/0x84
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff8104033b>] ? mod_timer+0x189/0x1a1
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff813b1201>] ? ieee80211_deliver_skb+0xc3/0x104
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff813b20c8>] ? ieee80211_rx_handlers+0xe86/0x17e2
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff810b42fd>] ? send_sigio+0x91/0xa7
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff8102f3b6>] ? __wake_up+0x35/0x46
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff813b30d5>] ? ieee80211_prepare_and_rx_handle+0x6b1/0x734
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff813b39f8>] ? ieee80211_rx+0x735/0x7ac
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff81285f46>] ? iwl_rx_reply_rx+0x467/0x47e
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff813a021b>] ? ieee80211_tx_status+0x72d/0x73f
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff8128c444>] ? iwl_irq_tasklet+0x402/0x675
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff8103ab0a>] ? tasklet_action+0x67/0xa7
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff8103ae64>] ? __do_softirq+0x7f/0x106
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff813d22ac>] ? call_softirq+0x1c/0x26
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff810033fe>] ? do_softirq+0x31/0x67
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff8103b118>] ? irq_exit+0x44/0xb0
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff8100313f>] ? do_IRQ+0x94/0xad
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff813d07eb>] ? common_interrupt+0x6b/0x6b
W> > Nov 20 20:47:43 x220 kernel: <EOI> [<ffffffff8104f02c>] ? __hrtimer_start_range_ns+0x2c6/0x2d9
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff8118a94a>] ? intel_idle+0xcd/0xe9
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff8118a926>] ? intel_idle+0xa9/0xe9
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff812dca4d>] ? cpuidle_idle_call+0xa0/0xdb
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff81000699>] ? cpu_idle+0x53/0x7c
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff816879fa>] ? start_kernel+0x2be/0x2c9
W> > Nov 20 20:47:43 x220 kernel: ---[ end trace c69a09b105aa81ae ]---
W> > Nov 20 20:47:43 x220 kernel: ------------[ cut here ]------------
W> > Nov 20 20:47:43 x220 kernel: WARNING: at drivers/net/wireless/iwlwifi/iwl-sta.h:134 iwlagn_tx_skb+0xd2/0x68d()
W> > Nov 20 20:47:43 x220 kernel: Hardware name: 4290W4H
W> > Nov 20 20:47:43 x220 kernel: Pid: 0, comm: swapper Tainted: G W 3.1.0 #2
W> > Nov 20 20:47:43 x220 kernel: Call Trace:
W> > Nov 20 20:47:43 x220 kernel: <IRQ> [<ffffffff81036558>] ? warn_slowpath_common+0x73/0x87
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff8127ca3a>] ? iwlagn_tx_skb+0xd2/0x68d
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff81276029>] ? iwlagn_mac_tx+0xd/0x1c
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff813b4360>] ? __ieee80211_tx+0x18c/0x1ea
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff813b54ba>] ? ieee80211_tx+0x95/0xad
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff813b5618>] ? ieee80211_xmit+0x146/0x159
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff813b5dbb>] ? ieee80211_subif_start_xmit+0x5b8/0x5d5
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff81330ef8>] ? dev_hard_start_xmit+0x3f2/0x4f0
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff81048223>] ? queue_work_on+0x16/0x20
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff81048274>] ? queue_work+0x47/0x52
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff81342978>] ? sch_direct_xmit+0x67/0x18d
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff810b42fd>] ? send_sigio+0x91/0xa7
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff813313b5>] ? dev_queue_xmit+0x2fe/0x4fc
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff8107a785>] ? free_one_page+0x24e/0x264
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff8134f3b4>] ? ip_finish_output+0x216/0x267
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff8134ea04>] ? ip_queue_xmit+0x2c8/0x304
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff81051ff1>] ? getnstimeofday+0x54/0xa5
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff8136014b>] ? tcp_transmit_skb+0x6b4/0x6f4
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff81360f7b>] ? tcp_retransmit_skb+0x41c/0x505
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff81285f46>] ? iwl_rx_reply_rx+0x467/0x47e
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff81362ca0>] ? tcp_retransmit_timer+0x4f8/0x4f8
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff81362b02>] ? tcp_retransmit_timer+0x35a/0x4f8
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff81362d3b>] ? tcp_write_timer+0x9b/0x18d
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff8103fe83>] ? run_timer_softirq+0x19b/0x230
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff8103ae64>] ? __do_softirq+0x7f/0x106
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff813d22ac>] ? call_softirq+0x1c/0x26
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff810033fe>] ? do_softirq+0x31/0x67
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff8103b118>] ? irq_exit+0x44/0xb0
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff81014a09>] ? smp_apic_timer_interrupt+0x85/0x95
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff813d184b>] ? apic_timer_interrupt+0x6b/0x70
W> > Nov 20 20:47:43 x220 kernel: <EOI> [<ffffffff8118a94a>] ? intel_idle+0xcd/0xe9
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff8118a926>] ? intel_idle+0xa9/0xe9
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff812dca4d>] ? cpuidle_idle_call+0xa0/0xdb
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff81000699>] ? cpu_idle+0x53/0x7c
W> > Nov 20 20:47:43 x220 kernel: [<ffffffff816879fa>] ? start_kernel+0x2be/0x2c9
W> > Nov 20 20:47:43 x220 kernel: ---[ end trace c69a09b105aa81af ]---
W> >
W> > ... and it goes on and on
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413
From: Markus Trippelsdorf @ 2011-11-21 18:52 UTC (permalink / raw)
To: Eric Dumazet
Cc: Andrew Bresticker, Alex,Shi, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, Christoph Lameter, Pekka Enberg, Matt Mackall,
netdev@vger.kernel.org, Tejun Heo
In-Reply-To: <1321900743.10470.31.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
On 2011.11.21 at 19:39 +0100, Eric Dumazet wrote:
> Le lundi 21 novembre 2011 à 18:35 +0100, Markus Trippelsdorf a écrit :
>
> > New one:
>
> ...
>
> I was just wondering if you were using CONFIG_CGROUPS=y, and if yes, if
> you could try to disable it.
# CONFIG_CGROUPS is not set
(I never enable CGROUPS on my machines)
--
Markus
--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH] brcm80211: smac: Use kmemdup rather than duplicating its implementation
From: Franky Lin @ 2011-11-21 18:52 UTC (permalink / raw)
To: Thomas Meyer
Cc: linville@tuxdriver.com, linux-wireless@vger.kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <1321569820.1624.289.camel@localhost.localdomain>
On 11/17/2011 02:43 PM, Thomas Meyer wrote:
> The semantic patch that makes this change is available
> in scripts/coccinelle/api/memdup.cocci.
>
> Signed-off-by: Thomas Meyer<thomas@m3y3r.de>
> ---
Thanks Thomas.
Acked-by: Franky Lin <frankyl@broadcom.com>
Franky
^ permalink raw reply
* [PATCH 0/5] ks8851 MAC and eeprom updates
From: Stephen Boyd @ 2011-11-21 18:57 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, Sebastien Jan, Ben Dooks
I pulled this patch series off the netdev list[1] when the eeprom
reading didn't work for my ks8851 and I wanted the mac address to be
read out at boot. It all seems to work well, so I'm posting it here
again, slightly cleaned up and simplified, for inclusion.
Overall it reduces the lines of code and properly supports eeprom
reading; two things the previous implementation doesn't do.
This is based off of linux-next-20111025.
Thanks to Ben Dooks for doing the heavy lifting.
[1] http://article.gmane.org/gmane.linux.network/159708
Ben Dooks (4):
eeprom_93cx6: Add data direction control.
eeprom_93cx6: Add write support
KSZ8851-SNL: Add support for EEPROM MAC address
KSZ8851-SNL: Add ethtool support for EEPROM via eeprom_93cx6
Tristram Ha (1):
KSZ8851-SNL: Fix MAC address change problem
drivers/misc/eeprom/eeprom_93cx6.c | 88 ++++++
drivers/net/ethernet/micrel/Kconfig | 2 +
drivers/net/ethernet/micrel/ks8851.c | 513 ++++++++++++----------------------
drivers/net/ethernet/micrel/ks8851.h | 15 +-
include/linux/eeprom_93cx6.h | 8 +
5 files changed, 278 insertions(+), 348 deletions(-)
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* [PATCH 4/5] KSZ8851-SNL: Fix MAC address change problem
From: Stephen Boyd @ 2011-11-21 18:57 UTC (permalink / raw)
To: netdev; +Cc: Tristram Ha, linux-kernel, Sebastien Jan, Ben Dooks
In-Reply-To: <1321901880-12883-1-git-send-email-sboyd@codeaurora.org>
From: Tristram Ha <Tristram.Ha@micrel.com>
When device is off it is under power saving mode. Changing the MAC address
in that situation will result in the device not communicating as the first
write to the MAC address register is not executed.
Signed-off-by: Tristram Ha <Tristram.Ha@micrel.com>
[ben@simtec.co.uk: cleaned up header]
Signed-off-by: Ben Dooks <ben@simtec.co.uk>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
drivers/net/ethernet/micrel/ks8851.c | 47 +++++++++++++++++++--------------
drivers/net/ethernet/micrel/ks8851.h | 2 +-
2 files changed, 28 insertions(+), 21 deletions(-)
diff --git a/drivers/net/ethernet/micrel/ks8851.c b/drivers/net/ethernet/micrel/ks8851.c
index d1669bc..208e25a 100644
--- a/drivers/net/ethernet/micrel/ks8851.c
+++ b/drivers/net/ethernet/micrel/ks8851.c
@@ -343,6 +343,26 @@ static void ks8851_soft_reset(struct ks8851_net *ks, unsigned op)
}
/**
+ * ks8851_set_powermode - set power mode of the device
+ * @ks: The device state
+ * @pwrmode: The power mode value to write to KS_PMECR.
+ *
+ * Change the power mode of the chip.
+ */
+static void ks8851_set_powermode(struct ks8851_net *ks, unsigned pwrmode)
+{
+ unsigned pmecr;
+
+ netif_dbg(ks, hw, ks->netdev, "setting power mode %d\n", pwrmode);
+
+ pmecr = ks8851_rdreg16(ks, KS_PMECR);
+ pmecr &= ~PMECR_PM_MASK;
+ pmecr |= pwrmode;
+
+ ks8851_wrreg16(ks, KS_PMECR, pmecr);
+}
+
+/**
* ks8851_write_mac_addr - write mac address to device registers
* @dev: The network device
*
@@ -358,8 +378,15 @@ static int ks8851_write_mac_addr(struct net_device *dev)
mutex_lock(&ks->lock);
+ /*
+ * Wake up chip in case it was powered off when stopped; otherwise,
+ * the first write to the MAC address does not take effect.
+ */
+ ks8851_set_powermode(ks, PMECR_PM_NORMAL);
for (i = 0; i < ETH_ALEN; i++)
ks8851_wrreg8(ks, KS_MAR(i), dev->dev_addr[i]);
+ if (!netif_running(dev))
+ ks8851_set_powermode(ks, PMECR_PM_SOFTDOWN);
mutex_unlock(&ks->lock);
@@ -765,26 +792,6 @@ static void ks8851_tx_work(struct work_struct *work)
}
/**
- * ks8851_set_powermode - set power mode of the device
- * @ks: The device state
- * @pwrmode: The power mode value to write to KS_PMECR.
- *
- * Change the power mode of the chip.
- */
-static void ks8851_set_powermode(struct ks8851_net *ks, unsigned pwrmode)
-{
- unsigned pmecr;
-
- netif_dbg(ks, hw, ks->netdev, "setting power mode %d\n", pwrmode);
-
- pmecr = ks8851_rdreg16(ks, KS_PMECR);
- pmecr &= ~PMECR_PM_MASK;
- pmecr |= pwrmode;
-
- ks8851_wrreg16(ks, KS_PMECR, pmecr);
-}
-
-/**
* ks8851_net_open - open network device
* @dev: The network device being opened.
*
diff --git a/drivers/net/ethernet/micrel/ks8851.h b/drivers/net/ethernet/micrel/ks8851.h
index 537fb06e..b2703a1 100644
--- a/drivers/net/ethernet/micrel/ks8851.h
+++ b/drivers/net/ethernet/micrel/ks8851.h
@@ -16,7 +16,7 @@
#define CCR_32PIN (1 << 0)
/* MAC address registers */
-#define KS_MAR(_m) 0x15 - (_m)
+#define KS_MAR(_m) (0x15 - (_m))
#define KS_MARL 0x10
#define KS_MARM 0x12
#define KS_MARH 0x14
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply related
* [PATCH 5/5] KSZ8851-SNL: Add ethtool support for EEPROM via eeprom_93cx6
From: Stephen Boyd @ 2011-11-21 18:58 UTC (permalink / raw)
To: netdev; +Cc: Ben Dooks, linux-kernel, Sebastien Jan, Simtec Linux Team
In-Reply-To: <1321901880-12883-1-git-send-email-sboyd@codeaurora.org>
From: Ben Dooks <ben@simtec.co.uk>
Add ethtool EEPROM read/write support using the eeprom_93cx6
library instead of open-coding the functions.
Depends on eeprom_93cx6 driver getting EEPROM write support.
Signed-off-by: Ben Dooks <ben@simtec.co.uk>
Signed-off-by: Simtec Linux Team <linux@simtec.co.uk>
[sboyd@codeaurora.org: Removed previous eeprom implementation]
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
drivers/net/ethernet/micrel/Kconfig | 2 +
drivers/net/ethernet/micrel/ks8851.c | 425 ++++++++++------------------------
drivers/net/ethernet/micrel/ks8851.h | 13 +-
3 files changed, 120 insertions(+), 320 deletions(-)
diff --git a/drivers/net/ethernet/micrel/Kconfig b/drivers/net/ethernet/micrel/Kconfig
index d10c2e1..1ea811c 100644
--- a/drivers/net/ethernet/micrel/Kconfig
+++ b/drivers/net/ethernet/micrel/Kconfig
@@ -42,6 +42,8 @@ config KS8851
select NET_CORE
select MII
select CRC32
+ select MISC_DEVICES
+ select EEPROM_93CX6
---help---
SPI driver for Micrel KS8851 SPI attached network chip.
diff --git a/drivers/net/ethernet/micrel/ks8851.c b/drivers/net/ethernet/micrel/ks8851.c
index 208e25a..6b35e7d 100644
--- a/drivers/net/ethernet/micrel/ks8851.c
+++ b/drivers/net/ethernet/micrel/ks8851.c
@@ -22,6 +22,7 @@
#include <linux/cache.h>
#include <linux/crc32.h>
#include <linux/mii.h>
+#include <linux/eeprom_93cx6.h>
#include <linux/spi/spi.h>
@@ -82,6 +83,7 @@ union ks8851_tx_hdr {
* @rc_ccr: Cached copy of KS_CCR.
* @rc_rxqcr: Cached copy of KS_RXQCR.
* @eeprom_size: Companion eeprom size in Bytes, 0 if no eeprom
+ * @eeprom: 93CX6 EEPROM state for accessing on-board EEPROM.
*
* The @lock ensures that the chip is protected when certain operations are
* in progress. When the read or write packet transfer is in progress, most
@@ -128,6 +130,8 @@ struct ks8851_net {
struct spi_message spi_msg2;
struct spi_transfer spi_xfer1;
struct spi_transfer spi_xfer2[2];
+
+ struct eeprom_93cx6 eeprom;
};
static int msg_enable;
@@ -1071,234 +1075,6 @@ static const struct net_device_ops ks8851_netdev_ops = {
.ndo_validate_addr = eth_validate_addr,
};
-/* Companion eeprom access */
-
-enum { /* EEPROM programming states */
- EEPROM_CONTROL,
- EEPROM_ADDRESS,
- EEPROM_DATA,
- EEPROM_COMPLETE
-};
-
-/**
- * ks8851_eeprom_read - read a 16bits word in ks8851 companion EEPROM
- * @dev: The network device the PHY is on.
- * @addr: EEPROM address to read
- *
- * eeprom_size: used to define the data coding length. Can be changed
- * through debug-fs.
- *
- * Programs a read on the EEPROM using ks8851 EEPROM SW access feature.
- * Warning: The READ feature is not supported on ks8851 revision 0.
- *
- * Rough programming model:
- * - on period start: set clock high and read value on bus
- * - on period / 2: set clock low and program value on bus
- * - start on period / 2
- */
-unsigned int ks8851_eeprom_read(struct net_device *dev, unsigned int addr)
-{
- struct ks8851_net *ks = netdev_priv(dev);
- int eepcr;
- int ctrl = EEPROM_OP_READ;
- int state = EEPROM_CONTROL;
- int bit_count = EEPROM_OP_LEN - 1;
- unsigned int data = 0;
- int dummy;
- unsigned int addr_len;
-
- addr_len = (ks->eeprom_size == 128) ? 6 : 8;
-
- /* start transaction: chip select high, authorize write */
- mutex_lock(&ks->lock);
- eepcr = EEPCR_EESA | EEPCR_EESRWA;
- ks8851_wrreg16(ks, KS_EEPCR, eepcr);
- eepcr |= EEPCR_EECS;
- ks8851_wrreg16(ks, KS_EEPCR, eepcr);
- mutex_unlock(&ks->lock);
-
- while (state != EEPROM_COMPLETE) {
- /* falling clock period starts... */
- /* set EED_IO pin for control and address */
- eepcr &= ~EEPCR_EEDO;
- switch (state) {
- case EEPROM_CONTROL:
- eepcr |= ((ctrl >> bit_count) & 1) << 2;
- if (bit_count-- <= 0) {
- bit_count = addr_len - 1;
- state = EEPROM_ADDRESS;
- }
- break;
- case EEPROM_ADDRESS:
- eepcr |= ((addr >> bit_count) & 1) << 2;
- bit_count--;
- break;
- case EEPROM_DATA:
- /* Change to receive mode */
- eepcr &= ~EEPCR_EESRWA;
- break;
- }
-
- /* lower clock */
- eepcr &= ~EEPCR_EESCK;
-
- mutex_lock(&ks->lock);
- ks8851_wrreg16(ks, KS_EEPCR, eepcr);
- mutex_unlock(&ks->lock);
-
- /* waitread period / 2 */
- udelay(EEPROM_SK_PERIOD / 2);
-
- /* rising clock period starts... */
-
- /* raise clock */
- mutex_lock(&ks->lock);
- eepcr |= EEPCR_EESCK;
- ks8851_wrreg16(ks, KS_EEPCR, eepcr);
- mutex_unlock(&ks->lock);
-
- /* Manage read */
- switch (state) {
- case EEPROM_ADDRESS:
- if (bit_count < 0) {
- bit_count = EEPROM_DATA_LEN - 1;
- state = EEPROM_DATA;
- }
- break;
- case EEPROM_DATA:
- mutex_lock(&ks->lock);
- dummy = ks8851_rdreg16(ks, KS_EEPCR);
- mutex_unlock(&ks->lock);
- data |= ((dummy >> EEPCR_EESB_OFFSET) & 1) << bit_count;
- if (bit_count-- <= 0)
- state = EEPROM_COMPLETE;
- break;
- }
-
- /* wait period / 2 */
- udelay(EEPROM_SK_PERIOD / 2);
- }
-
- /* close transaction */
- mutex_lock(&ks->lock);
- eepcr &= ~EEPCR_EECS;
- ks8851_wrreg16(ks, KS_EEPCR, eepcr);
- eepcr = 0;
- ks8851_wrreg16(ks, KS_EEPCR, eepcr);
- mutex_unlock(&ks->lock);
-
- return data;
-}
-
-/**
- * ks8851_eeprom_write - write a 16bits word in ks8851 companion EEPROM
- * @dev: The network device the PHY is on.
- * @op: operand (can be WRITE, EWEN, EWDS)
- * @addr: EEPROM address to write
- * @data: data to write
- *
- * eeprom_size: used to define the data coding length. Can be changed
- * through debug-fs.
- *
- * Programs a write on the EEPROM using ks8851 EEPROM SW access feature.
- *
- * Note that a write enable is required before writing data.
- *
- * Rough programming model:
- * - on period start: set clock high
- * - on period / 2: set clock low and program value on bus
- * - start on period / 2
- */
-void ks8851_eeprom_write(struct net_device *dev, unsigned int op,
- unsigned int addr, unsigned int data)
-{
- struct ks8851_net *ks = netdev_priv(dev);
- int eepcr;
- int state = EEPROM_CONTROL;
- int bit_count = EEPROM_OP_LEN - 1;
- unsigned int addr_len;
-
- addr_len = (ks->eeprom_size == 128) ? 6 : 8;
-
- switch (op) {
- case EEPROM_OP_EWEN:
- addr = 0x30;
- break;
- case EEPROM_OP_EWDS:
- addr = 0;
- break;
- }
-
- /* start transaction: chip select high, authorize write */
- mutex_lock(&ks->lock);
- eepcr = EEPCR_EESA | EEPCR_EESRWA;
- ks8851_wrreg16(ks, KS_EEPCR, eepcr);
- eepcr |= EEPCR_EECS;
- ks8851_wrreg16(ks, KS_EEPCR, eepcr);
- mutex_unlock(&ks->lock);
-
- while (state != EEPROM_COMPLETE) {
- /* falling clock period starts... */
- /* set EED_IO pin for control and address */
- eepcr &= ~EEPCR_EEDO;
- switch (state) {
- case EEPROM_CONTROL:
- eepcr |= ((op >> bit_count) & 1) << 2;
- if (bit_count-- <= 0) {
- bit_count = addr_len - 1;
- state = EEPROM_ADDRESS;
- }
- break;
- case EEPROM_ADDRESS:
- eepcr |= ((addr >> bit_count) & 1) << 2;
- if (bit_count-- <= 0) {
- if (op == EEPROM_OP_WRITE) {
- bit_count = EEPROM_DATA_LEN - 1;
- state = EEPROM_DATA;
- } else {
- state = EEPROM_COMPLETE;
- }
- }
- break;
- case EEPROM_DATA:
- eepcr |= ((data >> bit_count) & 1) << 2;
- if (bit_count-- <= 0)
- state = EEPROM_COMPLETE;
- break;
- }
-
- /* lower clock */
- eepcr &= ~EEPCR_EESCK;
-
- mutex_lock(&ks->lock);
- ks8851_wrreg16(ks, KS_EEPCR, eepcr);
- mutex_unlock(&ks->lock);
-
- /* wait period / 2 */
- udelay(EEPROM_SK_PERIOD / 2);
-
- /* rising clock period starts... */
-
- /* raise clock */
- eepcr |= EEPCR_EESCK;
- mutex_lock(&ks->lock);
- ks8851_wrreg16(ks, KS_EEPCR, eepcr);
- mutex_unlock(&ks->lock);
-
- /* wait period / 2 */
- udelay(EEPROM_SK_PERIOD / 2);
- }
-
- /* close transaction */
- mutex_lock(&ks->lock);
- eepcr &= ~EEPCR_EECS;
- ks8851_wrreg16(ks, KS_EEPCR, eepcr);
- eepcr = 0;
- ks8851_wrreg16(ks, KS_EEPCR, eepcr);
- mutex_unlock(&ks->lock);
-
-}
-
/* ethtool support */
static void ks8851_get_drvinfo(struct net_device *dev,
@@ -1345,115 +1121,141 @@ static int ks8851_nway_reset(struct net_device *dev)
return mii_nway_restart(&ks->mii);
}
-static int ks8851_get_eeprom_len(struct net_device *dev)
-{
- struct ks8851_net *ks = netdev_priv(dev);
- return ks->eeprom_size;
-}
+/* EEPROM support */
-static int ks8851_get_eeprom(struct net_device *dev,
- struct ethtool_eeprom *eeprom, u8 *bytes)
+static void ks8851_eeprom_regread(struct eeprom_93cx6 *ee)
{
- struct ks8851_net *ks = netdev_priv(dev);
- u16 *eeprom_buff;
- int first_word;
- int last_word;
- int ret_val = 0;
- u16 i;
-
- if (eeprom->len == 0)
- return -EINVAL;
+ struct ks8851_net *ks = ee->data;
+ unsigned val;
- if (eeprom->len > ks->eeprom_size)
- return -EINVAL;
+ val = ks8851_rdreg16(ks, KS_EEPCR);
- eeprom->magic = ks8851_rdreg16(ks, KS_CIDER);
+ ee->reg_data_out = (val & EEPCR_EESB) ? 1 : 0;
+ ee->reg_data_clock = (val & EEPCR_EESCK) ? 1 : 0;
+ ee->reg_chip_select = (val & EEPCR_EECS) ? 1 : 0;
+}
- first_word = eeprom->offset >> 1;
- last_word = (eeprom->offset + eeprom->len - 1) >> 1;
+static void ks8851_eeprom_regwrite(struct eeprom_93cx6 *ee)
+{
+ struct ks8851_net *ks = ee->data;
+ unsigned val = EEPCR_EESA; /* default - eeprom access on */
+
+ if (ee->drive_data)
+ val |= EEPCR_EESRWA;
+ if (ee->reg_data_in)
+ val |= EEPCR_EEDO;
+ if (ee->reg_data_clock)
+ val |= EEPCR_EESCK;
+ if (ee->reg_chip_select)
+ val |= EEPCR_EECS;
+
+ ks8851_wrreg16(ks, KS_EEPCR, val);
+}
- eeprom_buff = kmalloc(sizeof(u16) *
- (last_word - first_word + 1), GFP_KERNEL);
- if (!eeprom_buff)
- return -ENOMEM;
+/**
+ * ks8851_eeprom_claim - claim device EEPROM and activate the interface
+ * @ks: The network device state.
+ *
+ * Check for the presence of an EEPROM, and then activate software access
+ * to the device.
+ */
+static int ks8851_eeprom_claim(struct ks8851_net *ks)
+{
+ if (!(ks->rc_ccr & CCR_EEPROM))
+ return -ENOENT;
- for (i = 0; i < last_word - first_word + 1; i++)
- eeprom_buff[i] = ks8851_eeprom_read(dev, first_word + 1);
+ mutex_lock(&ks->lock);
- /* Device's eeprom is little-endian, word addressable */
- for (i = 0; i < last_word - first_word + 1; i++)
- le16_to_cpus(&eeprom_buff[i]);
+ /* start with clock low, cs high */
+ ks8851_wrreg16(ks, KS_EEPCR, EEPCR_EESA | EEPCR_EECS);
+ return 0;
+}
- memcpy(bytes, (u8 *)eeprom_buff + (eeprom->offset & 1), eeprom->len);
- kfree(eeprom_buff);
+/**
+ * ks8851_eeprom_release - release the EEPROM interface
+ * @ks: The device state
+ *
+ * Release the software access to the device EEPROM
+ */
+static void ks8851_eeprom_release(struct ks8851_net *ks)
+{
+ unsigned val = ks8851_rdreg16(ks, KS_EEPCR);
- return ret_val;
+ ks8851_wrreg16(ks, KS_EEPCR, val & ~EEPCR_EESA);
+ mutex_unlock(&ks->lock);
}
+#define KS_EEPROM_MAGIC (0x00008851)
+
static int ks8851_set_eeprom(struct net_device *dev,
- struct ethtool_eeprom *eeprom, u8 *bytes)
+ struct ethtool_eeprom *ee, u8 *data)
{
struct ks8851_net *ks = netdev_priv(dev);
- u16 *eeprom_buff;
- void *ptr;
- int max_len;
- int first_word;
- int last_word;
- int ret_val = 0;
- u16 i;
-
- if (eeprom->len == 0)
- return -EOPNOTSUPP;
-
- if (eeprom->len > ks->eeprom_size)
+ int offset = ee->offset;
+ int len = ee->len;
+ u16 tmp;
+
+ /* currently only support byte writing */
+ if (len != 1)
return -EINVAL;
- if (eeprom->magic != ks8851_rdreg16(ks, KS_CIDER))
- return -EFAULT;
+ if (ee->magic != KS_EEPROM_MAGIC)
+ return -EINVAL;
- first_word = eeprom->offset >> 1;
- last_word = (eeprom->offset + eeprom->len - 1) >> 1;
- max_len = (last_word - first_word + 1) * 2;
- eeprom_buff = kmalloc(max_len, GFP_KERNEL);
- if (!eeprom_buff)
- return -ENOMEM;
+ if (ks8851_eeprom_claim(ks))
+ return -ENOENT;
+
+ eeprom_93cx6_wren(&ks->eeprom, true);
+
+ /* ethtool currently only supports writing bytes, which means
+ * we have to read/modify/write our 16bit EEPROMs */
- ptr = (void *)eeprom_buff;
+ eeprom_93cx6_read(&ks->eeprom, offset/2, &tmp);
- if (eeprom->offset & 1) {
- /* need read/modify/write of first changed EEPROM word */
- /* only the second byte of the word is being modified */
- eeprom_buff[0] = ks8851_eeprom_read(dev, first_word);
- ptr++;
+ if (offset & 1) {
+ tmp &= 0xff;
+ tmp |= *data << 8;
+ } else {
+ tmp &= 0xff00;
+ tmp |= *data;
}
- if ((eeprom->offset + eeprom->len) & 1)
- /* need read/modify/write of last changed EEPROM word */
- /* only the first byte of the word is being modified */
- eeprom_buff[last_word - first_word] =
- ks8851_eeprom_read(dev, last_word);
+ eeprom_93cx6_write(&ks->eeprom, offset/2, tmp);
+ eeprom_93cx6_wren(&ks->eeprom, false);
+
+ ks8851_eeprom_release(ks);
+
+ return 0;
+}
- /* Device's eeprom is little-endian, word addressable */
- le16_to_cpus(&eeprom_buff[0]);
- le16_to_cpus(&eeprom_buff[last_word - first_word]);
+static int ks8851_get_eeprom(struct net_device *dev,
+ struct ethtool_eeprom *ee, u8 *data)
+{
+ struct ks8851_net *ks = netdev_priv(dev);
+ int offset = ee->offset;
+ int len = ee->len;
- memcpy(ptr, bytes, eeprom->len);
+ /* must be 2 byte aligned */
+ if (len & 1 || offset & 1)
+ return -EINVAL;
- for (i = 0; i < last_word - first_word + 1; i++)
- eeprom_buff[i] = cpu_to_le16(eeprom_buff[i]);
+ if (ks8851_eeprom_claim(ks))
+ return -ENOENT;
- ks8851_eeprom_write(dev, EEPROM_OP_EWEN, 0, 0);
+ ee->magic = KS_EEPROM_MAGIC;
- for (i = 0; i < last_word - first_word + 1; i++) {
- ks8851_eeprom_write(dev, EEPROM_OP_WRITE, first_word + i,
- eeprom_buff[i]);
- mdelay(EEPROM_WRITE_TIME);
- }
+ eeprom_93cx6_multiread(&ks->eeprom, offset/2, (__le16 *)data, len/2);
+ ks8851_eeprom_release(ks);
- ks8851_eeprom_write(dev, EEPROM_OP_EWDS, 0, 0);
+ return 0;
+}
- kfree(eeprom_buff);
- return ret_val;
+static int ks8851_get_eeprom_len(struct net_device *dev)
+{
+ struct ks8851_net *ks = netdev_priv(dev);
+
+ /* currently, we assume it is an 93C46 attached, so return 128 */
+ return ks->rc_ccr & CCR_EEPROM ? 128 : 0;
}
static const struct ethtool_ops ks8851_ethtool_ops = {
@@ -1646,6 +1448,13 @@ static int __devinit ks8851_probe(struct spi_device *spi)
spi_message_add_tail(&ks->spi_xfer2[0], &ks->spi_msg2);
spi_message_add_tail(&ks->spi_xfer2[1], &ks->spi_msg2);
+ /* setup EEPROM state */
+
+ ks->eeprom.data = ks;
+ ks->eeprom.width = PCI_EEPROM_WIDTH_93C46;
+ ks->eeprom.register_read = ks8851_eeprom_regread;
+ ks->eeprom.register_write = ks8851_eeprom_regwrite;
+
/* setup mii state */
ks->mii.dev = ndev;
ks->mii.phy_id = 1,
diff --git a/drivers/net/ethernet/micrel/ks8851.h b/drivers/net/ethernet/micrel/ks8851.h
index b2703a1..b0fae86 100644
--- a/drivers/net/ethernet/micrel/ks8851.h
+++ b/drivers/net/ethernet/micrel/ks8851.h
@@ -27,22 +27,11 @@
#define KS_EEPCR 0x22
#define EEPCR_EESRWA (1 << 5)
#define EEPCR_EESA (1 << 4)
-#define EEPCR_EESB_OFFSET 3
-#define EEPCR_EESB (1 << EEPCR_EESB_OFFSET)
+#define EEPCR_EESB (1 << 3)
#define EEPCR_EEDO (1 << 2)
#define EEPCR_EESCK (1 << 1)
#define EEPCR_EECS (1 << 0)
-#define EEPROM_OP_LEN 3 /* bits:*/
-#define EEPROM_OP_READ 0x06
-#define EEPROM_OP_EWEN 0x04
-#define EEPROM_OP_WRITE 0x05
-#define EEPROM_OP_EWDS 0x14
-
-#define EEPROM_DATA_LEN 16 /* 16 bits EEPROM */
-#define EEPROM_WRITE_TIME 4 /* wrt ack time in ms */
-#define EEPROM_SK_PERIOD 400 /* in us */
-
#define KS_MBIR 0x24
#define MBIR_TXMBF (1 << 12)
#define MBIR_TXMBFA (1 << 11)
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply related
* [PATCH 2/5] eeprom_93cx6: Add write support
From: Stephen Boyd @ 2011-11-21 18:57 UTC (permalink / raw)
To: netdev; +Cc: Ben Dooks, linux-kernel, Sebastien Jan, Wolfram Sang,
Jean Delvare
In-Reply-To: <1321901880-12883-1-git-send-email-sboyd@codeaurora.org>
From: Ben Dooks <ben@simtec.co.uk>
Add support for writing data to EEPROM.
Signed-off-by: Ben Dooks <ben@simtec.co.uk>
Cc: Wolfram Sang <w.sang@pengutronix.de>
Cc: Jean Delvare <khali@linux-fr.org>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
drivers/misc/eeprom/eeprom_93cx6.c | 85 ++++++++++++++++++++++++++++++++++++
include/linux/eeprom_93cx6.h | 6 +++
2 files changed, 91 insertions(+), 0 deletions(-)
diff --git a/drivers/misc/eeprom/eeprom_93cx6.c b/drivers/misc/eeprom/eeprom_93cx6.c
index a6037af..0ff4b02 100644
--- a/drivers/misc/eeprom/eeprom_93cx6.c
+++ b/drivers/misc/eeprom/eeprom_93cx6.c
@@ -234,3 +234,88 @@ void eeprom_93cx6_multiread(struct eeprom_93cx6 *eeprom, const u8 word,
}
EXPORT_SYMBOL_GPL(eeprom_93cx6_multiread);
+/**
+ * eeprom_93cx6_wren - set the write enable state
+ * @eeprom: Pointer to eeprom structure
+ * @enable: true to enable writes, otherwise disable writes
+ *
+ * Set the EEPROM write enable state to either allow or deny
+ * writes depending on the @enable value.
+ */
+void eeprom_93cx6_wren(struct eeprom_93cx6 *eeprom, bool enable)
+{
+ u16 command;
+
+ /* start the command */
+ eeprom_93cx6_startup(eeprom);
+
+ /* create command to enable/disable */
+
+ command = enable ? PCI_EEPROM_EWEN_OPCODE : PCI_EEPROM_EWDS_OPCODE;
+ command <<= (eeprom->width - 2);
+
+ eeprom_93cx6_write_bits(eeprom, command,
+ PCI_EEPROM_WIDTH_OPCODE + eeprom->width);
+
+ eeprom_93cx6_cleanup(eeprom);
+}
+EXPORT_SYMBOL_GPL(eeprom_93cx6_wren);
+
+/**
+ * eeprom_93cx6_write - write data to the EEPROM
+ * @eeprom: Pointer to eeprom structure
+ * @addr: Address to write data to.
+ * @data: The data to write to address @addr.
+ *
+ * Write the @data to the specified @addr in the EEPROM and
+ * waiting for the device to finish writing.
+ *
+ * Note, since we do not expect large number of write operations
+ * we delay in between parts of the operation to avoid using excessive
+ * amounts of CPU time busy waiting.
+ */
+void eeprom_93cx6_write(struct eeprom_93cx6 *eeprom, u8 addr, u16 data)
+{
+ int timeout = 100;
+ u16 command;
+
+ /* start the command */
+ eeprom_93cx6_startup(eeprom);
+
+ command = PCI_EEPROM_WRITE_OPCODE << eeprom->width;
+ command |= addr;
+
+ /* send write command */
+ eeprom_93cx6_write_bits(eeprom, command,
+ PCI_EEPROM_WIDTH_OPCODE + eeprom->width);
+
+ /* send data */
+ eeprom_93cx6_write_bits(eeprom, data, 16);
+
+ /* get ready to check for busy */
+ eeprom->drive_data = 0;
+ eeprom->reg_chip_select = 1;
+ eeprom->register_write(eeprom);
+
+ /* wait at-least 250ns to get DO to be the busy signal */
+ usleep_range(1000, 2000);
+
+ /* wait for DO to go high to signify finish */
+
+ while (true) {
+ eeprom->register_read(eeprom);
+
+ if (eeprom->reg_data_out)
+ break;
+
+ usleep_range(1000, 2000);
+
+ if (--timeout <= 0) {
+ printk(KERN_ERR "%s: timeout\n", __func__);
+ break;
+ }
+ }
+
+ eeprom_93cx6_cleanup(eeprom);
+}
+EXPORT_SYMBOL_GPL(eeprom_93cx6_write);
diff --git a/include/linux/eeprom_93cx6.h b/include/linux/eeprom_93cx6.h
index e04546e..e50f98b 100644
--- a/include/linux/eeprom_93cx6.h
+++ b/include/linux/eeprom_93cx6.h
@@ -33,6 +33,7 @@
#define PCI_EEPROM_WIDTH_93C86 8
#define PCI_EEPROM_WIDTH_OPCODE 3
#define PCI_EEPROM_WRITE_OPCODE 0x05
+#define PCI_EEPROM_ERASE_OPCODE 0x07
#define PCI_EEPROM_READ_OPCODE 0x06
#define PCI_EEPROM_EWDS_OPCODE 0x10
#define PCI_EEPROM_EWEN_OPCODE 0x13
@@ -74,3 +75,8 @@ extern void eeprom_93cx6_read(struct eeprom_93cx6 *eeprom,
const u8 word, u16 *data);
extern void eeprom_93cx6_multiread(struct eeprom_93cx6 *eeprom,
const u8 word, __le16 *data, const u16 words);
+
+extern void eeprom_93cx6_wren(struct eeprom_93cx6 *eeprom, bool enable);
+
+extern void eeprom_93cx6_write(struct eeprom_93cx6 *eeprom,
+ u8 addr, u16 data);
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply related
* [PATCH 1/5] eeprom_93cx6: Add data direction control.
From: Stephen Boyd @ 2011-11-21 18:57 UTC (permalink / raw)
To: netdev; +Cc: Ben Dooks, linux-kernel, Sebastien Jan, Wolfram Sang,
Jean Delvare
In-Reply-To: <1321901880-12883-1-git-send-email-sboyd@codeaurora.org>
From: Ben Dooks <ben@simtec.co.uk>
Some devices need to know if the data is to be output or read, so add a
data direction into the eeprom structure to tell the driver whether the
data line should be driven.
The user in this case is the Micrel KS8851 which has a direction
control for the EEPROM data line and thus needs to know whether
to drive it (writing) or to tristate it for receiving.
Signed-off-by: Ben Dooks <ben@simtec.co.uk>
Cc: Wolfram Sang <w.sang@pengutronix.de>
Cc: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
drivers/misc/eeprom/eeprom_93cx6.c | 3 +++
include/linux/eeprom_93cx6.h | 2 ++
2 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/misc/eeprom/eeprom_93cx6.c b/drivers/misc/eeprom/eeprom_93cx6.c
index 7b33de9..a6037af 100644
--- a/drivers/misc/eeprom/eeprom_93cx6.c
+++ b/drivers/misc/eeprom/eeprom_93cx6.c
@@ -63,6 +63,7 @@ static void eeprom_93cx6_startup(struct eeprom_93cx6 *eeprom)
eeprom->reg_data_out = 0;
eeprom->reg_data_clock = 0;
eeprom->reg_chip_select = 1;
+ eeprom->drive_data = 1;
eeprom->register_write(eeprom);
/*
@@ -101,6 +102,7 @@ static void eeprom_93cx6_write_bits(struct eeprom_93cx6 *eeprom,
*/
eeprom->reg_data_in = 0;
eeprom->reg_data_out = 0;
+ eeprom->drive_data = 1;
/*
* Start writing all bits.
@@ -140,6 +142,7 @@ static void eeprom_93cx6_read_bits(struct eeprom_93cx6 *eeprom,
*/
eeprom->reg_data_in = 0;
eeprom->reg_data_out = 0;
+ eeprom->drive_data = 0;
/*
* Start reading all bits.
diff --git a/include/linux/eeprom_93cx6.h b/include/linux/eeprom_93cx6.h
index c4627cb..e04546e 100644
--- a/include/linux/eeprom_93cx6.h
+++ b/include/linux/eeprom_93cx6.h
@@ -46,6 +46,7 @@
* @register_write(struct eeprom_93cx6 *eeprom): handler to
* write to the eeprom register by using all reg_* fields.
* @width: eeprom width, should be one of the PCI_EEPROM_WIDTH_* defines
+ * @drive_data: Set if we're driving the data line.
* @reg_data_in: register field to indicate data input
* @reg_data_out: register field to indicate data output
* @reg_data_clock: register field to set the data clock
@@ -62,6 +63,7 @@ struct eeprom_93cx6 {
int width;
+ char drive_data;
char reg_data_in;
char reg_data_out;
char reg_data_clock;
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply related
* [PATCH 3/5] KSZ8851-SNL: Add support for EEPROM MAC address
From: Stephen Boyd @ 2011-11-21 18:57 UTC (permalink / raw)
To: netdev; +Cc: Ben Dooks, linux-kernel, Sebastien Jan
In-Reply-To: <1321901880-12883-1-git-send-email-sboyd@codeaurora.org>
From: Ben Dooks <ben@simtec.co.uk>
Add support for reading the MAC address from the system registers if there
is an EEPROM present. This involves caching the KS_CCR register for later
use (will also be useful for ETHTOOL support) and adding a print to say
that there is an EEPROM present.
Signed-off-by: Ben Dooks <ben@simtec.co.uk>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
drivers/net/ethernet/micrel/ks8851.c | 41 ++++++++++++++++++++++++++++-----
1 files changed, 34 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/micrel/ks8851.c b/drivers/net/ethernet/micrel/ks8851.c
index f56743a..d1669bc 100644
--- a/drivers/net/ethernet/micrel/ks8851.c
+++ b/drivers/net/ethernet/micrel/ks8851.c
@@ -367,21 +367,47 @@ static int ks8851_write_mac_addr(struct net_device *dev)
}
/**
+ * ks8851_read_mac_addr - read mac address from device registers
+ * @dev: The network device
+ *
+ * Update our copy of the KS8851 MAC address from the registers of @dev.
+*/
+static void ks8851_read_mac_addr(struct net_device *dev)
+{
+ struct ks8851_net *ks = netdev_priv(dev);
+ int i;
+
+ mutex_lock(&ks->lock);
+
+ for (i = 0; i < ETH_ALEN; i++)
+ dev->dev_addr[i] = ks8851_rdreg8(ks, KS_MAR(i));
+
+ mutex_unlock(&ks->lock);
+}
+
+/**
* ks8851_init_mac - initialise the mac address
* @ks: The device structure
*
* Get or create the initial mac address for the device and then set that
- * into the station address register. Currently we assume that the device
- * does not have a valid mac address in it, and so we use random_ether_addr()
+ * into the station address register. If there is an EEPROM present, then
+ * we try that. If no valid mac address is found we use random_ether_addr()
* to create a new one.
- *
- * In future, the driver should check to see if the device has an EEPROM
- * attached and whether that has a valid ethernet address in it.
*/
static void ks8851_init_mac(struct ks8851_net *ks)
{
struct net_device *dev = ks->netdev;
+ /* first, try reading what we've got already */
+ if (ks->rc_ccr & CCR_EEPROM) {
+ ks8851_read_mac_addr(dev);
+ if (is_valid_ether_addr(dev->dev_addr))
+ return;
+
+ netdev_err(ks->netdev, "invalid mac address read %pM\n",
+ dev->dev_addr);
+ }
+
random_ether_addr(dev->dev_addr);
ks8851_write_mac_addr(dev);
}
@@ -1674,9 +1700,10 @@ static int __devinit ks8851_probe(struct spi_device *spi)
goto err_netdev;
}
- netdev_info(ndev, "revision %d, MAC %pM, IRQ %d\n",
+ netdev_info(ndev, "revision %d, MAC %pM, IRQ %d, %s EEPROM\n",
CIDER_REV_GET(ks8851_rdreg16(ks, KS_CIDER)),
- ndev->dev_addr, ndev->irq);
+ ndev->dev_addr, ndev->irq,
+ ks->rc_ccr & CCR_EEPROM ? "has" : "no");
return 0;
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply related
* Re: MPLS for Linux kernel
From: Jorge Boncompte [DTI2] @ 2011-11-21 19:18 UTC (permalink / raw)
To: davem; +Cc: igorm, netdev
In-Reply-To: <20111121.132914.1611617296397809001.davem@davemloft.net>
El 21/11/2011 19:29, David Miller escribió:
> From: "Jorge Boncompte [DTI2]" <jorge@dti2.net>
> Date: Mon, 21 Nov 2011 16:01:26 +0100
>
>> mpls-linux it is not ready to go upstream in my opinion.
>
> And can arguably be implemented in terms of openvswitch and packet scheduler actions.
I guess so, I have not really looked much at the openvswitch code. The MPLS
code it is pretty self contained and in my opinion more tied to routing than to
switching (*). I don't think it should be necessary an userspace daemon, like it
seems necessary for openvswitch, just to bind a label to a route, the same way
that it is not necessary a daemon to support VLAN's currently. The label
signaling protocols are already complicated :)
I work in this code, like a lot of people do, because I have a use for it. I
would really like to see it upstreamed but if it does not fit upstream plans, it
is not a problem, this code it is not that hard to maintain.
In any case critics/reviews/patches are most than welcome.
(*) The code that you implemented for 2.6.1 and that James R. Leu used in this
codebase it is even more tied together to routing.
^ permalink raw reply
* [PATCH net-next] virtio_net: return already tracked tx_fifo_errors via virtnet_getstats()
From: Rick Jones @ 2011-11-21 19:28 UTC (permalink / raw)
To: netdev, rusty, mst
From: Rick Jones <rick.jones2@hp.com>
Tx_fifo_errors are tracked in start_xmit_ for virtio_net, but not
reported in the tallies returned by virtnet_stats(). Return them
as the rx "sub-stats" rx_length_errors and rx_frame_errors are.
Signed-off-by: Rick Jones <rick.jones2@hp.com>
---
Compiled and booted in a guest, but no tx_fifo_errors generated.
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 4dc9d84..5a96172 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -700,6 +700,7 @@ static struct rtnl_link_stats64 *virtnet_stats(struct net_device *dev,
}
tot->tx_dropped = dev->stats.tx_dropped;
+ tot->tx_fifo_errors = dev->stats.tx_fifo_errors;
tot->rx_dropped = dev->stats.rx_dropped;
tot->rx_length_errors = dev->stats.rx_length_errors;
tot->rx_frame_errors = dev->stats.rx_frame_errors;
^ permalink raw reply related
* Re: [PATCH net-next] tg3: Fix advertisement handling
From: Matt Carlson @ 2011-11-21 19:29 UTC (permalink / raw)
To: Hiroaki SHIMODA
Cc: davem@davemloft.net, Matthew Carlson, Michael Chan,
netdev@vger.kernel.org
In-Reply-To: <20111121080720.0e68f096.shimoda.hiroaki@gmail.com>
On Sun, Nov 20, 2011 at 03:07:20PM -0800, Hiroaki SHIMODA wrote:
> Commit 28011cf19b (net: Add ethtool to mii advertisment conversion
> helpers) added a helper function ethtool_adv_to_mii_100bt() and
> tg3_copper_is_advertising_all(), tg3_phy_autoneg_cfg() were
> modified to use this.
> Before that commit, ethtool to mii advertisement conversion was
> done wrt speed, but now pause operation is also taken account.
> So, in tg3_copper_is_advertising_all(), below condition becomes
> true and this makes link up fails.
>
> if ((adv_reg & ADVERTISE_ALL) != all_mask)
> return 0;
>
> To fix this add ADVERTISE_ALL bit and operation to cap speed.
>
> Signed-off-by: Hiroaki SHIMODA <shimoda.hiroaki@gmail.com>
The root cause of this problem can actually be fixed by the following
patch:
diff --git a/drivers/net/ethernet/broadcom/tg3.c b/drivers/net/ethernet/broadcom/tg3.c
index 024ca1d..53e501c 100644
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -13192,8 +13192,7 @@ static u32 __devinit tg3_read_otp_phycfg(struct tg3 *tp)
static void __devinit tg3_phy_init_link_config(struct tg3 *tp)
{
- u32 adv = ADVERTISED_Autoneg |
- ADVERTISED_Pause;
+ u32 adv = ADVERTISED_Autoneg;
if (!(tp->phy_flags & TG3_PHYFLG_10_100_ONLY))
adv |= ADVERTISED_1000baseT_Half |
Could you add it as part of this patch?
Technically the above patch should fix the problem, but this patch makes
the code clearer, should the same type of error pop up in the future.
More comments below.
> ---
> drivers/net/ethernet/broadcom/tg3.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/broadcom/tg3.c b/drivers/net/ethernet/broadcom/tg3.c
> index 024ca1d..c00e648 100644
> --- a/drivers/net/ethernet/broadcom/tg3.c
> +++ b/drivers/net/ethernet/broadcom/tg3.c
> @@ -3594,7 +3594,7 @@ static int tg3_phy_autoneg_cfg(struct tg3 *tp, u32 advertise, u32 flowctrl)
> u32 val, new_adv;
>
> new_adv = ADVERTISE_CSMA;
> - new_adv |= ethtool_adv_to_mii_100bt(advertise);
> + new_adv |= ethtool_adv_to_mii_100bt(advertise) & ADVERTISE_ALL;
> new_adv |= tg3_advert_flowctrl_1000T(flowctrl);
>
> err = tg3_writephy(tp, MII_ADVERTISE, new_adv);
> @@ -3783,7 +3783,7 @@ static int tg3_copper_is_advertising_all(struct tg3 *tp, u32 mask)
> if (tg3_readphy(tp, MII_ADVERTISE, &adv_reg))
> return 0;
>
> - if ((adv_reg & ADVERTISE_ALL) != all_mask)
> + if ((adv_reg & ADVERTISE_ALL) != (all_mask & ADVERTISE_ALL))
Rather than ANDing the all_mask here, can you make it look like the 1st
hunk of your patch by ANDing the value returned by
ethtool_adv_to_mii_100bt()? I plan on further changes in this area and
the uniformity will help.
> return 0;
>
> if (!(tp->phy_flags & TG3_PHYFLG_10_100_ONLY)) {
>
^ permalink raw reply related
* e1000 vlan functionality broken in 3.1
From: Josh Boyer @ 2011-11-21 19:28 UTC (permalink / raw)
To: Jesse Brandeburg, Jeff Kirsher, Jiri Pirko
Cc: netdev, linux-kernel, kernel-team
Hi All,
We've had a couple of reports of the e1000 driver no longer working with
tagged VLANs in the 3.1 kernel. The bug report has much more detail
here:
https://bugzilla.redhat.com/show_bug.cgi?id=754589
The summary is, if you turn of rxvlan and tx offloading, the driver
seems to work fine with 3.1 again whereas this wasn't needed on 3.0.
(Fedora calls 3.0 2.6.40 on Fedora 15, but that is strictly a naming
thing.)
Looking through the commit logs, 5622e4044a91 seems to be the most
relevant commit between those versions. Does anyone have any ideas?
josh
^ permalink raw reply
* Re: Firmware errors and warnings with Centrino Advanced-N 6205
From: wwguy @ 2011-11-21 19:33 UTC (permalink / raw)
To: Udo Steinberg; +Cc: Linux Network Mailing List, linux-wireless@vger.kernel.org
In-Reply-To: <20111121194824.12f4c276@x220>
On Mon, 2011-11-21 at 10:48 -0800, Udo Steinberg wrote:
> Hi Wey,
>
> Yes, I'm using a 40 Mhz channel. "iw wlan0 link" reports:
>
> Connected to 00:24:fe:41:8d:0e (on wlan0)
> freq: 2412
> RX: 80815 bytes (507 packets)
> TX: 3881 bytes (34 packets)
> signal: -40 dBm
> tx bitrate: 40.5 MBit/s MCS 2 40Mhz
>
Looks like the firmware not like the rate was used with the antenna
choice.
Could you please load the iwlagn module with debug flag = 0x1000
$ sudo modprobe iwlagn debug=0x1000
and let me know what you have
btw, what kernel version you are using?
Thanks
Wey
>
> On Mon, 21 Nov 2011 07:24:25 -0800 wwguy (W) wrote:
>
> W> Hi Udo,
> W>
> W> Are you using 40MHz?
> W>
> W> Thanks
> W> Wey
> W>
> W> On Sun, 2011-11-20 at 12:00 -0800, Udo Steinberg wrote:
> W> > Hi,
> W> >
> W> > I'm repeatedly getting firmware errors and warnings on my Centrino 6205 WiFi
> W> > card with Linux 3.1. These warnings keep filling the logs at a rate that is
> W> > not funny. Any idea how to fix this issue or at least rate-limit those
> W> > messages?
> W> >
> W> > Cheers,
> W> >
> W> > - Udo
> W> >
> W> > Excerpt from syslog:
> W> >
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: Microcode SW error detected. Restarting 0x82000000.
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: Loaded firmware version: 17.168.5.3 build 42301
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: Start IWL Error Log Dump:
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: Status: 0x000512E4, count: 6
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: 0x00002078 | ADVANCED_SYSASSERT
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: 0x00009514 | uPc
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: 0x00009496 | branchlink1
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: 0x00009496 | branchlink2
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: 0x0000D1F2 | interruptlink1
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: 0x00000000 | interruptlink2
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: 0x01008035 | data1
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: 0x0000C90F | data2
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: 0x000005A7 | line
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: 0x5080B520 | beacon time
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: 0xCC515AE0 | tsf low
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: 0x00000003 | tsf hi
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: 0x00000000 | time gp1
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: 0x29703BF0 | time gp2
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: 0x00000000 | time gp3
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: 0x000111A8 | uCode version
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: 0x000000B0 | hw version
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: 0x00480303 | board version
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: 0x09E8004E | hcmd
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR values:
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: (2nd byte of CSR_INT_COALESCING is CSR_INT_PERIODIC_REG)
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_HW_IF_CONFIG_REG: 0X00480303
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_INT_COALESCING: 0X0000ff40
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_INT: 0X00000000
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_INT_MASK: 0X00000000
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_FH_INT_STATUS: 0X00000000
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_GPIO_IN: 0X00000030
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_RESET: 0X00000000
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_GP_CNTRL: 0X080403c5
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_HW_REV: 0X000000b0
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_EEPROM_REG: 0X07d60ffd
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_EEPROM_GP: 0X90000001
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_OTP_GP_REG: 0X00030001
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_GIO_REG: 0X00080044
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_GP_UCODE_REG: 0X000093bb
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_GP_DRIVER_REG: 0X00000000
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_UCODE_DRV_GP1: 0X00000000
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_UCODE_DRV_GP2: 0X00000000
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_LED_REG: 0X00000078
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_DRAM_INT_TBL_REG: 0X88214dd2
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_GIO_CHICKEN_BITS: 0X27800200
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_ANA_PLL_CFG: 0X00000000
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_HW_REV_WA_REG: 0X0001001a
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_DBG_HPET_MEM_REG: 0Xffff0010
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: FH register values:
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: FH_RSCSR_CHNL0_STTS_WPTR_REG: 0X21316d00
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: FH_RSCSR_CHNL0_RBDCB_BASE_REG: 0X021479c0
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: FH_RSCSR_CHNL0_WPTR: 0X00000060
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: FH_MEM_RCSR_CHNL0_CONFIG_REG: 0X80819104
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: FH_MEM_RSSR_SHARED_CTRL_REG: 0X000000fc
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: FH_MEM_RSSR_RX_STATUS_REG: 0X07030000
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: FH_MEM_RSSR_RX_ENABLE_ERR_IRQ2DRV: 0X00000000
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: FH_TSSR_TX_STATUS_REG: 0X07ff0001
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: FH_TSSR_TX_ERROR_REG: 0X00000000
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: Start IWL Event Log Dump: display last 20 entries
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695219435:0x028a001c:0217
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695221022:0x028b001c:0206
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695221023:0x00000001:0204
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695221026:0x00000001:0214
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695221027:0x01001110:0205
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695221051:0x00000020:0208
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695221070:0x00000000:0302
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695221104:0x00000001:0203
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695221109:0x028b001c:0206
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695221110:0x00000040:0204
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695221113:0x01000110:0211
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695221117:0x00000000:0212
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695221159:0x00000000:0215
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695221162:0x00000008:0220
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695221179:0x00000000:0302
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695221211:0x000000d4:0303
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695221215:0x0000128c:0217
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695221215:0x028b001c:0217
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695221224:0x09e8004e:0401
> W> > Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695221234:0x00000000:0125
> W> > Nov 20 20:47:42 x220 kernel: iwlagn 0000:03:00.0: Error sending REPLY_ADD_STA: time out after 2000ms.
> W> > Nov 20 20:47:42 x220 kernel: iwlagn 0000:03:00.0: Adding station 00:24:fe:41:8d:0e failed.
> W> > Nov 20 20:47:42 x220 kernel: iwlagn 0000:03:00.0: Unable to add station 00:24:fe:41:8d:0e (-110)
> W> > Nov 20 20:47:42 x220 kernel: ------------[ cut here ]------------
> W> > Nov 20 20:47:42 x220 kernel: WARNING: at net/mac80211/util.c:1208 ieee80211_reconfig+0x1f1/0x407()
> W> > Nov 20 20:47:42 x220 kernel: Hardware name: 4290W4H
> W> > Nov 20 20:47:42 x220 kernel: Pid: 1896, comm: kworker/0:0 Not tainted 3.1.0 #2
> W> > Nov 20 20:47:42 x220 kernel: Call Trace:
> W> > Nov 20 20:47:42 x220 kernel: [<ffffffff81036558>] ? warn_slowpath_common+0x73/0x87
> W> > Nov 20 20:47:42 x220 kernel: [<ffffffff813b8966>] ? ieee80211_reconfig+0x1f1/0x407
> W> > Nov 20 20:47:42 x220 kernel: [<ffffffff8139e8dc>] ? ieee80211_recalc_smps_work+0x32/0x32
> W> > Nov 20 20:47:42 x220 kernel: [<ffffffff8139e95a>] ? ieee80211_restart_work+0x7e/0x87
> W> > Nov 20 20:47:42 x220 kernel: [<ffffffff810472fa>] ? process_one_work+0x1c8/0x2e3
> W> > Nov 20 20:47:42 x220 kernel: [<ffffffff810480c9>] ? worker_thread+0x17a/0x23a
> W> > Nov 20 20:47:42 x220 kernel: [<ffffffff81047f4f>] ? manage_workers.clone.18+0x15b/0x15b
> W> > Nov 20 20:47:42 x220 kernel: [<ffffffff81047f4f>] ? manage_workers.clone.18+0x15b/0x15b
> W> > Nov 20 20:47:42 x220 kernel: [<ffffffff8104ba97>] ? kthread+0x7a/0x82
> W> > Nov 20 20:47:42 x220 kernel: [<ffffffff813d21b4>] ? kernel_thread_helper+0x4/0x10
> W> > Nov 20 20:47:42 x220 kernel: [<ffffffff8104ba1d>] ? kthread_flush_work_fn+0x11/0x11
> W> > Nov 20 20:47:42 x220 kernel: [<ffffffff813d21b0>] ? gs_change+0xb/0xb
> W> > Nov 20 20:47:42 x220 kernel: ---[ end trace c69a09b105aa81ab ]---
> W> > Nov 20 20:47:42 x220 kernel: iwlagn 0000:03:00.0: Invalid station for AGG tid 0
> W> > Nov 20 20:47:42 x220 kernel: iwlagn 0000:03:00.0: Attempting to modify non-existing station 0
> W> > Nov 20 20:47:42 x220 kernel: ------------[ cut here ]------------
> W> > Nov 20 20:47:42 x220 kernel: WARNING: at drivers/net/wireless/iwlwifi/iwl-sta.h:134 iwlagn_tx_skb+0xd2/0x68d()
> W> > Nov 20 20:47:42 x220 kernel: Hardware name: 4290W4H
> W> > Nov 20 20:47:42 x220 kernel: Pid: 3, comm: ksoftirqd/0 Tainted: G W 3.1.0 #2
> W> > Nov 20 20:47:42 x220 kernel: Call Trace:
> W> > Nov 20 20:47:42 x220 kernel: [<ffffffff81036558>] ? warn_slowpath_common+0x73/0x87
> W> > Nov 20 20:47:42 x220 kernel: [<ffffffff8127ca3a>] ? iwlagn_tx_skb+0xd2/0x68d
> W> > Nov 20 20:47:42 x220 kernel: [<ffffffff8102adde>] ? update_curr+0x77/0xd0
> W> > Nov 20 20:47:42 x220 kernel: [<ffffffff81276029>] ? iwlagn_mac_tx+0xd/0x1c
> W> > Nov 20 20:47:42 x220 kernel: [<ffffffff813b4360>] ? __ieee80211_tx+0x18c/0x1ea
> W> > Nov 20 20:47:42 x220 kernel: [<ffffffff813b5f55>] ? ieee80211_tx_pending+0x14b/0x20a
> W> > Nov 20 20:47:42 x220 kernel: [<ffffffff8103ab0a>] ? tasklet_action+0x67/0xa7
> W> > Nov 20 20:47:42 x220 kernel: [<ffffffff8103ae64>] ? __do_softirq+0x7f/0x106
> W> > Nov 20 20:47:42 x220 kernel: [<ffffffff8103af96>] ? run_ksoftirqd+0xab/0x193
> W> > Nov 20 20:47:42 x220 kernel: [<ffffffff8103aeeb>] ? __do_softirq+0x106/0x106
> W> > Nov 20 20:47:42 x220 kernel: [<ffffffff8104ba97>] ? kthread+0x7a/0x82
> W> > Nov 20 20:47:42 x220 kernel: [<ffffffff813d21b4>] ? kernel_thread_helper+0x4/0x10
> W> > Nov 20 20:47:42 x220 kernel: [<ffffffff8104ba1d>] ? kthread_flush_work_fn+0x11/0x11
> W> > Nov 20 20:47:42 x220 kernel: [<ffffffff813d21b0>] ? gs_change+0xb/0xb
> W> > Nov 20 20:47:42 x220 kernel: ---[ end trace c69a09b105aa81ac ]---
> W> > Nov 20 20:47:43 x220 kernel: ------------[ cut here ]------------
> W> > Nov 20 20:47:43 x220 kernel: WARNING: at drivers/net/wireless/iwlwifi/iwl-sta.h:134 iwlagn_tx_skb+0xd2/0x68d()
> W> > Nov 20 20:47:43 x220 kernel: Hardware name: 4290W4H
> W> > Nov 20 20:47:43 x220 kernel: Pid: 1902, comm: firefox Tainted: G W 3.1.0 #2
> W> > Nov 20 20:47:43 x220 kernel: Call Trace:
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff81036558>] ? warn_slowpath_common+0x73/0x87
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff8127ca3a>] ? iwlagn_tx_skb+0xd2/0x68d
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff81276029>] ? iwlagn_mac_tx+0xd/0x1c
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff813b4360>] ? __ieee80211_tx+0x18c/0x1ea
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff813b54ba>] ? ieee80211_tx+0x95/0xad
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff813b5618>] ? ieee80211_xmit+0x146/0x159
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff813b5dbb>] ? ieee80211_subif_start_xmit+0x5b8/0x5d5
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff81330ef8>] ? dev_hard_start_xmit+0x3f2/0x4f0
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff81342978>] ? sch_direct_xmit+0x67/0x18d
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff813313b5>] ? dev_queue_xmit+0x2fe/0x4fc
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff8134f3b4>] ? ip_finish_output+0x216/0x267
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff8134ea04>] ? ip_queue_xmit+0x2c8/0x304
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff81051ff1>] ? getnstimeofday+0x54/0xa5
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff8136014b>] ? tcp_transmit_skb+0x6b4/0x6f4
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff813609d3>] ? tcp_write_xmit+0x7c8/0x8b0
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff81328188>] ? __alloc_skb+0x5f/0x114
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff81360b04>] ? __tcp_push_pending_frames+0x18/0x73
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff81356ab0>] ? tcp_close+0x157/0x390
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff81370c00>] ? inet_release+0x77/0x80
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff81322d65>] ? sock_release+0x10/0x54
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff81322dcb>] ? sock_close+0x22/0x29
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff810a89cf>] ? fput+0xea/0x194
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff810a6d0f>] ? filp_close+0x62/0x6a
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff810a6da8>] ? sys_close+0x91/0xd5
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff813d0e3b>] ? system_call_fastpath+0x16/0x1b
> W> > Nov 20 20:47:43 x220 kernel: ---[ end trace c69a09b105aa81ad ]---
> W> > Nov 20 20:47:43 x220 kernel: ------------[ cut here ]------------
> W> > Nov 20 20:47:43 x220 kernel: WARNING: at drivers/net/wireless/iwlwifi/iwl-sta.h:134 iwlagn_tx_skb+0xd2/0x68d()
> W> > Nov 20 20:47:43 x220 kernel: Hardware name: 4290W4H
> W> > Nov 20 20:47:43 x220 kernel: Pid: 0, comm: swapper Tainted: G W 3.1.0 #2
> W> > Nov 20 20:47:43 x220 kernel: Call Trace:
> W> > Nov 20 20:47:43 x220 kernel: <IRQ> [<ffffffff81036558>] ? warn_slowpath_common+0x73/0x87
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff8127ca3a>] ? iwlagn_tx_skb+0xd2/0x68d
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff81276029>] ? iwlagn_mac_tx+0xd/0x1c
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff813b4360>] ? __ieee80211_tx+0x18c/0x1ea
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff813b54ba>] ? ieee80211_tx+0x95/0xad
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff813b5618>] ? ieee80211_xmit+0x146/0x159
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff813b5dbb>] ? ieee80211_subif_start_xmit+0x5b8/0x5d5
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff81330ef8>] ? dev_hard_start_xmit+0x3f2/0x4f0
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff81342978>] ? sch_direct_xmit+0x67/0x18d
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff813313b5>] ? dev_queue_xmit+0x2fe/0x4fc
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff8102adde>] ? update_curr+0x77/0xd0
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff8134f3b4>] ? ip_finish_output+0x216/0x267
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff8134ea04>] ? ip_queue_xmit+0x2c8/0x304
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff81051ff1>] ? getnstimeofday+0x54/0xa5
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff8136014b>] ? tcp_transmit_skb+0x6b4/0x6f4
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff8135a3f9>] ? tcp_fin.clone.31+0x5c/0x18f
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff8135a94e>] ? tcp_data_queue+0x2de/0xb46
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff8135dca3>] ? tcp_validate_incoming+0x1bb/0x28b
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff8135ec3b>] ? tcp_rcv_state_process+0x8f5/0x96e
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff81363d0d>] ? tcp_v4_do_rcv+0x240/0x284
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff8133f9f4>] ? sk_filter+0x6d/0x78
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff81365aa1>] ? tcp_v4_rcv+0x416/0x65e
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff8134b6b0>] ? ip_local_deliver+0xa5/0xfe
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff8132ee96>] ? __netif_receive_skb+0x279/0x2af
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff810b3a0a>] ? send_sigio_to_task+0xf6/0x108
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff81331f3c>] ? netif_receive_skb+0x7e/0x84
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff8104033b>] ? mod_timer+0x189/0x1a1
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff813b1201>] ? ieee80211_deliver_skb+0xc3/0x104
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff813b20c8>] ? ieee80211_rx_handlers+0xe86/0x17e2
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff810b42fd>] ? send_sigio+0x91/0xa7
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff8102f3b6>] ? __wake_up+0x35/0x46
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff813b30d5>] ? ieee80211_prepare_and_rx_handle+0x6b1/0x734
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff813b39f8>] ? ieee80211_rx+0x735/0x7ac
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff81285f46>] ? iwl_rx_reply_rx+0x467/0x47e
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff813a021b>] ? ieee80211_tx_status+0x72d/0x73f
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff8128c444>] ? iwl_irq_tasklet+0x402/0x675
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff8103ab0a>] ? tasklet_action+0x67/0xa7
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff8103ae64>] ? __do_softirq+0x7f/0x106
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff813d22ac>] ? call_softirq+0x1c/0x26
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff810033fe>] ? do_softirq+0x31/0x67
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff8103b118>] ? irq_exit+0x44/0xb0
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff8100313f>] ? do_IRQ+0x94/0xad
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff813d07eb>] ? common_interrupt+0x6b/0x6b
> W> > Nov 20 20:47:43 x220 kernel: <EOI> [<ffffffff8104f02c>] ? __hrtimer_start_range_ns+0x2c6/0x2d9
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff8118a94a>] ? intel_idle+0xcd/0xe9
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff8118a926>] ? intel_idle+0xa9/0xe9
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff812dca4d>] ? cpuidle_idle_call+0xa0/0xdb
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff81000699>] ? cpu_idle+0x53/0x7c
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff816879fa>] ? start_kernel+0x2be/0x2c9
> W> > Nov 20 20:47:43 x220 kernel: ---[ end trace c69a09b105aa81ae ]---
> W> > Nov 20 20:47:43 x220 kernel: ------------[ cut here ]------------
> W> > Nov 20 20:47:43 x220 kernel: WARNING: at drivers/net/wireless/iwlwifi/iwl-sta.h:134 iwlagn_tx_skb+0xd2/0x68d()
> W> > Nov 20 20:47:43 x220 kernel: Hardware name: 4290W4H
> W> > Nov 20 20:47:43 x220 kernel: Pid: 0, comm: swapper Tainted: G W 3.1.0 #2
> W> > Nov 20 20:47:43 x220 kernel: Call Trace:
> W> > Nov 20 20:47:43 x220 kernel: <IRQ> [<ffffffff81036558>] ? warn_slowpath_common+0x73/0x87
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff8127ca3a>] ? iwlagn_tx_skb+0xd2/0x68d
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff81276029>] ? iwlagn_mac_tx+0xd/0x1c
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff813b4360>] ? __ieee80211_tx+0x18c/0x1ea
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff813b54ba>] ? ieee80211_tx+0x95/0xad
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff813b5618>] ? ieee80211_xmit+0x146/0x159
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff813b5dbb>] ? ieee80211_subif_start_xmit+0x5b8/0x5d5
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff81330ef8>] ? dev_hard_start_xmit+0x3f2/0x4f0
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff81048223>] ? queue_work_on+0x16/0x20
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff81048274>] ? queue_work+0x47/0x52
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff81342978>] ? sch_direct_xmit+0x67/0x18d
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff810b42fd>] ? send_sigio+0x91/0xa7
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff813313b5>] ? dev_queue_xmit+0x2fe/0x4fc
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff8107a785>] ? free_one_page+0x24e/0x264
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff8134f3b4>] ? ip_finish_output+0x216/0x267
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff8134ea04>] ? ip_queue_xmit+0x2c8/0x304
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff81051ff1>] ? getnstimeofday+0x54/0xa5
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff8136014b>] ? tcp_transmit_skb+0x6b4/0x6f4
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff81360f7b>] ? tcp_retransmit_skb+0x41c/0x505
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff81285f46>] ? iwl_rx_reply_rx+0x467/0x47e
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff81362ca0>] ? tcp_retransmit_timer+0x4f8/0x4f8
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff81362b02>] ? tcp_retransmit_timer+0x35a/0x4f8
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff81362d3b>] ? tcp_write_timer+0x9b/0x18d
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff8103fe83>] ? run_timer_softirq+0x19b/0x230
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff8103ae64>] ? __do_softirq+0x7f/0x106
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff813d22ac>] ? call_softirq+0x1c/0x26
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff810033fe>] ? do_softirq+0x31/0x67
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff8103b118>] ? irq_exit+0x44/0xb0
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff81014a09>] ? smp_apic_timer_interrupt+0x85/0x95
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff813d184b>] ? apic_timer_interrupt+0x6b/0x70
> W> > Nov 20 20:47:43 x220 kernel: <EOI> [<ffffffff8118a94a>] ? intel_idle+0xcd/0xe9
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff8118a926>] ? intel_idle+0xa9/0xe9
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff812dca4d>] ? cpuidle_idle_call+0xa0/0xdb
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff81000699>] ? cpu_idle+0x53/0x7c
> W> > Nov 20 20:47:43 x220 kernel: [<ffffffff816879fa>] ? start_kernel+0x2be/0x2c9
> W> > Nov 20 20:47:43 x220 kernel: ---[ end trace c69a09b105aa81af ]---
> W> >
> W> > ... and it goes on and on
^ permalink raw reply
* [PATCH] netns: fix proxy ARP entries listing on a netns
From: Jorge Boncompte [DTI2] @ 2011-11-21 19:46 UTC (permalink / raw)
To: netdev; +Cc: Jorge Boncompte [DTI2]
From: "Jorge Boncompte [DTI2]" <jorge@dti2.net>
Skip entries from foreign network namespaces.
Signed-off-by: Jorge Boncompte [DTI2] <jorge@dti2.net>
---
net/core/neighbour.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/net/core/neighbour.c b/net/core/neighbour.c
index 039d51e..2adcbeb 100644
--- a/net/core/neighbour.c
+++ b/net/core/neighbour.c
@@ -2397,6 +2397,7 @@ static struct pneigh_entry *pneigh_get_next(struct seq_file *seq,
struct net *net = seq_file_net(seq);
struct neigh_table *tbl = state->tbl;
+restart:
pn = pn->next;
while (!pn) {
if (++state->bucket > PNEIGH_HASHMASK)
@@ -2408,6 +2409,9 @@ static struct pneigh_entry *pneigh_get_next(struct seq_file *seq,
break;
}
+ if (pn && !net_eq(pneigh_net(pn), net))
+ goto restart;
+
if (pn && pos)
--(*pos);
--
1.7.7.1
^ permalink raw reply related
* [patch v2] caif: fix endian conversion in cffrml_transmit()
From: Dan Carpenter @ 2011-11-21 19:50 UTC (permalink / raw)
To: Al Viro; +Cc: Sjur Braendeland, David S. Miller, netdev, kernel-janitors
In-Reply-To: <20111121063356.GH2203@ZenIV.linux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 1307 bytes --]
The "tmp" variable here is used to store the result of cpu_to_le16()
so it should be an __le16 instead of an int. We want the high bits
set and the current code works on little endian systems but not on
big endian systems.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
---
v2: In v1 I used a u16 instead of an __le16. Also I've changed the
name to "data" instead of "tmp".
diff --git a/net/caif/cffrml.c b/net/caif/cffrml.c
index f399211..d3ca87b 100644
--- a/net/caif/cffrml.c
+++ b/net/caif/cffrml.c
@@ -136,20 +136,21 @@ static int cffrml_receive(struct cflayer *layr, struct cfpkt *pkt)
static int cffrml_transmit(struct cflayer *layr, struct cfpkt *pkt)
{
- int tmp;
u16 chks;
u16 len;
+ __le16 data;
+
struct cffrml *this = container_obj(layr);
if (this->dofcs) {
chks = cfpkt_iterate(pkt, cffrml_checksum, 0xffff);
- tmp = cpu_to_le16(chks);
- cfpkt_add_trail(pkt, &tmp, 2);
+ data = cpu_to_le16(chks);
+ cfpkt_add_trail(pkt, &data, 2);
} else {
cfpkt_pad_trail(pkt, 2);
}
len = cfpkt_getlen(pkt);
- tmp = cpu_to_le16(len);
- cfpkt_add_head(pkt, &tmp, 2);
+ data = cpu_to_le16(len);
+ cfpkt_add_head(pkt, &data, 2);
cfpkt_info(pkt)->hdr_len += 2;
if (cfpkt_erroneous(pkt)) {
pr_err("Packet is erroneous!\n");
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply related
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