Replacing kmalloc/memset combination with kzalloc.
Signed-off-by: vignesh babu [EMAIL PROTECTED]
---
diff --git a/drivers/net/sb1250-mac.c b/drivers/net/sb1250-mac.c
index 103c317..af7649f 100644
--- a/drivers/net/sb1250-mac.c
+++ b/drivers/net/sb1250-mac.c
@@ -735,8 +735,8 @@ static void
Ethernet bugfixes:
* Move the was_full/wake_queue logic from tx_intr to clean_tx
* Fix polarity in checks in pasemi_mac_close
Signed-off-by: Olof Johansson [EMAIL PROTECTED]
Index: linux-2.6/drivers/net/pasemi_mac.c
===
---
Hi,
The four following patches contain a number of fixes and improvements
of the pasemi_mac driver:
1/4: A couple of minor bugfixes.
2/4: Move the IRQ mapping from the PCI layer under our platform, to
the driver.
3/4: A rather large patch with various NAPI/performance-related fixes
and
Jamie webb wrote:
Well, so far so good. I'll let you know if it happens again, but it
looks like that's fixed it.
Further testing showed that I also had to disable rx checksumming,
otherwise I was getting random kernel crashes. Presumably it was not
only reading data from random
That's right. See the discussion on a similar problem here:
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=10
59644admit=-682735245+1158251313899+28353475
That's an AMD machine.
In this other case, the symptoms were very similar to yours.
I suspected it was an
On Mon, 2007-04-16 at 01:18 -0500, Olof Johansson wrote:
Fixes for ethernet IRQ mapping, to move it to the driver instead of in
the platform setup code.
Signed-off-by: Olof Johansson [EMAIL PROTECTED]
Index: powerpc/arch/powerpc/platforms/pasemi/pci.c
NAPI fixes and cleanups for pasemi_mac:
* Timer changes/fixes
* Abstract out the rx intr restart to a separate function
* Similar function for tx intr to reset to a known clear state even if
firmware used the same interface
* Add a copy-break and recycle the SKB in the driver for small
PHY support for pasemi_mac. Also add msg_enable flags for future
disablement of the link messages.
Signed-off-by: Olof Johansson [EMAIL PROTECTED]
Index: powerpc/drivers/net/pasemi_mac.c
===
---
Fixes for ethernet IRQ mapping, to move it to the driver instead of in
the platform setup code.
Signed-off-by: Olof Johansson [EMAIL PROTECTED]
Index: powerpc/arch/powerpc/platforms/pasemi/pci.c
===
---
Andi Kleen wrote:
tg3s never use the IOMMU on AMD systems with production kernels
because they have a suitably large DMA mask. IOMMU is only used
there to remap memory that doesn't fit a device's DMA mask.
There is a debugging mode to force iommu always, but it is not used
unless you
On Mon, Apr 16, 2007 at 01:16:54AM -0500, Olof Johansson wrote:
Hi,
The four following patches contain a number of fixes and improvements
of the pasemi_mac driver:
I just realized that these have been based on top of some OF API changes
that are in paulus' for-2.6.22 tree, and won't build on
[RTNETLINK]: Hold rtnl_mutex during netlink dump callbacks
Hold rtnl_mutex during the entire netlink dump operation. This allows
to simplify locking in the dump callbacks, since they can now rely on
that no concurrent changes happen.
Signed-off-by: Patrick McHardy [EMAIL PROTECTED]
---
commit
[RTNETLINK]: Remove unnecessary locking in dump callbacks
Since we're now holding the rtnl during the entire dump operation, we can
remove additional locking for rtnl protected data. This patch does that
for all simple cases (dev_base_lock for dev_base walking, RCU protection
for FIB rule
[NET_SCHED]: Eliminate qdisc_tree_lock
Since we're now holding the rtnl during the entire dump operation, we
can remove qdisc_tree_lock, whose only purpose is to protect dump
callbacks from concurrent changes to the qdisc tree.
Signed-off-by: Patrick McHardy [EMAIL PROTECTED]
---
commit
This patch fixes a few spots for using ingress_lock for the ingress
qdisc again and switches ing_filter back to use it.
Applies on top of the netlink dump patches.
[NET_SCHED]: ingress: switch back to using ingress_lock
Switch ingress queueing back to use ingress_lock. qdisc_lock_tree now locks
* Willy Tarreau [EMAIL PROTECTED] 2007-04-14 17:48
Finally, I think I have the correct fix below. Please someone confirm
or tell me I'm nuts.
Looks good, same is needed for DECnet
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
On Mon, Apr 16, 2007 at 10:14:17AM +0200, Thomas Graf wrote:
* Willy Tarreau [EMAIL PROTECTED] 2007-04-14 17:48
Finally, I think I have the correct fix below. Please someone confirm
or tell me I'm nuts.
Looks good, same is needed for DECnet
Thank you Thomas.
The DECnet stuff was already
in4_pton converts a textual representation of an ip4 address into an
integer representation. However, when the textual representation is of in
the form ip:port, c.f. 192.168.1.1:5060, and 'delim' is set to -1, the
function bails out when parsing the colon.
It makes sense to allow the colon as
Jerome Borsboom wrote:
in4_pton converts a textual representation of an ip4 address into an
integer representation. However, when the textual representation is of
in the form ip:port, c.f. 192.168.1.1:5060, and 'delim' is set to -1,
the function bails out when parsing the colon.
It makes
On 4/12/07, Stephen Hemminger [EMAIL PROTECTED] wrote:
Aubrey Li wrote:
I think we discussed this issue before.
The current checksum function doesn't consider the kind of packet
which is padded to reach a specific minimum length. I believe that's
the problem caused my test case failed. Is
Pavel Emelianov wrote:
From: Denis Lunev [EMAIL PROTECTED]
There is a race between netlink_dump_start() and netlink_release()
that can lead to the situation when a netlink socket with non-zero
callback is freed.
Can you describe the race in more detail please?
-
To unsubscribe from this
Manual completion to func(sk, tp, ...) - func(sk, ...)
conversion.
Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED]
---
net/ipv4/tcp_input.c |1 -
net/ipv4/tcp_output.c |3 ---
2 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index
Improves readability a bit here and there (this is likely less
than complete change anyway).
Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED]
---
net/ipv4/tcp_input.c | 10 ++
net/ipv4/tcp_output.c |2 ++
2 files changed, 12 insertions(+), 0 deletions(-)
diff --git
This is fully automated change using this magic:
sed -e '/struct sock \*sk/ N' -e '/struct sock \*sk/ N'
-e '/struct sock \*sk/ N' -e '/struct sock \*sk/ N'
-e 's|struct sock \*sk,[\n\t ]*struct tcp_sock \*tp\([^{]*\n{\n\)|
struct sock \*sk\1\tstruct tcp_sock *tp =
Pavel Emelianov wrote:
Patrick McHardy wrote:
There is a race between netlink_dump_start() and netlink_release()
that can lead to the situation when a netlink socket with non-zero
callback is freed.
Can you describe the race in more detail please?
Here it is:
[...]
The proposal it to
It would be easier if you sent all bits in a single patch, it's
one logical change after all, and a rather small one aswell.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Mon, 16 Apr 2007, Christoph Hellwig wrote:
It would be easier if you sent all bits in a single patch, it's
one logical change after all, and a rather small one aswell.
Here it is the way you requested...
[PATCH] [TCP]: Sed magic converts func(sk, tp, ...) - func(sk, ...)
This is (mostly)
Ilpo Järvinen wrote:
Tweaked newlines manually fixed four warnings that were
introduced.
Not all of them it seems:
-static inline void tcp_fast_path_check(struct sock *sk, struct tcp_sock *tp)
+static inline void tcp_fast_path_check(struct sock *sk)
{
+ struct tcp_sock *tp =
Lennart Sorensen wrote:
Which PCI host controller are you using with the PXA255? We tried using
a PXA255 based system with a PCI controller a couple of years ago and
have to change to a different cpu in the end due to the PCI controller
simply not being valid PCI. The PXA255 wasn't designed
On Mon, 16 Apr 2007, Patrick McHardy wrote:
Ilpo Järvinen wrote:
Tweaked newlines manually fixed four warnings that were
introduced.
Not all of them it seems:
-static inline void tcp_fast_path_check(struct sock *sk, struct tcp_sock
*tp)
+static inline void
Ilpo Järvinen wrote:
On Mon, 16 Apr 2007, Patrick McHardy wrote:
[...]
...in the other (original) patch description that is not copied fully here
I had a sort of disclaimer for these missing ones but in case they should
all be changed so that if the added tcp_sock is the only local
On Mon, 16 Apr 2007, Patrick McHardy wrote:
Ilpo Järvinen wrote:
On Mon, 16 Apr 2007, Patrick McHardy wrote:
[...] It's not clear to me what is really the preferred
style considering all the variants... [...]
The preferred style is a newline after variable declarations. Some
On Mon, 16 Apr 2007, Patrick McHardy wrote:
The preferred style is a newline after variable declarations. Some
(mostly old) code doesn't consistently do that, but in cases where
you add the first local variable you should really add them.
...No newline should be place here, since it's being
Dave Jones wrote:
I booted up 2.6.21rc7 without an ethernet cable plugged in,
and noticed this..
e1000: :02:00.0: e1000_probe: The EEPROM Checksum Is Not Valid
e1000: probe of :02:00.0 failed with error -5
I plugged a cable in, did rmmod e1000;modprobe e1000, and got this..
On Fri, 13 Apr 2007 08:39:31 -0700
Linsys Contractor Mithlesh Thukral [EMAIL PROTECTED] wrote:
NetXen: Fix the multi PCI function for cards with more than 2 ports.
This patch fixes the working of multi PCI capable driver on cards with
more than 2 ports by adding the addresses for their rings
Robert Iakobashvili wrote:
Hi John,
On 4/15/07, John Heffner [EMAIL PROTECTED] wrote:
Robert Iakobashvili wrote:
Vanilla 2.6.18.3 works for me perfectly, whereas 2.6.19.5 and
2.6.20.6 do not.
Looking into the tcp /proc entries of 2.6.18.3 versus 2.6.19.5
tcp_rmem and tcp_wmem are the
[cc:ed to netdev]
On Sun, Apr 15, 2007 at 10:45:37PM -0700, Mike Mattie wrote:
Hello,
netconsole is hanging my box during IDE init.
I am running 2.6.20.7, config is attached from /proc
Without using netconsole the kernel boots fine. I am writing this message
from it.
When I do
On Sat, 2007-04-14 at 17:20 -0700, Michael Chan wrote:
I also like Andi's idea of using change_page_attr() to isolate the
problem. I'll try to send you a debug patch in the next few days to try
that out. Thanks.
Here's the debug patch for x86 only that will change the statistics
memory
Robert Iakobashvili wrote:
Vanilla 2.6.18.3 works for me perfectly, whereas 2.6.19.5 and
2.6.20.6 do not.
Looking into the tcp /proc entries of 2.6.18.3 versus 2.6.19.5
tcp_rmem and tcp_wmem are the same, whereas tcp_mem are
much different:
kernel tcp_mem
Robert Iakobashvili wrote:
Kernels 2.6.19 and 2.6.20 series are effectively broken right now.
Don't you wish to patch them?
I don't know if this qualifies as an unconditional bug. The commit
above was actually a bugfix so that the limits were not higher than
total memory on some systems,
From: Robert Iakobashvili [EMAIL PROTECTED]
Date: Mon, 16 Apr 2007 20:51:54 +0200
Commit: 53cdcc04c1e85d4e423b2822b66149b6f2e52c2c
Author: John Heffner [EMAIL PROTECTED] Fri, 16 Mar 2007 15:04:03 -0700
[TCP]: Fix tcp_mem[] initialization.
Change tcp_mem initialization
From: John Heffner [EMAIL PROTECTED]
Date: Mon, 16 Apr 2007 15:11:07 -0400
I don't know if this qualifies as an unconditional bug. The commit
above was actually a bugfix so that the limits were not higher than
total memory on some systems, but had the side effect that it made them
even
On 4/15/07, Dave Jones [EMAIL PROTECTED] wrote:
I booted up 2.6.21rc7 without an ethernet cable plugged in,
and noticed this..
e1000: :02:00.0: e1000_probe: The EEPROM Checksum Is Not Valid
e1000: probe of :02:00.0 failed with error -5
I plugged a cable in, did rmmod e1000;modprobe
Greetings!
I have a SuSE 10.2 64-bit installation that uses a Realtek PCI GbE chip in
D-Link disguise (lspci see below).
While this works rather well after a normal boot sequence, I don't get a
gigabit link after resume from standby or suspend-to-disk.
Entering standby, the link speed goes
On Mon, 16 Apr 2007 13:35:47 -0700 [EMAIL PROTECTED] wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=8338
Summary: NAT of TCP connections broken
Kernel Version: 2.6.20.7
Status: NEW
Severity: high
Owner: [EMAIL PROTECTED]
://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.21-rc7/r8169-20070416
-
http://www.fr.zoreil.com/people/francois/misc/20070416-2.6.21-rc7-r8169-test.patch
If it does not work better, please fill an entry for it at bugzilla.kernel.org,
Cc: it to me and attach the output of a registers dump taken from mii-tool
before
I'm seeing some weird behavior in TCP. The issue is perfectly
reproducible using netcat and other programs. This is what I do:
1. Open a TCP connection over the loopback (over IPv4).
2. Send a couple of bytes of data each way. No problems.
3. Wait about 120 hours with no
On Mon, 16 Apr 2007 16:28:22 -0600
Sebastian Kuzminsky [EMAIL PROTECTED] wrote:
I'm seeing some weird behavior in TCP. The issue is perfectly
reproducible using netcat and other programs. This is what I do:
1. Open a TCP connection over the loopback (over IPv4).
2. Send a
Stephen Hemminger [EMAIL PROTECTED] wrote:
On Mon, 16 Apr 2007 16:28:22 -0600
Sebastian Kuzminsky [EMAIL PROTECTED] wrote:
I'm seeing some weird behavior in TCP. The issue is perfectly
reproducible using netcat and other programs. This is what I do:
1. Open a TCP connection
On Mon, Apr 16, 2007 at 12:10:51PM -0700, Michael Chan wrote:
On Sat, 2007-04-14 at 17:20 -0700, Michael Chan wrote:
I also like Andi's idea of using change_page_attr() to isolate the
problem. I'll try to send you a debug patch in the next few days to try
that out. Thanks.
Here's the
On Mon, 16 Apr 2007 17:05:42 -0600
Sebastian Kuzminsky [EMAIL PROTECTED] wrote:
Stephen Hemminger [EMAIL PROTECTED] wrote:
On Mon, 16 Apr 2007 16:28:22 -0600
Sebastian Kuzminsky [EMAIL PROTECTED] wrote:
I'm seeing some weird behavior in TCP. The issue is perfectly
reproducible
From: Patrick McHardy [EMAIL PROTECTED]
Date: Mon, 16 Apr 2007 09:51:53 +0200 (MEST)
[NETLINK]: Switch cb_lock spinlock to mutex and allow to override it
Switch cb_lock to mutex and allow netlink kernel users to override it
with a subsystem specific mutex for consistent locking in dump
From: Patrick McHardy [EMAIL PROTECTED]
Date: Mon, 16 Apr 2007 09:51:54 +0200 (MEST)
[RTNETLINK]: Hold rtnl_mutex during netlink dump callbacks
Hold rtnl_mutex during the entire netlink dump operation. This allows
to simplify locking in the dump callbacks, since they can now rely on
that no
From: Patrick McHardy [EMAIL PROTECTED]
Date: Mon, 16 Apr 2007 09:51:55 +0200 (MEST)
[RTNETLINK]: Remove unnecessary locking in dump callbacks
Since we're now holding the rtnl during the entire dump operation, we can
remove additional locking for rtnl protected data. This patch does that
From: Patrick McHardy [EMAIL PROTECTED]
Date: Mon, 16 Apr 2007 09:51:57 +0200 (MEST)
[NET_SCHED]: Eliminate qdisc_tree_lock
Since we're now holding the rtnl during the entire dump operation, we
can remove qdisc_tree_lock, whose only purpose is to protect dump
callbacks from concurrent
From: Patrick McHardy [EMAIL PROTECTED]
Date: Mon, 16 Apr 2007 09:53:55 +0200
This patch fixes a few spots for using ingress_lock for the ingress
qdisc again and switches ing_filter back to use it.
Applies on top of the netlink dump patches.
Applied, thanks a lot for following up on this
From: Patrick McHardy [EMAIL PROTECTED]
Date: Mon, 16 Apr 2007 06:59:06 +0200
RTM_DELROUTE + RTM_NEWROUTE seem to be safer, although you're correct
that it might cause userspace to perform some action upon receiving
the DELROUTE message since the update is non-atomic. So I really don't
know,
Adrian Bunk wrote:
Subject: laptops with e1000: lockups
References :
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229603
Submitter : Dave Jones [EMAIL PROTECTED]
Handled-By : Jesse Brandeburg [EMAIL PROTECTED]
Status : problem is being debugged
this is being actively
From: Ilpo_Järvinen [EMAIL PROTECTED]
Date: Mon, 16 Apr 2007 19:19:02 +0300 (EEST)
[PATCH] [TCP]: Sed magic converts func(sk, tp, ...) - func(sk, ...)
I was trying to spread out the net-2.6.22 tree from the tcp-2.6
one so that we could do the experimental TCP stuff in the tcp-2.6
tree and leave
On Mon, Apr 16, 2007 at 05:14:40PM -0700, Brandeburg, Jesse wrote:
Adrian Bunk wrote:
Subject: laptops with e1000: lockups
References :
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229603
Submitter : Dave Jones [EMAIL PROTECTED]
Handled-By : Jesse Brandeburg [EMAIL
Dave Jones wrote:
On Mon, Apr 16, 2007 at 05:14:40PM -0700, Brandeburg, Jesse wrote:
Adrian Bunk wrote:
Subject: laptops with e1000: lockups
References :
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229603
Submitter : Dave Jones [EMAIL PROTECTED]
Handled-By :
drivers/net/ibmveth.c:96:46: error: marked inline, but without a definition
drivers/net/ibmveth.c:96: warning: 'ibmveth_rxq_harvest_buffer' declared inline
after being called
drivers/net/ibmveth.c:96: warning: previous declaration of
'ibmveth_rxq_harvest_buffer' was here
Just let the compiler
Stephen Hemminger [EMAIL PROTECTED] wrote:
A guess: maybe something related to a PAWS wraparound problem.
Does turning off sysctl net.ipv4.tcp_timestamps fix it?
I just started this test, I'll let you know in 5 days. :-/
Any other things I should try, anyone? I'm doing the new tests under
Stephen Hemminger wrote:
A guess: maybe something related to a PAWS wraparound problem.
Does turning off sysctl net.ipv4.tcp_timestamps fix it?
That was my first thought too (aside from netfilter), but a failed PAWS
check should not result in a reset..
-John
-
To unsubscribe from this
John Heffner [EMAIL PROTECTED] wrote:
Stephen Hemminger wrote:
A guess: maybe something related to a PAWS wraparound problem.
Does turning off sysctl net.ipv4.tcp_timestamps fix it?
That was my first thought too (aside from netfilter), but a failed PAWS
check should not result in a
Sebastian Kuzminsky wrote:
I'm seeing some weird behavior in TCP. The issue is perfectly
reproducible using netcat and other programs. This is what I do:
1. Open a TCP connection over the loopback (over IPv4).
2. Send a couple of bytes of data each way. No problems.
3.
Philip Craig [EMAIL PROTECTED] wrote:
It sounds like it could easily be iptables related, if you have iptables
rules that only allow new connections in the client to server direction,
which is quite normal.
Sure I have those standard rules.
iptables -A INPUT -p tcp -m state --state
67 matches
Mail list logo
