* [PATCH] pch_gbe: Fix the issue that the receiving data is not normal.
From: Toshiharu Okada @ 2011-02-08 8:24 UTC (permalink / raw)
To: ML netdev, David S. Miller
Cc: LKML, Wang, Qi, Wang, Yong Y, Andrew, Intel OTC, Ewe, Kok Howg,
Tomoya Morinaga
Hi Devid
I resubmit this patch modified.
Please check them.
Best regards
Toshiharu Okada(OKI semiconductor)
---
This PCH_GBE driver had an issue that the receiving data is not normal.
This driver had not removed correctly the padding data
which the DMA include in receiving data.
This patch fixed this issue.
Signed-off-by: Toshiharu Okada <toshiharu-linux@dsn.okisemi.com>
---
drivers/net/pch_gbe/pch_gbe_main.c | 77 +++++++++++++++++++++--------------
1 files changed, 46 insertions(+), 31 deletions(-)
diff --git a/drivers/net/pch_gbe/pch_gbe_main.c b/drivers/net/pch_gbe/pch_gbe_main.c
index 03a1d28..3248313 100644
--- a/drivers/net/pch_gbe/pch_gbe_main.c
+++ b/drivers/net/pch_gbe/pch_gbe_main.c
@@ -29,6 +29,7 @@ const char pch_driver_version[] = DRV_VERSION;
#define PCH_GBE_SHORT_PKT 64
#define DSC_INIT16 0xC000
#define PCH_GBE_DMA_ALIGN 0
+#define PCH_GBE_DMA_PADDING 2
#define PCH_GBE_WATCHDOG_PERIOD (1 * HZ) /* watchdog time */
#define PCH_GBE_COPYBREAK_DEFAULT 256
#define PCH_GBE_PCI_BAR 1
@@ -1373,7 +1374,7 @@ pch_gbe_clean_rx(struct pch_gbe_adapter *adapter,
unsigned int i;
unsigned int cleaned_count = 0;
bool cleaned = false;
- struct sk_buff *skb;
+ struct sk_buff *skb, *new_skb;
u8 dma_status;
u16 gbec_status;
u32 tcp_ip_status;
@@ -1422,55 +1423,69 @@ pch_gbe_clean_rx(struct pch_gbe_adapter *adapter,
pr_err("Receive CRC Error\n");
} else {
/* get receive length */
- /* length convert[-3], padding[-2] */
- length = (rx_desc->rx_words_eob) - 3 - 2;
+ /* length convert[-3] */
+ length = (rx_desc->rx_words_eob) - 3;
/* Decide the data conversion method */
if (!adapter->rx_csum) {
/* [Header:14][payload] */
skb_padding_flag = 0;
- skb_copy_flag = 1;
+ if (NET_IP_ALIGN)
+ /* [NET_IP_ALIGN][Header:14][payload] */
+ skb_copy_flag = 1;
+ else
+ skb_copy_flag = 0;
} else {
/* [Header:14][padding:2][payload] */
skb_padding_flag = 1;
+ /* The length includes padding length */
+ length = length - PCH_GBE_DMA_PADDING;
if (length < copybreak)
skb_copy_flag = 1;
- else
- skb_copy_flag = 0;
+ else {
+ /* [Header:14][padding:2][payload]
+ * Chenge to the following
+ * [NET_IP_ALIGN][Header:14][payload] */
+ if (NET_IP_ALIGN == PCH_GBE_DMA_PADDING)
+ skb_copy_flag = 0;
+ else
+ skb_copy_flag = 1;
+ }
}
-
/* Data conversion */
- if (skb_copy_flag) { /* recycle skb */
- struct sk_buff *new_skb;
- new_skb =
- netdev_alloc_skb(netdev,
- length + NET_IP_ALIGN);
- if (new_skb) {
- if (!skb_padding_flag) {
- skb_reserve(new_skb,
- NET_IP_ALIGN);
- }
- memcpy(new_skb->data, skb->data,
- length);
- /* save the skb
- * in buffer_info as good */
- skb = new_skb;
- } else if (!skb_padding_flag) {
+ if (skb_copy_flag) {
+ new_skb = netdev_alloc_skb(netdev,
+ length + NET_IP_ALIGN);
+ if (!new_skb) {
/* dorrop error */
pr_err("New skb allocation Error\n");
goto dorrop;
}
+ skb_reserve(new_skb, NET_IP_ALIGN);
+ if (skb_padding_flag) {
+ memcpy(new_skb->data, skb->data,
+ ETH_HLEN);
+ memcpy(&new_skb->data[ETH_HLEN],
+ &skb->data[ETH_HLEN +
+ PCH_GBE_DMA_PADDING],
+ length - ETH_HLEN);
+ } else {
+ memcpy(new_skb->data, skb->data,
+ length);
+ }
+ skb = new_skb;
} else {
+ if (skb_padding_flag) {
+ memcpy(&tmp_packet[0], &skb->data[0],
+ ETH_HLEN);
+ memcpy(&skb->data[PCH_GBE_DMA_PADDING],
+ &tmp_packet[0], ETH_HLEN);
+ skb_reserve(skb, PCH_GBE_DMA_PADDING);
+ }
buffer_info->skb = NULL;
}
- if (skb_padding_flag) {
- memcpy(&tmp_packet[0], &skb->data[0], ETH_HLEN);
- memcpy(&skb->data[NET_IP_ALIGN], &tmp_packet[0],
- ETH_HLEN);
- skb_reserve(skb, NET_IP_ALIGN);
-
- }
-
+ /* The length includes FCS length */
+ length = length - ETH_FCS_LEN;
/* update status of driver */
adapter->stats.rx_bytes += length;
adapter->stats.rx_packets++;
--
1.6.2.5
^ permalink raw reply related
* Re: About bittiming calculation result
From: Wolfgang Grandegger @ 2011-02-08 7:57 UTC (permalink / raw)
To: Tomoya MORINAGA
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <93C12206407640199DCDD3A89A333F13-c0cKtqp5df7I9507bXv2FdBPR1lH4CV8@public.gmane.org>
Hi Tomoya,
On 02/08/2011 02:27 AM, Tomoya MORINAGA wrote:
> On Tuesday, February 08, 2011 12:53 AM, Wolfgang Grandegger wrote:
>
>> BTW, it's always possible to specify optimized bit-timing
>> parameters directly, e.g. the following seem better:
>>
>> 800000 60 12 4 4 4 3 793650 0.8% 80.0% 81.0% 1.2%
>>
>> You could set these with:
>>
>> $ ip link set can0 type can \
>> tq 60 prop-seg 12 phase-seg1 4 phase-seg2 4 sjw 4
>
> I can confirm 800K comms works well using the above.
Cool, I got these magic values from a CAN hardware expert.
> I wish Can-core could calculate like above.
Me too! I also got some indication on how to improve our algorithm in
case the bit-rate does not match. Hope to find some time soon to work
on this issue.
>>> seg1/seg2/sjw/prop_seg must be more than 1 ?
> BTW, according to EG20T PCH data sheet,
> CAN bit-timing parameters(BRP, Prop_Seg, Phase_Seg1, Phase_Seg2, SJW) must not be set 0.
OK, then please provide a patch setting tseg1_min to 2.
Wolfgang.
^ permalink raw reply
* Re: [PATCH] usb: gadget: nokia: disallow compilation with HIGHMEM
From: Rémi Denis-Courmont @ 2011-02-08 7:39 UTC (permalink / raw)
To: ext-eero.nurkkala; +Cc: linux-usb, dbrownell, netdev
In-Reply-To: <1297150245-31696-1-git-send-email-ext-eero.nurkkala@nokia.com>
On Tuesday 08 February 2011 09:30:45 ext-eero.nurkkala@nokia.com, you wrote:
> From: Eero Nurkkala <ext-eero.nurkkala@nokia.com>
>
> With HIGHMEM, g_phonet oopses with the following path:
> pn_rx_complete() -> pskb_pull() -> ... kmap_skb_frag() and
> oops with BUG_ON(in_irq()). Thus, if the gadget is enabled,
> it'd better conflict with the HIGHMEM.
>
> Signed-off-by: Eero Nurkkala <ext-eero.nurkkala@nokia.com>
Acked-by: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
In the long run, we should probably kludge the skb code like we did in
cdc-phonet.c.
Or better yet, fix kmap_skb_frag() to be less pessimistic. Thing is, the BUG_ON
is really bogus here. The way we allocated the skb, the fragment really cannot
be in HIGHMEM...
--
Rémi Denis-Courmont
Nokia Devices R&D, Maemo Software, Helsinki
^ permalink raw reply
* RE: About bittiming calculation result
From: Tomoya MORINAGA @ 2011-02-08 4:11 UTC (permalink / raw)
To: 'Bhupesh SHARMA', 'Wolfgang Grandegger'
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <D5ECB3C7A6F99444980976A8C6D896384DEE2BE1A7-8vAmw3ZAcdzhJTuQ9jeba9BPR1lH4CV8@public.gmane.org>
Hi Bhupesh,
On Tuesday, February 08, 2011 12:30 PM, Bhupesh SHARMA wrote:
> AFAIK pch uses the Bosch C_CAN core internally.
> As per Bosch C_CAN user manual tseg1= prop_seg + phase_seg1
> So, ideally tseg1_min should be 2. My version of Bosch C_CAN
> driver Uses the value 2.
Thank you for your suggestions.
I will submit the patch.
With Best Regards,
-----------------------------------------
Tomoya MORINAGA
OKI SEMICONDUCTOR CO., LTD.
^ permalink raw reply
* Re: pull request: batman-adv 2011-02-08
From: David Miller @ 2011-02-08 3:55 UTC (permalink / raw)
To: sven; +Cc: netdev, b.a.t.m.a.n
In-Reply-To: <1297123161-25612-1-git-send-email-sven@narfation.org>
From: Sven Eckelmann <sven@narfation.org>
Date: Tue, 8 Feb 2011 00:59:20 +0100
> I would like to propose following patch for net-2.6.git/2.6.38 which fixes a
> possible kernel oops in the unicast fragmentation code.
...
> The following changes since commit 1181e1daace88018b2ff66592aa10a4791d705ff:
>
> batman-adv: Make vis info stack traversal threadsafe (2011-01-30 10:32:08 +0100)
>
> are available in the git repository at:
> git://git.open-mesh.org/ecsv/linux-merge.git batman-adv/merge
Pulled, thanks.
^ permalink raw reply
* RE: About bittiming calculation result
From: Bhupesh SHARMA @ 2011-02-08 3:29 UTC (permalink / raw)
To: Tomoya MORINAGA, 'Wolfgang Grandegger'
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <E2BAACFF191C4175854E6B2EB9135BE5-c0cKtqp5df7I9507bXv2FdBPR1lH4CV8@public.gmane.org>
Hi Tomoya,
> -----Original Message-----
> From: socketcan-core-bounces-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org [mailto:socketcan-core-
> bounces-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org] On Behalf Of Tomoya MORINAGA
> Sent: Tuesday, February 08, 2011 6:40 AM
> To: 'Wolfgang Grandegger'
> Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org; netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-
> kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Subject: RE: About bittiming calculation result
>
> On Monday, February 07, 2011 9:01 PM, Wolfgang Grandegger wrote
> >
> > Well, only prop_seg+phase_seg=tseg1 is relevant and the
> > pch_can driver sets the allowed minimum "tseg1_min1" currently to 1:
> >
> > static struct can_bittiming_const pch_can_bittiming_const = {
> > .name = KBUILD_MODNAME,
> > .tseg1_min = 1,
> > .tseg1_max = 16,
> > .tseg2_min = 1,
> > .tseg2_max = 8,
> > .sjw_max = 4,
> > .brp_min = 1,
> > .brp_max = 1024, /* 6bit + extended 4bit */
> > .brp_inc = 1,
> > };
> >
> > > seg1/seg2/sjw/prop_seg must be more than 1 ?
> >
> > Then "tseg1_min" should be set to *2*.
>
> Though some drivers accepted by upstream have parameter "tseg1_min" as
> 1,
> Sould we release the patch like below ?
> - .tseg1_min = 1,
> + .tseg1_min = 2,
>
AFAIK pch uses the Bosch C_CAN core internally.
As per Bosch C_CAN user manual tseg1= prop_seg + phase_seg1
So, ideally tseg1_min should be 2. My version of Bosch C_CAN driver
Uses the value 2.
Regards,
Bhupesh
^ permalink raw reply
* Re: 2.6.37 regression: adding main interface to a bridge breaks vlan interface RX
From: Jesse Gross @ 2011-02-08 2:24 UTC (permalink / raw)
To: chriss; +Cc: netdev
In-Reply-To: <loom.20110206T203347-475@post.gmane.org>
On Sun, Feb 6, 2011 at 11:37 AM, chriss <mail_to_chriss@gmx.net> wrote:
> Jesse Gross <jesse <at> nicira.com> writes:
>
>>
>> You should either attached a bridge to a vlan device or stack a vlan
>> device on the bridge port depending on what you are trying to achieve.
>>
>> The bridge handler takes all packets of the device that it is attached
>> to, so having a vlan also attached to the same device will not work.
>> You may get different results on older kernels depending on what NIC
>> you were using but that was a bug.
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo <at> vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>>
>
>
> Hi and thanks for your reply
>
> I tried that.
>
> I had under 2.6.36.3 following combination:
>
> eth1 in br0 -> all traffic without vlan id
> eth1.3 -> traffic with vlan 3
>
> with 2.6.37 i should do the following
> eth1 in br0 -> traffic w/o vlans
> and br0.3 -> traffic with vlan id 3
>
> But still there is no rx for vlan 3.
> Any suggestions? Or am i missing something?
That configuration should work (and I've tested it in the past). I
would try running tcpdump on the various interfaces in the path (eth1,
br0, br0.3) to see where traffic is flowing or not.
^ permalink raw reply
* RE: About bittiming calculation result
From: Tomoya MORINAGA @ 2011-02-08 1:27 UTC (permalink / raw)
To: 'Wolfgang Grandegger'
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4D501555.5000905-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
On Tuesday, February 08, 2011 12:53 AM, Wolfgang Grandegger wrote:
> BTW, it's always possible to specify optimized bit-timing
> parameters directly, e.g. the following seem better:
>
> 800000 60 12 4 4 4 3 793650 0.8% 80.0% 81.0% 1.2%
>
> You could set these with:
>
> $ ip link set can0 type can \
> tq 60 prop-seg 12 phase-seg1 4 phase-seg2 4 sjw 4
I can confirm 800K comms works well using the above.
I wish Can-core could calculate like above.
>> seg1/seg2/sjw/prop_seg must be more than 1 ?
BTW, according to EG20T PCH data sheet,
CAN bit-timing parameters(BRP, Prop_Seg, Phase_Seg1, Phase_Seg2, SJW) must not be set 0.
Thanks,
-----------------------------------------
Tomoya MORINAGA
OKI SEMICONDUCTOR CO., LTD.
> -----Original Message-----
> From: Wolfgang Grandegger [mailto:wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org]
> Sent: Tuesday, February 08, 2011 12:53 AM
> To: Tomoya MORINAGA
> Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org; netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
> linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Subject: Re: About bittiming calculation result
>
> On 02/07/2011 01:00 PM, Wolfgang Grandegger wrote:
> > Hi Tomoya,
> >
> > On 02/07/2011 12:38 PM, Tomoya MORINAGA wrote:
> >> Hi,
> >>
> >> I have a question for bittiming-value calculated by Can-core.
> >>
> >> In case setting like below,
> >> - ip link set can0 type can bitrate 800000
> >> - clock=50MHz
> >> - Use pch_can
> >>
> >> Can-core calculates like below
> >> brp=21
> >> seg1=1
> >> seg2=1
> >> sjw=1
> >> prop_seg=0
> >>
> >> Is "prop_seg=0" true ?
> >
> > Well, only prop_seg+phase_seg=tseg1 is relevant and the
> pch_can driver
> > sets the allowed minimum "tseg1_min1" currently to 1:
> >
> > static struct can_bittiming_const pch_can_bittiming_const = {
> > .name = KBUILD_MODNAME,
> > .tseg1_min = 1,
> > .tseg1_max = 16,
> > .tseg2_min = 1,
> > .tseg2_max = 8,
> > .sjw_max = 4,
> > .brp_min = 1,
> > .brp_max = 1024, /* 6bit + extended 4bit */
> > .brp_inc = 1,
> > };
> >
> >> seg1/seg2/sjw/prop_seg must be more than 1 ?
> >
> > Then "tseg1_min" should be set to *2*.
> >
> >> Also I can see the following kernel error log.
> >> bitrate error 0.7%
> >
> > A clock frequency of 50 MHz is sub-optimal for CAN and some
> bit-rates
> > cannot be reproduced properly. Here is the output of the can-utils
> > program "can-calc-bit-timing" (with an entry for the pch-can added):
> >
> > $ ./can-calc-bit-timing pch-can
> > Bit timing parameters for pch-can with 50.000000 MHz ref clock
> > nominal real Bitrt nom real SampP
> > Bitrate TQ[ns] PrS PhS1 PhS2 SJW BRP Bitrate Error SampP
> SampP Error CNF1 CNF2 CNF3
> > 1000000 100 3 3 3 1 5 1000000 0.0% 75.0%
> 70.0% 6.7% 0x05 0x92 0x02
> > 800000 420 0 1 1 1 21 793650 0.8% 80.0%
> 66.6% 16.8% 0x15 0xff 0x00
> > 500000 100 8 8 3 1 5 500000 0.0% 87.5%
> 85.0% 2.9% 0x05 0xbf 0x02
> > 250000 500 3 3 1 1 25 250000 0.0% 87.5%
> 87.5% 0.0% 0x19 0x92 0x00
> > 125000 500 6 7 2 1 25 125000 0.0% 87.5%
> 87.5% 0.0% 0x19 0xb5 0x01
> > 100000 500 8 8 3 1 25 100000 0.0% 87.5%
> 85.0% 2.9% 0x19 0xbf 0x02
> > 50000 2500 3 3 1 1 125 50000 0.0% 87.5%
> 87.5% 0.0% 0x7d 0x92 0x00
> > 20000 2500 8 8 3 1 125 20000 0.0% 87.5%
> 85.0% 2.9% 0x7d 0xbf 0x02
> > 10000 12500 3 3 1 1 625 10000 0.0% 87.5%
> 87.5% 0.0% 0x71 0x92 0x00
> >
> > As you can see, especially 800000 gives rather bad results.
>
> BTW, it's always possible to specify optimized bit-timing
> parameters directly, e.g. the following seem better:
>
> 800000 60 12 4 4 4 3 793650 0.8% 80.0% 81.0% 1.2%
>
> You could set these with:
>
> $ ip link set can0 type can \
> tq 60 prop-seg 12 phase-seg1 4 phase-seg2 4 sjw 4
>
> Wolfgang.
>
^ permalink raw reply
* compat-wireless for 2.6.38-rc3 - third release
From: Luis R. Rodriguez @ 2011-02-08 1:10 UTC (permalink / raw)
To: linux-wireless, linux-bluetooth, netdev; +Cc: linux-kernel
I updated compat-wireless for 2.6.38-rc3, this is the third update, it
should now include the proper compat.git branch and also adds some new
patches from Hauke to minimize deltas and fix compilation. While at it
I took the time to suck in new pending-stable patches for an "-s"
release, I haven't cherry picked any patches yet as I cannot think of
anything immediately important, if you do send me a patch.
Code metrics for the vanilla release:
782535 - Total upstream lines of code being pulled
2108 - backport code changes
1847 - backport code additions
261 - backport code deletions
7292 - backport from compat module
9400 - total backport code
1.2012 - % of code consists of backport work
Base tree: linux-2.6-allstable.git
Base tree version: v2.6.38-rc3
compat-wireless release: compat-wireless-v2.6.38-rc3-3
Code metrics for the "-s" release:
782535 - Total upstream lines of code being pulled
2108 - backport code changes
1847 - backport code additions
261 - backport code deletions
7292 - backport from compat module
9400 - total backport code
1.2012 - % of code consists of backport work
115 - Code changes brought in from pending-stable
57 - Code additions brought in from pending-stable
58 - Code deletions brought in from pending-stable
0.0147 - % of code being cherry picked from pending-stable
Base tree: linux-2.6-allstable.git
Base tree version: v2.6.38-rc3
compat-wireless release: compat-wireless-v2.6.38-rc3-3-s
Relevant URLs:
http://www.orbit-lab.org/kernel/compat-wireless-2.6-stable/v2.6.38/compat-wireless-2.6.38-rc3-3.tar.bz2
http://www.orbit-lab.org/kernel/compat-wireless-2.6-stable/v2.6.38/compat-wireless-2.6.38-rc3-3-s.tar.bz2
http://www.orbit-lab.org/kernel/compat-wireless-2.6-stable/v2.6.38/ChangeLog-2.6.38-wireless
http://wireless.kernel.org/en/users/Download/stable
Luis
^ permalink raw reply
* RE: About bittiming calculation result
From: Tomoya MORINAGA @ 2011-02-08 1:09 UTC (permalink / raw)
To: 'Wolfgang Grandegger'
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4D4FDEF9.2030305-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
On Monday, February 07, 2011 9:01 PM, Wolfgang Grandegger wrote
>
> Well, only prop_seg+phase_seg=tseg1 is relevant and the
> pch_can driver sets the allowed minimum "tseg1_min1" currently to 1:
>
> static struct can_bittiming_const pch_can_bittiming_const = {
> .name = KBUILD_MODNAME,
> .tseg1_min = 1,
> .tseg1_max = 16,
> .tseg2_min = 1,
> .tseg2_max = 8,
> .sjw_max = 4,
> .brp_min = 1,
> .brp_max = 1024, /* 6bit + extended 4bit */
> .brp_inc = 1,
> };
>
> > seg1/seg2/sjw/prop_seg must be more than 1 ?
>
> Then "tseg1_min" should be set to *2*.
Though some drivers accepted by upstream have parameter "tseg1_min" as 1,
Sould we release the patch like below ?
- .tseg1_min = 1,
+ .tseg1_min = 2,
Thanks,
-----------------------------------------
Tomoya MORINAGA
OKI SEMICONDUCTOR CO., LTD.
^ permalink raw reply
* Re: [Bugme-new] [Bug 28542] New: 3c59x.c: Regression since 2.6.36 (incl.), for e. g., TCP stalls on receive
From: Ben Hutchings @ 2011-02-08 0:39 UTC (permalink / raw)
To: for.poige+bugzilla.kernel.org
Cc: netdev, bugzilla-daemon, bugme-daemon, Jan Beulich, Neil Horman,
Steffen Klassert, Andrew Morton
In-Reply-To: <20110207150919.cd253b97.akpm@linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 897 bytes --]
On Mon, 2011-02-07 at 15:09 -0800, Andrew Morton wrote:
> On Mon, 7 Feb 2011 18:55:29 GMT
> bugzilla-daemon@bugzilla.kernel.org wrote:
[...]
> > Dump of kernel source bz2 download being stalled:
> > http://poige.livejournal.com/475372.html#cutid1 (see the bunch of ACKs
> > #5555523).
That's not a stall, that's selective-ACKing (see the ranges listed on
the right of each ACK line).
> > As a workaround I've just replaced drivers/net/3c59x.c with its former
> > (2.6.35.11) version, the connectivity problems are gone now.
This could just be a coincidence. But it could be that packet loss is
now more likely for some reason. Does the rx_fifo_errors statistic
increase quickly with the later version of the driver? (This seems to
be the only receive error type reported.)
Ben.
--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Send-to-self TCP connection hangs in 2.6.38-rc3.
From: Ben Greear @ 2011-02-08 0:34 UTC (permalink / raw)
To: netdev
I'm seeing something weird on the latest wireless-testing kernel
(I have some wifi hacks in here, but no modifications to the basic
networking system, no proprietary modules loaded.)
Wireless-testing is currently based on 2.6.38-rc3.
This has been happening for a while, but I'm not sure
exactly when it started.
I am sending-to-self across some virtual wifi stations. UDP runs fine,
but TCP connections tend to hang after a while..often in only one
direction.
The ip rules seem right, I'm detecting no spurious link admin up/down. I suspect
conn-tracking. Notice that the dport and sport do not match the netstat output
in the entry marked 'UNREPLIED'. What sort of thing could cause that?
Here's some conntrack output for a broken connection:
ipv4 2 tcp 6 299 ESTABLISHED src=33.1.2.35 dst=33.1.2.32 sport=33381 dport=33382 src=33.1.2.32 dst=33.1.2.35 sport=33382 dport=33381 [ASSURED] mark=0
zone=0 use=2
ipv4 2 tcp 6 431687 ESTABLISHED src=33.1.2.32 dst=33.1.2.35 sport=33194 dport=33193 [UNREPLIED] src=33.1.2.35 dst=33.1.2.32 sport=33193 dport=33194
mark=0 zone=0 use=2
ipv4 2 udp 17 179 src=33.1.2.35 dst=33.1.2.32 sport=33381 dport=33382 src=33.1.2.32 dst=33.1.2.35 sport=33382 dport=33381 [ASSURED] mark=0 zone=0 use=2
The 33.1.2.32 side seems unable to send to the peer, though the peer can send to .32
[root@lec2010-ath9k-1 lanforge]# netstat -an|grep 1.2.32
tcp 0 0 33.1.2.32:33382 0.0.0.0:* LISTEN
tcp 0 5852 33.1.2.32:33382 33.1.2.35:33381 ESTABLISHED
tcp 0 0 33.1.2.35:33381 33.1.2.32:33382 ESTABLISHED
udp 0 0 33.1.2.32:33382 0.0.0.0:*
udp 0 0 33.1.2.32:123 0.0.0.0:*
Here's the same connection after re-starting it. It appears to be passing traffic
properly.
[root@lec2010-ath9k-1 lanforge]# netstat -an|grep 1.2.32
tcp 0 0 33.1.2.32:33480 0.0.0.0:* LISTEN
tcp 0 0 33.1.2.35:33479 33.1.2.32:33480 ESTABLISHED
tcp 0 0 33.1.2.32:33480 33.1.2.35:33479 ESTABLISHED
udp 0 0 33.1.2.32:123 0.0.0.0:*
udp 0 0 33.1.2.32:33484 0.0.0.0:*
[root@lec2010-ath9k-1 lanforge]# cat /proc/net/nf_conntrack|grep 1.2.32
ipv4 2 udp 17 179 src=33.1.2.35 dst=33.1.2.32 sport=33483 dport=33484 src=33.1.2.32 dst=33.1.2.35 sport=33484 dport=33483 [ASSURED] mark=0 zone=0 use=2
ipv4 2 tcp 6 430352 ESTABLISHED src=33.1.2.32 dst=33.1.2.35 sport=33194 dport=33193 [UNREPLIED] src=33.1.2.35 dst=33.1.2.32 sport=33193 dport=33194
mark=0 zone=0 use=2
ipv4 2 udp 17 161 src=33.1.2.35 dst=33.1.2.32 sport=33381 dport=33382 src=33.1.2.32 dst=33.1.2.35 sport=33382 dport=33381 [ASSURED] mark=0 zone=0 use=2
ipv4 2 tcp 6 431999 ESTABLISHED src=33.1.2.35 dst=33.1.2.32 sport=33479 dport=33480 src=33.1.2.32 dst=33.1.2.35 sport=33480 dport=33479 [ASSURED]
mark=0 zone=0 use=2
Here's a connection that had been running for several minutes and seems
to have been passing traffic fine. I'm not sure about what the
CLOSE_WAIT thing is...
[root@lec2010-ath9k-1 lanforge]# netstat -an|grep 1.2.20
tcp 0 0 33.1.2.18:33362 33.1.2.20:33361 ESTABLISHED
tcp 1 0 33.1.2.18:33202 33.1.2.20:33201 CLOSE_WAIT
tcp 0 0 33.1.2.20:33361 33.1.2.18:33362 ESTABLISHED
udp 0 0 33.1.2.20:33361 0.0.0.0:*
udp 0 0 33.1.2.20:123 0.0.0.0:*
[root@lec2010-ath9k-1 lanforge]# cat /proc/net/nf_conntrack|grep 1.2.20
ipv4 2 tcp 6 431999 ESTABLISHED src=33.1.2.20 dst=33.1.2.18 sport=33361 dport=33362 src=33.1.2.18 dst=33.1.2.20 sport=33362 dport=33361 [ASSURED]
mark=0 zone=0 use=2
ipv4 2 udp 17 178 src=33.1.2.20 dst=33.1.2.18 sport=33361 dport=33362 src=33.1.2.18 dst=33.1.2.20 sport=33362 dport=33361 [ASSURED] mark=0 zone=0 use=2
I'll be happy to provide more details..just ask.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH] tcp: undo_retrans counter fixes
From: Yuchung Cheng @ 2011-02-08 0:22 UTC (permalink / raw)
To: Ilpo Järvinen; +Cc: David Miller, Netdev
In-Reply-To: <alpine.DEB.2.00.1102080112450.29228@melkinpaasi.cs.helsinki.fi>
On Mon, Feb 7, 2011 at 3:36 PM, Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> wrote:
>
> On Mon, 7 Feb 2011, David Miller wrote:
>
> > From: Yuchung Cheng <ycheng@google.com>
> > Date: Mon, 7 Feb 2011 14:57:04 -0800
> >
> > > Fix a bug that undo_retrans is incorrectly decremented when undo_marker is
> > > not set or undo_retrans is already 0. This happens when sender receives
> > > more DSACK ACKs than packets retransmitted during the current
> > > undo phase. This may also happen when sender receives DSACK after
> > > the undo operation is completed or cancelled.
> > >
> > > Fix another bug that undo_retrans is incorrectly incremented when
> > > sender retransmits an skb and tcp_skb_pcount(skb) > 1 (TSO). This case
> > > is rare but not impossible.
> > >
> > > Signed-off-by: Yuchung Cheng <ycheng@google.com>
> >
> > Looks good, Ilpo could you please review this real quick?
>
> I already too a quick look so you're real lucky, only delay of writing is
> needed... :-)
thanks.
>
> Neither is harmful to "fix" but I think they're partially also checking
> for things which shouldn't cause problems... E.g., undo_retrans is only
> used after checking undo_marker's validity first so I don't think
> undo_marker check is exactly necessary there (but on the other hand it
> does no harm)...
logically we should check the validity of undo_marker/undo_retrans
before we use them? The current code has no problem if
tcp_fastretrans_alert() always call tcp_try_undo_* functions whenever
undo_marker != 0 and undo_retrans == 0. I don't think that's always
true.
>
> The tcp_retransmit_skb problem I don't understand at all as we should be
> fragmenting or resetting pcount to 1 (the latter is true only if all
> bugfixes were included to the kernel where >1 pcount for a rexmitted skb
> was seen). If pcount is indeed >1 we might have other issues too somewhere
We found that sometimes pcount > 1 on real servers. This change keeps
the retrans_out/undo_retrans counters consistent.
> but I fail to remember immediately what they would be. That change is not
> bad though since using +/-1 is something we should be getting rid of
> anyway and on long term it would be nice to make tcp_retransmit_skb to be
> able to take advantage of TSO anyway whenever possible.
>
> I also noticed that the undo_retrans code in sacktag side is still doing
> undo_retrans-- ops which could certainly cause real miscounts, though
> it is extremely unlikely due to the fact that DSACK should be sent
> immediately for a single segment at a time (so the sender would need to
> split+recollapse in between).
I have the same doubt but our servers never hit this condition (pcount
> 1). So I keep this part intact.
>
> --
> i.
^ permalink raw reply
* [PATCH] batman-adv: Linearize fragment packets before merge
From: Sven Eckelmann @ 2011-02-07 23:59 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r, Marek Lindner
In-Reply-To: <1297123161-25612-1-git-send-email-sven-KaDOiPu9UxWEi8DpZVb4nw@public.gmane.org>
We access the data inside the skbs of two fragments directly using memmove
during the merge. The data of the skb could span over multiple skb pages. An
direct access without knowledge about the pages would lead to an invalid memory
access.
Signed-off-by: Sven Eckelmann <sven-KaDOiPu9UxWEi8DpZVb4nw@public.gmane.org>
[lindner_marek-LWAfsSFWpa4@public.gmane.org: Move return from function to the end]
Signed-off-by: Marek Lindner <lindner_marek-LWAfsSFWpa4@public.gmane.org>
---
net/batman-adv/unicast.c | 15 ++++++++++-----
1 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/net/batman-adv/unicast.c b/net/batman-adv/unicast.c
index ee41fef..d1a6113 100644
--- a/net/batman-adv/unicast.c
+++ b/net/batman-adv/unicast.c
@@ -50,12 +50,12 @@ static struct sk_buff *frag_merge_packet(struct list_head *head,
skb = tfp->skb;
}
+ if (skb_linearize(skb) < 0 || skb_linearize(tmp_skb) < 0)
+ goto err;
+
skb_pull(tmp_skb, sizeof(struct unicast_frag_packet));
- if (pskb_expand_head(skb, 0, tmp_skb->len, GFP_ATOMIC) < 0) {
- /* free buffered skb, skb will be freed later */
- kfree_skb(tfp->skb);
- return NULL;
- }
+ if (pskb_expand_head(skb, 0, tmp_skb->len, GFP_ATOMIC) < 0)
+ goto err;
/* move free entry to end */
tfp->skb = NULL;
@@ -70,6 +70,11 @@ static struct sk_buff *frag_merge_packet(struct list_head *head,
unicast_packet->packet_type = BAT_UNICAST;
return skb;
+
+err:
+ /* free buffered skb, skb will be freed later */
+ kfree_skb(tfp->skb);
+ return NULL;
}
static void frag_create_entry(struct list_head *head, struct sk_buff *skb)
--
1.7.2.3
^ permalink raw reply related
* pull request: batman-adv 2011-02-08
From: Sven Eckelmann @ 2011-02-07 23:59 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r
Hi,
I would like to propose following patch for net-2.6.git/2.6.38 which fixes a
possible kernel oops in the unicast fragmentation code.
thanks,
Sven
The following changes since commit 1181e1daace88018b2ff66592aa10a4791d705ff:
batman-adv: Make vis info stack traversal threadsafe (2011-01-30 10:32:08 +0100)
are available in the git repository at:
git://git.open-mesh.org/ecsv/linux-merge.git batman-adv/merge
Sven Eckelmann (1):
batman-adv: Linearize fragment packets before merge
net/batman-adv/unicast.c | 15 ++++++++++-----
1 files changed, 10 insertions(+), 5 deletions(-)
^ permalink raw reply
* Re: [PATCH] tcp: undo_retrans counter fixes
From: Ilpo Järvinen @ 2011-02-07 23:36 UTC (permalink / raw)
To: David Miller; +Cc: ycheng, Netdev
In-Reply-To: <20110207.150522.28821840.davem@davemloft.net>
On Mon, 7 Feb 2011, David Miller wrote:
> From: Yuchung Cheng <ycheng@google.com>
> Date: Mon, 7 Feb 2011 14:57:04 -0800
>
> > Fix a bug that undo_retrans is incorrectly decremented when undo_marker is
> > not set or undo_retrans is already 0. This happens when sender receives
> > more DSACK ACKs than packets retransmitted during the current
> > undo phase. This may also happen when sender receives DSACK after
> > the undo operation is completed or cancelled.
> >
> > Fix another bug that undo_retrans is incorrectly incremented when
> > sender retransmits an skb and tcp_skb_pcount(skb) > 1 (TSO). This case
> > is rare but not impossible.
> >
> > Signed-off-by: Yuchung Cheng <ycheng@google.com>
>
> Looks good, Ilpo could you please review this real quick?
I already too a quick look so you're real lucky, only delay of writing is
needed... :-)
Neither is harmful to "fix" but I think they're partially also checking
for things which shouldn't cause problems... E.g., undo_retrans is only
used after checking undo_marker's validity first so I don't think
undo_marker check is exactly necessary there (but on the other hand it
does no harm)...
The tcp_retransmit_skb problem I don't understand at all as we should be
fragmenting or resetting pcount to 1 (the latter is true only if all
bugfixes were included to the kernel where >1 pcount for a rexmitted skb
was seen). If pcount is indeed >1 we might have other issues too somewhere
but I fail to remember immediately what they would be. That change is not
bad though since using +/-1 is something we should be getting rid of
anyway and on long term it would be nice to make tcp_retransmit_skb to be
able to take advantage of TSO anyway whenever possible.
I also noticed that the undo_retrans code in sacktag side is still doing
undo_retrans-- ops which could certainly cause real miscounts, though
it is extremely unlikely due to the fact that DSACK should be sent
immediately for a single segment at a time (so the sender would need to
split+recollapse in between).
--
i.
^ permalink raw reply
* Re: [Bugme-new] [Bug 28482] New: ADSL PPPOE kernel bug at /arch/x86/kernel/pci-nommu.c
From: Andrew Morton @ 2011-02-07 23:30 UTC (permalink / raw)
To: wm666, linux-ide; +Cc: bugzilla-daemon, bugme-daemon, netdev
In-Reply-To: <bug-28482-10286@https.bugzilla.kernel.org/>
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Mon, 7 Feb 2011 13:24:48 GMT
bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=28482
>
> Summary: ADSL PPPOE kernel bug at /arch/x86/kernel/pci-nommu.c
> Product: Drivers
> Version: 2.5
2.6.36.x, actually.
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: high
> Priority: P1
> Component: Network
> AssignedTo: drivers_network@kernel-bugs.osdl.org
OK, this is strange. The BUG trace points very firmly at the ATA code,
but your report attributes the crash to the PPPOE code. How can this be?
Perhaps the PPPOE code is scribbling on memory which the ata code uses.
If you have more oops traces then it would be useful for us to see them
please. You could attach them to the bugzilla report and then let us
know via reply-to-all to this email, thanks.
> ReportedBy: wm666@mail.ru
> Regression: No
>
>
> Created an attachment (id=46712)
> --> (https://bugzilla.kernel.org/attachment.cgi?id=46712)
> Screenshot
>
> uname -a
> Linux server 2.6.36-gentoo-r5-sfireman #1 SMP Sun Feb 6 17:34:43 MSK 2011
> x86_64 Intel(R) Core(TM)2 CPU 6400 @ 2.13GHz GenuineIntel GNU/Linux
>
> lsmod
> xt_CLASSIFY 877 24
> sch_sfq 5791 4
> sch_htb 14250 1
> xt_limit 1830 2
> xt_state 1143 5
> ipt_addrtype 1865 0
> xt_DSCP 2059 0
> xt_dscp 1579 0
> xt_string 1211 0
> xt_owner 1063 0
> xt_NFQUEUE 1565 0
> xt_multiport 1702 6
> xt_mark 1093 0
> xt_iprange 1456 0
> xt_hashlimit 5797 0
> xt_conntrack 2551 0
> xt_connmark 1629 0
> scsi_wait_scan 679 0
>
> lspci
> 00:00.0 Host bridge: Intel Corporation 82P965/G965 Memory Controller Hub (rev
> 02)
> 00:01.0 PCI bridge: Intel Corporation 82P965/G965 PCI Express Root Port (rev
> 02)
> 00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1
> (rev 02)
> 00:1c.5 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 6
> (rev 02)
> 00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI
> Controller #1 (rev 02)
> 00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI
> Controller #2 (rev 02)
> 00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI
> Controller #3 (rev 02)
> 00:1d.3 USB Controller: Intel Corporation Device 2833 (rev 02)
> 00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI
> Controller #1 (rev 02)
> 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev f2)
> 00:1f.0 ISA bridge: Intel Corporation 82801HB/HR (ICH8/R) LPC Interface
> Controller (rev 02)
> 00:1f.2 SATA controller: Intel Corporation 82801HR/HO/HH (ICH8R/DO/DH) 6 port
> SATA AHCI Controller (rev 02)
> 00:1f.3 SMBus: Intel Corporation 82801H (ICH8 Family) SMBus Controller (rev 02)
> 02:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8056 PCI-E
> Gigabit Ethernet Controller (rev 12)
> 03:00.0 VGA compatible controller: nVidia Corporation Device 10c3 (rev a2)
> 03:00.1 Audio device: nVidia Corporation Device 0be3 (rev a1)
> 04:00.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)
> 04:02.0 Ethernet controller: D-Link System Inc DGE-530T Gigabit Ethernet
> Adapter (rev 11) (rev 11)
> 04:04.0 Ethernet controller: Marvell Technology Group Ltd. 88E8001 Gigabit
> Ethernet Controller (rev 14)
>
> kernel bug at /arch/x86/kernel/pci-nommu.c
>
> how to reproduce:
> I use pppoe(pppd with compiled in kernel module for pppoe)
> gentoo /etc/conf.d/net
>
> #HOME DOMAIN NAME
> dns_domain_lo="home"
>
> #LAN
> config_eth0=( "192.168.10.1 netmask 255.255.255.0 brd 192.168.10.255" )
>
> #WIFI
> config_eth1=( "192.168.0.2 netmask 255.255.255.0 brd 192.168.0.255" )
>
> #ADSL
> config_eth2=( "192.168.1.2 netmask 255.255.255.0 brd 192.168.1.255" )
>
> #ADSL Primary
> config_ppp0=(
> "ppp"
> "192.168.1.254" #ALIAS
> )
> link_ppp0="eth2"
> plugins_ppp0=( "pppoe" )
> username_ppp0='sfireman'
> password_ppp0='zpres9'
> pppd_ppp0=(
> "noauth"
> "defaultroute"
> "usepeerdns"
> "holdoff 3"
> "child-timeout 60"
> "lcp-echo-interval 15"
> "lcp-echo-failure 3"
> noaccomp noccp nobsdcomp nodeflate nopcomp novj novjccomp
> )
>
> depend_ppp0() {
> need net.eth2
> }
>
> #ADSL Statistic only
> config_ppp1=( "ppp" )
> link_ppp1="eth2"
> plugins_ppp1=( "pppoe" )
> username_ppp1='stat'
> password_ppp1='stat'
> pppd_ppp1=(
> "noauth"
> "defaultroute"
> "usepeerdns"
> "holdoff 3"
> "child-timeout 60"
> "lcp-echo-interval 15"
> "lcp-echo-failure 3"
> noaccomp noccp nobsdcomp nodeflate nopcomp novj novjccomp
> )
>
> depend_ppp1() {
> need net.eth2
> }
>
> do.:
> /etc/init.d/net.ppp0 start
> /etc/init.d/net.ppp1 start
>
> so. bug causes by starting second ppp link, if first already present.
>
> Bumps! :(
> It's reproduces 100%.
> But stack traces is different.
> Please, fix it.
>
> P.S. sorry for my ugly english :)
^ permalink raw reply
* Re: [Bugme-new] [Bug 28512] New: IPv6 SLAAC address preferred over static one as source address
From: Andrew Morton @ 2011-02-07 23:20 UTC (permalink / raw)
To: netdev; +Cc: bugzilla-daemon, bugme-daemon, ghen
In-Reply-To: <bug-28512-10286@https.bugzilla.kernel.org/>
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Mon, 7 Feb 2011 16:15:16 GMT
bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=28512
>
> Summary: IPv6 SLAAC address preferred over static one as source
> address
> Product: Networking
> Version: 2.5
> Kernel Version: 2.6.36
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: IPV6
> AssignedTo: yoshfuji@linux-ipv6.org
> ReportedBy: ghen@telenet.be
> Regression: No
>
>
> Linux IPv6 source address selection rules are described here:
> http://www.davidc.net/networking/ipv6-source-address-selection-linux
>
> In case of a tie, "Linux chooses to use the latest address added".
>
> A very common tie is where a host has a SLAAC (Stateless address
> auto-configuration) address as well as one or more statically assigned ones in
> the same /64. The SLAAC address will almost always be the most recently
> "added" one, as it is renewed with every Router Advertisement on the network,
> and there will be a tie for all other rules.
>
> As a consequence, the kernel chooses this address by default for outgoing
> connections. This is usually not the preferred scenario; the static address
> will more likely have proper reverse DNS, be configured in ACL's, etc.
>
> This has been discussed on the ipv6-ops mailing list
> (ipv6-ops@lists.cluenet.de), and a better suggestion for a tie-breaker came
> out: the preferred lifetime of the address.
>
> SLAAC addresses will have a limited preferred lifetime (as defined by the
> router), static addresses will usually have an unlimited preferred lifetime
> (0). So it makes a lot of sense to take this preferred lifetime into account
> for source address selection (how is it otherwise "preferred"?).
>
> This could be added as rule #9 before using the most recently added as a final
> tie breaker?
>
> Geert
^ permalink raw reply
* Re: [Bugme-new] [Bug 28532] New: Link state change detection problem on Moschip MCS7832 [mcs7830]
From: Andrew Morton @ 2011-02-07 23:14 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA
Cc: bugzilla-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r,
bugme-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r,
myxal.mxl-Re5JQEeQqe8AvxtiuMwx3w, Andreas Mohr
In-Reply-To: <bug-28532-10286-3bo0kxnWaOQUvHkbgXJLS5sdmw4N0Rt+2LY78lusg7I@public.gmane.org/>
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Mon, 7 Feb 2011 18:14:56 GMT
bugzilla-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r@public.gmane.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=28532
>
> Summary: Link state change detection problem on Moschip MCS7832
> [mcs7830]
> Product: Drivers
> Version: 2.5
> Kernel Version: 2.6.38-rc2
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: Network
> AssignedTo: drivers_network-ztI5WcYan/vQLgFONoPN62D2FQJk+8+b@public.gmane.org
> ReportedBy: myxal.mxl-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
> Regression: No
>
>
> Created an attachment (id=46752)
> --> (https://bugzilla.kernel.org/attachment.cgi?id=46752)
> lsusb -vv output
>
> Hi.
>
> I have a network adapter which uses the aforementioned driver and while
> checking for the link state via ethtool reports the correct state, many
> networking userspace utilities seem to have no clue about it (NM 0.8.1 starts
> dhclient BEFORE any cable is plugged) - and more importantly, don't notice when
> the cable is (dis)connected. Since there's not even a kernel message when
> (dis)connecting the cable, I suspect the driver does not implement Link state
> change detection at all. Is this accurate?
>
> LSCD works in Windows, where it's apparently implemented through periodic
> polling (judging by virtualbox's blinking USB icon).
> How is this situation normally handled? Is it kernel's job to do the polling?
> Or are userspace utilities expected to do this?
>
> Docs to the chip are available here:
> http://www.moschip.com/data/products/MCS7830/Data%20Sheet_7830.pdf
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 0/5] net: Unified offload configuration
From: Michał Mirosław @ 2011-02-07 23:12 UTC (permalink / raw)
To: David Miller; +Cc: netdev, bhutchings
In-Reply-To: <20110207.145259.246536239.davem@davemloft.net>
On Mon, Feb 07, 2011 at 02:52:59PM -0800, David Miller wrote:
> From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
> Date: Mon, 7 Feb 2011 23:49:37 +0100
> > What driver did you get this output from?
> NIU, which sets NETIF_F_HW_CSUM in netdev->features, which is
> absolutely correct.
Quick look at niu_process_rx_pkt() reveals that if you disable
TX checksumming you will also get 'rx-checksumming: off' from ethtool,
but RX checksumming will still be used.
Best Regards,
Michał Mirosław
^ permalink raw reply
* Re: [Bugme-new] [Bug 28542] New: 3c59x.c: Regression since 2.6.36 (incl.), for e. g., TCP stalls on receive
From: Andrew Morton @ 2011-02-07 23:09 UTC (permalink / raw)
To: netdev
Cc: bugzilla-daemon, bugme-daemon, Jan Beulich, Ben Hutchings,
Neil Horman, Steffen Klassert, for.poige+bugzilla.kernel.org
In-Reply-To: <bug-28542-10286@https.bugzilla.kernel.org/>
On Mon, 7 Feb 2011 18:55:29 GMT
bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=28542
>
> Summary: 3c59x.c: Regression since 2.6.36 (incl.), for e. g.,
> TCP stalls on receive
> Product: Drivers
> Version: 2.5
> Kernel Version: 2.6.36—2.6.37
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: high
> Priority: P1
> Component: Network
> AssignedTo: drivers_network@kernel-bugs.osdl.org
> ReportedBy: for.poige+bugzilla.kernel.org@gmail.com
> Regression: Yes
>
>
> Dump of kernel source bz2 download being stalled:
> http://poige.livejournal.com/475372.html#cutid1 (see the bunch of ACKs
> #5555523).
>
> As a workaround I've just replaced drivers/net/3c59x.c with its former
> (2.6.35.11) version, the connectivity problems are gone now.
>
^ permalink raw reply
* Re: [Bugme-new] [Bug 28552] New: ipheth stopped working between 2.6.35.9 and 2.6.36.2
From: Andrew Morton @ 2011-02-07 23:07 UTC (permalink / raw)
To: linux-usb, netdev; +Cc: bugzilla-daemon, bugme-daemon, linux-kernel
In-Reply-To: <bug-28552-10286@https.bugzilla.kernel.org/>
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Mon, 7 Feb 2011 19:24:29 GMT
bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=28552
>
> Summary: ipheth stopped working between 2.6.35.9 and 2.6.36.2
> Product: Drivers
> Version: 2.5
> Kernel Version: 2.6.36.2
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: Network
> AssignedTo: drivers_network@kernel-bugs.osdl.org
> ReportedBy: linux-kernel@jmbreuer.net
> Regression: Yes
>
>
> Created an attachment (id=46762)
> --> (https://bugzilla.kernel.org/attachment.cgi?id=46762)
> tcpdump of iPhone tethering attempt in 2.6.36.2
>
> Overview:
>
> Internet connection via iPhone 3G ("USB tethering") no longer works in
> 2.6.36.2; it appears that the packets coming from the iPhone are
> misinterpreted.
>
> Steps to Reproduce:
>
> 1) Connect iPhone to computer via USB cable
>
> 2) Put iPhone in "tethering" mode
>
> Actual Results:
>
> The DHCP client times out trying to obtain a lease.
>
> Expected Results:
>
> The computer gets IP information via DHCP, and is able to share the
> iPhone's internet connection.
>
> Build Date & Platform:
>
> 2.6.36.2 on x86_64
> iPhone 3G Firmware 3.1.3
>
> Additional Builds and Platforms:
>
> 2.6.35.9 on x86_64 (same hardware) works as expected.
>
> Additional Information:
>
> Attached are 2 tcpdump logs:
> 2.6.36.2-tcpdump.txt in the failure case
> 2.6.35.9-tcpdump.txt, working connection setup
>
> Comparing the DHCP reply at 19:53:36.581403 (works) to 19:05:05.744666 (fails)
> it appears that 2.6.36.2 misinterprets the data coming from the iPhone, so that
> the failing packet is not recognized as an IP packet / valid DHCP reply.
>
> The change to ipheth.c itself between 2.6.36 and 2.6.35 seems trivial:
> http://lxr.free-electrons.com/diff/drivers/net/usb/ipheth.c?v=2.6.35;diffval=2.6.36;diffvar=v
>
> Therefore I'd at first tried copying 2.6.35's ipheth.c into my 2.6.36 tree and
> rebuilding this driver; it appears to fail the same as vanilla 2.6.36 does
> [sorry, no logs - I can repeat this if required].
>
> This suggests that the failure happens somewhere in either the networking or
> USB layer, not the ipheth.c driver itself.
>
> I'm happy to perform any additional testing required.
>
^ permalink raw reply
* Re: [PATCH] tcp: undo_retrans counter fixes
From: David Miller @ 2011-02-07 23:05 UTC (permalink / raw)
To: ycheng; +Cc: netdev, ilpo.jarvinen
In-Reply-To: <1297119424-19956-1-git-send-email-ycheng@google.com>
From: Yuchung Cheng <ycheng@google.com>
Date: Mon, 7 Feb 2011 14:57:04 -0800
> Fix a bug that undo_retrans is incorrectly decremented when undo_marker is
> not set or undo_retrans is already 0. This happens when sender receives
> more DSACK ACKs than packets retransmitted during the current
> undo phase. This may also happen when sender receives DSACK after
> the undo operation is completed or cancelled.
>
> Fix another bug that undo_retrans is incorrectly incremented when
> sender retransmits an skb and tcp_skb_pcount(skb) > 1 (TSO). This case
> is rare but not impossible.
>
> Signed-off-by: Yuchung Cheng <ycheng@google.com>
Looks good, Ilpo could you please review this real quick?
Thanks.
^ permalink raw reply
* [PATCH] tcp: undo_retrans counter fixes
From: Yuchung Cheng @ 2011-02-07 22:57 UTC (permalink / raw)
To: netdev; +Cc: ilpo.jarvinen, Yuchung Cheng
Fix a bug that undo_retrans is incorrectly decremented when undo_marker is
not set or undo_retrans is already 0. This happens when sender receives
more DSACK ACKs than packets retransmitted during the current
undo phase. This may also happen when sender receives DSACK after
the undo operation is completed or cancelled.
Fix another bug that undo_retrans is incorrectly incremented when
sender retransmits an skb and tcp_skb_pcount(skb) > 1 (TSO). This case
is rare but not impossible.
Signed-off-by: Yuchung Cheng <ycheng@google.com>
---
net/ipv4/tcp_input.c | 5 +++--
net/ipv4/tcp_output.c | 2 +-
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 2f692ce..08ea735 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -1222,7 +1222,7 @@ static int tcp_check_dsack(struct sock *sk, struct sk_buff *ack_skb,
}
/* D-SACK for already forgotten data... Do dumb counting. */
- if (dup_sack &&
+ if (dup_sack && tp->undo_marker && tp->undo_retrans &&
!after(end_seq_0, prior_snd_una) &&
after(end_seq_0, tp->undo_marker))
tp->undo_retrans--;
@@ -1299,7 +1299,8 @@ static u8 tcp_sacktag_one(struct sk_buff *skb, struct sock *sk,
/* Account D-SACK for retransmitted packet. */
if (dup_sack && (sacked & TCPCB_RETRANS)) {
- if (after(TCP_SKB_CB(skb)->end_seq, tp->undo_marker))
+ if (tp->undo_marker && tp->undo_retrans &&
+ after(TCP_SKB_CB(skb)->end_seq, tp->undo_marker))
tp->undo_retrans--;
if (sacked & TCPCB_SACKED_ACKED)
state->reord = min(fack_count, state->reord);
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 406f320..dfa5beb 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -2162,7 +2162,7 @@ int tcp_retransmit_skb(struct sock *sk, struct sk_buff *skb)
if (!tp->retrans_stamp)
tp->retrans_stamp = TCP_SKB_CB(skb)->when;
- tp->undo_retrans++;
+ tp->undo_retrans += tcp_skb_pcount(skb);
/* snd_nxt is stored to detect loss of retransmitted segment,
* see tcp_input.c tcp_sacktag_write_queue().
--
1.7.3.1
^ permalink raw reply related
* Re: [PATCH v4 0/5] net: Unified offload configuration
From: David Miller @ 2011-02-07 22:52 UTC (permalink / raw)
To: mirq-linux; +Cc: netdev, bhutchings
In-Reply-To: <20110207224937.GA32549@rere.qmqm.pl>
From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Date: Mon, 7 Feb 2011 23:49:37 +0100
> What driver did you get this output from?
NIU, which sets NETIF_F_HW_CSUM in netdev->features, which is
absolutely correct.
^ 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