ax88796: add superh to kconfig dependencies

ax88796: add superh to kconfig dependencies This patch adds sh architecture support to the ax88796 kconfig. Signed-off-by: Magnus Damm <[EMAIL PROTECTED]> --- This patch was posted about a month ago but never picked up: http://www.mail-archive.com/netdev@vger.kernel.org/msg50018.html The rest

Question about the email about "[PATCH 2/3] IPV6: unify 3 similar code path in ndisc_recv_ns()"

Dear David S. Miller : Happy to write to you. In the email <[EMAIL PROTECTED] > >, yoshfuji unified 3 similar code patch in ndisc_recv_ns(). I have a question about the "flags sent with NA in reply to this NS" . In the kernel 2.4.21,

Re: build #337 failed for 2.6.24-rc1-gb1d08ac In function `usbnet_set_settings':

On Wed, Nov 07, 2007 at 11:52:32PM +0100, Adrian Bunk wrote: > On Wed, Nov 07, 2007 at 02:34:52PM -0800, David Brownell wrote: > > > > But on the other hand, it seems that only the ASIX code will work > > > > right; the DM9601 and MCS7830 Kconfig is different/wrong. > > > > > > I'm not seeing the

Re: build #337 failed for 2.6.24-rc1-gb1d08ac In function `usbnet_set_settings':

On Wed, Nov 07, 2007 at 06:53:48PM -0800, David Brownell wrote: > On Wednesday 07 November 2007, Adrian Bunk wrote: > > On Wed, Nov 07, 2007 at 02:34:52PM -0800, David Brownell wrote: > > > > > But on the other hand, it seems that only the ASIX code will work > > > > > right; the DM9601 and MCS7830

Re: build #337 failed for 2.6.24-rc1-gb1d08ac In function `usbnet_set_settings':

On Wednesday 07 November 2007, Adrian Bunk wrote: > On Wed, Nov 07, 2007 at 02:34:52PM -0800, David Brownell wrote: > > > > But on the other hand, it seems that only the ASIX code will work > > > > right; the DM9601 and MCS7830 Kconfig is different/wrong. > > > > > > I'm not seeing the problem. >

Please pull 'fixes-davem' branch of wireless-2.6 (this time for real!)

On Wed, Nov 07, 2007 at 04:32:00PM -0800, David Miller wrote: > From: "John W. Linville" <[EMAIL PROTECTED]> > Date: Wed, 7 Nov 2007 13:51:54 -0500 > > > Hold-off on this one for now if -- clearly Johannes and I need to > > brush-up on our Kconfig skills... :-( > > > > I'll post a new pull reques

Please pull 'fixes-jgarzik' branch of wireless-2.6 (this time for real!)

On Wed, Nov 07, 2007 at 02:24:19PM -0500, Jeff Garzik wrote: > On Wed, Nov 07, 2007 at 02:13:29PM -0500, John W. Linville wrote: > > Jeff, > > > > If you haven't already pulled this then please hold-off. I'll post > > a new request soon. > > Haven't pulled yet... Jeff, These fixes are additive

Re: build #337 failed for 2.6.24-rc1-gb1d08ac In function `usbnet_set_settings':

On Wed, Nov 07, 2007 at 02:34:52PM -0800, David Brownell wrote: > > > But on the other hand, it seems that only the ASIX code will work > > > right; the DM9601 and MCS7830 Kconfig is different/wrong. > > > > I'm not seeing the problem. > > > > Which configuration will be handled wrongly? > > Not

Re: [PATCH 2/2]: e1000: avoid lockup durig error recovery

On Wed, 07 Nov 2007 14:45:18 -0800 "Kok, Auke" <[EMAIL PROTECTED]> wrote: > [adding netdev, jeff G to the Cc] > > Linas Vepstas wrote: > > On Wed, Nov 07, 2007 at 01:50:17PM -0800, Kok, Auke wrote: > >> Linas Vepstas wrote: > >>> If a PCI bus error is encountered during device open, the > >>> err

RE: [PATCH 01/05] ipv6: RFC4214 Support (2)

I apologize for this, but it appears that my mailer is still inserting line breaks where it shouldn't; please disregard. Can anyone advise on how to configure Microsoft Office so that the line breaks do not occur? Thanks - Fred [EMAIL PROTECTED] > -Original Message- > From: Templin, Fred

Re: [PATCH 01/05] ipv6: RFC4214 Support (2)

On Wed, 7 Nov 2007 17:08:50 -0800 "Templin, Fred L" <[EMAIL PROTECTED]> wrote: > > From: Fred L. Templin <[EMAIL PROTECTED]> > > This is experimental support for the Intra-Site Automatic > Tunnel Addressing Protocol (ISATAP) per RFC4214. It uses > the SIT module, and is configured using the unm

[PATCH 01/05] ipv6: RFC4214 Support (2)

From: Fred L. Templin <[EMAIL PROTECTED]> This is experimental support for the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) per RFC4214. It uses the SIT module, and is configured using the unmodified "ip" utility with device names beginning with: "isatap". The following diffs are sp

