From: Andrew Morton <[EMAIL PROTECTED]>
Date: Sat, 16 Feb 2008 11:26:18 -0800
> On Sat, 16 Feb 2008 13:03:54 +0100 Eric Dumazet <[EMAIL PROTECTED]> wrote:
>
> > Yes, per connection basis. Some workloads want to open/close more than 1000
> > sockets per second.
>
> ie: slowpath
Definitely not s
Patch 0/16 and 15/16 of this series are getting dropped by the
spam filter. I am trying to get them across with changes
that will please the spam filter. Sorry about the inconvenience.
Below is the 0/16 of the series.
--
Hi,
I am sending a patch for network driver for S
F/W header files.
---
diff -uprN
orig/linux-2.6.24.2/drivers/message/beclib/fw/bmap/iscsi_common_host_struct_bmap.h
benet/linux-2.6.24.2/drivers/message/beclib/fw/bmap/iscsi_common_host_struct_bmap.h
---
orig/linux-2.6.24.2/drivers/message/beclib/fw/bmap/iscsi_common_host_
F/W header files.
--
diff -uprN
orig/linux-2.6.24.2/drivers/message/beclib/fw/bmap/iscsi_initiator_host_struct_bmap.h
benet/linux-2.6.24.2/drivers/message/beclib/fw/bmap/iscsi_initiator_host_struct_bmap.h
---
orig/linux-2.6.24.2/drivers/message/beclib/fw/bmap/iscsi_initiator_ho
F/W header files.
---
diff -uprN
orig/linux-2.6.24.2/drivers/message/beclib/fw/bmap/ioctl_types_bmap.h
benet/linux-2.6.24.2/drivers/message/beclib/fw/bmap/ioctl_types_bmap.h
--- orig/linux-2.6.24.2/drivers/message/beclib/fw/bmap/ioctl_types_bmap.h
1970-01-01 05:30:00.0
System abstraction function for Linux. beclib uses these helper routines /
macros to do OS dependent functions.
diff -uprN orig/linux-2.6.24.2/drivers/message/beclib/sa/setypes.h
benet/linux-2.6.24.2/drivers/message/beclib/sa/setypes.h
--- orig/linux-2.6.24.2/drivers/messag
Ether ring creation function in beclib.
---
diff -uprN orig/linux-2.6.24.2/drivers/message/beclib/ethtx_ll.c
benet/linux-2.6.24.2/drivers/message/beclib/ethtx_ll.c
--- orig/linux-2.6.24.2/drivers/message/beclib/ethtx_ll.c 1970-01-01
05:30:00.0 +0530
++
beclib header files.
---
diff -uprN orig/linux-2.6.24.2/drivers/message/beclib/pch.h
benet/linux-2.6.24.2/drivers/message/beclib/pch.h
--- orig/linux-2.6.24.2/drivers/message/beclib/pch.h1970-01-01
05:30:00.0 +0530
+++ benet/linux-2.6.24.2/drivers/message/beclib/p
NIC driver transmit and interrupt / completion processing functions.
diff -uprN orig/linux-2.6.24.2/drivers/net/benet/be_int.c
benet/linux-2.6.24.2/drivers/net/benet/be_int.c
--- orig/linux-2.6.24.2/drivers/net/benet/be_int.c 1970-01-01
05:30:00.0 +0530
+++ benet/li
Server is fully redundant now, so i apply patches (but i apply both, probably
it will make system more reliable somehow) and i enable required debug
options in kernel. So i will try to catch this bug few more times, probably
if it will generate more detailed info over netconsole it will be usefu
[ 58.097923] =
[ 58.098883] [ INFO: possible recursive locking detected ]
[ 58.099603] 2.6.25-rc2-1avb #1
[ 58.100013] -
[ 58.100672] wpa_supplicant/2682 is trying to acquire lock:
[ 58.100672] (dev
On Sat, Feb 16, 2008 at 12:25:31PM +0200, Denys Fedoryshchenko wrote:
> Thanks, i will try it.
> You think lockdep can be buggy?
Just like every code... But the main reason is it has quite meaningful
overhead, so could be right "in production" only after lockups happen.
But if it doesn't report an
Here's a patch with cleanups and without various encoding bugs.
Can you verify it still works?
Also, some of the Prolific chips use some bizarre control requests,
which by all rights should not be needed. They seem to exist only
to cope with things the device firmware should have handled ... like
On Sat, 16 Feb 2008 11:26:18 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
> > indirect functions calls are everywhere in kernel, network, fs,
> > everywhere.
>
> That doesn't make them fast.
just to emphasize this: an indirect function call is at least as expensive as
an atomic operation on
The mv643xx_eth driver can be loaded as a platform device, as is done by
various Orion (ARM) based devices. The driver needs to define a module
alias for the platform driver so udev will load it automatically.
Tested with Debian on a QNAP TS-209.
Signed-off-by: Martin Michlmayr <[EMAIL PROTECTED]
Also suggested by Herbert Xu, using workqueue is better than timer
for net/xfrm/xfrm_state.c, so replace them with delayed_work.
Note that, this patch is not fully tested, just compile and
run as a whole on an Intel Core Duo matchine. So should be
in -mm first.
Signed-off-by: WANG Cong <[EMAIL P
As suggested by Herbert, using workqueue is better than timer
for net/xfrm/xfrm_policy.c, so replace them with delayed_work.
Note that, this patch is not fully tested, just compile and
run as a whole on an Intel Core Duo matchine. So should be
in -mm first.
Signed-off-by: WANG Cong <[EMAIL PROTE
Andrew Morton a écrit :
On Sat, 16 Feb 2008 11:07:29 +0100 Eric Dumazet <[EMAIL PROTECTED]> wrote:
Andrew, pcounter is a temporary abstraction.
It's buggy! Main problems are a) possible return of negative numbers b)
some of the API can't be from preemptible code c) excessive interrupt-off
ti
<#part type=text/plain nofile=yes>
Any comments on this? Apparently introduced in 2.1.68, so there's not
much hurry. But I'd still like to hear whether that analysis is correct
or not...
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="==-=-="
The bug did bite at least one user, who di
On Sat, 16 Feb 2008 11:07:29 +0100 Eric Dumazet <[EMAIL PROTECTED]> wrote:
>
> Andrew, pcounter is a temporary abstraction.
It's buggy! Main problems are a) possible return of negative numbers b)
some of the API can't be from preemptible code c) excessive interrupt-off
time on some machines if
Thanks, i will try it.
You think lockdep can be buggy?
On Sat, 16 Feb 2008 09:00:36 +0100, Jarek Poplawski wrote
> Denys Fedoryshchenko wrote, On 02/13/2008 09:13 AM:
>
> > It is very difficult to reproduce, happened after running about 1month.
No
> > changes done in classes at time of crash.
>
Andrew Morton a écrit :
- First up, why was this added at all? We have percpu_counter.h which
has several years development invested in it. afaict it would suit the
present applications of pcounters.
If some deficiency in percpu_counters has been identified, is it
possible to correct t
On Jan 8, 2008 5:23 AM, David Miller <[EMAIL PROTECTED]> wrote:
> I am going to push this patch upstream, it is correct and we
> have a positive test case that failed before, so overall it's
> a net improvement even if we still don't exactly know why
> Adolfo's case still fails.
Sorry it took so l
23 matches
Mail list logo
