* [PATCH 2/2] New PowerPC 4xx on-chip ethernet controller driver
From: Eugene Surovegin @ 2005-08-31 5:01 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, linuxppc-embedded
In-Reply-To: <20050831050048.GB17017@gate.ebshome.net>
Add new PPC 4xx NAPI EMAC driver
Signed-off-by: Eugene Surovegin <ebs@ebshome.net>
---
drivers/net/Kconfig | 70 +
drivers/net/ibm_emac/Makefile | 11
drivers/net/ibm_emac/ibm_emac.h | 309 +++++
drivers/net/ibm_emac/ibm_emac_core.c | 2248 +++++++++++++++++++++++++++++++++
drivers/net/ibm_emac/ibm_emac_core.h | 221 +++
drivers/net/ibm_emac/ibm_emac_debug.c | 213 +++
drivers/net/ibm_emac/ibm_emac_debug.h | 63 +
drivers/net/ibm_emac/ibm_emac_mal.c | 584 +++++++++
drivers/net/ibm_emac/ibm_emac_mal.h | 267 ++++
drivers/net/ibm_emac/ibm_emac_phy.c | 355 +++++
drivers/net/ibm_emac/ibm_emac_phy.h | 80 +
drivers/net/ibm_emac/ibm_emac_rgmii.c | 202 +++
drivers/net/ibm_emac/ibm_emac_rgmii.h | 65 +
drivers/net/ibm_emac/ibm_emac_tah.c | 111 ++
drivers/net/ibm_emac/ibm_emac_tah.h | 88 +
drivers/net/ibm_emac/ibm_emac_zmii.c | 256 ++++
drivers/net/ibm_emac/ibm_emac_zmii.h | 83 +
17 files changed, 5226 insertions(+), 0 deletions(-)
Patch is quite big (146K) and can be found at
http://kernel.ebshome.net/emac/06-add_napi_ibm_emac.diff
I can post it to the mail list for discussion, just let me know.
^ permalink raw reply
* [PATCH 1/2] New PowerPC 4xx on-chip ethernet controller driver
From: Eugene Surovegin @ 2005-08-31 5:00 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, linuxppc-embedded
In-Reply-To: <20050831045847.GA17017@gate.ebshome.net>
Remove old PPC4xx EMAC driver
Signed-off-by: Eugene Surovegin <ebs@ebshome.net>
---
drivers/net/Kconfig | 34 -
drivers/net/ibm_emac/Makefile | 12
drivers/net/ibm_emac/ibm_emac.h | 267 ----
drivers/net/ibm_emac/ibm_emac_core.c | 2011 ---------------------------------
drivers/net/ibm_emac/ibm_emac_core.h | 146 --
drivers/net/ibm_emac/ibm_emac_debug.c | 224 ----
drivers/net/ibm_emac/ibm_emac_mal.c | 463 --------
drivers/net/ibm_emac/ibm_emac_mal.h | 131 --
drivers/net/ibm_emac/ibm_emac_phy.c | 298 -----
drivers/net/ibm_emac/ibm_emac_phy.h | 137 --
drivers/net/ibm_emac/ibm_emac_rgmii.h | 65 -
drivers/net/ibm_emac/ibm_emac_tah.h | 48 -
drivers/net/ibm_emac/ibm_emac_zmii.h | 93 --
13 files changed, 0 insertions(+), 3929 deletions(-)
Patch is quite big (110K) and not interesting, it can be found at
http://kernel.ebshome.net/emac/05-remove_old_ibm_emac.diff
^ permalink raw reply
* [PATCH 0/2] New PowerPC 4xx on-chip ethernet controller driver
From: Eugene Surovegin @ 2005-08-31 4:58 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, linuxppc-embedded
Jeff,
the following patches replace current PowerPC 4xx EMAC driver with
new, re-written version.
New driver uses NAPI, it solves problems under heavy packet load and
low memory, corrects chip register access and fixes numerous small
bugs I don't even remember now :).
This patch has been tested on all supported in 2.6 PPC 4xx boards.
It's been used in production for almost a year now on custom
4xx hardware. PPC32 specific parts were just posted to linuxppc-dev
and linuxppc-embedded mail lists.
Patch was acked by the current EMAC driver maintainer (Matt Porter). I
will be maintaining this new version.
Signed-off-by: Eugene Surovegin <ebs@ebshome.net>
^ permalink raw reply
* Re: Very strange Marvell/Yukon Gigabit NIC networking problems
From: Steve Kieu @ 2005-08-31 0:09 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Jesse Brandeburg, Daniel Drake, Steve Kieu, linux-kernel, netdev
In-Reply-To: <20050830152908.1dc24339@dxpl.pdx.osdl.net>
--- Stephen Hemminger <shemminger@osdl.org> wrote:
> On Wed, 31 Aug 2005 07:49:37 +1000 (EST)
> >
> > install-8_23.tar.bz2
>
> Just look for references to CHIP_REV_YU_LITE_A3 in
> the driver
> sk98lin/skgeinit.c and sk98lin/skxmac2.c
> The comparison should always be:
Have a look but no clue to patch it, there are one
instance of comparing
> pAC->GIni.GIChipRev >= CHIP_REV_YU_LITE_A3
> otherwise it will not correctly take chip out of
> powerdown (coma) mode.
please send me a patch to the install-8_23.tar.bz2
then I can test. Or intruct more details, which line
and what should change then I can do manually.
I have nerver done device driver programming in my
life!
>
S.KIEU
Send instant messages to your online friends http://au.messenger.yahoo.com
^ permalink raw reply
* Re: Kernel 2.6.13: TCP (libnet?)
From: Patrick McHardy @ 2005-08-30 22:36 UTC (permalink / raw)
To: John McGowan, mike; +Cc: linux-kernel, Maillist netdev
In-Reply-To: <20050830194107.GA11652@localhost.localdomain>
John McGowan wrote:
> Kernel 2.6.13: TCP (libnet?)
>
> Broken libnet?
>
> KERNEL: linux-kernel@vger.kernel.org
> LIBNET 1.1 (c) 1998 - 2004 Mike D. Schiffman <mike@infonexus.com>
>
> I don't like spam. I track spamvertized sites. Many only respond to TCP
> packets sent to port 80. I need a TCP traceroute (traceroute using TCP/SYN
> packets).
>
> I have four such programmes.
>
> 1: Hping in traceroute mode.
> Poor. If it hits a router which does not respond, it just sits
> and waits.
> 2: LFT
> OK.
> a: Does not work in Fedora Core2 - without patching.
> The source code expects a header of zero bytes in the
> pcap output of zero bytes (hard coded in the source).
> My captures have a "linux cooked capture" header of sixteen bytes.
> Changing an offset from zero to sixteen gets it to work.
> b: Requires traffic on the interface.
> It seems it gets into a loop and awaits some traffic.
> It examines it - if it is data it expects it uses it.
> If it is other data from other programmes accessing the 'net
> it does nothing with it.
> In both those cases it moves on and starts over.
> What if there is no traffic? Unless there is something for it
> either to use or ignore, it seems to hang. To get it to work
> I have to, say, read the NY Times online while running it.
> (I believe the traceproto site mentions doing something to
> get around the timeout problem)
> Output is OK - but I don't really like it.
> 3: Tcptraceroute
> I have used this since kernel 2.2 through 2.4
> (older version with older version of libnet) and
> 2.6.5, 2.6.7, 2.6.9, 2.6.10, 2.6.11, 2.6.12
> It was my favourite until I got traceproto.
> 4: Traceproto
> I have used this in kernels 2.4,
> 2.6.5, 2.6.7, 2.6.9, 2.6.10, 2.6.11, 2.6.12
> Good.
>
>
> In kernel 2.6.13: [patching 2.1.12 with the patch file]
>
> Standard "traceroute" works.
> LFT works.
> HPING works (also in traceroute mode).
> tcptraceroute fails.
> traceproto (tcp or udp mode) fails.
>
> How do they fail?
>
> A TCPDUMP shows that they do send out the packets.
> I do get back ICMP "time exceeded" error messages.
> They no longer recognize them.
>
> Something that had never changed before has now changed
> and has broken traceproto and tcptraceroute.
[netdev CC'ed]
Could you provide tcpdump dumps and your .config file please?
^ permalink raw reply
* Re: Very strange Marvell/Yukon Gigabit NIC networking problems
From: Stephen Hemminger @ 2005-08-30 22:29 UTC (permalink / raw)
To: Steve Kieu
Cc: Jesse Brandeburg, Daniel Drake, Steve Kieu, linux-kernel, netdev
In-Reply-To: <20050830214937.22956.qmail@web53604.mail.yahoo.com>
On Wed, 31 Aug 2005 07:49:37 +1000 (EST)
Steve Kieu <haiquy@yahoo.com> wrote:
>
> --- Stephen Hemminger <shemminger@osdl.org> wrote:
>
> > You have a version of the Marvell Yukon that was
> > affected
> > by a fix in 2.6.13.
> > skge addr 0xfeaf8000 irq 19 chip Yukon-Lite rev 9
> >
> > Both the skge and sk98lin driver were fixed to check
> > for this.
> > Without the fix, the chip will be in the wrong power
> > mode.
> >
> > The version of sk98lin driver from SysKonnect
> > already had the
> > fix, so if your distro used that one, it would have
> > the reset
> > the power mode as needed.
>
> I am afraid not. The last time, I reproduced the
> problem using the latest sk98lin driver from
> SysKonnect (run create patch and patch the kernel
> 2.6.13). Problem still there. The file I got from
> sysconnect is:
>
> install-8_23.tar.bz2
Just look for references to CHIP_REV_YU_LITE_A3 in the driver
sk98lin/skgeinit.c and sk98lin/skxmac2.c
The comparison should always be:
pAC->GIni.GIChipRev >= CHIP_REV_YU_LITE_A3
otherwise it will not correctly take chip out of powerdown (coma) mode.
^ permalink raw reply
* Re: Very strange Marvell/Yukon Gigabit NIC networking problems
From: Steve Kieu @ 2005-08-30 21:49 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Jesse Brandeburg, Daniel Drake, Steve Kieu, linux-kernel, netdev
In-Reply-To: <20050830140516.316e9695@dxpl.pdx.osdl.net>
--- Stephen Hemminger <shemminger@osdl.org> wrote:
> You have a version of the Marvell Yukon that was
> affected
> by a fix in 2.6.13.
> skge addr 0xfeaf8000 irq 19 chip Yukon-Lite rev 9
>
> Both the skge and sk98lin driver were fixed to check
> for this.
> Without the fix, the chip will be in the wrong power
> mode.
>
> The version of sk98lin driver from SysKonnect
> already had the
> fix, so if your distro used that one, it would have
> the reset
> the power mode as needed.
I am afraid not. The last time, I reproduced the
problem using the latest sk98lin driver from
SysKonnect (run create patch and patch the kernel
2.6.13). Problem still there. The file I got from
sysconnect is:
install-8_23.tar.bz2
>
S.KIEU
____________________________________________________
Do you Yahoo!?
The New Yahoo! Movies: Check out the Latest Trailers, Premiere Photos and full Actor Database.
http://au.movies.yahoo.com
^ permalink raw reply
* Re: [PATCH] crypto_free_tfm callers do not need to check for NULL
From: Jesper Juhl @ 2005-08-30 21:26 UTC (permalink / raw)
To: Sridhar Samudrala
Cc: Linux Kernel Mailing List, Alexey Dobriyan, Herbert Xu,
YOSHIFUJI Hideaki, David S. Miller, Benjamin Reed, Andy Adamson,
netdev, lksctp developers, Bruce Fields, Andy Adamson, linux-net,
linux-crypto
In-Reply-To: <1125436415.3952.11.camel@w-sridhar2.beaverton.ibm.com>
On 8/30/05, Sridhar Samudrala <sri@us.ibm.com> wrote:
> On Tue, 2005-08-30 at 22:45 +0200, Jesper Juhl wrote:
> > Since the patch to add a NULL short-circuit to crypto_free_tfm() went in,
> > there's no longer any need for callers of that function to check for NULL.
> > This patch removes the redundant NULL checks and also a few similar checks
> > for NULL before calls to kfree() that I ran into while doing the
> > crypto_free_tfm bits.
> >
> > I've posted similar patches in the past, but was asked to first until the
> > short-circuit patch moved from -mm to mainline - and since it is now
> > firmly there in 2.6.13 I assume there's no problem there anymore.
> > I was also asked previously to make the patch against mainline and not -mm,
> > so this patch is against 2.6.13.
> >
> > Feedback, ACK, NACK, etc welcome.
>
> sctp change looks fine.
> A similar check in sctp_endpoint_destroy() can also be removed.
>
Thanks, I'll remember that and either update the patch or send a small
incremental one later.
--
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
^ permalink raw reply
* Re: [PATCH] crypto_free_tfm callers do not need to check for NULL
From: Sridhar Samudrala @ 2005-08-30 21:13 UTC (permalink / raw)
To: Jesper Juhl
Cc: Linux Kernel Mailing List, Alexey Dobriyan, Herbert Xu,
YOSHIFUJI Hideaki, David S. Miller, Benjamin Reed, Andy Adamson,
netdev, lksctp developers, Bruce Fields, Andy Adamson, linux-net,
linux-crypto
In-Reply-To: <200508302245.55392.jesper.juhl@gmail.com>
On Tue, 2005-08-30 at 22:45 +0200, Jesper Juhl wrote:
> Since the patch to add a NULL short-circuit to crypto_free_tfm() went in,
> there's no longer any need for callers of that function to check for NULL.
> This patch removes the redundant NULL checks and also a few similar checks
> for NULL before calls to kfree() that I ran into while doing the
> crypto_free_tfm bits.
>
> I've posted similar patches in the past, but was asked to first until the
> short-circuit patch moved from -mm to mainline - and since it is now
> firmly there in 2.6.13 I assume there's no problem there anymore.
> I was also asked previously to make the patch against mainline and not -mm,
> so this patch is against 2.6.13.
>
> Feedback, ACK, NACK, etc welcome.
sctp change looks fine.
A similar check in sctp_endpoint_destroy() can also be removed.
Thanks
Sridhar
^ permalink raw reply
* Re: Very strange Marvell/Yukon Gigabit NIC networking problems
From: Stephen Hemminger @ 2005-08-30 21:05 UTC (permalink / raw)
To: Steve Kieu
Cc: Jesse Brandeburg, Daniel Drake, Steve Kieu, linux-kernel, netdev
In-Reply-To: <20050830205027.59306.qmail@web53609.mail.yahoo.com>
You have a version of the Marvell Yukon that was affected
by a fix in 2.6.13.
skge addr 0xfeaf8000 irq 19 chip Yukon-Lite rev 9
Both the skge and sk98lin driver were fixed to check for this.
Without the fix, the chip will be in the wrong power mode.
The version of sk98lin driver from SysKonnect already had the
fix, so if your distro used that one, it would have the reset
the power mode as needed.
^ permalink raw reply
* Re: Very strange Marvell/Yukon Gigabit NIC networking problems
From: Steve Kieu @ 2005-08-30 20:50 UTC (permalink / raw)
To: Stephen Hemminger, Jesse Brandeburg
Cc: Daniel Drake, Steve Kieu, linux-kernel, netdev
In-Reply-To: <20050830133918.42444cae@dxpl.pdx.osdl.net>
[-- Attachment #1: Type: text/plain, Size: 1000 bytes --]
Ok, I reproduce the problem and attached several lspci
log here
--- Stephen Hemminger <shemminger@osdl.org> wrote:
> On Tue, 30 Aug 2005 13:18:57 -0700
> Jesse Brandeburg <jesse.brandeburg@gmail.com> wrote:
>
> > on 2.6.11/12 when it isn't working maybe you
> should send us the output
> > of lspci -vvv
> >
> > just a hint, I'm guessing its power management
> related, and / or
> > something to do with the pci bus code.
>
> Also, the dmesg output with skge driver will show
> chip version and revision.
> The problem is obviously some of the chip
> initialization that is complex
> with the Marvell chips. Something is probably
> missing. There was a fix
> in the latest 2.6.13 that is probably related:
>
>
>
http://www.mail-archive.com/netdev@vger.kernel.org/msg00438.html
>
S.KIEU
____________________________________________________
Do you Yahoo!?
The New Yahoo! Movies: Check out the Latest Trailers, Premiere Photos and full Actor Database.
http://au.movies.yahoo.com
[-- Attachment #2: 2772971102-dmesg-2.6.12-nowork.log.gz --]
[-- Type: application/x-gzip, Size: 5927 bytes --]
[-- Attachment #3: 3668832883-dmesg-2613.log.gz --]
[-- Type: application/x-gzip, Size: 4868 bytes --]
[-- Attachment #4: 3470857198-lspci-2612-nowork.log.gz --]
[-- Type: application/x-gzip, Size: 2012 bytes --]
[-- Attachment #5: 1122749440-lspci-2613.log.gz --]
[-- Type: application/x-gzip, Size: 1672 bytes --]
[-- Attachment #6: 267994485-lspci-2612-work.log.gz --]
[-- Type: application/x-gzip, Size: 1672 bytes --]
^ permalink raw reply
* Re: [PATCH] crypto_free_tfm callers do not need to check for NULL
From: J. Bruce Fields @ 2005-08-30 20:49 UTC (permalink / raw)
To: Jesper Juhl
Cc: Linux Kernel Mailing List, Alexey Dobriyan, Herbert Xu,
YOSHIFUJI Hideaki, David S. Miller, Benjamin Reed, Andy Adamson,
netdev, lksctp developers, Andy Adamson, linux-net, linux-crypto
In-Reply-To: <200508302245.55392.jesper.juhl@gmail.com>
On Tue, Aug 30, 2005 at 10:45:54PM +0200, Jesper Juhl wrote:
> Since the patch to add a NULL short-circuit to crypto_free_tfm() went in,
> there's no longer any need for callers of that function to check for NULL.
...
> Feedback, ACK, NACK, etc welcome.
I've no problem with the auth_gss or nfsv4 bits.--b.
^ permalink raw reply
* [PATCH] crypto_free_tfm callers do not need to check for NULL
From: Jesper Juhl @ 2005-08-30 20:45 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Alexey Dobriyan, Herbert Xu, YOSHIFUJI Hideaki, David S. Miller,
Benjamin Reed, Andy Adamson, netdev, lksctp developers,
Bruce Fields, Andy Adamson, linux-net, linux-crypto
Since the patch to add a NULL short-circuit to crypto_free_tfm() went in,
there's no longer any need for callers of that function to check for NULL.
This patch removes the redundant NULL checks and also a few similar checks
for NULL before calls to kfree() that I ran into while doing the
crypto_free_tfm bits.
I've posted similar patches in the past, but was asked to first until the
short-circuit patch moved from -mm to mainline - and since it is now
firmly there in 2.6.13 I assume there's no problem there anymore.
I was also asked previously to make the patch against mainline and not -mm,
so this patch is against 2.6.13.
Feedback, ACK, NACK, etc welcome.
Sorry about the large Cc list, but I wanted to include everyone involved
with the code I change.
Please keep me on Cc.
Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
---
./drivers/net/wireless/airo.c | 3 +--
./fs/nfsd/nfs4recover.c | 3 +--
./net/ipv4/ah4.c | 18 ++++++------------
./net/ipv4/esp4.c | 24 ++++++++----------------
./net/ipv4/ipcomp.c | 3 +--
./net/ipv6/addrconf.c | 6 ++----
./net/ipv6/ah6.c | 18 ++++++------------
./net/ipv6/esp6.c | 24 ++++++++----------------
./net/ipv6/ipcomp6.c | 3 +--
./net/sctp/socket.c | 3 +--
./net/sunrpc/auth_gss/gss_krb5_crypto.c | 3 +--
./net/sunrpc/auth_gss/gss_krb5_mech.c | 9 +++------
./net/sunrpc/auth_gss/gss_spkm3_mech.c | 12 ++++--------
13 files changed, 43 insertions(+), 86 deletions(-)
--- linux-2.6.13-orig/./drivers/net/wireless/airo.c 2005-08-29 01:41:01.000000000 +0200
+++ linux-2.6.13/./drivers/net/wireless/airo.c 2005-08-30 18:08:15.000000000 +0200
@@ -2403,8 +2403,7 @@ void stop_airo_card( struct net_device *
}
}
#ifdef MICSUPPORT
- if (ai->tfm)
- crypto_free_tfm(ai->tfm);
+ crypto_free_tfm(ai->tfm);
#endif
del_airo_dev( dev );
free_netdev( dev );
--- linux-2.6.13-orig/./fs/nfsd/nfs4recover.c 2005-08-29 01:41:01.000000000 +0200
+++ linux-2.6.13/./fs/nfsd/nfs4recover.c 2005-08-30 18:08:25.000000000 +0200
@@ -114,8 +114,7 @@ nfs4_make_rec_clidname(char *dname, stru
kfree(cksum.data);
status = nfs_ok;
out:
- if (tfm)
- crypto_free_tfm(tfm);
+ crypto_free_tfm(tfm);
return status;
}
--- linux-2.6.13-orig/./net/ipv4/ah4.c 2005-08-29 01:41:01.000000000 +0200
+++ linux-2.6.13/./net/ipv4/ah4.c 2005-08-30 18:10:10.000000000 +0200
@@ -263,10 +263,8 @@ static int ah_init_state(struct xfrm_sta
error:
if (ahp) {
- if (ahp->work_icv)
- kfree(ahp->work_icv);
- if (ahp->tfm)
- crypto_free_tfm(ahp->tfm);
+ kfree(ahp->work_icv);
+ crypto_free_tfm(ahp->tfm);
kfree(ahp);
}
return -EINVAL;
@@ -279,14 +277,10 @@ static void ah_destroy(struct xfrm_state
if (!ahp)
return;
- if (ahp->work_icv) {
- kfree(ahp->work_icv);
- ahp->work_icv = NULL;
- }
- if (ahp->tfm) {
- crypto_free_tfm(ahp->tfm);
- ahp->tfm = NULL;
- }
+ kfree(ahp->work_icv);
+ ahp->work_icv = NULL;
+ crypto_free_tfm(ahp->tfm);
+ ahp->tfm = NULL;
kfree(ahp);
}
--- linux-2.6.13-orig/./net/ipv4/esp4.c 2005-08-29 01:41:01.000000000 +0200
+++ linux-2.6.13/./net/ipv4/esp4.c 2005-08-30 18:10:49.000000000 +0200
@@ -343,22 +343,14 @@ static void esp_destroy(struct xfrm_stat
if (!esp)
return;
- if (esp->conf.tfm) {
- crypto_free_tfm(esp->conf.tfm);
- esp->conf.tfm = NULL;
- }
- if (esp->conf.ivec) {
- kfree(esp->conf.ivec);
- esp->conf.ivec = NULL;
- }
- if (esp->auth.tfm) {
- crypto_free_tfm(esp->auth.tfm);
- esp->auth.tfm = NULL;
- }
- if (esp->auth.work_icv) {
- kfree(esp->auth.work_icv);
- esp->auth.work_icv = NULL;
- }
+ crypto_free_tfm(esp->conf.tfm);
+ esp->conf.tfm = NULL;
+ kfree(esp->conf.ivec);
+ esp->conf.ivec = NULL;
+ crypto_free_tfm(esp->auth.tfm);
+ esp->auth.tfm = NULL;
+ kfree(esp->auth.work_icv);
+ esp->auth.work_icv = NULL;
kfree(esp);
}
--- linux-2.6.13-orig/./net/ipv4/ipcomp.c 2005-08-29 01:41:01.000000000 +0200
+++ linux-2.6.13/./net/ipv4/ipcomp.c 2005-08-30 18:11:14.000000000 +0200
@@ -345,8 +345,7 @@ static void ipcomp_free_tfms(struct cryp
for_each_cpu(cpu) {
struct crypto_tfm *tfm = *per_cpu_ptr(tfms, cpu);
- if (tfm)
- crypto_free_tfm(tfm);
+ crypto_free_tfm(tfm);
}
free_percpu(tfms);
}
--- linux-2.6.13-orig/./net/ipv6/addrconf.c 2005-08-29 01:41:01.000000000 +0200
+++ linux-2.6.13/./net/ipv6/addrconf.c 2005-08-30 18:11:34.000000000 +0200
@@ -3593,10 +3593,8 @@ void __exit addrconf_cleanup(void)
rtnl_unlock();
#ifdef CONFIG_IPV6_PRIVACY
- if (likely(md5_tfm != NULL)) {
- crypto_free_tfm(md5_tfm);
- md5_tfm = NULL;
- }
+ crypto_free_tfm(md5_tfm);
+ md5_tfm = NULL;
#endif
#ifdef CONFIG_PROC_FS
--- linux-2.6.13-orig/./net/ipv6/ah6.c 2005-08-29 01:41:01.000000000 +0200
+++ linux-2.6.13/./net/ipv6/ah6.c 2005-08-30 18:12:03.000000000 +0200
@@ -402,10 +402,8 @@ static int ah6_init_state(struct xfrm_st
error:
if (ahp) {
- if (ahp->work_icv)
- kfree(ahp->work_icv);
- if (ahp->tfm)
- crypto_free_tfm(ahp->tfm);
+ kfree(ahp->work_icv);
+ crypto_free_tfm(ahp->tfm);
kfree(ahp);
}
return -EINVAL;
@@ -418,14 +416,10 @@ static void ah6_destroy(struct xfrm_stat
if (!ahp)
return;
- if (ahp->work_icv) {
- kfree(ahp->work_icv);
- ahp->work_icv = NULL;
- }
- if (ahp->tfm) {
- crypto_free_tfm(ahp->tfm);
- ahp->tfm = NULL;
- }
+ kfree(ahp->work_icv);
+ ahp->work_icv = NULL;
+ crypto_free_tfm(ahp->tfm);
+ ahp->tfm = NULL;
kfree(ahp);
}
--- linux-2.6.13-orig/./net/ipv6/esp6.c 2005-08-29 01:41:01.000000000 +0200
+++ linux-2.6.13/./net/ipv6/esp6.c 2005-08-30 18:12:25.000000000 +0200
@@ -277,22 +277,14 @@ static void esp6_destroy(struct xfrm_sta
if (!esp)
return;
- if (esp->conf.tfm) {
- crypto_free_tfm(esp->conf.tfm);
- esp->conf.tfm = NULL;
- }
- if (esp->conf.ivec) {
- kfree(esp->conf.ivec);
- esp->conf.ivec = NULL;
- }
- if (esp->auth.tfm) {
- crypto_free_tfm(esp->auth.tfm);
- esp->auth.tfm = NULL;
- }
- if (esp->auth.work_icv) {
- kfree(esp->auth.work_icv);
- esp->auth.work_icv = NULL;
- }
+ crypto_free_tfm(esp->conf.tfm);
+ esp->conf.tfm = NULL;
+ kfree(esp->conf.ivec);
+ esp->conf.ivec = NULL;
+ crypto_free_tfm(esp->auth.tfm);
+ esp->auth.tfm = NULL;
+ kfree(esp->auth.work_icv);
+ esp->auth.work_icv = NULL;
kfree(esp);
}
--- linux-2.6.13-orig/./net/ipv6/ipcomp6.c 2005-08-29 01:41:01.000000000 +0200
+++ linux-2.6.13/./net/ipv6/ipcomp6.c 2005-08-30 18:12:34.000000000 +0200
@@ -341,8 +341,7 @@ static void ipcomp6_free_tfms(struct cry
for_each_cpu(cpu) {
struct crypto_tfm *tfm = *per_cpu_ptr(tfms, cpu);
- if (tfm)
- crypto_free_tfm(tfm);
+ crypto_free_tfm(tfm);
}
free_percpu(tfms);
}
--- linux-2.6.13-orig/./net/sctp/socket.c 2005-08-29 01:41:01.000000000 +0200
+++ linux-2.6.13/./net/sctp/socket.c 2005-08-30 18:12:59.000000000 +0200
@@ -4194,8 +4194,7 @@ out:
sctp_release_sock(sk);
return err;
cleanup:
- if (tfm)
- sctp_crypto_free_tfm(tfm);
+ sctp_crypto_free_tfm(tfm);
goto out;
}
--- linux-2.6.13-orig/./net/sunrpc/auth_gss/gss_krb5_crypto.c 2005-08-29 01:41:01.000000000 +0200
+++ linux-2.6.13/./net/sunrpc/auth_gss/gss_krb5_crypto.c 2005-08-30 18:13:05.000000000 +0200
@@ -199,8 +199,7 @@ make_checksum(s32 cksumtype, char *heade
crypto_digest_final(tfm, cksum->data);
code = 0;
out:
- if (tfm)
- crypto_free_tfm(tfm);
+ crypto_free_tfm(tfm);
return code;
}
--- linux-2.6.13-orig/./net/sunrpc/auth_gss/gss_krb5_mech.c 2005-08-29 01:41:01.000000000 +0200
+++ linux-2.6.13/./net/sunrpc/auth_gss/gss_krb5_mech.c 2005-08-30 18:13:48.000000000 +0200
@@ -185,12 +185,9 @@ static void
gss_delete_sec_context_kerberos(void *internal_ctx) {
struct krb5_ctx *kctx = internal_ctx;
- if (kctx->seq)
- crypto_free_tfm(kctx->seq);
- if (kctx->enc)
- crypto_free_tfm(kctx->enc);
- if (kctx->mech_used.data)
- kfree(kctx->mech_used.data);
+ crypto_free_tfm(kctx->seq);
+ crypto_free_tfm(kctx->enc);
+ kfree(kctx->mech_used.data);
kfree(kctx);
}
--- linux-2.6.13-orig/./net/sunrpc/auth_gss/gss_spkm3_mech.c 2005-08-29 01:41:01.000000000 +0200
+++ linux-2.6.13/./net/sunrpc/auth_gss/gss_spkm3_mech.c 2005-08-30 18:14:18.000000000 +0200
@@ -214,14 +214,10 @@ static void
gss_delete_sec_context_spkm3(void *internal_ctx) {
struct spkm3_ctx *sctx = internal_ctx;
- if(sctx->derived_integ_key)
- crypto_free_tfm(sctx->derived_integ_key);
- if(sctx->derived_conf_key)
- crypto_free_tfm(sctx->derived_conf_key);
- if(sctx->share_key.data)
- kfree(sctx->share_key.data);
- if(sctx->mech_used.data)
- kfree(sctx->mech_used.data);
+ crypto_free_tfm(sctx->derived_integ_key);
+ crypto_free_tfm(sctx->derived_conf_key);
+ kfree(sctx->share_key.data);
+ kfree(sctx->mech_used.data);
kfree(sctx);
}
^ permalink raw reply
* Re: Very strange Marvell/Yukon Gigabit NIC networking problems
From: Stephen Hemminger @ 2005-08-30 20:39 UTC (permalink / raw)
To: Jesse Brandeburg; +Cc: Daniel Drake, Steve Kieu, linux-kernel, netdev
In-Reply-To: <4807377b05083013185767744a@mail.gmail.com>
On Tue, 30 Aug 2005 13:18:57 -0700
Jesse Brandeburg <jesse.brandeburg@gmail.com> wrote:
> on 2.6.11/12 when it isn't working maybe you should send us the output
> of lspci -vvv
>
> just a hint, I'm guessing its power management related, and / or
> something to do with the pci bus code.
Also, the dmesg output with skge driver will show chip version and revision.
The problem is obviously some of the chip initialization that is complex
with the Marvell chips. Something is probably missing. There was a fix
in the latest 2.6.13 that is probably related:
http://www.mail-archive.com/netdev@vger.kernel.org/msg00438.html
^ permalink raw reply
* Re: Very strange Marvell/Yukon Gigabit NIC networking problems
From: Jesse Brandeburg @ 2005-08-30 20:18 UTC (permalink / raw)
To: Daniel Drake; +Cc: shemminger, Steve Kieu, linux-kernel, netdev
In-Reply-To: <43145FB5.6080300@gentoo.org>
on 2.6.11/12 when it isn't working maybe you should send us the output
of lspci -vvv
just a hint, I'm guessing its power management related, and / or
something to do with the pci bus code.
On 8/30/05, Daniel Drake <dsd@gentoo.org> wrote:
> Forwarding on, please reply-to-all in future.
>
> Steve Kieu wrote:
> > Hi all,
> >
> > I have "fixed" the problem in a very wierd way.Reading
> > your post I thought maybe when removing the driver
> > itself it set some bit incorrectly. Then I decided to
> > do:
> >
> > Boot with init=/bin/bash so bypass all other things.
> > modprobe skge
> >
> > run ifconfig eth0 ip_num up
> >
> >
> > ping a host
> >
> > then while pinging hit Ctrl+Alt+Del key to hot reboot
> > the system.
> >
> > I still see the light at the hub lits. Now I boot to
> > winXP and as I expected , it worked!
> >
> > No I boot 2.6.11 and it worked, so the problem resolve
> > but I am tooooo scared to run 2613 now :-)
> >
> > Hope this information helps debuging the driver.
> >
> > Thanks.
> >
> > S.KIEU
> -
> 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
* Linux Policy Routing Feature Enhancement Request
From: Jeremy M. Guthrie @ 2005-08-30 15:10 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 533 bytes --]
If possible, I'd like to put in a feature request to increase the number of
available tables from 256 to 65536. The IDS load balancer can actually make
use of all of them. My attempts to do this to 2.6.11 and 'ip' failed
miserably. 8(
--
--------------------------------------------------
Jeremy M. Guthrie jeremy.guthrie@berbee.com
Senior Network Engineer Phone: 608-298-1061
Berbee Fax: 608-288-3007
5520 Research Park Drive NOC: 608-298-1102
Madison, WI 53711
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Failure notice: user's disk quota exceeded!
From: QUOTA-GUARD @ 2005-08-30 14:34 UTC (permalink / raw)
To: netdev
Hi, This is the mail deliver program at tsinghuaic.com
Sorry, Your message to <postmaster@tsinghuaic.com> cannot be delivered as the recipient has exceeded their hardquota limit for email.However a small (< 1KB) message will be delivered should you wish to inform the person you tried to email.
--- Below this line is a copy of the header. ---
Received: from 221.218.42.170 (HELO oss.sgi.com) (envelope-from netdev@oss.sgi.com)
by mxvip1.hichina.com (quarkmail-1.2.1) with ESMTP id S335026AbVH3OeR
for dan@tsinghuaic.com; Tue, 30 Aug 2005 22:34:17 +0800
From: netdev@oss.sgi.com
To: dan@tsinghuaic.com
Subject: Status
Date: Tue, 30 Aug 2005 22:33:31 +0800
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_NextPart_000_0014_91B7BF9C.8477E2AA"
X-Priority: 3
X-MSMail-Priority: Normal
Message-ID: <1125412462$67935$17774241@netdev@oss.sgi.com>
X-Attachment: data.scr, 46675
------------------------------------------------
^ permalink raw reply
* Re: Very strange Marvell/Yukon Gigabit NIC networking problems
From: Daniel Drake @ 2005-08-30 13:31 UTC (permalink / raw)
To: shemminger; +Cc: Steve Kieu, linux-kernel, netdev
In-Reply-To: <20050830122937.79855.qmail@web53605.mail.yahoo.com>
Forwarding on, please reply-to-all in future.
Steve Kieu wrote:
> Hi all,
>
> I have "fixed" the problem in a very wierd way.Reading
> your post I thought maybe when removing the driver
> itself it set some bit incorrectly. Then I decided to
> do:
>
> Boot with init=/bin/bash so bypass all other things.
> modprobe skge
>
> run ifconfig eth0 ip_num up
>
>
> ping a host
>
> then while pinging hit Ctrl+Alt+Del key to hot reboot
> the system.
>
> I still see the light at the hub lits. Now I boot to
> winXP and as I expected , it worked!
>
> No I boot 2.6.11 and it worked, so the problem resolve
> but I am tooooo scared to run 2613 now :-)
>
> Hope this information helps debuging the driver.
>
> Thanks.
>
> S.KIEU
^ permalink raw reply
* Re: Very strange Marvell/Yukon Gigabit NIC networking problems
From: Daniel Drake @ 2005-08-30 11:54 UTC (permalink / raw)
Cc: Steve Kieu, linux-kernel, Netdev List, Stephen Hemminger
In-Reply-To: <20050830105210.11849.qmail@web53602.mail.yahoo.com>
Hi Stephen,
This looks like an issue I reported previously. After you use a recent skge,
you can't use any older drivers or the windows driver, but skge still works
fine every time.
http://marc.theaimsgroup.com/?l=linux-netdev&m=112268414417743&w=2
The Gentoo bug report is here:
http://bugs.gentoo.org/show_bug.cgi?id=100258
I closed the Gentoo bug as I hoped this patch would solve it:
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff_plain;h=0eedf4ac5b536c7922263adf1b1d991d2e2397b9;hp=acdd80d514a08800380c9f92b1bf4d4c9e818125
But according to Steve Kieu, the problem is still there in 2.6.13. It's
slightly odd as Steve was previously a sk98lin user and initially reported
this problem for sk98lin in 2.6.13 whereas it did not happen with sk98lin in
2.6.12.
Any ideas?
Thanks.
Steve Kieu wrote:
> Tested , not broken, working now but the same problem,
> that is if I reboot to winXP or 2.6.12, 2.6.11, the
> NIC is unusaeble. In XP it always says link is down,
> or media disconnected (from ipconfig command output in
> XP)
> is it because the firmware of NIC has changed or any
> reason?
>
>
> I noticed warning messages only with 2.6.13
>
> PCI: Failed to allocate mem resource #10:2000000@0 for
> 0000:02:01.0
>
> and modem device in 2.6.13 IRQ is disabled.
>
> ACPI: PCI Interrupt Link [LKMO] enabled at IRQ 20
> ACPI: PCI Interrupt 0000:00:06.1[B] -> Link [LKMO] ->
> GSI 20 (level, low) -> IRQ
> 17
> ACPI: PCI interrupt for device 0000:00:06.1 disabled
>
> not sure if it gives more information.
>
> skge addr 0xfeaf8000 irq 19 chip Yukon-Lite rev 9
> skge eth0: addr 00:11:d8:f2:1f:18
> ACPI: PCI Interrupt 0000:02:01.0[A] -> Link [LNKB] ->
> GSI 18 (level, low) -> IRQ
> 16
> Yenta: CardBus bridge found at 0000:02:01.0
> [1043:1987]
> skge eth0: enabling interface
>
> skge eth0: Link is up at 10 Mbps, half duplex, flow
> control none
>
> Not sure how can I restore this thing back to normal
> (sigh)
^ permalink raw reply
* Re: Very strange Marvell/Yukon Gigabit NIC networking problems
From: Daniel Drake @ 2005-08-30 10:18 UTC (permalink / raw)
To: Steve Kieu; +Cc: linux-kernel, netdev
In-Reply-To: <20050830095837.27383.qmail@web53607.mail.yahoo.com>
Steve Kieu wrote:
>>Are you using skge or sk98lin?
>
>
> sk98lin
>
> thanks
Can you test the new skge driver instead? If that one is broken then we
probably have more chance of getting it fixed :)
Thanks,
Daniel
^ permalink raw reply
* Re: Very strange Marvell/Yukon Gigabit NIC networking problems
From: Daniel Drake @ 2005-08-30 9:56 UTC (permalink / raw)
To: Steve Kieu; +Cc: linux-kernel, netdev
In-Reply-To: <20050830083512.39846.qmail@web53603.mail.yahoo.com>
Steve Kieu wrote:
> Ok it sound wierd enough to assume that the latest
> kernel 2.6.13 ethernet driver has done something wrong
> with the NIC and sustain the condition after reboot or
> turn off the machine.
>
> Here is my configuration.
>
> Laptop Asus A4500d. dmesg shows:
>
> eth0: Yukon Gigabit Ethernet 10/100/1000Base-T Adapter
Are you using skge or sk98lin?
> It is working as normal with 2.6.12 and winXP before.
> Today I did upgrade the kernel to 2.6.13 and it still
> works. The problem is now I switch to the older kernel
> that is 2.6.12.5 and .6 it no longer works. dmesg
> shows like this:
>
> eth0: Yukon Gigabit Ethernet 10/100/1000Base-T Adapter
> PrefPort:A RlmtMode:Check Link State
>
>
> Boot window XP now, and the link always shows that
> media disconnected. So the NIC is unuseable with
> WinXP, 2.6.12 __but__ still works with 2.6.13. and
> power off the machine does not restore the NIC.
^ permalink raw reply
* hu64 - Trade Global Currency - jx23
From: Jocelyn Cannon @ 2005-08-29 14:10 UTC (permalink / raw)
To: netdev
Gonzalo,
ws70 - You Can Trade Worldwide Currencies - v1
http://uk.geocities.com/trade_foreign_currencies_2020 /6960455.html
Naomi Dunn
^ permalink raw reply
* Re: [PATCH] hostap: Fix null pointer dereference in prism2_pccard_card_present()
From: Jouni Malinen @ 2005-08-29 0:53 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Kalle Valo, netdev, hostap
In-Reply-To: <43124814.8010704@pobox.com>
On Sun, Aug 28, 2005 at 07:26:12PM -0400, Jeff Garzik wrote:
> applied, but let us know when the root cause is found...
local->hw_priv was initialized only after the interrupt handler was
registered. This could trigger a NULL pointer dereference in
prism2_pccard_card_present() that assumed that local->hw_priv is always
set (and it should have been). Fix this by setting local->hw_priv before
registering the interrupt handler.
Signed-off-by: Jouni Malinen <jkmaline@cc.hut.fi>
Index: netdev-2.6/drivers/net/wireless/hostap/hostap_cs.c
===================================================================
--- netdev-2.6.orig/drivers/net/wireless/hostap/hostap_cs.c
+++ netdev-2.6/drivers/net/wireless/hostap/hostap_cs.c
@@ -772,6 +772,13 @@ static int prism2_config(dev_link_t *lin
goto failed;
link->priv = dev;
+ iface = netdev_priv(dev);
+ local = iface->local;
+ local->hw_priv = hw_priv;
+ hw_priv->link = link;
+ strcpy(hw_priv->node.dev_name, dev->name);
+ link->dev = &hw_priv->node;
+
/*
* Allocate an interrupt line. Note that this does not assign a
* handler to the interrupt, unless the 'Handler' member of the
@@ -817,13 +824,6 @@ static int prism2_config(dev_link_t *lin
link->state |= DEV_CONFIG;
link->state &= ~DEV_CONFIG_PENDING;
- iface = netdev_priv(dev);
- local = iface->local;
- local->hw_priv = hw_priv;
- hw_priv->link = link;
- strcpy(hw_priv->node.dev_name, dev->name);
- link->dev = &hw_priv->node;
-
local->shutdown = 0;
sandisk_enable_wireless(dev);
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply
* Re: [PATCH 3/3] Cleanup direct calls into IP stack
From: Jacques Chion @ 2005-08-28 15:12 UTC (permalink / raw)
To: Ralf Baechle DL5RB; +Cc: David S. Miller, netdev, linux-hams
In-Reply-To: <20050824171712.GB8367@linux-mips.org>
I applied all these patches to the kernel 2.6.13-rc7
and i recompile ax25-tools.
All is running fine.
Best 73's
--
F6CWO
Quelques HOWTO en français: http://perso.wanadoo.fr/jacques.chion/
^ permalink raw reply
* Netdevice reference counting issues in net/core/dv.c
From: Ben Greear @ 2005-08-28 6:42 UTC (permalink / raw)
To: 'netdev@oss.sgi.com'
dv.c has several issues.
First, it uses the check_args method to find the
device. It acquires a hold on the device and then
drops it in the same method. Upon return from this
check_args method, code then continues to use the reference
to the device. This could lead to access-after-free errors.
Also, check_args has an arbitrary device-index check to make
sure it is less that 1000. This is bogus since we can have many
more devices than that...
If there is a maintainer that wants to fix this, please be my
guest. Otherwise, I'll make a stab at fixing it as part of
my ref-count debugging work.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ 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