Re: [PATCH 13/24] [IPSEC]: Move x->outer_mode->output out of locked section

On Wed, Nov 07, 2007 at 05:17:42PM +0100, Ingo Oeser wrote: > Hi Herbert, > > Herbert Xu schrieb: > > diff --git a/net/ipv6/xfrm6_mode_ro.c b/net/ipv6/xfrm6_mode_ro.c > > index a7bc8c6..4a01cb3 100644 > > --- a/net/ipv6/xfrm6_mode_ro.c > > +++ b/net/ipv6/xfrm6_mode_ro.c > > @@ -53,7 +54,9 @@ stati

Re: Please pull 'fixes-davem' branch of wireless-2.6

From: "John W. Linville" <[EMAIL PROTECTED]> Date: Wed, 7 Nov 2007 13:51:54 -0500 > Hold-off on this one for now if -- clearly Johannes and I need to > brush-up on our Kconfig skills... :-( > > I'll post a new pull request soon. Ok. - To unsubscribe from this list: send the line "unsubscribe net

Re: [PATCH] NET: Remove unneeded type cast in skb_truesize_check()

From: Chuck Lever <[EMAIL PROTECTED]> Date: Wed, 07 Nov 2007 10:11:28 -0500 > The (int) type cast in that assertion is nothing more than a comment. > The compiler promotes that side of the comparison to match the type on > the right side, and the explicit type cast is entirely ignored. So in >

Re: net: skge breakage on 2.6.24-rc1

On Wed, Nov 07, 2007 at 03:06:21PM -0800, Andrew Morton wrote: > > On Wed, 7 Nov 2007 23:50:30 +0100 "Rafael J. Wysocki" <[EMAIL PROTECTED]> > > wrote: > > On Wednesday, 7 of November 2007, Heikki Orsila wrote: > > > On Wed, Nov 07, 2007 at 11:46:21PM +0200, Heikki Orsila wrote: > > > > After some

Re: [PATCH 2/2]: e1000: avoid lockup durig error recovery

On Wed, Nov 07, 2007 at 02:45:18PM -0800, Kok, Auke wrote: > [adding netdev, jeff G to the Cc] > > Linas Vepstas wrote: > > On Wed, Nov 07, 2007 at 01:50:17PM -0800, Kok, Auke wrote: > >> Linas Vepstas wrote: > >>> If a PCI bus error is encountered during device open, the > >>> error recovery rout

Re: net: skge breakage on 2.6.24-rc1

> On Wed, 7 Nov 2007 23:50:30 +0100 "Rafael J. Wysocki" <[EMAIL PROTECTED]> > wrote: > On Wednesday, 7 of November 2007, Heikki Orsila wrote: > > On Wed, Nov 07, 2007 at 11:46:21PM +0200, Heikki Orsila wrote: > > > After some bisecting, I found that net skge driver broke on > > > > > > commit 7fb

Re: [PATCH 2/2]: e1000: avoid lockup durig error recovery

[adding netdev, jeff G to the Cc] Linas Vepstas wrote: > On Wed, Nov 07, 2007 at 01:50:17PM -0800, Kok, Auke wrote: >> Linas Vepstas wrote: >>> If a PCI bus error is encountered during device open, the >>> error recovery routines will attempt to close the device. >>> If napi has not yet been enabl

Re: build #337 failed for 2.6.24-rc1-gb1d08ac In function `usbnet_set_settings':

> > But on the other hand, it seems that only the ASIX code will work > > right; the DM9601 and MCS7830 Kconfig is different/wrong. > > I'm not seeing the problem. > > Which configuration will be handled wrongly? Notice how only the ASIX kconfig depended on NET_ETHERNET... since MII depends on N

Re: [2.6 patch] usbnet.c: check for the right MII variable

On Friday 02 November 2007, Adrian Bunk wrote: > <-- snip --> > > > This patch fixes the following compile error with CONFIG_MII=m, > CONFIG_USB_USBNET=y, CONFIG_USB_USBNET_MII=n: This is the patch I liked better, if there was going to be one going upstream without additional test from me ...

Re: build #337 failed for 2.6.24-rc1-gb1d08ac In function `usbnet_set_settings':

On Wednesday 07 November 2007, David Miller wrote: > David, I hate to say this and point you out like this, but you are a > real cancer for bug fixes to USB things in the kernel, You didn't hate it enough to find a way to deal with your issue that doesn't involve namecalling or other flamage, I'll

Re: [PATCH] PCI: export pci_restore_msi_state()

Hi, On Wed, Nov 07, 2007 at 03:43:59PM -0600, Linas Vepstas wrote: > > PCI error recovery usually involves the PCI adapter being reset. > If the device is using MSI, the reset will cause the MSI state > to be lost; the device driver needs to restore the MSI state. > > The pci_restore_msi_state(

[PATCH 2/2] qla3xxx: bugfix: Fix bad logical operation in link state machine.

Luckily, this wasn't reported or reproduced. The logical operation for setting duplex had wrong grouping. Signed-off-by: Ron Mercer <[EMAIL PROTECTED]> --- drivers/net/qla3xxx.c | 15 +-- 1 files changed, 5 insertions(+), 10 deletions(-) diff --git a/drivers/net/qla3xxx.c b/drivers

[PATCH 1/2] qla3xxx: bugfix: Move link state machine into a worker thread

The link state machine requires access to some resources that are shared with the iSCSI function on the chip. (See iSCSI driver at drivers/scsi/qla4xxx) If the interface is being up/downed at a rapid pace this driver may need to sleep waiting to get access to the common resources. For this we are

[PATCH 0/2] qla3xxx: bugfixes to link management.

Hi Jeff, The attached two patches fix a couple of problems in the link management. Built and tested on today's netdev/upstream. Regards, Ron Mercer Signed-off-by: Ron Mercer <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAI

[PATCH] PCI: export pci_restore_msi_state()

PCI error recovery usually involves the PCI adapter being reset. If the device is using MSI, the reset will cause the MSI state to be lost; the device driver needs to restore the MSI state. The pci_restore_msi_state() routine is currently protected by CONFIG_PM; remove this, and also export the

Re: [PATCH] Read back MSI message in rtas_setup_msi_irqs() so restore works

On Tue, Oct 23, 2007 at 02:23:44PM +1000, Michael Ellerman wrote: > There are plans afoot to use pci_restore_msi_state() to restore MSI > state after a device reset. In order for this to work for the RTAS MSI > backend, we need to read back the MSI message from config space after > it has been setu

Re: 2.6.23.1-smp kernel panic (network-related)

(cc netdev) > On Wed, 7 Nov 2007 17:52:11 +0100 Marek Kierdelewicz <[EMAIL PROTECTED]> > wrote: > Hi there, > > My company's (ISP) bussines model requires dynamic resizing of the > client queues. It's achieved by regenerating shaping rules and loading > then using batch mode of a tc binary. On p

Re: Why does a connect to IPv6 LLA address fail ?

Jiri Bohac wrote: > Hi, > >> For this it create a socket for datagram and >> protocol IPPROTO_IP and then try to connect it with the destination >> address. This fails in the case of a LLA, because connect returns EINVAL, >> since here is no device bind to this socket at this time. > > [snip] >

Re: [PATCH 02/05] ipv6: RFC4214 Support

In article <[EMAIL PROTECTED]> (at Wed, 7 Nov 2007 10:52:47 -0800), "Templin, Fred L" <[EMAIL PROTECTED]> says: > > > > > > + if (((ipv4 >= 0x0100) && (ipv4 < 0x0a00)) || > > > > > > + ((ipv4 >= 0x0b00) && (ipv4 < 0x7f00)) || > > > > > > + ((ipv4 >= 0x8000) && (i

Re: [PATCH 02/05] ipv6: RFC4214 Support

On 07/11/07 19:32, Templin, Fred L wrote: > > >> -Original Message- >> From: Simon Arlott [mailto:[EMAIL PROTECTED] >> Sent: Wednesday, November 07, 2007 11:02 AM >> To: Templin, Fred L >> Cc: YOSHIFUJI Hideaki / 吉藤英明; [EMAIL PROTECTED]; netdev@vger.kernel.org >> Subject: Re: [PATCH 02/

RE: [PATCH 02/05] ipv6: RFC4214 Support

> -Original Message- > From: Simon Arlott [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 07, 2007 11:02 AM > To: Templin, Fred L > Cc: YOSHIFUJI Hideaki / 吉藤英明; [EMAIL PROTECTED]; netdev@vger.kernel.org > Subject: Re: [PATCH 02/05] ipv6: RFC4214 Support > > On 07/11/07 18:52, Te

Re: Please pull 'fixes-jgarzik' branch of wireless-2.6

On Wed, Nov 07, 2007 at 02:13:29PM -0500, John W. Linville wrote: > Jeff, > > If you haven't already pulled this then please hold-off. I'll post > a new request soon. Haven't pulled yet... Jeff - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a messa

[PATCH 1/1] [INET]: Remove leftover prototypes from include/net/inet_common.h

Signed-off-by: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]> --- include/net/inet_common.h |4 1 files changed, 0 insertions(+), 4 deletions(-) diff --git a/include/net/inet_common.h b/include/net/inet_common.h index 227adcb..38d5a1e 100644 --- a/include/net/inet_common.h +++ b/include/ne

Re: Please pull 'fixes-jgarzik' branch of wireless-2.6

Jeff, If you haven't already pulled this then please hold-off. I'll post a new request soon. Thanks, John On Tue, Nov 06, 2007 at 03:07:00PM -0500, John W. Linville wrote: > Jeff, > > Here are a few fixes for 2.6.24. The iwlwifi "is_power_of_2" patch is > a little questionable as a fix. But

RE: [PATCH 04/05] ipv6: RFC4214 Support

> -Original Message- > From: Stephen Hemminger [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 07, 2007 10:45 AM > To: Templin, Fred L > Cc: YOSHIFUJI Hideaki / 吉藤英明; netdev@vger.kernel.org > Subject: Re: [PATCH 04/05] ipv6: RFC4214 Support > > On Wed, 7 Nov 2007 10:41:49 -0800 >

Re: [PATCH 02/05] ipv6: RFC4214 Support

On 07/11/07 18:52, Templin, Fred L wrote: >> > > > > +eui[0] = 0; >> > > > > + >> > > > > +/* Check for RFC3330 global address ranges */ >> > > > > +if (((ipv4 >= 0x0100) && (ipv4 < 0x0a00)) || >> > > > > +((ipv4 >= 0x0b00) && (ipv4 < 0x7f00)) || >> > > > > +

RE: [PATCH 02/05] ipv6: RFC4214 Support

> -Original Message- > From: YOSHIFUJI Hideaki / 吉藤英明 [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 07, 2007 10:49 AM > To: Templin, Fred L > Cc: [EMAIL PROTECTED]; netdev@vger.kernel.org; [EMAIL PROTECTED] > Subject: Re: [PATCH 02/05] ipv6: RFC4214 Support > > In article > <[

Re: Please pull 'fixes-davem' branch of wireless-2.6

Dave, Hold-off on this one for now if -- clearly Johannes and I need to brush-up on our Kconfig skills... :-( I'll post a new pull request soon. Thanks, John On Tue, Nov 06, 2007 at 07:13:14PM -0500, John W. Linville wrote: > Dave, > > Here are some fixes for 2.6.24... > > The iwlwifi patch

Re: [PATCH 02/05] ipv6: RFC4214 Support

In article <[EMAIL PROTECTED]> (at Wed, 7 Nov 2007 10:24:50 -0800), "Templin, Fred L" <[EMAIL PROTECTED]> says: > > > > -Original Message- > > From: YOSHIFUJI Hideaki / 吉藤英明 [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, November 07, 2007 10:12 AM > > To: [EMAIL PROTECTED] > > Cc: Tem

Re: 2.6.23.1-smp kernel panic (network-related)

On Wed, 7 Nov 2007 19:38:43 +0100 Marek Kierdelewicz <[EMAIL PROTECTED]> wrote: > >What is the test input that causes the crash?? > > Test box is treated with mirrored traffic that is routed by production > linux router (with non-smp kernel). It's usual traffic generated by > broadband clients. S

Re: 2.6.23.1-smp kernel panic (network-related)

>What is the test input that causes the crash?? Test box is treated with mirrored traffic that is routed by production linux router (with non-smp kernel). It's usual traffic generated by broadband clients. Some of the characteristics: bandwidth used: ~40/40 Mbit (up/down) pps: ~15k number of cli

Re: [PATCH 04/05] ipv6: RFC4214 Support

On Wed, 7 Nov 2007 10:41:49 -0800 "Templin, Fred L" <[EMAIL PROTECTED]> wrote: > Yoshifuji, > > > -Original Message- > > From: YOSHIFUJI Hideaki / 吉藤英明 [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, November 07, 2007 10:37 AM > > To: Templin, Fred L > > Cc: netdev@vger.kernel.org; [EMAI

RE: [PATCH 04/05] ipv6: RFC4214 Support

Yoshifuji, > -Original Message- > From: YOSHIFUJI Hideaki / 吉藤英明 [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 07, 2007 10:37 AM > To: Templin, Fred L > Cc: netdev@vger.kernel.org; [EMAIL PROTECTED] > Subject: Re: [PATCH 04/05] ipv6: RFC4214 Support > > Hello. > > In article >

Re: [PATCH 04/05] ipv6: RFC4214 Support

Hello. In article <[EMAIL PROTECTED]> (at Tue, 6 Nov 2007 17:16:11 -0800), "Templin, Fred L" <[EMAIL PROTECTED]> says: > @@ -154,6 +155,14 @@ static struct ip_tunnel * ipip6_tunnel_l > struct net_device *dev; > char name[IFNAMSIZ]; > > +#if defined(CONFIG_IPV6_ISATAP) > + /* IS

RE: [PATCH 02/05] ipv6: RFC4214 Support

> -Original Message- > From: YOSHIFUJI Hideaki / 吉藤英明 [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 07, 2007 10:12 AM > To: [EMAIL PROTECTED] > Cc: Templin, Fred L; netdev@vger.kernel.org; [EMAIL PROTECTED] > Subject: Re: [PATCH 02/05] ipv6: RFC4214 Support > > Hello. > > In a

Re: [PATCH] ethtool: add support for supporting 10000baseT

Kok, Auke wrote: > Ben Hutchings wrote: > > Auke Kok wrote: > >> From: Jesse Brandeburg <[EMAIL PROTECTED]> > >> > >> there is missing support in ethtool for reporting 1baseT > >> as SUPPORTED_1baseT_Full. The code seems to be half > >> implemented because the "advertising" field has the i

RE: [PATCH 03/05] ipv6: RFC4214 Support

> -Original Message- > From: Stephen Hemminger [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 07, 2007 9:37 AM > To: Templin, Fred L > Cc: netdev@vger.kernel.org > Subject: Re: [PATCH 03/05] ipv6: RFC4214 Support > > On Tue, 6 Nov 2007 17:16:07 -0800 > "Templin, Fred L" <[EMAIL

Re: [PATCH 02/05] ipv6: RFC4214 Support

Hello. In article <[EMAIL PROTECTED]> (at Wed, 7 Nov 2007 16:58:59 +0100), Ingo Oeser <[EMAIL PROTECTED]> says: > > + eui[0] = 0; > > + > > + /* Check for RFC3330 global address ranges */ > > + if (((ipv4 >= 0x0100) && (ipv4 < 0x0a00)) || > > + ((ipv4 >= 0x0b00) && (ipv4

[PATCH 12/13] SCTP: Clean-up some defines for regressions tests.

The SCTP regression tests now use the in-kernel version of proc_fs.h and we don't need to undef any more. Signed-off-by: Vlad Yasevich <[EMAIL PROTECTED]> --- include/net/sctp/sctp.h |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/include/net/sctp/sctp.h b/include/net/sct

Re: [PATCH] ethtool: add support for supporting 10000baseT

Ben Hutchings wrote: > Auke Kok wrote: >> From: Jesse Brandeburg <[EMAIL PROTECTED]> >> >> there is missing support in ethtool for reporting 1baseT >> as SUPPORTED_1baseT_Full. The code seems to be half >> implemented because the "advertising" field has the implementation. > > I reported

[PATCH 05/13] SCTP: Correctly disable ADD-IP when AUTH is not supported.

Signed-off-by: Vlad Yasevich <[EMAIL PROTECTED]> --- include/net/sctp/structs.h |1 - net/sctp/associola.c |2 +- net/sctp/sm_make_chunk.c |5 +++-- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h index a177

[PATCH 02/13] SCTP : Fix to process bundled ASCONF chunk correctly

From: Wei Yongjun <[EMAIL PROTECTED]> If ASCONF chunk is bundled with other chunks as the first chunk, when process the ASCONF parameters, full packet data will be process as the parameters of the ASCONF chunk, not only the real parameters. So if you send a ASCONF chunk bundled with other chunks,

[PATCH 13/13] SCTP: Always flush the queue when uncorcking.

When the code calls uncork, trigger a queue flush, even if the queue was not corked. Most callers that explicitly cork the queue will have additional checks to see if they corked it. Callers who do not cork the queue expect packets to flow when they call uncork. The scenario that showcased this

[PATCH 01/13] SCTP : Fix bad formatted comment in outqueue.c

From: Wei Yongjun <[EMAIL PROTECTED]> Just fix the bad format of the comment in outqueue.c. Signed-off-by: Wei Yongjun <[EMAIL PROTECTED]> Signed-off-by: Vlad Yasevich <[EMAIL PROTECTED]> --- net/sctp/outqueue.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/net/sctp/

[PATCH 08/13] SCTP: Use hashed lookup when looking for an association.

A SCTP endpoint may have a lot of associations on them and walking the list is fairly inefficient. Instead, use a hashed lookup, and filter out the hash list based on the endopoint we already have. Signed-off-by: Vlad Yasevich <[EMAIL PROTECTED]> --- net/sctp/endpointola.c | 33 +++

[PATCH 06/13] SCTP: Allow ADD-IP to work with AUTH for backward compatibility.

This patch adds a tunable that will allow ADD-IP to work without AUTH for backward compatibility. The default value is off since the default value for ADD-IP is off as well. People who need to use ADD-IP with older implementations take risks of connection hijacking and should consider upgrading o

[PATCH 09/13] SCTP: Convert custom hash lists to use hlist.

Convert the custom hash list traversals to use hlist functions. Signed-off-by: Vlad Yasevich <[EMAIL PROTECTED]> --- include/net/sctp/sctp.h|3 +++ include/net/sctp/structs.h | 10 -- net/sctp/endpointola.c |3 ++- net/sctp/input.c | 43 +++---

[PATCH 10/13] SCTP: Make sctp_verify_param return multiple indications.

SCTP-AUTH and future ADD-IP updates have a requirement to do additional verification of parameters and an ability to ABORT the association if verification fails. So, introduce additional return code so that we can clearly signal a required action. Signed-off-by: Vlad Yasevich <[EMAIL PROTECTED]>

[GIT PATCHES 0/13] SCTP fixes

Hi David The following are the accumulated SCTP patches. You can also pull from: master.kernel.org:/pub/scm/linux/kernel/git/vxy/lksctp-dev.git pending Vlad Yasevich (11): SCTP: Fix difference cases of retransmit. SCTP: Update RCU handling during the ADD-IP case SCTP: Correctl

Fw: 2.6.23.1-smp kernel panic (network-related)

What is the test input that causes the crash?? Forwarding message to proper group. Begin forwarded message: Date: Wed, 7 Nov 2007 17:52:11 +0100 From: Marek Kierdelewicz <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Newsgroups: gmane.linux.kernel Subject: 2.6.23.1-smp kernel panic (network-related)

[PATCH 11/13] SCTP: Fix PR-SCTP to deliver all the accumulated ordered chunks

There is a small bug when we process a FWD-TSN. We'll deliver anything up to the current next expected SSN. However, if the next expected is already in the queue, it will take another chunk to trigger its delivery. The fix is to simply check the current queued SSN is the next expected one. Sign

[PATCH 03/13] SCTP: Fix difference cases of retransmit.

Commit d0ce92910bc04e107b2f3f2048f07e94f570035d broke several retransmit cases including fast retransmit. The reason is that we should only delay by rto while doing retransmits as a result of a timeout. Retransmit as a result of path mtu discovery, fast retransmit, or other events that should trig

[PATCH 07/13] SCTP: Fix a potential race between timers and receive path.

There is a possible race condition where the timer code will free the association and the next packet in the queue will also attempt to free the same association. The example is, when we receive an ABORT at about the same time as the retransmission timer fires. If the timer wins the race, it will

[PATCH 04/13] SCTP: Update RCU handling during the ADD-IP case

After learning more about rcu, it looks like the ADD-IP handling doesn't need to call call_rcu_bh. All the rcu critical sections use rcu_read_lock, so using call_rcu_bh is wrong here. Now, restore the local_bh_disable() code blocks and use normal call_rcu() calls. Also restore the missing return

RE: [PATCH] [AF_PACKET]: Allow multicast traffic to be caught by ORIGDEV when bonded

> -Original Message- > From: David Miller [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 07, 2007 3:52 AM > To: Waskiewicz Jr, Peter P > Cc: netdev@vger.kernel.org > Subject: Re: [PATCH] [AF_PACKET]: Allow multicast traffic to > be caught by ORIGDEV when bonded > > From: "Waskiewi

Re: [PATCH 03/05] ipv6: RFC4214 Support

On Tue, 6 Nov 2007 17:16:07 -0800 "Templin, Fred L" <[EMAIL PROTECTED]> wrote: > From: Fred L. Templin <[EMAIL PROTECTED]> > > This is experimental support for the Intra-Site Automatic > Tunnel Addressing Protocol (ISATAP) per RFC4214. It uses > the SIT module, and is configured using the unmodif

RE: [PATCH 01/05] ipv6: RFC4214 Support

Thanks, and will fix. Fred > -Original Message- > From: Stephen Hemminger [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 07, 2007 9:31 AM > To: Templin, Fred L > Cc: netdev@vger.kernel.org > Subject: Re: [PATCH 01/05] ipv6: RFC4214 Support > > On Tue, 6 Nov 2007 17:16:01 -0800 >

Re: [PATCH 00/05] ipv6: RFC4214 Support

Pekka, Thanks! That answers the question I had (i.e., you believe the legal issues are resolved). +-DLS - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at

Re: [PATCH 01/05] ipv6: RFC4214 Support

On Tue, 6 Nov 2007 17:16:01 -0800 "Templin, Fred L" <[EMAIL PROTECTED]> wrote: > From: Fred L. Templin <[EMAIL PROTECTED]> > > This is experimental support for the Intra-Site Automatic > Tunnel Addressing Protocol (ISATAP) per RFC4214. It uses > the SIT module, and is configured using the unmodif

RE: [PATCH 00/05] ipv6: RFC4214 Support

As further clarification, here is the US patent office transaction history for the SRI application, which shows that the application was rejected on 8/02/04: http://portal.uspto.gov/external/portal/!ut/p/kcxml/04_Sj9SPykssy0xPLMnM z0vM0Y_QjzKLN4gPMATJgFieAfqRqCLGpugijnABX4_83FT9IKBEpDlQxNDCRz8qJzU

Re: [PATCH] ethtool: add support for supporting 10000baseT

Auke Kok wrote: > From: Jesse Brandeburg <[EMAIL PROTECTED]> > > there is missing support in ethtool for reporting 1baseT > as SUPPORTED_1baseT_Full. The code seems to be half > implemented because the "advertising" field has the implementation. I reported this lack on Sourceforge a whil

Re: [PATCH][PACKET] Remove unneeded packet_socks_nr variable

Em Wed, Nov 07, 2007 at 07:16:14PM +0300, Pavel Emelyanov escreveu: > Arnaldo Carvalho de Melo wrote: > > Em Wed, Nov 07, 2007 at 01:50:04PM -0200, Arnaldo Carvalho de Melo escreveu: > >> Em Wed, Nov 07, 2007 at 06:32:51PM +0300, Pavel Emelyanov escreveu: > >>> This one is used only under ifdef PAC

[PATCH] ethtool: add support for supporting 10000baseT

From: Jesse Brandeburg <[EMAIL PROTECTED]> there is missing support in ethtool for reporting 1baseT as SUPPORTED_1baseT_Full. The code seems to be half implemented because the "advertising" field has the implementation. this patch just adds it for supported reporting. Signed-off-by: Jes

RE: [PATCH 02/05] ipv6: RFC4214 Support

Thanks for these, Ingo. Will fix and test immediately. Fred [EMAIL PROTECTED] > -Original Message- > From: Ingo Oeser [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 07, 2007 7:59 AM > To: Templin, Fred L > Cc: netdev@vger.kernel.org > Subject: Re: [PATCH 02/05] ipv6: RFC4214 Supp

Re: [PATCH][PACKET] Remove unneeded packet_socks_nr variable

Em Wed, Nov 07, 2007 at 01:50:04PM -0200, Arnaldo Carvalho de Melo escreveu: > Em Wed, Nov 07, 2007 at 06:32:51PM +0300, Pavel Emelyanov escreveu: > > This one is used only under ifdef PACKET_REFCNT_DEBUG in > > printk and is not needed otherwise. So hide all this stuff > > under the PACKET_REFCNT_

Re: [PATCH 02/05] ipv6: RFC4214 Support

Hi Fred, some comments. Templin, Fred L schrieb: > From: Fred L. Templin <[EMAIL PROTECTED]> > > This is experimental support for the Intra-Site Automatic > Tunnel Addressing Protocol (ISATAP) per RFC4214. It uses > the SIT module, and is configured using the unmodified > "ip" utility with devic

Re: [PATCH][PACKET] Remove unneeded packet_socks_nr variable

Em Wed, Nov 07, 2007 at 06:32:51PM +0300, Pavel Emelyanov escreveu: > This one is used only under ifdef PACKET_REFCNT_DEBUG in > printk and is not needed otherwise. So hide all this stuff > under the PACKET_REFCNT_DEBUG. > > Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]> Look at sk_refcnt_deb

Re: [PATCH 13/24] [IPSEC]: Move x->outer_mode->output out of locked section

Hi Herbert, Herbert Xu schrieb: > diff --git a/net/ipv6/xfrm6_mode_ro.c b/net/ipv6/xfrm6_mode_ro.c > index a7bc8c6..4a01cb3 100644 > --- a/net/ipv6/xfrm6_mode_ro.c > +++ b/net/ipv6/xfrm6_mode_ro.c > @@ -53,7 +54,9 @@ static int xfrm6_ro_output(struct xfrm_state *x, struct > sk_buff *skb) >

Re: [PATCH] NET: Remove unneeded type cast in skb_truesize_check()

David Miller wrote: From: Chuck Lever <[EMAIL PROTECTED]> Date: Mon, 05 Nov 2007 18:59:26 -0500 If that's truly the case, document the requirement (perhaps using something the compiler itself can verify) instead of using a clever type cast trick. Feel free to submit such a change. Here's wh

RE: [2.6 patch] unexport softnet_data

>From: David Miller [mailto:[EMAIL PROTECTED] >Sent: Tuesday, November 06, 2007 11:41 PM > >From: "Nelson, Shannon" <[EMAIL PROTECTED]> >Date: Fri, 26 Oct 2007 08:38:55 -0700 > >> There is no creation of a pinned_list yet in this path, so I >don't think >> this would do us much good. > >The pinne

[PATCH][PACKET] Remove unneeded packet_socks_nr variable

This one is used only under ifdef PACKET_REFCNT_DEBUG in printk and is not needed otherwise. So hide all this stuff under the PACKET_REFCNT_DEBUG. Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]> --- diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c index 4cb2dfb..e6a96ee 100644 ---

Re: bonding / 2.6.24-rc1 issues

Or Gerlitz wrote: > Jay, Moni > > I did some tests with 2.6.24-rc1 and the first patch to bonding that Jay > sent last night to netdev. Basic operation and fail over work fine. > However, I see some crashes which are somehow related to destroying the > bond when the slaves are ipoib ones, I don't

RE: [PATCH 04/05] ipv6: RFC4214 Support

> @@ -395,8 +451,6 @@ static int ipip6_rcv(struct sk_buff *skb > } > > icmp_send(skb, ICMP_DEST_UNREACH, ICMP_PORT_UNREACH, 0); > - kfree_skb(skb); > - read_unlock(&ipip6_lock); > out: > return 0; > } Note that the above lines were incorrectly deleted. This has been f

[PATCH 2/2] [NET] proto: Use pcounters for the inuse field

Signed-off-by: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]> --- include/net/sock.h | 59 ++--- net/core/sock.c| 61 +-- 2 files changed, 14 insertions(+), 106 deletions(-) diff --git a/include/net/

[PATCH 1/2] [LIB]: Introduce struct pcounter

This just generalises what was introduced by Eric Dumazet for the struct proto inuse field in 286ab3d46058840d68e5d7d52e316c1f7e98c59f: [NET]: Define infrastructure to keep 'inuse' changes in an efficent SMP/NUMA way. Please look at the comment in there to see the rationale. Signed-off-by:

Re: [PATCH][PACKET] Remove unneeded packet_socks_nr variable

Arnaldo Carvalho de Melo wrote: > Em Wed, Nov 07, 2007 at 01:50:04PM -0200, Arnaldo Carvalho de Melo escreveu: >> Em Wed, Nov 07, 2007 at 06:32:51PM +0300, Pavel Emelyanov escreveu: >>> This one is used only under ifdef PACKET_REFCNT_DEBUG in >>> printk and is not needed otherwise. So hide all this

[PATCH 0/2] generalize {DEFINE|REF}_PROTO_INUSE was Re: [PATCH 0/4] NET : struct proto diet

Em Mon, Nov 05, 2007 at 11:43:06PM -0800, David Miller escreveu: > From: Eric Dumazet <[EMAIL PROTECTED]> > Date: Mon, 05 Nov 2007 18:52:32 +0100 > > > This patch series does some cleanup and optimization. > > > > [PATCH 1/4] NET : defines an infrastructure to keep 'inuse' changes in > > an effi

Re: [PATCH 1/2] bonding: fix rtnl locking merge error

Jay Vosburgh wrote: > Looks like I incorrectly merged one of the rtnl lock changes, > so that one function, bonding_show_active_slave, held rtnl but didn't > release it, and another, bonding_store_active_slave, never held rtnl but > did release it. > > Fixed so the first function doesn

RE: [PATCH 00/05] ipv6: RFC4214 Support

I think I can clear this up. The patent office rejected SRI's patent application, therefore there are no valid claims that could prevent ISATAP from being included in public domain software releases. Indeed, Microsoft, cisco, and FreeBSD/KAME are shipping ISATAP and have been doing so for a long ti

Re: Please pull 'fixes-davem' branch of wireless-2.6

On Wednesday 07 November 2007 01:13:14 John W. Linville wrote: > "ssb: Fix initcall ordering" changes a subsys_initcall to an > fs_initcall. This seems like a bit of a hack, but it fixes a real > problem and I'm not sure what cleaner solution is either reasonable > or available. The comment in th

Re: Endianness problem with u32 classifier hash masks

On Wed, 2007-11-07 at 01:22 -0800, David Miller wrote: > I've grown impatient and done the work for you :-) I've applied > the patch below to my tree, thank you! > > If someone wants to send me the ffs() thing relative to this, > I'd appreciate it. Thanks again! Thanks again for making the patc

[PATCH 14/24] [INET]: Give outer DSCP directly to ip*_copy_dscp

[INET]: Give outer DSCP directly to ip*_copy_dscp This patch changes the prototype of ipv4_copy_dscp and ipv6_copy_dscp so that they directly take the outer DSCP rather than the outer IP header. This will help us to unify the code for inter-family tunnels. Signed-off-by: Herbert Xu <[EMAIL PROTEC

[PATCH 10/24] [IPSEC]: Move flow construction into xfrm_dst_lookup

[IPSEC]: Move flow construction into xfrm_dst_lookup This patch moves the flow construction from the callers of xfrm_dst_lookup into that function. It also changes xfrm_dst_lookup so that it takes an xfrm state as its argument instead of explicit addresses. This removes any address-specific logi

[PATCH 12/24] [IPSEC]: Forbid BEET + ipcomp for now

[IPSEC]: Forbid BEET + ipcomp for now While BEET can theoretically work with IPComp the current code can't do that because it tries to construct a BEET mode tunnel type which doesn't (and cannot) exist. In fact as it is it won't even attach a tunnel object at all for BEET which is bogus. To supp

Re: [PATCH 00/05] ipv6: RFC4214 Support

On Tue, 6 Nov 2007, David Stevens wrote: give it away on this specific instance. I'm not sure if you should attribute to hidden agendas what you can explain by "doing the right thing" (granted, very few companies do this which may make it suspect, but still..). Pekka, I'm not assuming h

[PATCH 13/24] [IPSEC]: Move x->outer_mode->output out of locked section

[IPSEC]: Move x->outer_mode->output out of locked section RO mode is the only one that requires a locked output function. So it's easier to move the lock into that function rather than requiring everyone else to run under the lock. In particular, this allows us to move the size check into the ou

[PATCH 16/24] [IPSEC]: Separate inner/outer mode processing on input

[IPSEC]: Separate inner/outer mode processing on input With inter-family transforms the inner mode differs from the outer mode. Attempting to handle both sides from the same function means that it needs to handle both IPv4 and IPv6 which creates duplication and confusion. This patch separates the

[PATCH 20/24] [IPSEC]: Add async resume support on output

[IPSEC]: Add async resume support on output This patch adds support for async resumptions on output. To do so, the transform would return -EINPROGRESS and subsequently invoke the function xfrm_output_resume to resume processing. Signed-off-by: Herbert Xu <[EMAIL PROTECTED]> --- include/net/xfr

  1   2   >