* Re: [PATCH net-next 6/6] r8169: support RTL8168G
From: David Miller @ 2012-07-11 8:29 UTC (permalink / raw)
To: romieu; +Cc: hayeswang, netdev, linux-kernel, wfg
In-Reply-To: <20120710065010.GA30193@electric-eye.fr.zoreil.com>
From: Francois Romieu <romieu@fr.zoreil.com>
Date: Tue, 10 Jul 2012 08:50:10 +0200
> Hayes Wang <hayeswang@realtek.com> :
>> fix incorrct argument in rtl_hw_init_8168g.
>>
>> Signed-off-by: Hayes Wang <hayeswang@realtek.com>
>
> Thanks Hayes.
>
> It's available with proper attribution and subject at:
>
> git://violet.fr.zoreil.com/romieu/linux davem-next.r8169
Pulled, thanks.
^ permalink raw reply
* Re: [patch -next] net: writes past the end of the struct
From: David Miller @ 2012-07-11 8:27 UTC (permalink / raw)
To: dan.carpenter; +Cc: kuznet, jmorris, yoshfuji, kaber, netdev, kernel-janitors
In-Reply-To: <20120711063214.GA11812@elgon.mountain>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Wed, 11 Jul 2012 09:32:14 +0300
> There are a couple places that try to set part of the struct to 0 by
> doing:
>
> memset(&rt->rt6i_table, 0, sizeof(*rt) - sizeof(struct dst_entry));
>
> It assumes that the first element is a dst_entry and the second element
> is ->rt6_table. The problem is we changed the struct in 97cac0821a
> ('ipv6: Store route neighbour in rt6_info struct.') and we aren't
> clearing rt->n but instead we're writing past the end of the array.
>
> I've changed it to:
> memset(&rt->n, 0, sizeof(*rt) - offsetof(struct rt6_info, n));
>
> The memset in ip6_dst_alloc() was ok but I changed it to use offsetof()
> as a cleanup.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Steffen Klassert had patches to do this more nicely, using "dst + 1"
as the pointer calculation, which therefore works no matter what
elements we add to struct rt6_info after the dst_entry.
I asked him to fix some things, he did too much casting, but he never
respun his patch set. I definitely prefer this gets fixed his way.
http://patchwork.ozlabs.org/patch/169391/
http://patchwork.ozlabs.org/patch/169395/
^ permalink raw reply
* Re: [PATCH net-next 3/9] IB/ipoib: Add support for acting as VIF
From: David Miller @ 2012-07-11 8:19 UTC (permalink / raw)
To: ogerlitz; +Cc: eric.dumazet, roland, netdev, ali, sean.hefty, erezsh
In-Reply-To: <4FFD33B8.5010604@mellanox.com>
From: Or Gerlitz <ogerlitz@mellanox.com>
Date: Wed, 11 Jul 2012 11:05:12 +0300
> On 7/10/2012 3:26 PM, Eric Dumazet wrote:
>> On Tue, 2012-07-10 at 15:16 +0300, Or Gerlitz wrote:
>>> The IPoIB code checks the VIF private flag on the RX path, and
>>> accoriding
>>> to the value of the flag prepares the skb CB data, etc.
>>>
>>
>> skb->cb[] can be destroyed in netif_receive_skb() /
>> __netif_receive_skb()
>>
>> #ifdef CONFIG_NET_CLS_ACT
>> skb = handle_ing(skb, &pt_prev, &ret, orig_dev);
>> ...
>> #endif
>
> Eric,
>
> Can you elaborate a little further? we're not sure to see where
> skb->cb[] is touched on the flow
> you pointed to.
handle_ing() goes into the packet scheduler and qdisc layer,
the qdisc layer uses skb->cb[] via struct qdisc_skb_cb.
^ permalink raw reply
* Re: [PATCH] gianfar: fix potential sk_wmem_alloc imbalance
From: Claudiu Manoil @ 2012-07-11 8:06 UTC (permalink / raw)
To: Eric Dumazet
Cc: Paul Gortmaker, David Miller, netdev, Manfred Rudigier, Jiajun Wu,
Andy Fleming
In-Reply-To: <1341738542.3265.1406.camel@edumazet-glaptop>
Hi,
On 7/8/2012 12:09 PM, Eric Dumazet wrote:
> On Fri, 2012-07-06 at 14:09 -0400, Paul Gortmaker wrote:
>
>> Aside from the one line change at driver init, is there more to it than
>> that? More specifically, it currently does:
>>
>> fcb_length = GMAC_FCB_LEN;
>>
>> if (...timestamps...)
>> fcb_length = GMAC_FCB_LEN + GMAC_TXPAL_LEN;
>>
>> if (... && (skb_headroom(skb) < fcb_length))
>> ...
>> skb_new = skb_realloc_headroom(skb, fcb_length);
>>
>> and I don't know the code well enough to know if setting the
>> needed_headroom value _guarantees_ the above fcb_length comparison
>> will always be false, and hence can be deleted. It kind of looks
>> like it via LL_RESERVED_SPACE, but I'm not 100% sure...
>
> This is not a guarantee but should take care of most cases.
>
> So we should keep the test anyway.
>
> And init needed_headroom to the largest room. Existing tests seems to
> ignore vlan case and timestamping.
VLAN tagging (offloaded by eTSEC) is accommodated by the FCB block (8
bytes), which seemingly has already been reserved in the headroom
(GMAC_FCB_LEN). So it shouldn't require extra headroom.
And, according to the hw manual, time stamp insertion for transmit
packets requires an additional 16 bytes, next to the FCB, as the
timestamp (8 bytes) is written at an offset of 16. And looks like this
is taken care of by GMAC_TXPAL_LEN.
However I don't fully understand the "needed_headroom" setting and its
implications, maybe you could help with the following questions.
Is "needed_headroom" setting relevant for IP forwarding scenarios too?
Or is it used only in the case when the networking stack generates
packets for Tx?
Thanks!
Claudiu
>
> diff --git a/drivers/net/ethernet/freescale/gianfar.c b/drivers/net/ethernet/freescale/gianfar.c
> index af16f9f..b4517b7 100644
> --- a/drivers/net/ethernet/freescale/gianfar.c
> +++ b/drivers/net/ethernet/freescale/gianfar.c
> @@ -1084,9 +1084,7 @@ static int gfar_probe(struct platform_device *ofdev)
> else
> priv->padding = 0;
>
> - if (dev->features & NETIF_F_IP_CSUM ||
> - priv->device_flags & FSL_GIANFAR_DEV_HAS_TIMER)
> - dev->needed_headroom = GMAC_FCB_LEN;
> + dev->needed_headroom = GMAC_FCB_LEN + GMAC_TXPAL_LEN;
>
> /* Program the isrg regs only if number of grps > 1 */
> if (priv->num_grps > 1) {
>
>
>
>
> .
>
^ permalink raw reply
* Re: [PATCH net-next 3/9] IB/ipoib: Add support for acting as VIF
From: Or Gerlitz @ 2012-07-11 8:05 UTC (permalink / raw)
To: Eric Dumazet; +Cc: davem, roland, netdev, ali, sean.hefty, Erez Shitrit
In-Reply-To: <1341923180.3265.5005.camel@edumazet-glaptop>
On 7/10/2012 3:26 PM, Eric Dumazet wrote:
> On Tue, 2012-07-10 at 15:16 +0300, Or Gerlitz wrote:
>> The IPoIB code checks the VIF private flag on the RX path, and accoriding
>> to the value of the flag prepares the skb CB data, etc.
>>
>
> skb->cb[] can be destroyed in netif_receive_skb() / __netif_receive_skb()
>
> #ifdef CONFIG_NET_CLS_ACT
> skb = handle_ing(skb, &pt_prev, &ret, orig_dev);
> ...
> #endif
Eric,
Can you elaborate a little further? we're not sure to see where
skb->cb[] is touched on the flow
you pointed to.
Or.
^ permalink raw reply
* UDP ordering when using multiple rx queue
From: Jean-Michel Hautbois @ 2012-07-11 7:53 UTC (permalink / raw)
To: netdev
Hi list,
I am doing some experiments on several NICs and I have an issue with
my application.
This is a sending of raw data packets which consists of bursts each
1/30s of 784 times 4000 bytes UDP packets.
The packets are one a wired link, no switch or anything, so there is
no chance of reordering or drop between the sender and receiver.
On receiver side, I need to get the packets ordered, or the
application will consider the packets are late (and then, lost).
(Yes, the application is badly written on that specific part, but it
is not mine :)).
Several tests lead to a simple conclusion : when the NIC has only one
RX queue, everything is ok (like be2net for instance), but when it has
more than one RX queue, then I can have "lost packets".
This is the case for bnx2x or mlx4 for instance.
Here are my questions :
- Is it possible to force a driver to use only one rx queue, even if
it can use more without reloading the driver (and this is feasible
only when a parameter exists for that !) ?
- Is it possible to "force" the network stack to give the packets on
the correct order (I would say no, as this is not specified in the
protocol) ?
My only bet is the first one (forcing one rx queue).
The last and desperate solution would be rewriting the application,
not easy to make it accepted.
Thanks !
JM
^ permalink raw reply
* Re: 82571EB: Detected Hardware Unit Hang
From: Joe Jin @ 2012-07-11 7:53 UTC (permalink / raw)
To: Dave, Tushar N
Cc: netdev@vger.kernel.org, e1000-devel@lists.sf.net,
linux-kernel@vger.kernel.org
In-Reply-To: <061C8A8601E8EE4CA8D8FD6990CEA891274EF055@ORSMSX102.amr.corp.intel.com>
On 07/11/12 15:50, Dave, Tushar N wrote:
> Device status and AER sections show some errors that looks little suspicious to me but I'm not too sure. I will get back tomorrow.
>
Thanks a lot, Tushar!
Joe
--
Oracle <http://www.oracle.com>
Joe Jin | Software Development Senior Manager | +8610.6106.5624
ORACLE | Linux and Virtualization
No. 24 Zhongguancun Software Park, Haidian District | 100193 Beijing
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* RE: 82571EB: Detected Hardware Unit Hang
From: Dave, Tushar N @ 2012-07-11 7:50 UTC (permalink / raw)
To: Joe Jin
Cc: e1000-devel@lists.sf.net, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, Dave, Tushar N
In-Reply-To: <4FFD2D7E.60801@oracle.com>
>-----Original Message-----
>From: Joe Jin [mailto:joe.jin@oracle.com]
>Sent: Wednesday, July 11, 2012 12:39 AM
>To: Dave, Tushar N
>Cc: e1000-devel@lists.sf.net; netdev@vger.kernel.org; linux-
>kernel@vger.kernel.org
>Subject: Re: 82571EB: Detected Hardware Unit Hang
>
>On 07/11/12 15:37, Dave, Tushar N wrote:
>>> -----Original Message-----
>>> From: Joe Jin [mailto:joe.jin@oracle.com]
>>> Sent: Wednesday, July 11, 2012 12:18 AM
>>> To: Dave, Tushar N
>>> Cc: e1000-devel@lists.sf.net; netdev@vger.kernel.org; linux-
>>> kernel@vger.kernel.org
>>> Subject: Re: 82571EB: Detected Hardware Unit Hang
>>>
>>> On 07/11/12 15:11, Dave, Tushar N wrote:
>>>>> -----Original Message-----
>>>>> From: Joe Jin [mailto:joe.jin@oracle.com]
>>>>> Sent: Tuesday, July 10, 2012 10:03 PM
>>>>> To: Dave, Tushar N
>>>>> Cc: e1000-devel@lists.sf.net; netdev@vger.kernel.org; linux-
>>>>> kernel@vger.kernel.org
>>>>> Subject: Re: 82571EB: Detected Hardware Unit Hang
>>>>>
>>>>> On 07/11/12 12:05, Dave, Tushar N wrote:
>>>>>> When you said you had this issue with RHEL5 and RHEL6 drivers,
>>>>>> have you
>>>>> install RHEl5/6 kernel and reproduced it? If so I think I should
>>>>> install
>>>>> RHEL6 and try reproduce it locally!
>>>>>>
>>>>> Yes I reproduced this on both RHEL5 and RHEL6.
>>>>>
>>>>> So far I tried to scp big file (~1GB) will hit it at once.
>>>>>
>>>>> Thanks,
>>>>> Joe
>>>>
>>>> Joe,
>>>> Can you please send lspci -vvv output for failing port before issue
>>> occurs.
>>>> Thanks.
>>>>
>>> # lspci -s 05:00.0 -vvv
>>> 05:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit
>>> Ethernet Controller (Copper) (rev 06)
>>> Subsystem: Oracle Corporation x4 PCI-Express Quad Gigabit Ethernet
>>> UTP Low Profile Adapter
>>> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
>>> Stepping- SERR- FastB2B- DisINTx+
>>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
>>> <TAbort- <MAbort- >SERR- <PERR- INTx-
>>> Latency: 0, Cache Line Size: 256 bytes
>>> Interrupt: pin B routed to IRQ 80
>>> Region 0: Memory at fbde0000 (32-bit, non-prefetchable) [size=128K]
>>> Region 1: Memory at fbdc0000 (32-bit, non-prefetchable) [size=128K]
>>> Region 2: I/O ports at dc00 [size=32]
>>> Expansion ROM at fbda0000 [disabled] [size=128K]
>>> Capabilities: [c8] Power Management version 2
>>> Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-
>>> ,D3hot+,D3cold+)
>>> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME-
>>> Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
>>> Address: 00000000fee21000 Data: 40cb
>>> Capabilities: [e0] Express (v1) Endpoint, MSI 00
>>> DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s
>>> <512ns, L1 <64us
>>> ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset-
>>> DevCtl: Report errors: Correctable- Non-Fatal- Fatal-
>>> Unsupported-
>>> RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
>>> MaxPayload 128 bytes, MaxReadReq 512 bytes
>>> DevSta: CorrErr- UncorrErr+ FatalErr- UnsuppReq+ AuxPwr+
>>> TransPend-
>>> LnkCap: Port #2, Speed 2.5GT/s, Width x4, ASPM L0s,
>>> Latency L0 <4us, L1 <64us
>>> ClockPM- Surprise- LLActRep- BwNot-
>>> LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain-
>>> CommClk-
>>> ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
>>> LnkSta: Speed 2.5GT/s, Width x4, TrErr- Train- SlotClk+
>>> DLActive- BWMgmt- ABWMgmt-
>>> Capabilities: [100 v1] Advanced Error Reporting
>>> UESta: DLP- SDES- TLP- FCP- CmpltTO+ CmpltAbrt- UnxCmplt-
>>> RxOF- MalfTLP+ ECRC- UnsupReq+ ACSViol-
>>> UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt-
>>> RxOF- MalfTLP- ECRC- UnsupReq+ ACSViol-
>>> UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt-
>>> UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
>>> CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
>>> CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
>>> AERCap: First Error Pointer: 12, GenCap- CGenEn- ChkCap-
>>> ChkEn-
>>> Capabilities: [140 v1] Device Serial Number 00-15-17-ff-ff-b9-77-9c
>>> Kernel driver in use: e1000e
>>> Kernel modules: e1000e
>>>
>>>
>>> Thanks,
>>> Joe
>>
>> was this lspci output taken on freshly booted system?
>>
>
>Yes, any issue do you find?
>
>Thanks,
>Joe
>
Device status and AER sections show some errors that looks little suspicious to me but I'm not too sure. I will get back tomorrow.
-Tushar
^ permalink raw reply
* Re: net-next kernel NULL pointer dereference at fib_rules_tclass
From: Or Gerlitz @ 2012-07-11 7:42 UTC (permalink / raw)
To: David Miller; +Cc: gregory.v.rose, eric.dumazet, netdev, shlomop, amirv, erezsh
In-Reply-To: <20120710.180543.1460678493453873565.davem@davemloft.net>
On 7/11/2012 4:05 AM, David Miller wrote:
> Great, pushed out to net-next, thanks everyone.
works here too, no crashing any more (on that one...)
Or.
^ permalink raw reply
* Re: 82571EB: Detected Hardware Unit Hang
From: Joe Jin @ 2012-07-11 7:38 UTC (permalink / raw)
To: Dave, Tushar N
Cc: netdev@vger.kernel.org, e1000-devel@lists.sf.net,
linux-kernel@vger.kernel.org
In-Reply-To: <061C8A8601E8EE4CA8D8FD6990CEA891274EEFD7@ORSMSX102.amr.corp.intel.com>
On 07/11/12 15:37, Dave, Tushar N wrote:
>> -----Original Message-----
>> From: Joe Jin [mailto:joe.jin@oracle.com]
>> Sent: Wednesday, July 11, 2012 12:18 AM
>> To: Dave, Tushar N
>> Cc: e1000-devel@lists.sf.net; netdev@vger.kernel.org; linux-
>> kernel@vger.kernel.org
>> Subject: Re: 82571EB: Detected Hardware Unit Hang
>>
>> On 07/11/12 15:11, Dave, Tushar N wrote:
>>>> -----Original Message-----
>>>> From: Joe Jin [mailto:joe.jin@oracle.com]
>>>> Sent: Tuesday, July 10, 2012 10:03 PM
>>>> To: Dave, Tushar N
>>>> Cc: e1000-devel@lists.sf.net; netdev@vger.kernel.org; linux-
>>>> kernel@vger.kernel.org
>>>> Subject: Re: 82571EB: Detected Hardware Unit Hang
>>>>
>>>> On 07/11/12 12:05, Dave, Tushar N wrote:
>>>>> When you said you had this issue with RHEL5 and RHEL6 drivers, have
>>>>> you
>>>> install RHEl5/6 kernel and reproduced it? If so I think I should
>>>> install
>>>> RHEL6 and try reproduce it locally!
>>>>>
>>>> Yes I reproduced this on both RHEL5 and RHEL6.
>>>>
>>>> So far I tried to scp big file (~1GB) will hit it at once.
>>>>
>>>> Thanks,
>>>> Joe
>>>
>>> Joe,
>>> Can you please send lspci -vvv output for failing port before issue
>> occurs.
>>> Thanks.
>>>
>> # lspci -s 05:00.0 -vvv
>> 05:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet
>> Controller (Copper) (rev 06)
>> Subsystem: Oracle Corporation x4 PCI-Express Quad Gigabit Ethernet
>> UTP Low Profile Adapter
>> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
>> Stepping- SERR- FastB2B- DisINTx+
>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
>> <TAbort- <MAbort- >SERR- <PERR- INTx-
>> Latency: 0, Cache Line Size: 256 bytes
>> Interrupt: pin B routed to IRQ 80
>> Region 0: Memory at fbde0000 (32-bit, non-prefetchable) [size=128K]
>> Region 1: Memory at fbdc0000 (32-bit, non-prefetchable) [size=128K]
>> Region 2: I/O ports at dc00 [size=32]
>> Expansion ROM at fbda0000 [disabled] [size=128K]
>> Capabilities: [c8] Power Management version 2
>> Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-
>> ,D3hot+,D3cold+)
>> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME-
>> Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
>> Address: 00000000fee21000 Data: 40cb
>> Capabilities: [e0] Express (v1) Endpoint, MSI 00
>> DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s
>> <512ns, L1 <64us
>> ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset-
>> DevCtl: Report errors: Correctable- Non-Fatal- Fatal-
>> Unsupported-
>> RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
>> MaxPayload 128 bytes, MaxReadReq 512 bytes
>> DevSta: CorrErr- UncorrErr+ FatalErr- UnsuppReq+ AuxPwr+
>> TransPend-
>> LnkCap: Port #2, Speed 2.5GT/s, Width x4, ASPM L0s,
>> Latency L0 <4us, L1 <64us
>> ClockPM- Surprise- LLActRep- BwNot-
>> LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain-
>> CommClk-
>> ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
>> LnkSta: Speed 2.5GT/s, Width x4, TrErr- Train- SlotClk+
>> DLActive- BWMgmt- ABWMgmt-
>> Capabilities: [100 v1] Advanced Error Reporting
>> UESta: DLP- SDES- TLP- FCP- CmpltTO+ CmpltAbrt- UnxCmplt-
>> RxOF- MalfTLP+ ECRC- UnsupReq+ ACSViol-
>> UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt-
>> RxOF- MalfTLP- ECRC- UnsupReq+ ACSViol-
>> UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt-
>> UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
>> CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
>> CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
>> AERCap: First Error Pointer: 12, GenCap- CGenEn- ChkCap-
>> ChkEn-
>> Capabilities: [140 v1] Device Serial Number 00-15-17-ff-ff-b9-77-9c
>> Kernel driver in use: e1000e
>> Kernel modules: e1000e
>>
>>
>> Thanks,
>> Joe
>
> was this lspci output taken on freshly booted system?
>
Yes, any issue do you find?
Thanks,
Joe
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: 82571EB: Detected Hardware Unit Hang
From: Dave, Tushar N @ 2012-07-11 7:37 UTC (permalink / raw)
To: Joe Jin
Cc: netdev@vger.kernel.org, e1000-devel@lists.sf.net,
linux-kernel@vger.kernel.org
In-Reply-To: <4FFD2896.3090209@oracle.com>
>-----Original Message-----
>From: Joe Jin [mailto:joe.jin@oracle.com]
>Sent: Wednesday, July 11, 2012 12:18 AM
>To: Dave, Tushar N
>Cc: e1000-devel@lists.sf.net; netdev@vger.kernel.org; linux-
>kernel@vger.kernel.org
>Subject: Re: 82571EB: Detected Hardware Unit Hang
>
>On 07/11/12 15:11, Dave, Tushar N wrote:
>>> -----Original Message-----
>>> From: Joe Jin [mailto:joe.jin@oracle.com]
>>> Sent: Tuesday, July 10, 2012 10:03 PM
>>> To: Dave, Tushar N
>>> Cc: e1000-devel@lists.sf.net; netdev@vger.kernel.org; linux-
>>> kernel@vger.kernel.org
>>> Subject: Re: 82571EB: Detected Hardware Unit Hang
>>>
>>> On 07/11/12 12:05, Dave, Tushar N wrote:
>>>> When you said you had this issue with RHEL5 and RHEL6 drivers, have
>>>> you
>>> install RHEl5/6 kernel and reproduced it? If so I think I should
>>> install
>>> RHEL6 and try reproduce it locally!
>>>>
>>> Yes I reproduced this on both RHEL5 and RHEL6.
>>>
>>> So far I tried to scp big file (~1GB) will hit it at once.
>>>
>>> Thanks,
>>> Joe
>>
>> Joe,
>> Can you please send lspci -vvv output for failing port before issue
>occurs.
>> Thanks.
>>
># lspci -s 05:00.0 -vvv
>05:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet
>Controller (Copper) (rev 06)
> Subsystem: Oracle Corporation x4 PCI-Express Quad Gigabit Ethernet
>UTP Low Profile Adapter
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
>Stepping- SERR- FastB2B- DisINTx+
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
><TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 0, Cache Line Size: 256 bytes
> Interrupt: pin B routed to IRQ 80
> Region 0: Memory at fbde0000 (32-bit, non-prefetchable) [size=128K]
> Region 1: Memory at fbdc0000 (32-bit, non-prefetchable) [size=128K]
> Region 2: I/O ports at dc00 [size=32]
> Expansion ROM at fbda0000 [disabled] [size=128K]
> Capabilities: [c8] Power Management version 2
> Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-
>,D3hot+,D3cold+)
> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME-
> Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
> Address: 00000000fee21000 Data: 40cb
> Capabilities: [e0] Express (v1) Endpoint, MSI 00
> DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s
><512ns, L1 <64us
> ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset-
> DevCtl: Report errors: Correctable- Non-Fatal- Fatal-
>Unsupported-
> RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
> MaxPayload 128 bytes, MaxReadReq 512 bytes
> DevSta: CorrErr- UncorrErr+ FatalErr- UnsuppReq+ AuxPwr+
>TransPend-
> LnkCap: Port #2, Speed 2.5GT/s, Width x4, ASPM L0s,
>Latency L0 <4us, L1 <64us
> ClockPM- Surprise- LLActRep- BwNot-
> LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain-
>CommClk-
> ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
> LnkSta: Speed 2.5GT/s, Width x4, TrErr- Train- SlotClk+
>DLActive- BWMgmt- ABWMgmt-
> Capabilities: [100 v1] Advanced Error Reporting
> UESta: DLP- SDES- TLP- FCP- CmpltTO+ CmpltAbrt- UnxCmplt-
>RxOF- MalfTLP+ ECRC- UnsupReq+ ACSViol-
> UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt-
>RxOF- MalfTLP- ECRC- UnsupReq+ ACSViol-
> UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt-
>UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
> CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
> CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
> AERCap: First Error Pointer: 12, GenCap- CGenEn- ChkCap-
>ChkEn-
> Capabilities: [140 v1] Device Serial Number 00-15-17-ff-ff-b9-77-9c
> Kernel driver in use: e1000e
> Kernel modules: e1000e
>
>
>Thanks,
>Joe
was this lspci output taken on freshly booted system?
-Tushar
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: [PATCH] etherdevice: introduce eth_broadcast_addr
From: Johannes Berg @ 2012-07-11 7:27 UTC (permalink / raw)
To: Paul Gortmaker
Cc: David Miller, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CAP=VYLqNyAF1gSsKTd3YojeJXK_-pEzXAKyVQbQfwhtwOyMmwg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue, 2012-07-10 at 20:09 -0400, Paul Gortmaker wrote:
> On Tue, Jul 10, 2012 at 12:18 PM, Johannes Berg
> <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> wrote:
> > From: Johannes Berg <johannes.berg-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> >
> > A lot of code has either the memset or an inefficient copy
> > from a static array that contains the all-ones broadcast
>
> Shouldn't we see all that "lot of code" here in this same
> commit, now using this new shortcut? If we apply this, we
> have a new function, but with no users. If you have done
> the audit, and found the inefficient cases, why isn't it here?
I'm planning to fix the wireless uses (at least the ones I'm responsible
for), but I'm just going to stick them into my mac80211-next tree after
this patch percolates down there, I don't see a need to send around a
ton of patches for it.
> I would think it better to just fix those people who have a
> pointless static array of all-ones to use the memset. If it was a
> multi line thing to achieve the eth_broadcast_addr() then it
> might make sense to exist. But as a one line alias, it does
> seem somewhat pointless to me.
At least in my code I'm going to prefer this over the memset for
documentation purposes. I'll agree that memset(..., 0xff, ETH_ALEN) is
pretty obvious already, but eth_broadcast_addr(...) is even easier to
read IMHO.
johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH net-next v2 7/7] 6lowpan: rework fragment-deleting routine
From: Alexander Smirnov @ 2012-07-11 7:22 UTC (permalink / raw)
To: davem, eric.dumazet; +Cc: netdev, Alexander Smirnov
In-Reply-To: <1341991368-11800-1-git-send-email-alex.bluesman.smirnov@gmail.com>
6lowpan module starts collecting incomming frames and fragments
right after lowpan_module_init() therefor it will be better to
clean unfinished fragments in lowpan_cleanup_module() function
instead of doing it when link goes down.
Changed spinlocks type to prevent deadlock with expired timer event
and removed unused one.
Signed-off-by: Alexander Smirnov <alex.bluesman.smirnov@gmail.com>
---
net/ieee802154/6lowpan.c | 39 ++++++++++++++++++++-------------------
1 files changed, 20 insertions(+), 19 deletions(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index 2e790fb..6871ec1 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -113,7 +113,6 @@ struct lowpan_dev_record {
struct lowpan_fragment {
struct sk_buff *skb; /* skb to be assembled */
- spinlock_t lock; /* concurency lock */
u16 length; /* length to be assemled */
u32 bytes_rcv; /* bytes received */
u16 tag; /* current fragment tag */
@@ -637,10 +636,7 @@ static void lowpan_fragment_timer_expired(unsigned long entry_addr)
pr_debug("timer expired for frame with tag %d\n", entry->tag);
- spin_lock(&flist_lock);
list_del(&entry->list);
- spin_unlock(&flist_lock);
-
dev_kfree_skb(entry->skb);
kfree(entry);
}
@@ -727,7 +723,7 @@ lowpan_process_data(struct sk_buff *skb)
* check if frame assembling with the same tag is
* already in progress
*/
- spin_lock(&flist_lock);
+ spin_lock_bh(&flist_lock);
list_for_each_entry(frame, &lowpan_fragments, list)
if (frame->tag == tag) {
@@ -761,9 +757,9 @@ lowpan_process_data(struct sk_buff *skb)
if ((frame->bytes_rcv == frame->length) &&
frame->timer.expires > jiffies) {
/* if timer haven't expired - first of all delete it */
- del_timer(&frame->timer);
+ del_timer_sync(&frame->timer);
list_del(&frame->list);
- spin_unlock(&flist_lock);
+ spin_unlock_bh(&flist_lock);
dev_kfree_skb(skb);
skb = frame->skb;
@@ -774,7 +770,7 @@ lowpan_process_data(struct sk_buff *skb)
break;
}
- spin_unlock(&flist_lock);
+ spin_unlock_bh(&flist_lock);
return kfree_skb(skb), 0;
}
@@ -929,7 +925,7 @@ lowpan_process_data(struct sk_buff *skb)
return lowpan_skb_deliver(skb, &hdr);
unlock_and_drop:
- spin_unlock(&flist_lock);
+ spin_unlock_bh(&flist_lock);
drop:
kfree_skb(skb);
return -EINVAL;
@@ -1196,19 +1192,9 @@ static void lowpan_dellink(struct net_device *dev, struct list_head *head)
struct lowpan_dev_info *lowpan_dev = lowpan_dev_info(dev);
struct net_device *real_dev = lowpan_dev->real_dev;
struct lowpan_dev_record *entry, *tmp;
- struct lowpan_fragment *frame, *tframe;
ASSERT_RTNL();
- spin_lock(&flist_lock);
- list_for_each_entry_safe(frame, tframe, &lowpan_fragments, list) {
- del_timer(&frame->timer);
- list_del(&frame->list);
- dev_kfree_skb(frame->skb);
- kfree(frame);
- }
- spin_unlock(&flist_lock);
-
mutex_lock(&lowpan_dev_info(dev)->dev_list_mtx);
list_for_each_entry_safe(entry, tmp, &lowpan_devices, list) {
if (entry->ldev == dev) {
@@ -1264,9 +1250,24 @@ out:
static void __exit lowpan_cleanup_module(void)
{
+ struct lowpan_fragment *frame, *tframe;
+
lowpan_netlink_fini();
dev_remove_pack(&lowpan_packet_type);
+
+ /* Now 6lowpan packet_type is removed, so no new fragments are
+ * expected on RX, therefore that's the time to clean incomplete
+ * fragments.
+ */
+ spin_lock_bh(&flist_lock);
+ list_for_each_entry_safe(frame, tframe, &lowpan_fragments, list) {
+ del_timer_sync(&frame->timer);
+ list_del(&frame->list);
+ dev_kfree_skb(frame->skb);
+ kfree(frame);
+ }
+ spin_unlock_bh(&flist_lock);
}
module_init(lowpan_init_module);
--
1.7.2.3
^ permalink raw reply related
* [PATCH net-next v2 6/7] 6lowpan: fix tag variable size
From: Alexander Smirnov @ 2012-07-11 7:22 UTC (permalink / raw)
To: davem, eric.dumazet; +Cc: netdev, Alexander Smirnov, Tony Cheneau
In-Reply-To: <1341991368-11800-1-git-send-email-alex.bluesman.smirnov@gmail.com>
Function lowpan_alloc_new_frame() takes u8 tag as an argument. However,
its only caller, lowpan_process_data() passes down a u16. Hence,
the tag value can get corrupted. This prevent 6lowpan fragment reassembly of a
message when the fragment tag value is over 256.
Signed-off-by: Alexander Smirnov <alex.bluesman.smirnov@gmail.com>
Cc: Tony Cheneau <tony.cheneau@amnesiak.org>
---
net/ieee802154/6lowpan.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index ae3f4eb..2e790fb 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -646,7 +646,7 @@ static void lowpan_fragment_timer_expired(unsigned long entry_addr)
}
static struct lowpan_fragment *
-lowpan_alloc_new_frame(struct sk_buff *skb, u8 iphc0, u8 len, u8 tag)
+lowpan_alloc_new_frame(struct sk_buff *skb, u8 iphc0, u8 len, u16 tag)
{
struct lowpan_fragment *frame;
--
1.7.2.3
^ permalink raw reply related
* [PATCH net-next v2 5/7] mac802154: sparse warnings: make symbols static
From: Alexander Smirnov @ 2012-07-11 7:22 UTC (permalink / raw)
To: davem, eric.dumazet; +Cc: netdev, Alexander Smirnov
In-Reply-To: <1341991368-11800-1-git-send-email-alex.bluesman.smirnov@gmail.com>
Make symbols static to avoid the following warning shown up
by sparse:
warning: symbol ... was not declared. Should it be static?
Signed-off-by: Alexander Smirnov <alex.bluesman.smirnov@gmail.com>
---
net/mac802154/mac_cmd.c | 2 +-
net/mac802154/mib.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/mac802154/mac_cmd.c b/net/mac802154/mac_cmd.c
index 5d9a47b..d8d2770 100644
--- a/net/mac802154/mac_cmd.c
+++ b/net/mac802154/mac_cmd.c
@@ -55,7 +55,7 @@ static int mac802154_mlme_start_req(struct net_device *dev,
return 0;
}
-struct wpan_phy *mac802154_get_phy(const struct net_device *dev)
+static struct wpan_phy *mac802154_get_phy(const struct net_device *dev)
{
struct mac802154_sub_if_data *priv = netdev_priv(dev);
diff --git a/net/mac802154/mib.c b/net/mac802154/mib.c
index 5c66b8f..f47781a 100644
--- a/net/mac802154/mib.c
+++ b/net/mac802154/mib.c
@@ -39,7 +39,7 @@ struct hw_addr_filt_notify_work {
unsigned long changed;
};
-struct mac802154_priv *mac802154_slave_get_priv(struct net_device *dev)
+static struct mac802154_priv *mac802154_slave_get_priv(struct net_device *dev)
{
struct mac802154_sub_if_data *priv = netdev_priv(dev);
--
1.7.2.3
^ permalink raw reply related
* [PATCH net-next v2 4/7] 6lowpan: get extra headroom in allocated frame
From: Alexander Smirnov @ 2012-07-11 7:22 UTC (permalink / raw)
To: davem, eric.dumazet; +Cc: netdev, Alexander Smirnov
In-Reply-To: <1341991368-11800-1-git-send-email-alex.bluesman.smirnov@gmail.com>
Use netdev_alloc_skb_ip_align() instead of alloc_skb() to get some
extra headroom in case we need to forward this frame in a tunnel or
something else.
Signed-off-by: Alexander Smirnov <alex.bluesman.smirnov@gmail.com>
---
net/ieee802154/6lowpan.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index b872515..ae3f4eb 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -661,8 +661,8 @@ lowpan_alloc_new_frame(struct sk_buff *skb, u8 iphc0, u8 len, u8 tag)
frame->tag = tag;
/* allocate buffer for frame assembling */
- frame->skb = alloc_skb(frame->length +
- sizeof(struct ipv6hdr), GFP_ATOMIC);
+ frame->skb = netdev_alloc_skb_ip_align(skb->dev, frame->length +
+ sizeof(struct ipv6hdr));
if (!frame->skb)
goto skb_err;
--
1.7.2.3
^ permalink raw reply related
* [PATCH net-next v2 3/7] mac802154: add get short address method
From: Alexander Smirnov @ 2012-07-11 7:22 UTC (permalink / raw)
To: davem, eric.dumazet; +Cc: netdev, Alexander Smirnov
In-Reply-To: <1341991368-11800-1-git-send-email-alex.bluesman.smirnov@gmail.com>
Add method to get the device short 802.15.4 address. This call
needed by ieee802154 layer to satisfy 'iz list' request from
the user space.
Signed-off-by: Alexander Smirnov <alex.bluesman.smirnov@gmail.com>
---
net/mac802154/mac802154.h | 1 +
net/mac802154/mac_cmd.c | 2 ++
net/mac802154/mib.c | 14 ++++++++++++++
3 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/net/mac802154/mac802154.h b/net/mac802154/mac802154.h
index 6967864..a4dcaf1 100644
--- a/net/mac802154/mac802154.h
+++ b/net/mac802154/mac802154.h
@@ -109,6 +109,7 @@ netdev_tx_t mac802154_tx(struct mac802154_priv *priv, struct sk_buff *skb,
/* MIB callbacks */
void mac802154_dev_set_short_addr(struct net_device *dev, u16 val);
+u16 mac802154_dev_get_short_addr(const struct net_device *dev);
void mac802154_dev_set_ieee_addr(struct net_device *dev);
u16 mac802154_dev_get_pan_id(const struct net_device *dev);
void mac802154_dev_set_pan_id(struct net_device *dev, u16 val);
diff --git a/net/mac802154/mac_cmd.c b/net/mac802154/mac_cmd.c
index 7f5403e..5d9a47b 100644
--- a/net/mac802154/mac_cmd.c
+++ b/net/mac802154/mac_cmd.c
@@ -71,4 +71,6 @@ struct ieee802154_reduced_mlme_ops mac802154_mlme_reduced = {
struct ieee802154_mlme_ops mac802154_mlme_wpan = {
.get_phy = mac802154_get_phy,
.start_req = mac802154_mlme_start_req,
+ .get_pan_id = mac802154_dev_get_pan_id,
+ .get_short_addr = mac802154_dev_get_short_addr,
};
diff --git a/net/mac802154/mib.c b/net/mac802154/mib.c
index 380829d..5c66b8f 100644
--- a/net/mac802154/mib.c
+++ b/net/mac802154/mib.c
@@ -100,6 +100,20 @@ void mac802154_dev_set_short_addr(struct net_device *dev, u16 val)
}
}
+u16 mac802154_dev_get_short_addr(const struct net_device *dev)
+{
+ struct mac802154_sub_if_data *priv = netdev_priv(dev);
+ u16 ret;
+
+ BUG_ON(dev->type != ARPHRD_IEEE802154);
+
+ spin_lock_bh(&priv->mib_lock);
+ ret = priv->short_addr;
+ spin_unlock_bh(&priv->mib_lock);
+
+ return ret;
+}
+
void mac802154_dev_set_ieee_addr(struct net_device *dev)
{
struct mac802154_sub_if_data *priv = netdev_priv(dev);
--
1.7.2.3
^ permalink raw reply related
* [PATCH net-next v2 2/7] drivers/ieee802154/at86rf230: rework irq handler
From: Alexander Smirnov @ 2012-07-11 7:22 UTC (permalink / raw)
To: davem, eric.dumazet; +Cc: netdev, Alexander Smirnov
In-Reply-To: <1341991368-11800-1-git-send-email-alex.bluesman.smirnov@gmail.com>
Fix LOCKDEP bug message for the irq handler spinlock.
Make the irq processing code more explicit and stable.
Signed-off-by: Alexander Smirnov <alex.bluesman.smirnov@gmail.com>
---
drivers/ieee802154/at86rf230.c | 32 ++++++++++++++++++--------------
1 files changed, 18 insertions(+), 14 deletions(-)
diff --git a/drivers/ieee802154/at86rf230.c b/drivers/ieee802154/at86rf230.c
index 902e38b..5d30940 100644
--- a/drivers/ieee802154/at86rf230.c
+++ b/drivers/ieee802154/at86rf230.c
@@ -543,6 +543,13 @@ at86rf230_xmit(struct ieee802154_dev *dev, struct sk_buff *skb)
int rc;
unsigned long flags;
+ spin_lock(&lp->lock);
+ if (lp->irq_disabled) {
+ spin_unlock(&lp->lock);
+ return -EBUSY;
+ }
+ spin_unlock(&lp->lock);
+
might_sleep();
rc = at86rf230_state(dev, STATE_FORCE_TX_ON);
@@ -592,12 +599,8 @@ static int at86rf230_rx(struct at86rf230_local *lp)
if (!skb)
return -ENOMEM;
- if (at86rf230_write_subreg(lp, SR_RX_PDT_DIS, 1) ||
- at86rf230_read_fbuf(lp, skb_put(skb, len), &len, &lqi) ||
- at86rf230_write_subreg(lp, SR_RX_SAFE_MODE, 1) ||
- at86rf230_write_subreg(lp, SR_RX_PDT_DIS, 0)) {
+ if (at86rf230_read_fbuf(lp, skb_put(skb, len), &len, &lqi))
goto err;
- }
if (len < 2)
goto err;
@@ -633,7 +636,6 @@ static void at86rf230_irqwork(struct work_struct *work)
int rc;
unsigned long flags;
- spin_lock_irqsave(&lp->lock, flags);
rc = at86rf230_read_subreg(lp, RG_IRQ_STATUS, 0xff, 0, &val);
status |= val;
@@ -643,31 +645,33 @@ static void at86rf230_irqwork(struct work_struct *work)
status &= ~IRQ_TRX_UR; /* FIXME: possibly handle ???*/
if (status & IRQ_TRX_END) {
+ spin_lock_irqsave(&lp->lock, flags);
status &= ~IRQ_TRX_END;
if (lp->is_tx) {
lp->is_tx = 0;
+ spin_unlock_irqrestore(&lp->lock, flags);
complete(&lp->tx_complete);
} else {
+ spin_unlock_irqrestore(&lp->lock, flags);
at86rf230_rx(lp);
}
}
- if (lp->irq_disabled) {
- lp->irq_disabled = 0;
- enable_irq(lp->spi->irq);
- }
+ spin_lock_irqsave(&lp->lock, flags);
+ lp->irq_disabled = 0;
spin_unlock_irqrestore(&lp->lock, flags);
+
+ enable_irq(lp->spi->irq);
}
static irqreturn_t at86rf230_isr(int irq, void *data)
{
struct at86rf230_local *lp = data;
+ disable_irq_nosync(irq);
+
spin_lock(&lp->lock);
- if (!lp->irq_disabled) {
- disable_irq_nosync(irq);
- lp->irq_disabled = 1;
- }
+ lp->irq_disabled = 1;
spin_unlock(&lp->lock);
schedule_work(&lp->irqwork);
--
1.7.2.3
^ permalink raw reply related
* [PATCH net-next v2 1/7] 6lowpan: revert: add missing spin_lock_init()
From: Alexander Smirnov @ 2012-07-11 7:22 UTC (permalink / raw)
To: davem, eric.dumazet; +Cc: netdev, Alexander Smirnov
In-Reply-To: <1341991368-11800-1-git-send-email-alex.bluesman.smirnov@gmail.com>
Revert the commit 768f7c7c121e80f458a9d013b2e8b169e5dfb1e5 to initialize
spinlock in the more preferable way and make it static to avoid sparse
warning.
Signed-off-by: Alexander Smirnov <alex.bluesman.smirnov@gmail.com>
---
net/ieee802154/6lowpan.c | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index f4070e5..b872515 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -123,7 +123,7 @@ struct lowpan_fragment {
static unsigned short fragment_tag;
static LIST_HEAD(lowpan_fragments);
-spinlock_t flist_lock;
+static DEFINE_SPINLOCK(flist_lock);
static inline struct
lowpan_dev_info *lowpan_dev_info(const struct net_device *dev)
@@ -1186,8 +1186,6 @@ static int lowpan_newlink(struct net *src_net, struct net_device *dev,
list_add_tail(&entry->list, &lowpan_devices);
mutex_unlock(&lowpan_dev_info(dev)->dev_list_mtx);
- spin_lock_init(&flist_lock);
-
register_netdevice(dev);
return 0;
--
1.7.2.3
^ permalink raw reply related
* [PATCH net-next v2 0/7] ieee802.15.4 general fixes
From: Alexander Smirnov @ 2012-07-11 7:22 UTC (permalink / raw)
To: davem, eric.dumazet; +Cc: netdev
Dear David, Eric,
this patch-set is mostly intended to fix sparse and LOCKDEP warnings.
It mostly contains some my previous patches reworked and extended according
to the hints from Eric Dumazet and Fengguang Wu. Many thanks to they!
Changes since v1:
1. A new patch from Tony Cheneau was added. The fragmentation stops working
after some amount of packets sent. This patch fixes this issue.
2. 6lowpan fragment deleting routine: I removed spinlocks from timer_expired
handler and use spin_lock_bh to disable concurrency races with timer interrupt.
3. at86rf230 irq handler was a little bit modified
With best regards,
Alex
Alexander Smirnov (7):
6lowpan: revert: add missing spin_lock_init()
drivers/ieee802154/at86rf230: rework irq handler
mac802154: add get short address method
6lowpan: get extra headroom in allocated frame
mac802154: sparse warnings: make symbols static
6lowpan: fix tag variable size
6lowpan: rework fragment-deleting routine
drivers/ieee802154/at86rf230.c | 32 ++++++++++++++-----------
net/ieee802154/6lowpan.c | 49 +++++++++++++++++++--------------------
net/mac802154/mac802154.h | 1 +
net/mac802154/mac_cmd.c | 4 ++-
net/mac802154/mib.c | 16 ++++++++++++-
5 files changed, 61 insertions(+), 41 deletions(-)
--
1.7.2.3
^ permalink raw reply
* [PATCH] tc_util: fix incorrect bare number process in get_rate.
From: Li Wei @ 2012-07-11 7:24 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
As the comment and manpage indicated that the bare number means
bytes per second, so the division is not needed.
---
tc/tc_util.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/tc/tc_util.c b/tc/tc_util.c
index 926ed08..e8d89c1 100644
--- a/tc/tc_util.c
+++ b/tc/tc_util.c
@@ -153,7 +153,7 @@ int get_rate(unsigned *rate, const char *str)
return -1;
if (*p == '\0') {
- *rate = bps / 8.; /* assume bytes/sec */
+ *rate = bps; /* assume bytes/sec */
return 0;
}
--
1.7.1
^ permalink raw reply related
* Re: 82571EB: Detected Hardware Unit Hang
From: Joe Jin @ 2012-07-11 7:17 UTC (permalink / raw)
To: Dave, Tushar N
Cc: netdev@vger.kernel.org, e1000-devel@lists.sf.net,
linux-kernel@vger.kernel.org
In-Reply-To: <061C8A8601E8EE4CA8D8FD6990CEA891274EEF38@ORSMSX102.amr.corp.intel.com>
On 07/11/12 15:11, Dave, Tushar N wrote:
>> -----Original Message-----
>> From: Joe Jin [mailto:joe.jin@oracle.com]
>> Sent: Tuesday, July 10, 2012 10:03 PM
>> To: Dave, Tushar N
>> Cc: e1000-devel@lists.sf.net; netdev@vger.kernel.org; linux-
>> kernel@vger.kernel.org
>> Subject: Re: 82571EB: Detected Hardware Unit Hang
>>
>> On 07/11/12 12:05, Dave, Tushar N wrote:
>>> When you said you had this issue with RHEL5 and RHEL6 drivers, have you
>> install RHEl5/6 kernel and reproduced it? If so I think I should install
>> RHEL6 and try reproduce it locally!
>>>
>> Yes I reproduced this on both RHEL5 and RHEL6.
>>
>> So far I tried to scp big file (~1GB) will hit it at once.
>>
>> Thanks,
>> Joe
>
> Joe,
> Can you please send lspci -vvv output for failing port before issue occurs.
> Thanks.
>
# lspci -s 05:00.0 -vvv
05:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (Copper) (rev 06)
Subsystem: Oracle Corporation x4 PCI-Express Quad Gigabit Ethernet UTP Low Profile Adapter
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 256 bytes
Interrupt: pin B routed to IRQ 80
Region 0: Memory at fbde0000 (32-bit, non-prefetchable) [size=128K]
Region 1: Memory at fbdc0000 (32-bit, non-prefetchable) [size=128K]
Region 2: I/O ports at dc00 [size=32]
Expansion ROM at fbda0000 [disabled] [size=128K]
Capabilities: [c8] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME-
Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Address: 00000000fee21000 Data: 40cb
Capabilities: [e0] Express (v1) Endpoint, MSI 00
DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <512ns, L1 <64us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr- UncorrErr+ FatalErr- UnsuppReq+ AuxPwr+ TransPend-
LnkCap: Port #2, Speed 2.5GT/s, Width x4, ASPM L0s, Latency L0 <4us, L1 <64us
ClockPM- Surprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x4, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
Capabilities: [100 v1] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO+ CmpltAbrt- UnxCmplt- RxOF- MalfTLP+ ECRC- UnsupReq+ ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq+ ACSViol-
UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
AERCap: First Error Pointer: 12, GenCap- CGenEn- ChkCap- ChkEn-
Capabilities: [140 v1] Device Serial Number 00-15-17-ff-ff-b9-77-9c
Kernel driver in use: e1000e
Kernel modules: e1000e
Thanks,
Joe
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* RE: 82571EB: Detected Hardware Unit Hang
From: Dave, Tushar N @ 2012-07-11 7:11 UTC (permalink / raw)
To: Joe Jin
Cc: e1000-devel@lists.sf.net, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, Dave, Tushar N
In-Reply-To: <4FFD0908.6080506@oracle.com>
>-----Original Message-----
>From: Joe Jin [mailto:joe.jin@oracle.com]
>Sent: Tuesday, July 10, 2012 10:03 PM
>To: Dave, Tushar N
>Cc: e1000-devel@lists.sf.net; netdev@vger.kernel.org; linux-
>kernel@vger.kernel.org
>Subject: Re: 82571EB: Detected Hardware Unit Hang
>
>On 07/11/12 12:05, Dave, Tushar N wrote:
>> When you said you had this issue with RHEL5 and RHEL6 drivers, have you
>install RHEl5/6 kernel and reproduced it? If so I think I should install
>RHEL6 and try reproduce it locally!
>>
>Yes I reproduced this on both RHEL5 and RHEL6.
>
>So far I tried to scp big file (~1GB) will hit it at once.
>
>Thanks,
>Joe
Joe,
Can you please send lspci -vvv output for failing port before issue occurs.
Thanks.
-Tushar
^ permalink raw reply
* Re: [PATCH] IPoIB: fix skb truesize underestimatiom
From: David Miller @ 2012-07-11 6:37 UTC (permalink / raw)
To: eric.dumazet; +Cc: ogerlitz, erezsh, roland, netdev, shlomop
In-Reply-To: <1341950621.3265.6331.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 10 Jul 2012 22:03:41 +0200
> From: Eric Dumazet <edumazet@google.com>
>
> Or Gerlitz reported triggering of WARN_ON_ONCE(delta < len); in
> skb_try_coalesce()
> This warning tracks drivers that incorrectly set skb->truesize
>
> IPoIB indeed allocates a full page to store a fragment, but only
> accounts in skb->truesize the used part of the page (frame length)
>
> This patch fixes skb truesize underestimation, and
> also fixes a performance issue, because RX skbs have not enough tailroom
> to allow IP and TCP stacks to pull their header in skb linear part
> without an expensive call to pskb_expand_head()
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: Or Gerlitz <ogerlitz@mellanox.com>
Applied to net, thanks.
^ permalink raw reply
* Re: [PATCH net] bnx2: Fix bug in bnx2_free_tx_skbs().
From: David Miller @ 2012-07-11 6:37 UTC (permalink / raw)
To: mchan; +Cc: netdev
In-Reply-To: <1341950680-12266-1-git-send-email-mchan@broadcom.com>
From: "Michael Chan" <mchan@broadcom.com>
Date: Tue, 10 Jul 2012 13:04:40 -0700
> In rare cases, bnx2x_free_tx_skbs() can unmap the wrong DMA address
> when it gets to the last entry of the tx ring. We were not using
> the proper macro to skip the last entry when advancing the tx index.
>
> Reported-by: Zongyun Lai <zlai@vmware.com>
> Reviewed-by: Jeffrey Huang <huangjw@broadcom.com>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
Applied and queued up for -stable.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox