* Re: [RFC][PATCH] iproute: Faster ip link add, set and delete
From: Serge Hallyn @ 2013-03-28 4:28 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Stephen Hemminger, Benoit Lourdelet, netdev@vger.kernel.org
In-Reply-To: <87vc8cnq6v.fsf@xmission.com>
Quoting Eric W. Biederman (ebiederm@xmission.com):
> Serge Hallyn <serge.hallyn@ubuntu.com> writes:
>
> > Quoting Eric W. Biederman (ebiederm@xmission.com):
> >> Stephen Hemminger <stephen@networkplumber.org> writes:
> >>
> >> > If you need to do lots of operations the --batch mode will be significantly faster.
> >> > One command start and one link map.
> >>
> >> The problem in this case as I understand it is lots of independent
> >> operations. Now maybe lxc should not shell out to ip and perform the
> >> work itself.
> >
> > fwiw lxc uses netlink to create new veths, and picks random names with
> > mktemp() ahead of time.
>
> I am puzzled where does the slownes in iproute2 come into play?
Benoit originally reported slowness when starting >1500 containers. I
asked him to run a few manual tests to figure out what was taking the
time. Manually creating a large # of veths was an obvious test, and
one which showed poorly scaling performance.
May well be there are other things slowing down lxc of course.
-serge
^ permalink raw reply
* [PATCH v2] igb: fix error return code in igb_sysfs_init()
From: Wei Yongjun @ 2013-03-28 4:18 UTC (permalink / raw)
To: jeffrey.t.kirsher, jesse.brandeburg, bruce.w.allan,
carolyn.wyborny, donald.c.skidmore, gregory.v.rose,
peter.p.waskiewicz.jr, alexander.h.duyck, john.ronciak,
tushar.n.dave, stephen, akeem.g.abodunrin
Cc: e1000-devel, netdev, yongjun_wei
From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Fix to return a negative error code from the error handling
case instead of 0, as returned elsewhere in this function.
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
---
v1 -> v2: use EIO instead of ENOMEM
---
drivers/net/ethernet/intel/igb/igb_hwmon.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/intel/igb/igb_hwmon.c b/drivers/net/ethernet/intel/igb/igb_hwmon.c
index 0478a1a..770455e 100644
--- a/drivers/net/ethernet/intel/igb/igb_hwmon.c
+++ b/drivers/net/ethernet/intel/igb/igb_hwmon.c
@@ -208,6 +208,7 @@ int igb_sysfs_init(struct igb_adapter *adapter)
if (client == NULL) {
dev_info(&adapter->pdev->dev,
"Failed to create new i2c device..\n");
+ rc = -EIO;
goto exit;
}
adapter->i2c_client = client;
------------------------------------------------------------------------------
Own the Future-Intel® Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest.
Compete for recognition, cash, and the chance to get your game
on Steam. $5K grand prize plus 10 genre and skill prizes.
Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
_______________________________________________
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 related
* Re: defxx: skb_push() failing?
From: David Oostdyk @ 2013-03-28 4:11 UTC (permalink / raw)
To: Maciej W. Rozycki; +Cc: Eric Dumazet, netdev@vger.kernel.org
In-Reply-To: <alpine.LFD.2.03.1303261852220.8240@linux-mips.org>
[-- Attachment #1: Type: text/plain, Size: 1070 bytes --]
Hi Maciej,
I can confirm that the two FDDI cards work on a 32-bit kernel. I'm not
getting anywhere near the data rates I'd expect (3.5MB/sec?) but it's a
start. I'd be glad to help test any 64-bit patches you come up with,
Maciej.
Either way, Eric Dumazet's patch to drivers/block/aoe/aoecmd.c seems to
be required to prevent a panic right after defxx is loaded. Eric - good
find. Should your patch be submitted upstream, then?
Dave O.
On 03/26/13 15:00, Maciej W. Rozycki wrote:
> On Tue, 26 Mar 2013, David Oostdyk wrote:
>
>> (Now if I could only figure out why these FDDI cards don't want to talk to
>> each other... I was hoping that was it.)
> I saw 64-bit addresses in your log -- the driver is known not to be
> 64-bit-clean, I've had an initial look into it recently and will be
> addressing it shortly.
>
> Maciej
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4567 bytes --]
^ permalink raw reply
* RE: Atheros Communications Inc. AR8121/AR8113/AR8114 Gigabit or Fast Ethernet (rev b0) 1.0.0.7 md5/sha1 corrupted using NFS and samba (updated) Version 2
From: Huang, Xiong @ 2013-03-28 3:52 UTC (permalink / raw)
To: Hannes Frederic Sowa; +Cc: Sven Hartge, netdev@vger.kernel.org
In-Reply-To: <20130328032934.GD2176@order.stressinduktion.org>
Sorry, my fault, your code is right.
> -----Original Message-----
> From: Hannes Frederic Sowa [mailto:hannes@stressinduktion.org]
> Sent: Thursday, March 28, 2013 11:30 AM
> To: Huang, Xiong
> Cc: Sven Hartge; netdev@vger.kernel.org
> Subject: Re: Atheros Communications Inc. AR8121/AR8113/AR8114 Gigabit or
> Fast Ethernet (rev b0) 1.0.0.7 md5/sha1 corrupted using NFS and samba
> (updated) Version 2
>
> On Thu, Mar 28, 2013 at 03:25:29AM +0000, Huang, Xiong wrote:
> > Please don't revise following code:
> >
> > rx_page->read_offset +=
> > (((u32)((prrs->word1 >>
> RRS_PKT_SIZE_SHIFT) &
> > RRS_PKT_SIZE_MASK) +
> > sizeof(struct atl1e_recv_ret_status) + 31) &
> > 0xFFFFFFE0);
> >
> > Here 32bytes alignment is no matter with Page alignment.
>
> If I revert this change I get sequence errors:
>
> [ 781.449864] ATL1E 0000:04:00.0: irq 45 for MSI/MSI-X [ 781.454634] IPv6:
> ADDRCONF(NETDEV_UP): p33p1: link is not ready [ 782.893744] ATL1E
> 0000:04:00.0 p33p1: NIC Link is Up <100 Mbps Full Duplex> [ 782.893797] IPv6:
> ADDRCONF(NETDEV_CHANGE): p33p1: link becomes ready [ 783.194443]
> ATL1E 0000:04:00.0 p33p1: rx sequence number error (rx=0) (expect=1)
> [ 783.204497] ATL1E 0000:04:00.0 p33p1: NIC Link is Up <100 Mbps Full Duplex>
> [ 783.225336] ATL1E 0000:04:00.0 p33p1: rx sequence number error (rx=0)
> (expect=1) [ 783.236636] ATL1E 0000:04:00.0 p33p1: NIC Link is Up <100 Mbps
> Full Duplex> [ 783.462652] ATL1E 0000:04:00.0 p33p1: rx sequence number
> error (rx=0) (expect=1) [ 783.472530] ATL1E 0000:04:00.0 p33p1: NIC Link is
> Up <100 Mbps Full Duplex> [ 784.038976] ATL1E 0000:04:00.0 p33p1: rx
> sequence number error (rx=0) (expect=1) [ 784.047354] ATL1E 0000:04:00.0
> p33p1: NIC Link is Up <100 Mbps Full Duplex> ...
^ permalink raw reply
* Re: [RFC][PATCH] iproute: Faster ip link add, set and delete
From: Eric W. Biederman @ 2013-03-28 3:44 UTC (permalink / raw)
To: Serge Hallyn; +Cc: Stephen Hemminger, Benoit Lourdelet, netdev@vger.kernel.org
In-Reply-To: <20130328032046.GA32083@sergelap>
Serge Hallyn <serge.hallyn@ubuntu.com> writes:
> Quoting Eric W. Biederman (ebiederm@xmission.com):
>> Stephen Hemminger <stephen@networkplumber.org> writes:
>>
>> > If you need to do lots of operations the --batch mode will be significantly faster.
>> > One command start and one link map.
>>
>> The problem in this case as I understand it is lots of independent
>> operations. Now maybe lxc should not shell out to ip and perform the
>> work itself.
>
> fwiw lxc uses netlink to create new veths, and picks random names with
> mktemp() ahead of time.
I am puzzled where does the slownes in iproute2 come into play?
Eric
^ permalink raw reply
* RE: Atheros Communications Inc. AR8121/AR8113/AR8114 Gigabit or Fast Ethernet (rev b0) 1.0.0.7 md5/sha1 corrupted using NFS and samba (updated) Version 2
From: Huang, Xiong @ 2013-03-28 3:39 UTC (permalink / raw)
To: Hannes Frederic Sowa; +Cc: Sven Hartge, netdev@vger.kernel.org
In-Reply-To: <20130328032934.GD2176@order.stressinduktion.org>
Dump every packet length & read_offset value, compare them.
> -----Original Message-----
> From: Hannes Frederic Sowa [mailto:hannes@stressinduktion.org]
> Sent: Thursday, March 28, 2013 11:30 AM
> To: Huang, Xiong
> Cc: Sven Hartge; netdev@vger.kernel.org
> Subject: Re: Atheros Communications Inc. AR8121/AR8113/AR8114 Gigabit or
> Fast Ethernet (rev b0) 1.0.0.7 md5/sha1 corrupted using NFS and samba
> (updated) Version 2
>
> On Thu, Mar 28, 2013 at 03:25:29AM +0000, Huang, Xiong wrote:
> > Please don't revise following code:
> >
> > rx_page->read_offset +=
> > (((u32)((prrs->word1 >>
> RRS_PKT_SIZE_SHIFT) &
> > RRS_PKT_SIZE_MASK) +
> > sizeof(struct atl1e_recv_ret_status) + 31) &
> > 0xFFFFFFE0);
> >
> > Here 32bytes alignment is no matter with Page alignment.
>
> If I revert this change I get sequence errors:
>
> [ 781.449864] ATL1E 0000:04:00.0: irq 45 for MSI/MSI-X [ 781.454634] IPv6:
> ADDRCONF(NETDEV_UP): p33p1: link is not ready [ 782.893744] ATL1E
> 0000:04:00.0 p33p1: NIC Link is Up <100 Mbps Full Duplex> [ 782.893797] IPv6:
> ADDRCONF(NETDEV_CHANGE): p33p1: link becomes ready [ 783.194443]
> ATL1E 0000:04:00.0 p33p1: rx sequence number error (rx=0) (expect=1)
> [ 783.204497] ATL1E 0000:04:00.0 p33p1: NIC Link is Up <100 Mbps Full Duplex>
> [ 783.225336] ATL1E 0000:04:00.0 p33p1: rx sequence number error (rx=0)
> (expect=1) [ 783.236636] ATL1E 0000:04:00.0 p33p1: NIC Link is Up <100 Mbps
> Full Duplex> [ 783.462652] ATL1E 0000:04:00.0 p33p1: rx sequence number
> error (rx=0) (expect=1) [ 783.472530] ATL1E 0000:04:00.0 p33p1: NIC Link is
> Up <100 Mbps Full Duplex> [ 784.038976] ATL1E 0000:04:00.0 p33p1: rx
> sequence number error (rx=0) (expect=1) [ 784.047354] ATL1E 0000:04:00.0
> p33p1: NIC Link is Up <100 Mbps Full Duplex> ...
^ permalink raw reply
* Re: Atheros Communications Inc. AR8121/AR8113/AR8114 Gigabit or Fast Ethernet (rev b0) 1.0.0.7 md5/sha1 corrupted using NFS and samba (updated) Version 2
From: Hannes Frederic Sowa @ 2013-03-28 3:29 UTC (permalink / raw)
To: Huang, Xiong; +Cc: Sven Hartge, netdev@vger.kernel.org
In-Reply-To: <157393863283F442885425D2C45428564F201026@nasanexd02f.na.qualcomm.com>
On Thu, Mar 28, 2013 at 03:25:29AM +0000, Huang, Xiong wrote:
> Please don't revise following code:
>
> rx_page->read_offset +=
> (((u32)((prrs->word1 >> RRS_PKT_SIZE_SHIFT) &
> RRS_PKT_SIZE_MASK) +
> sizeof(struct atl1e_recv_ret_status) + 31) &
> 0xFFFFFFE0);
>
> Here 32bytes alignment is no matter with Page alignment.
If I revert this change I get sequence errors:
[ 781.449864] ATL1E 0000:04:00.0: irq 45 for MSI/MSI-X
[ 781.454634] IPv6: ADDRCONF(NETDEV_UP): p33p1: link is not ready
[ 782.893744] ATL1E 0000:04:00.0 p33p1: NIC Link is Up <100 Mbps Full Duplex>
[ 782.893797] IPv6: ADDRCONF(NETDEV_CHANGE): p33p1: link becomes ready
[ 783.194443] ATL1E 0000:04:00.0 p33p1: rx sequence number error (rx=0) (expect=1)
[ 783.204497] ATL1E 0000:04:00.0 p33p1: NIC Link is Up <100 Mbps Full Duplex>
[ 783.225336] ATL1E 0000:04:00.0 p33p1: rx sequence number error (rx=0) (expect=1)
[ 783.236636] ATL1E 0000:04:00.0 p33p1: NIC Link is Up <100 Mbps Full Duplex>
[ 783.462652] ATL1E 0000:04:00.0 p33p1: rx sequence number error (rx=0) (expect=1)
[ 783.472530] ATL1E 0000:04:00.0 p33p1: NIC Link is Up <100 Mbps Full Duplex>
[ 784.038976] ATL1E 0000:04:00.0 p33p1: rx sequence number error (rx=0) (expect=1)
[ 784.047354] ATL1E 0000:04:00.0 p33p1: NIC Link is Up <100 Mbps Full Duplex>
...
^ permalink raw reply
* Re: [PATCH net-next] bnx2x: fix compilation without CONFIG_BNX2X_SRIOV
From: David Miller @ 2013-03-28 3:26 UTC (permalink / raw)
To: dmitry; +Cc: netdev
In-Reply-To: <1364410570-18129-1-git-send-email-dmitry@broadcom.com>
From: "Dmitry Kravkov" <dmitry@broadcom.com>
Date: Wed, 27 Mar 2013 20:56:10 +0200
> Move mutex initialization by allocation of the mailbox it protects.
>
> introduced in commit 1d6f3cd89 'bnx2x: Prevent VF race'
>
> Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
> Reported-by: kbuild test robot <fengguang.wu@intel.com>
Applied, thanks.
^ permalink raw reply
* RE: Atheros Communications Inc. AR8121/AR8113/AR8114 Gigabit or Fast Ethernet (rev b0) 1.0.0.7 md5/sha1 corrupted using NFS and samba (updated) Version 2
From: Huang, Xiong @ 2013-03-28 3:25 UTC (permalink / raw)
To: Hannes Frederic Sowa; +Cc: Sven Hartge, netdev@vger.kernel.org
In-Reply-To: <20130328031932.GC2176@order.stressinduktion.org>
Please don't revise following code:
rx_page->read_offset +=
(((u32)((prrs->word1 >> RRS_PKT_SIZE_SHIFT) &
RRS_PKT_SIZE_MASK) +
sizeof(struct atl1e_recv_ret_status) + 31) &
0xFFFFFFE0);
Here 32bytes alignment is no matter with Page alignment.
Thanks
Xiong
> -----Original Message-----
> From: Hannes Frederic Sowa [mailto:hannes@stressinduktion.org]
> Sent: Thursday, March 28, 2013 11:20 AM
> To: Huang, Xiong
> Cc: Sven Hartge; netdev@vger.kernel.org
> Subject: Re: Atheros Communications Inc. AR8121/AR8113/AR8114 Gigabit or
> Fast Ethernet (rev b0) 1.0.0.7 md5/sha1 corrupted using NFS and samba
> (updated) Version 2
>
> On Thu, Mar 28, 2013 at 01:17:53AM +0000, Huang, Xiong wrote:
> > >
> > > We will try to go with RXQ_CTRL_PBA_ALIGN_256 in REG_RXQ_CTRL next.
> > > Just have to check the ring resources are initialized correctly.
> > >
> > > Thanks,
> >
> >
> > ALIGN_256 require the RXF page 256 byte alignment, you should also revise
> the memory allocation function.
>
> Could you have a look at the following diff? It does not work either. Perhaps
> something is wrong in the calculations (but there are no seq number
> mismatches).
>
> diff --git a/drivers/net/ethernet/atheros/atl1e/atl1e_main.c
> b/drivers/net/ethernet/atheros/atl1e/atl1e_main.c
> index e1f1b2a..5264810 100644
> --- a/drivers/net/ethernet/atheros/atl1e/atl1e_main.c
> +++ b/drivers/net/ethernet/atheros/atl1e/atl1e_main.c
> @@ -697,7 +697,7 @@ static void atl1e_cal_ring_size(struct atl1e_adapter
> *adapter, u32 *ring_size)
> sizeof(struct atl1e_tpd_desc) + 7
> /* tx ring, qword align */
> + adapter->rx_ring.real_page_size *
> AT_PAGE_NUM_PER_QUEUE *
> - adapter->num_rx_queues + 31
> + adapter->num_rx_queues + 255
> /* rx ring, 32 bytes align */
> + (1 + AT_PAGE_NUM_PER_QUEUE * adapter-
> >num_rx_queues) *
> sizeof(u32) + 3));
> @@ -714,7 +714,7 @@ static void atl1e_init_ring_resources(struct
> atl1e_adapter *adapter)
> + adapter->hw.max_frame_size
> + ETH_HLEN + VLAN_HLEN
> + ETH_FCS_LEN;
> - rx_ring->real_page_size = roundup(rx_ring->real_page_size, 32);
> + rx_ring->real_page_size = roundup(rx_ring->real_page_size, 256);
> atl1e_cal_ring_size(adapter, &adapter->ring_size);
>
> adapter->ring_vir_addr = NULL;
> @@ -825,7 +825,7 @@ static int atl1e_setup_ring_resources(struct
> atl1e_adapter *adapter)
>
> /* Init RXF-Pages */
> offset += (sizeof(struct atl1e_tpd_desc) * tx_ring->count);
> - offset = roundup(offset, 32);
> + offset = roundup(offset, 256);
>
> for (i = 0; i < adapter->num_rx_queues; i++) {
> for (j = 0; j < AT_PAGE_NUM_PER_QUEUE; j++) { @@ -1003,7
> +1003,7 @@ static inline void atl1e_configure_rx(struct atl1e_adapter
> *adapter)
> rxq_ctrl_data |=
> (RXQ_CTRL_HASH_ENABLE |
> RXQ_CTRL_RSS_MODE_MQUESINT);
>
> - rxq_ctrl_data |= RXQ_CTRL_IPV6_XSUM_VERIFY_EN |
> RXQ_CTRL_PBA_ALIGN_32 |
> + rxq_ctrl_data |= RXQ_CTRL_IPV6_XSUM_VERIFY_EN |
> RXQ_CTRL_PBA_ALIGN_256
> +|
> RXQ_CTRL_CUT_THRU_EN | RXQ_CTRL_EN;
>
> AT_WRITE_REG(hw, REG_RXQ_CTRL, rxq_ctrl_data); @@ -1444,8
> +1444,8 @@ skip_pkt:
> rx_page->read_offset +=
> (((u32)((prrs->word1 >>
> RRS_PKT_SIZE_SHIFT) &
> RRS_PKT_SIZE_MASK) +
> - sizeof(struct atl1e_recv_ret_status) + 31) &
> - 0xFFFFFFE0);
> + sizeof(struct atl1e_recv_ret_status) + 255) &
> + 0xFFFFFF00);
>
> if (rx_page->read_offset >= rx_ring->page_size) {
> /* mark this page clean */
^ permalink raw reply
* Re: [PATCH] tokenring: delete last holdout of CONFIG_TR
From: David Miller @ 2013-03-28 3:25 UTC (permalink / raw)
To: pebolle; +Cc: paul.gortmaker, netdev, linux-kernel
In-Reply-To: <1364417548.1345.38.camel@x61.thuisdomein>
From: Paul Bolle <pebolle@tiscali.nl>
Date: Wed, 27 Mar 2013 21:52:28 +0100
> Tokenring support was deleted in v3.5. One last holdout of the macro
> CONFIG_TR escaped that fate. Until now.
>
> Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH net-next] net: fix compile error of implicit declaration of skb_probe_transport_header
From: David Miller @ 2013-03-28 3:22 UTC (permalink / raw)
To: jasowang; +Cc: ying.xue, netdev, edumazet
In-Reply-To: <5153B506.40105@redhat.com>
From: Jason Wang <jasowang@redhat.com>
Date: Thu, 28 Mar 2013 11:12:06 +0800
> On 03/28/2013 10:46 AM, Ying Xue wrote:
>> The commit 40893fd(net: switch to use skb_probe_transport_header())
>> involes a new error accidently. When NET_SKBUFF_DATA_USES_OFFSE is
>> not enabled, below compile error happens:
>>
>> CC net/packet/af_packet.o
>> net/packet/af_packet.c: In function ‘packet_sendmsg_spkt’:
>> net/packet/af_packet.c:1516:2: error: implicit declaration of function ‘skb_probe_transport_header’ [-Werror=implicit-function-declaration]
>> cc1: some warnings being treated as errors
>> make[2]: *** [net/packet/af_packet.o] Error 1
>> make[1]: *** [net/packet] Error 2
>> make: *** [net] Error 2
>>
>> As it seems skb_probe_transport_header() is not related to
>> NET_SKBUFF_DATA_USES_OFFSE, we should move the definition of
>> skb_probe_transport_header() out of scope of
>> NET_SKBUFF_DATA_USES_OFFSE macro.
>>
>> Cc: Jason Wang <jasowang@redhat.com>
>> Cc: Eric Dumazet <edumazet@google.com>
>> Signed-off-by: Ying Xue <ying.xue@windriver.com>
>> ---
>> include/linux/skbuff.h | 26 +++++++++++++-------------
>> 1 file changed, 13 insertions(+), 13 deletions(-)
>
> Oops.
>
> Acked-by: Jason Wang <jasowang@redhat.com>
Applied, thanks.
^ permalink raw reply
* Re: [RFC][PATCH] iproute: Faster ip link add, set and delete
From: Serge Hallyn @ 2013-03-28 3:20 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Stephen Hemminger, Benoit Lourdelet, netdev@vger.kernel.org
In-Reply-To: <87620cpd0y.fsf@xmission.com>
Quoting Eric W. Biederman (ebiederm@xmission.com):
> Stephen Hemminger <stephen@networkplumber.org> writes:
>
> > If you need to do lots of operations the --batch mode will be significantly faster.
> > One command start and one link map.
>
> The problem in this case as I understand it is lots of independent
> operations. Now maybe lxc should not shell out to ip and perform the
> work itself.
fwiw lxc uses netlink to create new veths, and picks random names with
mktemp() ahead of time.
-serge
^ permalink raw reply
* Re: Davicom Linux driver
From: David Miller @ 2013-03-28 3:19 UTC (permalink / raw)
To: joseph_chang
Cc: allen_huang, R.E.Wolff, corbet, bonbons, wfp5p, matthew, gregkh,
jiri, netdev, linux-kernel, michael_chen, andrew_chen,
spenser_tsai, willie_niou, charles_tsai
In-Reply-To: <201303280225.r2S2PuG2009800@mail.davicom.com.tw>
From: "Joseph Chang" <joseph_chang@davicom.com.tw>
Date: Thu, 28 Mar 2013 10:25:58 +0800
> Dear Miller,
>
> This is Joseph CHANG.
> I had sent you the patches used my gmail earlier than Allen did.
> My gmail account is josright123@gmail.com
> The patches's subjects were:
> [PATCH 1/2] ethernet: dm9000 driver: davicom: upgrade driver: 3rd trial
> [PATCH 2/2] ethernet: dm9000 driver: davicom: upgrade driver: 3rd trial
> patch2
You were given feedback and requested to make changes to those
patches.
^ permalink raw reply
* Re: Atheros Communications Inc. AR8121/AR8113/AR8114 Gigabit or Fast Ethernet (rev b0) 1.0.0.7 md5/sha1 corrupted using NFS and samba (updated) Version 2
From: Hannes Frederic Sowa @ 2013-03-28 3:19 UTC (permalink / raw)
To: Huang, Xiong; +Cc: Sven Hartge, netdev@vger.kernel.org
In-Reply-To: <157393863283F442885425D2C45428564F200FFD@nasanexd02f.na.qualcomm.com>
On Thu, Mar 28, 2013 at 01:17:53AM +0000, Huang, Xiong wrote:
> >
> > We will try to go with RXQ_CTRL_PBA_ALIGN_256 in REG_RXQ_CTRL next.
> > Just have to check the ring resources are initialized correctly.
> >
> > Thanks,
>
>
> ALIGN_256 require the RXF page 256 byte alignment, you should also revise the memory allocation function.
Could you have a look at the following diff? It does not work either. Perhaps
something is wrong in the calculations (but there are no seq number mismatches).
diff --git a/drivers/net/ethernet/atheros/atl1e/atl1e_main.c b/drivers/net/ethernet/atheros/atl1e/atl1e_main.c
index e1f1b2a..5264810 100644
--- a/drivers/net/ethernet/atheros/atl1e/atl1e_main.c
+++ b/drivers/net/ethernet/atheros/atl1e/atl1e_main.c
@@ -697,7 +697,7 @@ static void atl1e_cal_ring_size(struct atl1e_adapter *adapter, u32 *ring_size)
sizeof(struct atl1e_tpd_desc) + 7
/* tx ring, qword align */
+ adapter->rx_ring.real_page_size * AT_PAGE_NUM_PER_QUEUE *
- adapter->num_rx_queues + 31
+ adapter->num_rx_queues + 255
/* rx ring, 32 bytes align */
+ (1 + AT_PAGE_NUM_PER_QUEUE * adapter->num_rx_queues) *
sizeof(u32) + 3));
@@ -714,7 +714,7 @@ static void atl1e_init_ring_resources(struct atl1e_adapter *adapter)
+ adapter->hw.max_frame_size
+ ETH_HLEN + VLAN_HLEN
+ ETH_FCS_LEN;
- rx_ring->real_page_size = roundup(rx_ring->real_page_size, 32);
+ rx_ring->real_page_size = roundup(rx_ring->real_page_size, 256);
atl1e_cal_ring_size(adapter, &adapter->ring_size);
adapter->ring_vir_addr = NULL;
@@ -825,7 +825,7 @@ static int atl1e_setup_ring_resources(struct atl1e_adapter *adapter)
/* Init RXF-Pages */
offset += (sizeof(struct atl1e_tpd_desc) * tx_ring->count);
- offset = roundup(offset, 32);
+ offset = roundup(offset, 256);
for (i = 0; i < adapter->num_rx_queues; i++) {
for (j = 0; j < AT_PAGE_NUM_PER_QUEUE; j++) {
@@ -1003,7 +1003,7 @@ static inline void atl1e_configure_rx(struct atl1e_adapter *adapter)
rxq_ctrl_data |=
(RXQ_CTRL_HASH_ENABLE | RXQ_CTRL_RSS_MODE_MQUESINT);
- rxq_ctrl_data |= RXQ_CTRL_IPV6_XSUM_VERIFY_EN | RXQ_CTRL_PBA_ALIGN_32 |
+ rxq_ctrl_data |= RXQ_CTRL_IPV6_XSUM_VERIFY_EN | RXQ_CTRL_PBA_ALIGN_256 |
RXQ_CTRL_CUT_THRU_EN | RXQ_CTRL_EN;
AT_WRITE_REG(hw, REG_RXQ_CTRL, rxq_ctrl_data);
@@ -1444,8 +1444,8 @@ skip_pkt:
rx_page->read_offset +=
(((u32)((prrs->word1 >> RRS_PKT_SIZE_SHIFT) &
RRS_PKT_SIZE_MASK) +
- sizeof(struct atl1e_recv_ret_status) + 31) &
- 0xFFFFFFE0);
+ sizeof(struct atl1e_recv_ret_status) + 255) &
+ 0xFFFFFF00);
if (rx_page->read_offset >= rx_ring->page_size) {
/* mark this page clean */
^ permalink raw reply related
* Re: [PATCH net-next] net: fix compile error of implicit declaration of skb_probe_transport_header
From: Jason Wang @ 2013-03-28 3:12 UTC (permalink / raw)
To: Ying Xue; +Cc: netdev, davem, edumazet
In-Reply-To: <1364438766-14042-1-git-send-email-ying.xue@windriver.com>
On 03/28/2013 10:46 AM, Ying Xue wrote:
> The commit 40893fd(net: switch to use skb_probe_transport_header())
> involes a new error accidently. When NET_SKBUFF_DATA_USES_OFFSE is
> not enabled, below compile error happens:
>
> CC net/packet/af_packet.o
> net/packet/af_packet.c: In function ‘packet_sendmsg_spkt’:
> net/packet/af_packet.c:1516:2: error: implicit declaration of function ‘skb_probe_transport_header’ [-Werror=implicit-function-declaration]
> cc1: some warnings being treated as errors
> make[2]: *** [net/packet/af_packet.o] Error 1
> make[1]: *** [net/packet] Error 2
> make: *** [net] Error 2
>
> As it seems skb_probe_transport_header() is not related to
> NET_SKBUFF_DATA_USES_OFFSE, we should move the definition of
> skb_probe_transport_header() out of scope of
> NET_SKBUFF_DATA_USES_OFFSE macro.
>
> Cc: Jason Wang <jasowang@redhat.com>
> Cc: Eric Dumazet <edumazet@google.com>
> Signed-off-by: Ying Xue <ying.xue@windriver.com>
> ---
> include/linux/skbuff.h | 26 +++++++++++++-------------
> 1 file changed, 13 insertions(+), 13 deletions(-)
Oops.
Acked-by: Jason Wang <jasowang@redhat.com>
Thanks
>
> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> index fa88b96..878e0ee 100644
> --- a/include/linux/skbuff.h
> +++ b/include/linux/skbuff.h
> @@ -1560,19 +1560,6 @@ static inline void skb_set_transport_header(struct sk_buff *skb,
> skb->transport_header += offset;
> }
>
> -static inline void skb_probe_transport_header(struct sk_buff *skb,
> - const int offset_hint)
> -{
> - struct flow_keys keys;
> -
> - if (skb_transport_header_was_set(skb))
> - return;
> - else if (skb_flow_dissect(skb, &keys))
> - skb_set_transport_header(skb, keys.thoff);
> - else
> - skb_set_transport_header(skb, offset_hint);
> -}
> -
> static inline unsigned char *skb_network_header(const struct sk_buff *skb)
> {
> return skb->head + skb->network_header;
> @@ -1716,6 +1703,19 @@ static inline void skb_set_mac_header(struct sk_buff *skb, const int offset)
> }
> #endif /* NET_SKBUFF_DATA_USES_OFFSET */
>
> +static inline void skb_probe_transport_header(struct sk_buff *skb,
> + const int offset_hint)
> +{
> + struct flow_keys keys;
> +
> + if (skb_transport_header_was_set(skb))
> + return;
> + else if (skb_flow_dissect(skb, &keys))
> + skb_set_transport_header(skb, keys.thoff);
> + else
> + skb_set_transport_header(skb, offset_hint);
> +}
> +
> static inline void skb_mac_header_rebuild(struct sk_buff *skb)
> {
> if (skb_mac_header_was_set(skb)) {
^ permalink raw reply
* Re: Davicom Linux driver
From: Greg KH @ 2013-03-28 3:11 UTC (permalink / raw)
To: Joseph Chang
Cc: 'David Miller', allen_huang, R.E.Wolff, corbet, bonbons,
wfp5p, matthew, jiri, netdev, linux-kernel, michael_chen,
andrew_chen, spenser_tsai, willie_niou, charles_tsai
In-Reply-To: <201303280225.r2S2PuG2009800@mail.davicom.com.tw>
On Thu, Mar 28, 2013 at 10:25:58AM +0800, Joseph Chang wrote:
> Dear Miller,
>
> This is Joseph CHANG.
> I had sent you the patches used my gmail earlier than Allen did.
> My gmail account is josright123@gmail.com
> The patches's subjects were:
> [PATCH 1/2] ethernet: dm9000 driver: davicom: upgrade driver: 3rd trial
> [PATCH 2/2] ethernet: dm9000 driver: davicom: upgrade driver: 3rd trial
> patch2
>
> Would you help confirm it again, Thanks.
That is not necessary, you can always "confirm" that a patch made it to
a mailing list, by looking at the mailing list.
^ permalink raw reply
* RE: [PATCH 1/2] ethernet: dm9000 driver: davicom: upgrade driver: 3rd trial
From: Joseph Chang @ 2013-03-28 2:50 UTC (permalink / raw)
To: 'Denis Kirjanov', 'Joseph CHANG'
Cc: 'David S. Miller', 'Bill Pemberton',
'Matthew Leach', 'Greg Kroah-Hartman',
'Joseph CHANG', 'Jiri Pirko', netdev,
linux-kernel
In-Reply-To: <CAOJe8K24A6jSLsfLn6yc0cKvLPNU8+8wLs+ip0AsVUYS_HVBGg@mail.gmail.com>
Dear Denis,
Yes, I can tell more detail, Should I re-do the patch and submit again?
I will revise the log as below: (Please help comment again, thanks.)
- Fixing bug for DM9000B(DSP) which is a DSP revision! 3rd trial.
-
- The chip of DM9000B(DSP) is different in internal PHY compare to
DM9000A(analog) and
- DM9000E(analog).
- This patch add a PHY RESET and a PHY INIT PARAMETER settings in
- "dm9000_init_dm9000()", and
- This patch change set DM9000_NCR by reset-bit to be set DM9000_NCR by
reset-bit
- conjunction with mac_loopback-bit in "dm9000_probe()".
- The driver could get wrong DM9000B FIFO(internal) state during driver
initialize, But not each
- target board case, error rate is around 2%.
- We patch the driver this way to solve this initial fatal issue.
Best Regards,
Joseph CHANG
System Application Engineering Division
Davicom Semiconductor, Inc.
No. 6 Li-Hsin Rd. VI, Science-Based Park,
Hsin-Chu, Taiwan.
Tel: 886-3-5798797 Ex 8534
Fax: 886-3-5646929
Web: http://www.davicom.com.tw
-----Original Message-----
From: Denis Kirjanov [mailto:kda@linux-powerpc.org]
Sent: Wednesday, March 27, 2013 9:14 PM
To: Joseph CHANG
Cc: David S. Miller; Bill Pemberton; Matthew Leach; Greg Kroah-Hartman; Joseph
CHANG; Jiri Pirko; netdev@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] ethernet: dm9000 driver: davicom: upgrade driver: 3rd
trial
It's not clear from your log what was wrong with the driver. Could you
please update the log message.
On 3/27/13, Joseph CHANG <josright123@gmail.com> wrote:
> Fixing bug for DM9000B(DSP) which is a DSP revision! 3rd trial.
>
> Tested to Davicom DM9000 series include DM9000E(analog),
> DM9000A(analog), DM9000B(DSP), and DM9000C(DSP) in X86 and
> ARM Embedded Linux these years.
>
> Signed-off-by: Joseph CHANG <josright123@gmail.com>
> ---
> drivers/net/ethernet/davicom/dm9000.c | 219
> +++++++++++++++++----------------
> drivers/net/ethernet/davicom/dm9000.h | 11 ++-
> 2 files changed, 124 insertions(+), 106 deletions(-)
>
> diff --git a/drivers/net/ethernet/davicom/dm9000.c
> b/drivers/net/ethernet/davicom/dm9000.c
> index 8cdf025..9dd4bd6 100644
> --- a/drivers/net/ethernet/davicom/dm9000.c
> +++ b/drivers/net/ethernet/davicom/dm9000.c
> @@ -47,7 +47,7 @@
> #define DM9000_PHY 0x40 /* PHY address 0x01 */
>
> #define CARDNAME "dm9000"
> -#define DRV_VERSION "1.31"
> +#define DRV_VERSION "1.39"
>
> /*
> * Transmit timeout, default 5 seconds.
> @@ -257,6 +257,109 @@ static void dm9000_dumpblk_32bit(void __iomem *reg,
> int count)
> tmp = readl(reg);
> }
>
> +/*
> + * Sleep, either by using msleep() or if we are suspending, then
> + * use mdelay() to sleep.
> + */
> +static void dm9000_msleep(board_info_t *db, unsigned int ms)
> +{
> + if (db->in_suspend)
> + mdelay(ms);
> + else
> + msleep(ms);
> +}
> +
> +/*
> + * Read a word from phyxcer
> + */
> +static int
> +dm9000_phy_read(struct net_device *dev, int phy_reg_unused, int reg)
> +{
> + board_info_t *db = netdev_priv(dev);
> + unsigned long flags;
> + unsigned int reg_save;
> + int ret;
> +
> + mutex_lock(&db->addr_lock);
> +
> + spin_lock_irqsave(&db->lock,flags);
> +
> + /* Save previous register address */
> + reg_save = readb(db->io_addr);
> +
> + /* Fill the phyxcer register into REG_0C */
> + iow(db, DM9000_EPAR, DM9000_PHY | reg);
> +
> + iow(db, DM9000_EPCR, EPCR_ERPRR | EPCR_EPOS); /* Issue phyxcer read
> command */
> +
> + writeb(reg_save, db->io_addr);
> + spin_unlock_irqrestore(&db->lock,flags);
> +
> + dm9000_msleep(db, 1); /* Wait read complete */
> +
> + spin_lock_irqsave(&db->lock,flags);
> + reg_save = readb(db->io_addr);
> +
> + iow(db, DM9000_EPCR, 0x0); /* Clear phyxcer read command */
> +
> + /* The read data keeps on REG_0D & REG_0E */
> + ret = (ior(db, DM9000_EPDRH) << 8) | ior(db, DM9000_EPDRL);
> +
> + /* restore the previous address */
> + writeb(reg_save, db->io_addr);
> + spin_unlock_irqrestore(&db->lock,flags);
> +
> + mutex_unlock(&db->addr_lock);
> +
> + dm9000_dbg(db, 5, "phy_read[%02x] -> %04x\n", reg, ret);
> + return ret;
> +}
> +
> +/*
> + * Write a word to phyxcer
> + */
> +static void
> +dm9000_phy_write(struct net_device *dev,
> + int phyaddr_unused, int reg, int value)
> +{
> + board_info_t *db = netdev_priv(dev);
> + unsigned long flags;
> + unsigned long reg_save;
> +
> + dm9000_dbg(db, 5, "phy_write[%02x] = %04x\n", reg, value);
> + mutex_lock(&db->addr_lock);
> +
> + spin_lock_irqsave(&db->lock,flags);
> +
> + /* Save previous register address */
> + reg_save = readb(db->io_addr);
> +
> + /* Fill the phyxcer register into REG_0C */
> + iow(db, DM9000_EPAR, DM9000_PHY | reg);
> +
> + /* Fill the written data into REG_0D & REG_0E */
> + iow(db, DM9000_EPDRL, value);
> + iow(db, DM9000_EPDRH, value >> 8);
> +
> + iow(db, DM9000_EPCR, EPCR_EPOS | EPCR_ERPRW); /* Issue phyxcer write
> command */
> +
> + writeb(reg_save, db->io_addr);
> + spin_unlock_irqrestore(&db->lock, flags);
> +
> + dm9000_msleep(db, 1); /* Wait write complete */
> +
> + spin_lock_irqsave(&db->lock,flags);
> + reg_save = readb(db->io_addr);
> +
> + iow(db, DM9000_EPCR, 0x0); /* Clear phyxcer write command */
> +
> + /* restore the previous address */
> + writeb(reg_save, db->io_addr);
> +
> + spin_unlock_irqrestore(&db->lock, flags);
> + mutex_unlock(&db->addr_lock);
> +}
> +
> /* dm9000_set_io
> *
> * select the specified set of io routines to use with the
> @@ -795,6 +898,8 @@ dm9000_init_dm9000(struct net_device *dev)
>
> iow(db, DM9000_GPCR, GPCR_GEP_CNTL); /* Let GPIO0 output */
>
> + dm9000_phy_write(dev, 0, MII_BMCR, BMCR_RESET); /* PHY RESET */
> +
> ncr = (db->flags & DM9000_PLATF_EXT_PHY) ? NCR_EXT_PHY : 0;
>
> /* if wol is needed, then always set NCR_WAKEEN otherwise we end
> @@ -830,6 +935,8 @@ dm9000_init_dm9000(struct net_device *dev)
> db->tx_pkt_cnt = 0;
> db->queue_pkt_len = 0;
> dev->trans_start = jiffies;
> +
> + dm9000_phy_write(dev, 0, MII_DM_DSPCR, DSPCR_INIT_PARAM); /* Init */
> }
>
> /* Our watchdog timed out. Called by the networking layer */
> @@ -1201,109 +1308,6 @@ dm9000_open(struct net_device *dev)
> return 0;
> }
>
> -/*
> - * Sleep, either by using msleep() or if we are suspending, then
> - * use mdelay() to sleep.
> - */
> -static void dm9000_msleep(board_info_t *db, unsigned int ms)
> -{
> - if (db->in_suspend)
> - mdelay(ms);
> - else
> - msleep(ms);
> -}
> -
> -/*
> - * Read a word from phyxcer
> - */
> -static int
> -dm9000_phy_read(struct net_device *dev, int phy_reg_unused, int reg)
> -{
> - board_info_t *db = netdev_priv(dev);
> - unsigned long flags;
> - unsigned int reg_save;
> - int ret;
> -
> - mutex_lock(&db->addr_lock);
> -
> - spin_lock_irqsave(&db->lock,flags);
> -
> - /* Save previous register address */
> - reg_save = readb(db->io_addr);
> -
> - /* Fill the phyxcer register into REG_0C */
> - iow(db, DM9000_EPAR, DM9000_PHY | reg);
> -
> - iow(db, DM9000_EPCR, EPCR_ERPRR | EPCR_EPOS); /* Issue phyxcer read
> command */
> -
> - writeb(reg_save, db->io_addr);
> - spin_unlock_irqrestore(&db->lock,flags);
> -
> - dm9000_msleep(db, 1); /* Wait read complete */
> -
> - spin_lock_irqsave(&db->lock,flags);
> - reg_save = readb(db->io_addr);
> -
> - iow(db, DM9000_EPCR, 0x0); /* Clear phyxcer read command */
> -
> - /* The read data keeps on REG_0D & REG_0E */
> - ret = (ior(db, DM9000_EPDRH) << 8) | ior(db, DM9000_EPDRL);
> -
> - /* restore the previous address */
> - writeb(reg_save, db->io_addr);
> - spin_unlock_irqrestore(&db->lock,flags);
> -
> - mutex_unlock(&db->addr_lock);
> -
> - dm9000_dbg(db, 5, "phy_read[%02x] -> %04x\n", reg, ret);
> - return ret;
> -}
> -
> -/*
> - * Write a word to phyxcer
> - */
> -static void
> -dm9000_phy_write(struct net_device *dev,
> - int phyaddr_unused, int reg, int value)
> -{
> - board_info_t *db = netdev_priv(dev);
> - unsigned long flags;
> - unsigned long reg_save;
> -
> - dm9000_dbg(db, 5, "phy_write[%02x] = %04x\n", reg, value);
> - mutex_lock(&db->addr_lock);
> -
> - spin_lock_irqsave(&db->lock,flags);
> -
> - /* Save previous register address */
> - reg_save = readb(db->io_addr);
> -
> - /* Fill the phyxcer register into REG_0C */
> - iow(db, DM9000_EPAR, DM9000_PHY | reg);
> -
> - /* Fill the written data into REG_0D & REG_0E */
> - iow(db, DM9000_EPDRL, value);
> - iow(db, DM9000_EPDRH, value >> 8);
> -
> - iow(db, DM9000_EPCR, EPCR_EPOS | EPCR_ERPRW); /* Issue phyxcer write
> command */
> -
> - writeb(reg_save, db->io_addr);
> - spin_unlock_irqrestore(&db->lock, flags);
> -
> - dm9000_msleep(db, 1); /* Wait write complete */
> -
> - spin_lock_irqsave(&db->lock,flags);
> - reg_save = readb(db->io_addr);
> -
> - iow(db, DM9000_EPCR, 0x0); /* Clear phyxcer write command */
> -
> - /* restore the previous address */
> - writeb(reg_save, db->io_addr);
> -
> - spin_unlock_irqrestore(&db->lock, flags);
> - mutex_unlock(&db->addr_lock);
> -}
> -
> static void
> dm9000_shutdown(struct net_device *dev)
> {
> @@ -1502,7 +1506,12 @@ dm9000_probe(struct platform_device *pdev)
> db->flags |= DM9000_PLATF_SIMPLE_PHY;
> #endif
>
> - dm9000_reset(db);
> + /* Fixing bug on dm9000_probe, takeover dm9000_reset(db),
> + * Need 'NCR_MAC_LBK' bit to indeed stable our DM9000 fifo
> + * while probe stage.
> + */
> +
> + iow(db, DM9000_NCR, NCR_MAC_LBK | NCR_RST);
>
> /* try multiple times, DM9000 sometimes gets the read wrong */
> for (i = 0; i < 8; i++) {
> diff --git a/drivers/net/ethernet/davicom/dm9000.h
> b/drivers/net/ethernet/davicom/dm9000.h
> index 55688bd..9ce058a 100644
> --- a/drivers/net/ethernet/davicom/dm9000.h
> +++ b/drivers/net/ethernet/davicom/dm9000.h
> @@ -69,7 +69,9 @@
> #define NCR_WAKEEN (1<<6)
> #define NCR_FCOL (1<<4)
> #define NCR_FDX (1<<3)
> -#define NCR_LBK (3<<1)
> +
> +#define NCR_RESERVED (3<<1)
> +#define NCR_MAC_LBK (1<<1)
> #define NCR_RST (1<<0)
>
> #define NSR_SPEED (1<<7)
> @@ -167,5 +169,12 @@
> #define ISR_LNKCHNG (1<<5)
> #define ISR_UNDERRUN (1<<4)
>
> +/* Davicom MII registers.
> + */
> +
> +#define MII_DM_DSPCR 0x1b /* DSP Control Register */
> +
> +#define DSPCR_INIT_PARAM 0xE100 /* DSP init parameter */
> +
> #endif /* _DM9000X_H_ */
>
> --
> 1.7.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
^ permalink raw reply
* Re: [PATCH 1/2] man/send(2): add EPERM to the list of possible errors
From: Fernando Luis Vazquez Cao @ 2013-03-28 2:46 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: Michael Kerrisk, linux-man-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
netfilter-devel-u79uwXL29TY76Z2rM5mHXA, Patrick McHardy,
Hirotaka Sasaki
In-Reply-To: <20130327174207.GA5725@localhost>
On 2013-03-28 02:42, Pablo Neira Ayuso wrote:
> On Tue, Mar 19, 2013 at 03:45:13PM +0900, Fernando Luis Vázquez Cao wrote:
>> Subject: [PATCH 1/2] man/send(2): add EPERM to the list of possible errors
>>
>> System policy (for example netfilter rule) can cause a send* operation
>> to fail with EPERM.
>>
>> Reported-by: Hirotaka Sasaki <sasaki.hirotaka-Zyj7fXuS5i5L9jVzuh4AOg@public.gmane.org>
>> Signed-off-by: Fernando Luis Vazquez Cao <fernando-gVGce1chcLdL9jVzuh4AOg@public.gmane.org>
> Acked-by: Pablo Neira Ayuso <pablo-Cap9r6Oaw4JrovVCs/uTlw@public.gmane.org>
Thank you for the "Acked-by", Pablo.
Michael, could you pick this patch?
- Fernando
--
To unsubscribe from this list: send the line "unsubscribe linux-man" 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] net: fix compile error of implicit declaration of skb_probe_transport_header
From: Ying Xue @ 2013-03-28 2:46 UTC (permalink / raw)
To: netdev; +Cc: davem, jasowang, edumazet
The commit 40893fd(net: switch to use skb_probe_transport_header())
involes a new error accidently. When NET_SKBUFF_DATA_USES_OFFSE is
not enabled, below compile error happens:
CC net/packet/af_packet.o
net/packet/af_packet.c: In function ‘packet_sendmsg_spkt’:
net/packet/af_packet.c:1516:2: error: implicit declaration of function ‘skb_probe_transport_header’ [-Werror=implicit-function-declaration]
cc1: some warnings being treated as errors
make[2]: *** [net/packet/af_packet.o] Error 1
make[1]: *** [net/packet] Error 2
make: *** [net] Error 2
As it seems skb_probe_transport_header() is not related to
NET_SKBUFF_DATA_USES_OFFSE, we should move the definition of
skb_probe_transport_header() out of scope of
NET_SKBUFF_DATA_USES_OFFSE macro.
Cc: Jason Wang <jasowang@redhat.com>
Cc: Eric Dumazet <edumazet@google.com>
Signed-off-by: Ying Xue <ying.xue@windriver.com>
---
include/linux/skbuff.h | 26 +++++++++++++-------------
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index fa88b96..878e0ee 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -1560,19 +1560,6 @@ static inline void skb_set_transport_header(struct sk_buff *skb,
skb->transport_header += offset;
}
-static inline void skb_probe_transport_header(struct sk_buff *skb,
- const int offset_hint)
-{
- struct flow_keys keys;
-
- if (skb_transport_header_was_set(skb))
- return;
- else if (skb_flow_dissect(skb, &keys))
- skb_set_transport_header(skb, keys.thoff);
- else
- skb_set_transport_header(skb, offset_hint);
-}
-
static inline unsigned char *skb_network_header(const struct sk_buff *skb)
{
return skb->head + skb->network_header;
@@ -1716,6 +1703,19 @@ static inline void skb_set_mac_header(struct sk_buff *skb, const int offset)
}
#endif /* NET_SKBUFF_DATA_USES_OFFSET */
+static inline void skb_probe_transport_header(struct sk_buff *skb,
+ const int offset_hint)
+{
+ struct flow_keys keys;
+
+ if (skb_transport_header_was_set(skb))
+ return;
+ else if (skb_flow_dissect(skb, &keys))
+ skb_set_transport_header(skb, keys.thoff);
+ else
+ skb_set_transport_header(skb, offset_hint);
+}
+
static inline void skb_mac_header_rebuild(struct sk_buff *skb)
{
if (skb_mac_header_was_set(skb)) {
--
1.7.9.5
^ permalink raw reply related
* RE: Davicom Linux driver
From: Joseph Chang @ 2013-03-28 2:25 UTC (permalink / raw)
To: 'David Miller', allen_huang
Cc: R.E.Wolff, corbet, bonbons, wfp5p, matthew, gregkh, jiri, netdev,
linux-kernel, michael_chen, andrew_chen, spenser_tsai,
willie_niou, charles_tsai
In-Reply-To: <20130327.221023.858242820429458866.davem@davemloft.net>
Dear Miller,
This is Joseph CHANG.
I had sent you the patches used my gmail earlier than Allen did.
My gmail account is josright123@gmail.com
The patches's subjects were:
[PATCH 1/2] ethernet: dm9000 driver: davicom: upgrade driver: 3rd trial
[PATCH 2/2] ethernet: dm9000 driver: davicom: upgrade driver: 3rd trial
patch2
Would you help confirm it again, Thanks.
Best Regards,
Joseph CHANG
System Application Engineering Division
Davicom Semiconductor, Inc.
No. 6 Li-Hsin Rd. VI, Science-Based Park,
Hsin-Chu, Taiwan.
Tel: 886-3-5798797 Ex 8534
Fax: 886-3-5646929
Web: http://www.davicom.com.tw
-----Original Message-----
From: David Miller [mailto:davem@davemloft.net]
Sent: Thursday, March 28, 2013 10:10 AM
To: allen_huang@davicom.com.tw
Cc: R.E.Wolff@BitWizard.nl; corbet@lwn.net; bonbons@linux-vserver.org;
wfp5p@virginia.edu; matthew@mattleach.net; gregkh@linuxfoundation.org;
jiri@resnulli.us; netdev@vger.kernel.org; linux-kernel@vger.kernel.org;
michael_chen@mail.davicom.com.tw; andrew_chen@davicom.com.tw;
spenser_tsai@davicom.com.tw; willie_niou@mail.davicom.com.tw;
charles_tsai@davicom.com.tw; joseph_chang@mail.davicom.com.tw
Subject: Re: Davicom Linux driver
This is not the correct way to submit a patch for inclusion upstream
You should post each patch in a seperate, numbered, list posting, in
plain ASCII text, and not as an attachment.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
^ permalink raw reply
* Re: [Bug 55861] New: PMTU discovery no longer works in Linux 3.6+ with routers that do not send next hop MTU information
From: David Miller @ 2013-03-28 2:24 UTC (permalink / raw)
To: lw; +Cc: stephen, netdev
In-Reply-To: <5153A3E8.9000004@cn.fujitsu.com>
From: Li Wei <lw@cn.fujitsu.com>
Date: Thu, 28 Mar 2013 09:59:04 +0800
> It seems to be in icmp_unreach():
>
> case ICMP_FRAG_NEEDED:
> if (ipv4_config.no_pmtu_disc) {
> LIMIT_NETDEBUG(KERN_INFO pr_fmt("%pI4: fragmentation needed and DF set\n"),
> &iph->daddr);
> } else {
> info = ntohs(icmph->un.frag.mtu);
> if (!info)
> goto out;
>
> When MTU is zero, we skip the process in icmp_socket_deliver() which propagate
> this error to transport protocols.
No, really, MTU field should not be set to zero. It should be set to
the actual MTU value we should use.
If you remove this check then we'll go down to the ipv4 routing code
and use the minimum ipv4 MTU, you absolutely do not want that.
The old code, that was removed, would try to guess in this case using
a table, the guard for this code path had comment:
/* BSD 4.2 derived systems incorrectly adjust
* tot_len by the IP header length, and report
* a zero MTU in the ICMP message.
*/
So the machines sending these zero MTUs are very broken.
I'm not accomodating such broken systems, sorry.
^ permalink raw reply
* Re: Fw: [Bug 55861] New: PMTU discovery no longer works in Linux 3.6+ with routers that do not send next hop MTU information
From: Li Wei @ 2013-03-28 1:59 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20130327083127.0740d793@nehalam.linuxnetplumber.net>
It seems to be in icmp_unreach():
case ICMP_FRAG_NEEDED:
if (ipv4_config.no_pmtu_disc) {
LIMIT_NETDEBUG(KERN_INFO pr_fmt("%pI4: fragmentation needed and DF set\n"),
&iph->daddr);
} else {
info = ntohs(icmph->un.frag.mtu);
if (!info)
goto out;
When MTU is zero, we skip the process in icmp_socket_deliver() which propagate
this error to transport protocols.
After some investigation it seems in transport protocols' err_handler which
finally called dst->update_pmtu(ip_rt_update_pmtu for IPv4) can deal with this
situation properly.
So I think we can simply kill the check of icmph->un.frag.mtu here.
On 03/27/2013 11:31 PM, Stephen Hemminger wrote:
>
>
> Begin forwarded message:
>
> Date: Wed, 27 Mar 2013 08:25:40 -0700
> From: "bugzilla-daemon@bugzilla.kernel.org" <bugzilla-daemon@bugzilla.kernel.org>
> To: "stephen@networkplumber.org" <stephen@networkplumber.org>
> Subject: [Bug 55861] New: PMTU discovery no longer works in Linux 3.6+ with routers that do not send next hop MTU information
>
>
> https://bugzilla.kernel.org/show_bug.cgi?id=55861
>
> Summary: PMTU discovery no longer works in Linux 3.6+ with
> routers that do not send next hop MTU information
> Product: Networking
> Version: 2.5
> Kernel Version: 3.6 onwards
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: IPV4
> AssignedTo: shemminger@linux-foundation.org
> ReportedBy: _@maxb.eu
> Regression: Yes
>
>
> After upgrading recently, I found that path MTU discovery no longer worked
> correctly for accessing some devices on the other side of an IPsec tunnel.
>
> Bisection revealed the problems started with 3.6 and are still present in
> 3.9-rc4 (latest available at time of reporting).
>
> Some investigation into code changes leads me to the belief that Linux lost
> support for handling ICMP destination unreachable fragmentation needed packets
> for which the next hop MTU field is zero. This is an expected condition when
> dealing with older routers, as RFC792 originally defined ICMP destination
> unreachable fragmentation needed without a next hop MTU field, and it was later
> added in bytes previously allocated as unused.
>
> The particular router in my case generating such packets is a machine running
> OpenBSD 4.6.
>
> A commit that appears to be of particular interest in this bug is
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=46517008e1168dc926cf2c47d529efc07eca85c0
>
^ permalink raw reply
* Re: Davicom Linux driver
From: David Miller @ 2013-03-28 2:10 UTC (permalink / raw)
To: allen_huang
Cc: R.E.Wolff, corbet, bonbons, wfp5p, matthew, gregkh, jiri, netdev,
linux-kernel, michael_chen, andrew_chen, spenser_tsai,
willie_niou, charles_tsai, joseph_chang
In-Reply-To: <C3A1E0E612FB4A879061BBD7DF6536E5@Domaindsi>
This is not the correct way to submit a patch for inclusion upstream
You should post each patch in a seperate, numbered, list posting, in
plain ASCII text, and not as an attachment.
^ permalink raw reply
* RE: [PATCH] libertas: drop maintainership
From: Bing Zhao @ 2013-03-28 2:06 UTC (permalink / raw)
To: Dan Williams, netdev@vger.kernel.org
Cc: linux-wireless@vger.kernel.org, Daniel Drake
In-Reply-To: <1363625321.1597.28.camel@dcbw.foobar.com>
Hi Dan,
> Would be better maintained by somebody who actualy has time for it.
>
> Signed-off-by: Dan Williams <dcbw@redhat.com>
> ---
> Daniel? Bing? :)
I don't have much time for Libertas either. Hope someone else does.
Thanks,
Bing
^ permalink raw reply
* RE: Atheros Communications Inc. AR8121/AR8113/AR8114 Gigabit or Fast Ethernet (rev b0) 1.0.0.7 md5/sha1 corrupted using NFS and samba (updated) Version 2
From: Huang, Xiong @ 2013-03-28 1:17 UTC (permalink / raw)
To: Hannes Frederic Sowa; +Cc: Sven Hartge, netdev@vger.kernel.org
In-Reply-To: <20130328011602.GB2176@order.stressinduktion.org>
>
> We will try to go with RXQ_CTRL_PBA_ALIGN_256 in REG_RXQ_CTRL next.
> Just have to check the ring resources are initialized correctly.
>
> Thanks,
ALIGN_256 require the RXF page 256 byte alignment, you should also revise the memory allocation function.
Thanks
Xiong
^ 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