* Re: [PATCH 17/11]Optimize the upload speed for PPP connection.
From: David Miller @ 2009-11-17 9:22 UTC (permalink / raw)
To: huananhu; +Cc: netdev, linux-kernel, william.allen.simpson
In-Reply-To: <faf197be196ee.196eefaf197be@huawei.com>
From: fangxiaozhi 00110321 <huananhu@huawei.com>
Date: Tue, 17 Nov 2009 17:19:02 +0800
> From: fangxiaozhi <huananhu@huawei.com>
> 1. This patch is based on the kernel of 2.6.32-rc4
> 2. In this patch, we enlarge the out buffer size to optimize the upload speed for the ppp connection. Then it can support the upload of HSUPA data cards.
> Signed-off-by: fangxiaozhi <huananhu@huawei.com>
Your patch is broken, please don't wate my time like this.
+ git apply --check --whitespace=error-all diff
error: patch failed: drivers/net/ppp_async.c:36
error: drivers/net/ppp_async.c: patch does not apply
^ permalink raw reply
* Re: Shared i2c adapter locking
From: Jean Delvare @ 2009-11-17 9:35 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Ben Hutchings, David Miller, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-next-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Mika Kuoppala, Linux I2C
In-Reply-To: <20091117193313.b750804e.sfr-3FnU+UHB4dNDw9hX6IcOSA@public.gmane.org>
Hi Stephen,
On Tue, 17 Nov 2009 19:33:13 +1100, Stephen Rothwell wrote:
> Hi Jean,
>
> On Thu, 5 Nov 2009 15:07:15 +0100 Jean Delvare <khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org> wrote:
> >
> > > Presumably this is meant for net-next-2.6, and you'll implement
> >
> > Actually I meant to push this to Linus immediately, through my i2c
> > tree. This is essentially a no-op: the binary code will be the same as
> > before the patch, so guaranteed to be safe, and this will solve
> > conflicts in linux-next.
>
> Any word on this?
Haven't you read this:
http://www.spinics.net/lists/linux-next/msg07839.html
and the 3 following posts?
If you did and something is still not clear, please let me know. My
understanding is that the action token is in David's hands now.
--
Jean Delvare
^ permalink raw reply
* Re: [PATCH 17/11]Optimize the upload speed for PPP connection.
From: William Allen Simpson @ 2009-11-17 10:20 UTC (permalink / raw)
To: huananhu; +Cc: David Miller, netdev, linux-kernel
In-Reply-To: <20091117.012248.86306050.davem@davemloft.net>
David Miller wrote:
> Your patch is broken, please don't wate my time like this.
>
> + git apply --check --whitespace=error-all diff
> error: patch failed: drivers/net/ppp_async.c:36
> error: drivers/net/ppp_async.c: patch does not apply
>
What David may have meant, had he followed Documentation/ManagementStyle
or had any project management skills what-so-ever, is that you need to
follow Documentation/SubmittingPatches more carefully.
Look at 15) The canonical patch format
[PATCH 17/11] makes no sense, you don't have 11 patches, and the 17th
patch of 11 can never exist.
Need a better "subsystem: summary phrase", perhaps
"net: PPP buffer too small for higher speed connections"
A marker line containing simply "---".
And your trailer boilerplate badly breaks the system, because it's
missing the SMTP email standard "--" line in front of it.
You'll get nicer formatting with 'git format-patch -o ~ HEAD~1' after you
do a 'git commit -a' on your git tree.
It takes some time, even for a simple 1 line fix like this....
Hope that helps.
^ permalink raw reply
* Re: [net-next-2.6 PATCH v6 4/7 RFC] TCPCT part 1d: define TCP cookie option, extend existing struct's
From: William Allen Simpson @ 2009-11-17 10:41 UTC (permalink / raw)
To: David Miller; +Cc: eric.dumazet, netdev, joe
In-Reply-To: <20091116.191522.178198674.davem@davemloft.net>
David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Mon, 16 Nov 2009 23:26:04 +0100
>
>> So adding DATA to SYN packets might be problematic for part of our tcp stack.
>
But is outside the scope of anything in this part 1 patch series.
Of course, part 2 will dispense with the request_sock entirely....
> I can almost guarentee it won't work. For one thing getting a SACK
> response to a SYN+DATA packet will explode quite nicely for one thing.
>
Sounds like a lack of error handling to me.... Never trust that sensible
data will appear from the network!
> A lot of the other retransmit queue handling would need to be audited
> as well. So much code assumes that if we see sent data in the
> retransmit queue, there won't be SYN or SYN+ACK things in there to
> contend with.
>
Well then, it's a darn tootin' good thing that the code in part 1g doesn't
send SYNACK data in the retransmit queue, and the code in 1d (here) doesn't
include the SYNACK data in the tcp_minisocks.c clone. The prominent
comment might have been a sign to the careful reviewer:
+ * as it differs for each connection. There is no need to
+ * copy any s_data_payload stored at the original socket.
^ permalink raw reply
* Re: [PATCH 17/11]Optimize the upload speed for PPP connection.
From: Jarek Poplawski @ 2009-11-17 11:14 UTC (permalink / raw)
To: William Allen Simpson; +Cc: huananhu, David Miller, netdev, linux-kernel
In-Reply-To: <4B0278D9.6030806@gmail.com>
On 17-11-2009 11:20, William Allen Simpson wrote:
> David Miller wrote:
>> Your patch is broken, please don't wate my time like this.
>>
>> + git apply --check --whitespace=error-all diff
>> error: patch failed: drivers/net/ppp_async.c:36
>> error: drivers/net/ppp_async.c: patch does not apply
>>
> What David may have meant, had he followed Documentation/ManagementStyle
> or had any project management skills what-so-ever, is that you need to
> follow Documentation/SubmittingPatches more carefully.
I think this time it was only about a missing tab ;-)
Jarek P.
>
> Look at 15) The canonical patch format
>
> [PATCH 17/11] makes no sense, you don't have 11 patches, and the 17th
> patch of 11 can never exist.
>
> Need a better "subsystem: summary phrase", perhaps
> "net: PPP buffer too small for higher speed connections"
>
> A marker line containing simply "---".
>
> And your trailer boilerplate badly breaks the system, because it's
> missing the SMTP email standard "--" line in front of it.
>
> You'll get nicer formatting with 'git format-patch -o ~ HEAD~1' after you
> do a 'git commit -a' on your git tree.
>
> It takes some time, even for a simple 1 line fix like this....
>
> Hope that helps.
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* net-next-2.6 compilation errors: missing wireless/i82593.h
From: William Allen Simpson @ 2009-11-17 11:34 UTC (permalink / raw)
To: Linux Kernel Developers; +Cc: Linux Kernel Network Developers, John W. Linville
For the past 9-10 days, net-next-2.6 has failed to compile. In addition to
the errors and warnings already reported here last week, since Nov 12th
there has been another missing file. I kept hoping it was temporary, but
no joy.
/home/administer/net-next-2.6/drivers/net/znet.c:107:29: error: wireless/i82593.h: No such file or directory
/home/administer/net-next-2.6/drivers/net/znet.c:133: error: field ‘i593_init’ has incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c: In function ‘znet_set_multicast_list’:
/home/administer/net-next-2.6/drivers/net/znet.c:235: error: invalid application of ‘sizeof’ to incomplete type ‘struct i82593_conf_block’
/home/administer/net-next-2.6/drivers/net/znet.c:235: error: invalid application of ‘sizeof’ to incomplete type ‘struct i82593_conf_block’
/home/administer/net-next-2.6/drivers/net/znet.c:235: error: invalid application of ‘sizeof’ to incomplete type ‘struct i82593_conf_block’
/home/administer/net-next-2.6/drivers/net/znet.c:235: error: invalid application of ‘sizeof’ to incomplete type ‘struct i82593_conf_block’
/home/administer/net-next-2.6/drivers/net/znet.c:235: error: invalid application of ‘sizeof’ to incomplete type ‘struct i82593_conf_block’
/home/administer/net-next-2.6/drivers/net/znet.c:235: error: invalid application of ‘sizeof’ to incomplete type ‘struct i82593_conf_block’
/home/administer/net-next-2.6/drivers/net/znet.c:247: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:248: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:249: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:250: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:251: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:254: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:255: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:256: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:259: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:260: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:261: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:262: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:265: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:266: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:267: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:268: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:271: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:274: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:277: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:278: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:281: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:282: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:283: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:284: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:285: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:286: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:289: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:290: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:291: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:294: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:297: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:298: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:299: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:300: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:301: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:302: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:303: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:304: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:307: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:310: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:311: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:312: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:315: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:316: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:317: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:318: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:319: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:320: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:323: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:324: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:325: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:326: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:327: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:328: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:329: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:330: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:333: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:334: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:340: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:345: error: invalid application of ‘sizeof’ to incomplete type ‘struct i82593_conf_block’
/home/administer/net-next-2.6/drivers/net/znet.c:346: error: invalid application of ‘sizeof’ to incomplete type ‘struct i82593_conf_block’
/home/administer/net-next-2.6/drivers/net/znet.c:346: error: invalid application of ‘sizeof’ to incomplete type ‘struct i82593_conf_block’
/home/administer/net-next-2.6/drivers/net/znet.c:346: error: invalid application of ‘sizeof’ to incomplete type ‘struct i82593_conf_block’
/home/administer/net-next-2.6/drivers/net/znet.c:347: error: invalid application of ‘sizeof’ to incomplete type ‘struct i82593_conf_block’
/home/administer/net-next-2.6/drivers/net/znet.c:348: error: ‘OP0_CONFIGURE’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c:348: error: (Each undeclared identifier is reported only once
/home/administer/net-next-2.6/drivers/net/znet.c:348: error: for each function it appears in.)
/home/administer/net-next-2.6/drivers/net/znet.c:348: error: ‘CR0_CHNL’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c: In function ‘znet_tx_timeout’:
/home/administer/net-next-2.6/drivers/net/znet.c:512: error: ‘CR0_STATUS_0’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c:514: error: ‘CR0_STATUS_1’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c:516: error: ‘CR0_STATUS_2’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c:518: error: ‘CR0_STATUS_3’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c:522: error: ‘TX_LOST_CRS’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c:525: error: ‘OP0_RESET’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c: In function ‘znet_send_packet’:
/home/administer/net-next-2.6/drivers/net/znet.c:549: error: ‘CR0_STATUS_0’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c:583: error: ‘OP0_TRANSMIT’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c:583: error: ‘CR0_CHNL’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c: In function ‘znet_interrupt’:
/home/administer/net-next-2.6/drivers/net/znet.c:612: error: ‘CR0_STATUS_0’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c:617: error: ‘CR0_STATUS_1’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c:619: error: ‘CR0_STATUS_2’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c:621: error: ‘CR0_STATUS_3’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c:626: error: ‘SR0_INTERRUPT’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c:631: error: ‘SR0_EVENT_MASK’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c:631: error: ‘SR0_TRANSMIT_DONE’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c:632: error: ‘SR0_RETRANSMIT_DONE’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c:633: error: ‘SR0_TRANSMIT_NO_CRC_DONE’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c:638: error: ‘TX_OK’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c:640: error: ‘TX_NCOL_MASK’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c:642: error: ‘TX_LOST_CTS’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c:642: error: ‘TX_LOST_CRS’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c:644: error: ‘TX_UND_RUN’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c:646: error: ‘TX_HRT_BEAT’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c:648: error: ‘TX_MAX_COL’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c:666: error: ‘SR0_RECEPTION’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c:667: error: ‘SR0_STOP_REG_HIT’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c:671: error: ‘CR0_INT_ACK’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c: In function ‘znet_rx’:
/home/administer/net-next-2.6/drivers/net/znet.c:688: error: ‘CR0_STATUS_2’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c:747: error: ‘RX_RCV_OK’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c:749: error: ‘RX_CRC_ERR’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c:750: error: ‘RX_ALG_ERR’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c:756: error: ‘RX_OVRRUN’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c:758: error: ‘RX_SRT_FRM’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c: In function ‘znet_close’:
/home/administer/net-next-2.6/drivers/net/znet.c:814: error: ‘OP0_RESET’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c: In function ‘hardware_init’:
/home/administer/net-next-2.6/drivers/net/znet.c:859: error: ‘OP0_RESET’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c:885: error: ‘OP0_CONFIGURE’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c:885: error: ‘CR0_CHNL’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c:893: error: ‘OP0_IA_SETUP’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c:898: error: ‘OP0_RCV_ENABLE’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c: In function ‘update_stop_hit’:
/home/administer/net-next-2.6/drivers/net/znet.c:904: error: ‘OP0_SWIT_TO_PORT_1’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c:904: error: ‘CR0_CHNL’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c:907: error: ‘CR1_STOP_REG_UPDATE’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c:909: error: ‘OP1_SWIT_TO_PORT_0’ undeclared (first use in this function)
make[3]: *** [drivers/net/znet.o] Error 1
make[3]: *** Waiting for unfinished jobs....
make[2]: *** [drivers/net] Error 2
make[1]: *** [drivers] Error 2
make: *** [sub-make] Error 2
^ permalink raw reply
* Re: net-next-2.6 compilation errors: missing wireless/i82593.h
From: David Miller @ 2009-11-17 11:44 UTC (permalink / raw)
To: william.allen.simpson; +Cc: linux-kernel, netdev, linville
In-Reply-To: <4B028A37.1010202@gmail.com>
From: William Allen Simpson <william.allen.simpson@gmail.com>
Date: Tue, 17 Nov 2009 06:34:15 -0500
> For the past 9-10 days, net-next-2.6 has failed to compile. In
> addition to the errors and warnings already reported here last week,
Those seemed to be for Android drivers and such, so I hope you
reported those failures to the driver maintainers as well as
linux-kernel.
For the time being could you just disable those drivers in your
build just to get work done or do you absolutely need them?
> since Nov 12th there has been another missing file. I kept hoping
> it was temporary, but no joy.
>
> /home/administer/net-next-2.6/drivers/net/znet.c:107:29: error:
> wireless/i82593.h: No such file or directory
That header file got moved out to drivers/staging along with the
wavelan driver.
The header file should instead be moved to, perhaps, include/linux
while there are still other users of it.
That's incredibly clumsy what drivers/net/znet.c is doing.
John please fix this up, thanks!
^ permalink raw reply
* Re: [PATCH 17/11]Optimize the upload speed for PPP connection.
From: William Allen Simpson @ 2009-11-17 11:49 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: huananhu, David Miller, netdev, linux-kernel
In-Reply-To: <20091117111454.GA8341@ff.dom.local>
Jarek Poplawski wrote:
> On 17-11-2009 11:20, William Allen Simpson wrote:
>> David Miller wrote:
>>> Your patch is broken, please don't wate my time like this.
>>>
>>> + git apply --check --whitespace=error-all diff
>>> error: patch failed: drivers/net/ppp_async.c:36
>>> error: drivers/net/ppp_async.c: patch does not apply
>>>
>> What David may have meant, had he followed Documentation/ManagementStyle
>> or had any project management skills what-so-ever, is that you need to
>> follow Documentation/SubmittingPatches more carefully.
>
> I think this time it was only about a missing tab ;-)
>
In his inimitable inimical manner, comprehensively comprehensible. ;-)
^ permalink raw reply
* Re: [PATCH 17/11]Optimize the upload speed for PPP connection.
From: David Miller @ 2009-11-17 11:49 UTC (permalink / raw)
To: william.allen.simpson; +Cc: huananhu, netdev, linux-kernel
In-Reply-To: <4B0278D9.6030806@gmail.com>
From: William Allen Simpson <william.allen.simpson@gmail.com>
Date: Tue, 17 Nov 2009 05:20:09 -0500
> What David may have meant, had he followed
> Documentation/ManagementStyle or had any project management skills
> what-so-ever, is that you need to follow
> Documentation/SubmittingPatches more carefully.
Are personal attacks on me really necessary?
Do you want me to look closely at your patches with a high priority
when you submit them for inclusion? If so, then you may want to
think twice about saying things like this.
You may be right, but that doesn't matter if you're interested in
working together with me in the future. There are diplomatic ways to
do everything, and this wasn't one of those ways.
^ permalink raw reply
* Re: Shared i2c adapter locking
From: David Miller @ 2009-11-17 11:51 UTC (permalink / raw)
To: khali
Cc: sfr, bhutchings, netdev, linux-next, linux-kernel, mika.kuoppala,
linux-i2c
In-Reply-To: <20091117103554.03971b2f@hyperion.delvare>
From: Jean Delvare <khali@linux-fr.org>
Date: Tue, 17 Nov 2009 10:35:54 +0100
> If you did and something is still not clear, please let me know. My
> understanding is that the action token is in David's hands now.
So what exactly do I need to do?
All I see that needs to happen is to pull from Linus's tree into
net-2.6
But frankly I don't see how that helps resolve anything in linux-next
since Stephen starts with Linus's tree then pulls in everyone's work.
Or is that pull necessary so that some other patch can be applied
to net-2.6 or similar?
^ permalink raw reply
* Re: updates to the mscan-driver in net-next
From: David Miller @ 2009-11-17 11:54 UTC (permalink / raw)
To: w.sang; +Cc: netdev, linuxppc-dev, socketcan-core, grant.likely, wg
In-Reply-To: <1258412274-14686-1-git-send-email-w.sang@pengutronix.de>
From: Wolfram Sang <w.sang@pengutronix.de>
Date: Mon, 16 Nov 2009 23:57:43 +0100
> here are the patches which fix the issues for the mscan & mpc52xx_can drivers
> raised by Wolfgang Grandegger and Grant Likely. They are based on the initial
> version of the drivers I sent a few days ago. Devicetree-discuss has been added
> for the property changes. I will also update my branch on pengutronix.de
> tomorrow, I seem to have issues when trying that from home :(^
All applied to net-next-2.6, thank you.
^ permalink raw reply
* Re: [PATCH 17/11]Optimize the upload speed for PPP connection.
From: Franko Fang @ 2009-11-17 11:54 UTC (permalink / raw)
To: Jarek Poplawski, William Allen Simpson; +Cc: David Miller, netdev, linux-kernel
In-Reply-To: <20091117111454.GA8341@ff.dom.local>
Well, yes, I think that it misses the tab.
I will update the patch, and resubmit it again.
Thanks for all .
----- Original Message -----
From: "Jarek Poplawski" <jarkao2@gmail.com>
To: "William Allen Simpson" <william.allen.simpson@gmail.com>
Cc: <huananhu@huawei.com>; "David Miller" <davem@davemloft.net>; <netdev@vger.kernel.org>; <linux-kernel@vger.kernel.org>
Sent: Tuesday, November 17, 2009 7:14 PM
Subject: Re: [PATCH 17/11]Optimize the upload speed for PPP connection.
> On 17-11-2009 11:20, William Allen Simpson wrote:
>> David Miller wrote:
>>> Your patch is broken, please don't wate my time like this.
>>>
>>> + git apply --check --whitespace=error-all diff
>>> error: patch failed: drivers/net/ppp_async.c:36
>>> error: drivers/net/ppp_async.c: patch does not apply
>>>
>> What David may have meant, had he followed Documentation/ManagementStyle
>> or had any project management skills what-so-ever, is that you need to
>> follow Documentation/SubmittingPatches more carefully.
>
> I think this time it was only about a missing tab ;-)
>
> Jarek P.
>
>>
>> Look at 15) The canonical patch format
>>
>> [PATCH 17/11] makes no sense, you don't have 11 patches, and the 17th
>> patch of 11 can never exist.
>>
>> Need a better "subsystem: summary phrase", perhaps
>> "net: PPP buffer too small for higher speed connections"
>>
>> A marker line containing simply "---".
>>
>> And your trailer boilerplate badly breaks the system, because it's
>> missing the SMTP email standard "--" line in front of it.
>>
>> You'll get nicer formatting with 'git format-patch -o ~ HEAD~1' after you
>> do a 'git commit -a' on your git tree.
>>
>> It takes some time, even for a simple 1 line fix like this....
>>
>> Hope that helps.
>> --
>> 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
>>
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* [PATCH 1/5]net: PPP buffer too small for higher speed connections
From: fangxiaozhi 00110321 @ 2009-11-17 11:59 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel, william.allen.simpson, jarkao2
From: fangxiaozhi <huananhu@huawei.com>
1. This patch is based on the kernel of 2.6.32-rc7
2. In this patch, we enlarge the out buffer size to optimize the upload speed for the ppp connection. Then it can support the upload of HSUPA data cards.
Signed-off-by: fangxiaozhi <huananhu@huawei.com>
-----------------------------------------------------------------------------------------
--- a/drivers/net/ppp_async.c 2009-10-12 05:43:56.000000000 +0800
+++ b/drivers/net/ppp_async.c 2009-10-15 16:29:56.000000000 +0800
@@ -36,7 +36,7 @@
#define PPP_VERSION "2.4.2"
-#define OBUFSIZE 256
+#define OBUFSIZE 4096
/* Structure for storing local state. */
struct asyncppp {
******************************************************************************************
This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained here in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email
immediately and delete it!
*****************************************************************************************
^ permalink raw reply
* Re: net-next-2.6 compilation errors: missing wireless/i82593.h
From: William Allen Simpson @ 2009-11-17 11:59 UTC (permalink / raw)
To: David Miller; +Cc: linux-kernel, netdev, linville
In-Reply-To: <20091117.034428.47467823.davem@davemloft.net>
David Miller wrote:
> From: William Allen Simpson <william.allen.simpson@gmail.com>
> Date: Tue, 17 Nov 2009 06:34:15 -0500
>
>> For the past 9-10 days, net-next-2.6 has failed to compile. In
>> addition to the errors and warnings already reported here last week,
>
> Those seemed to be for Android drivers and such, so I hope you
> reported those failures to the driver maintainers as well as
> linux-kernel.
>
I did, at least some of them. Nothing seems to have been fixed yet.
> For the time being could you just disable those drivers in your
> build just to get work done or do you absolutely need them?
>
I did, at least some of them. Of course, since I'm making changes to
linux/tcp.h and net/tcp.h, an awful lot of drivers seem to include them
one way or another, and I'm trying to ensure nothing breaks (at least
for compilation purposes).
>> since Nov 12th there has been another missing file. I kept hoping
>> it was temporary, but no joy.
>>
>> /home/administer/net-next-2.6/drivers/net/znet.c:107:29: error:
>> wireless/i82593.h: No such file or directory
>
> That header file got moved out to drivers/staging along with the
> wavelan driver.
>
Too bad that CONFIG_STAGING "N" (# CONFIG_STAGING is not set) doesn't
actually turn off all the staging....
> John please fix this up, thanks!
>
Please.
^ permalink raw reply
* Re: [PATCH 1/5]net: PPP buffer too small for higher speed connections
From: David Miller @ 2009-11-17 12:02 UTC (permalink / raw)
To: huananhu; +Cc: netdev, linux-kernel, william.allen.simpson, jarkao2
In-Reply-To: <fb8cc3511cffa.1cffafb8cc351@huawei.com>
From: fangxiaozhi 00110321 <huananhu@huawei.com>
Date: Tue, 17 Nov 2009 19:59:05 +0800
> From: fangxiaozhi <huananhu@huawei.com>
> 1. This patch is based on the kernel of 2.6.32-rc7
> 2. In this patch, we enlarge the out buffer size to optimize the upload speed for the ppp connection. Then it can support the upload of HSUPA data cards.
> Signed-off-by: fangxiaozhi <huananhu@huawei.com>
Applied to net-next-2.6, thanks.
^ permalink raw reply
* Re: [PATCH 1/5]net: PPP buffer too small for higher speed connections
From: Franko Fang @ 2009-11-17 12:04 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-kernel, william.allen.simpson, jarkao2
In-Reply-To: <20091117.040234.245024359.davem@davemloft.net>
Well, that's great.
Thanks very much for your help.
----- Original Message -----
From: "David Miller" <davem@davemloft.net>
To: <huananhu@huawei.com>
Cc: <netdev@vger.kernel.org>; <linux-kernel@vger.kernel.org>; <william.allen.simpson@gmail.com>; <jarkao2@gmail.com>
Sent: Tuesday, November 17, 2009 8:02 PM
Subject: Re: [PATCH 1/5]net: PPP buffer too small for higher speed connections
> From: fangxiaozhi 00110321 <huananhu@huawei.com>
> Date: Tue, 17 Nov 2009 19:59:05 +0800
>
>> From: fangxiaozhi <huananhu@huawei.com>
>> 1. This patch is based on the kernel of 2.6.32-rc7
>> 2. In this patch, we enlarge the out buffer size to optimize the upload speed for the ppp connection. Then it can support the upload of HSUPA data cards.
>> Signed-off-by: fangxiaozhi <huananhu@huawei.com>
>
> Applied to net-next-2.6, thanks.
^ permalink raw reply
* Re: [PATCH] net: fix mdio section mismatch warning
From: David Miller @ 2009-11-17 12:06 UTC (permalink / raw)
To: sfr; +Cc: netdev, laurentp, paulius.zaleckas, mware
In-Reply-To: <20091117194733.bd2308a8.sfr@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 17 Nov 2009 19:47:33 +1100
> This fixes the following warning:
>
> WARNING: drivers/net/phy/built-in.o(.devexit.text+0x70): Section mismatch in reference from the function .mdio_gpio_bus_destroy() to the function .devinit.text:.mdio_gpio_bus_deinit()
> The function __devexit .mdio_gpio_bus_destroy() references
> a function __devinit .mdio_gpio_bus_deinit().
> This is often seen when error handling in the exit function
> uses functionality in the init path.
> The fix is often to remove the __devinit annotation of
> .mdio_gpio_bus_deinit() so it may be used outside an init section.
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Applied to net-2.6, thanks Stephen.
I wish there was a better way to handle this kind of situation as it's
a quite common pattern (exit cleanup function used by device init
functions) because currently we end up not being able to put such
things into either init or exit sections.
^ permalink raw reply
* Re: [net-next-2.6 PATCH v6 4/7 RFC] TCPCT part 1d: define TCP cookie option, extend existing struct's
From: Ilpo Järvinen @ 2009-11-17 12:07 UTC (permalink / raw)
To: Eric Dumazet
Cc: William Allen Simpson, Linux Kernel Network Developers,
Joe Perches
In-Reply-To: <4B01D17C.4010407@gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1077 bytes --]
On Mon, 16 Nov 2009, Eric Dumazet wrote:
> William Allen Simpson a écrit :
> > Eric Dumazet wrote:
> >
> >> I remember a previous remark from David that our skb queues would not
> >> contain
> >> DATA on SYN packets...
> >>
> > I haven't seen anything by David, but there's an existing comment in
> > tcp_input.c at the place where SYN data will be added later:
> >
>
> Yep, David comment was about another netdev thread, while tracking an
> obscure bug
>
> http://www.spinics.net/lists/netdev/msg110759.html
>
> http://www.spinics.net/lists/netdev/msg110764.html
>
>
> So adding DATA to SYN packets might be problematic for part of our tcp
> stack.
You both are right (and that's what is causing confusion)... What DaveM
said is this:
"And we're only dealing with data packets once we enter established
state, and when we enter established by definition we have unlinked
and freed up any SYN and SYN+ACK SKBs in the write queue."
We certainly can have SYN/SYNACKs in write queue but not in certain
states, and consequently, not in certain functions.
--
i.
^ permalink raw reply
* Re: [net-next] bnx2x: Handle Rx and Tx together in NAPI
From: David Miller @ 2009-11-17 12:08 UTC (permalink / raw)
To: vladz; +Cc: netdev, eilong
In-Reply-To: <1258387558.30637.77.camel@lb-tlvb-vladz.il.broadcom.com>
From: "Vladislav Zolotarov" <vladz@broadcom.com>
Date: Mon, 16 Nov 2009 18:05:58 +0200
> Put Tx and Rx DPC to be handled in the NAPI:
> - Saves status blocks.
> - Moves the Tx work from hardIRQ to NAPI.
>
> Signed-off-by: Vladislav Zolotarov <vladz@broadcom.com>
> Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
Applied, thank you.
^ permalink raw reply
* Re: netlink: remove subscriptions check on notifier
From: David Miller @ 2009-11-17 12:09 UTC (permalink / raw)
To: johannes; +Cc: netdev, kaber
In-Reply-To: <1258409134.1375.0.camel@johannes.local>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Mon, 16 Nov 2009 23:05:34 +0100
> The netlink URELEASE notifier doesn't notify for
> sockets that have been used to receive multicast
> but it should be called for such sockets as well
> since they might _also_ be used for sending and
> not solely for receiving multicast. We will need
> that for nl80211 (generic netlink sockets) in the
> future.
>
> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Applied, let's see what this breaks :-)
^ permalink raw reply
* Re: [PATCH 2.6.32-rc3] net: Getting rid of the x86 dependency to built vmxnet3
From: David Miller @ 2009-11-17 12:09 UTC (permalink / raw)
To: sbhatewara; +Cc: netdev, pv-drivers, linux-kernel
In-Reply-To: <alpine.LRH.2.00.0911161053050.23246@sbhatewara-dev1.eng.vmware.com>
From: Shreyas Bhatewara <sbhatewara@vmware.com>
Date: Mon, 16 Nov 2009 15:41:33 -0800 (PST)
>
> Getting rid of the x86 dependency to built vmxnet3
>
> From: Shreyas Bhatewara <sbhatewara@vmware.com>
>
> This patch removes config dependency on x86 to build vmxnet3 driver. Thus
> the driver can be built on big endian architectures now. Although vmxnet3
> is not supported on VMs other than x86 architecture, all this code goes in
> to ensure correctness. If the code is not dependent on x86, it should not
> assume little endian architecture in any of its operations.
>
> Signed-off-by: Shreyas Bhatewara <sbhatewara@vmware.com>
Patch applied, thanks for following up on this.
^ permalink raw reply
* Re: [PATCH net-next] Phonet: missing rcu_dereference()
From: David Miller @ 2009-11-17 12:09 UTC (permalink / raw)
To: remi; +Cc: netdev, remi.denis-courmont
In-Reply-To: <1258445844-6079-1-git-send-email-remi@remlab.net>
From: Rémi Denis-Courmont <remi@remlab.net>
Date: Tue, 17 Nov 2009 10:17:24 +0200
> From: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
>
> Reported-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> Signed-off-by: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
Applied, thank you.
^ permalink raw reply
* Re: net-next-2.6 compilation errors: missing wireless/i82593.h
From: Alan Cox @ 2009-11-17 12:13 UTC (permalink / raw)
To: William Allen Simpson; +Cc: David Miller, linux-kernel, netdev, linville
In-Reply-To: <4B029012.6030202@gmail.com>
> >> /home/administer/net-next-2.6/drivers/net/znet.c:107:29: error:
> >> wireless/i82593.h: No such file or directory
> >
> > That header file got moved out to drivers/staging along with the
> > wavelan driver.
> >
> Too bad that CONFIG_STAGING "N" (# CONFIG_STAGING is not set) doesn't
> actually turn off all the staging....
It does - that isn't the problem. Someone moves shared header files out
of the right directory into staging without double checking (lxr is
rather handy..)
Alan
^ permalink raw reply
* Re: [PATCH 1/2] act_mirred: cleanup
From: David Miller @ 2009-11-17 12:15 UTC (permalink / raw)
To: xiaosuo; +Cc: hadi, shemminger, netdev
In-Reply-To: <412e6f7f0911162148g72eb3749g860e476b7b5f3ab6@mail.gmail.com>
From: Changli Gao <xiaosuo@gmail.com>
Date: Tue, 17 Nov 2009 13:48:06 +0800
> Patch is resubmitted as attachment.
That's a lot better, applied.
^ permalink raw reply
* Re: [PATCH 2/2] act_mirred: optimization
From: David Miller @ 2009-11-17 12:16 UTC (permalink / raw)
To: xiaosuo; +Cc: hadi, shemminger, netdev
In-Reply-To: <412e6f7f0911162149q1eedf18vfbf980fc690629f5@mail.gmail.com>
From: Changli Gao <xiaosuo@gmail.com>
Date: Tue, 17 Nov 2009 13:49:00 +0800
> On Mon, Nov 16, 2009 at 9:33 PM, David Miller <davem@davemloft.net> wrote:
>> From: Changli Gao <xiaosuo@gmail.com>
>> Date: Mon, 16 Nov 2009 21:22:46 +0800
>>
>>> I am working against linux-next. I'll check if there is any
>>> difference. BTW: were these patches applied in order, 1 - 2?
>>
>> Yes, they were.
>>
>
> Patch is resubmitted as attachment.
Also applied, thanks.
^ 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