Re: [PATCH] mpt2sas: don't handle broadcast primitives

2013-07-24 Thread Baruch Even
On Sat, Jul 20, 2013 at 1:11 AM, Jörn Engel wrote: > On Fri, 19 July 2013 18:06:59 -0400, Jörn Engel wrote: >> >> The handling of broadcast primitives involves >> _scsih_block_io_all_device(), which does what the name implies. I have >> observed cases with >60s of blocking io on all devices,

Re: [PATCH] mpt2sas: don't handle broadcast primitives

2013-07-24 Thread Baruch Even
On Sat, Jul 20, 2013 at 1:11 AM, Jörn Engel jo...@logfs.org wrote: On Fri, 19 July 2013 18:06:59 -0400, Jörn Engel wrote: The handling of broadcast primitives involves _scsih_block_io_all_device(), which does what the name implies. I have observed cases with 60s of blocking io on all

Re: Unexpected Acknowledgement / Stalled Connections

2007-02-04 Thread Baruch Even
* Parag Warudkar <[EMAIL PROTECTED]> [070205 00:57]: > On 2/4/07, Parag Warudkar <[EMAIL PROTECTED]> wrote: > >I am running 2.6.20 and have trouble with stalled connections. For > >instance, if I try to download a debian ISO image using wget, the > >connection runs fine for few seconds and then

Re: Unexpected Acknowledgement / Stalled Connections

2007-02-04 Thread Baruch Even
* Parag Warudkar [EMAIL PROTECTED] [070205 00:57]: On 2/4/07, Parag Warudkar [EMAIL PROTECTED] wrote: I am running 2.6.20 and have trouble with stalled connections. For instance, if I try to download a debian ISO image using wget, the connection runs fine for few seconds and then stalls for

[PATCH] proc_ipmi_root depends on CONFIG_PROC_FS

2005-08-17 Thread Baruch Even
proc_ipmi_root is only defined for CONFIG_PROC_FS, #ifdef it for export as well. Signed-Off-By: Baruch Even <[EMAIL PROTECTED]> -- drivers/char/ipmi/ipmi_msghandler.c |2 ++ 1 files changed, 2 insertions(+) Index: k/drivers/char/ipmi/ipmi_msghan

[PATCH] proc_ipmi_root depends on CONFIG_PROC_FS

2005-08-17 Thread Baruch Even
proc_ipmi_root is only defined for CONFIG_PROC_FS, #ifdef it for export as well. Signed-Off-By: Baruch Even [EMAIL PROTECTED] -- drivers/char/ipmi/ipmi_msghandler.c |2 ++ 1 files changed, 2 insertions(+) Index: k/drivers/char/ipmi/ipmi_msghandler.c

Re: [2.6 patch] net: Spelling mistakes threshoulds -> thresholds

2005-07-29 Thread Baruch Even
Just simple spelling mistake fixes. Signed-Off-By: Baruch Even <[EMAIL PROTECTED]> diff -Nurp 2.6.13-rc4-orig/include/net/tcp.h 2.6.13-rc4/include/net/tcp.h --- 2.6.13-rc4-orig/include/net/tcp.h 2005-07-29 11:17:25.0 +0100 +++ 2.6.13-rc4/include/net/tcp.h2005-07-29

Re: [2.6 patch] net: Spelling mistakes threshoulds - thresholds

2005-07-29 Thread Baruch Even
Just simple spelling mistake fixes. Signed-Off-By: Baruch Even [EMAIL PROTECTED] diff -Nurp 2.6.13-rc4-orig/include/net/tcp.h 2.6.13-rc4/include/net/tcp.h --- 2.6.13-rc4-orig/include/net/tcp.h 2005-07-29 11:17:25.0 +0100 +++ 2.6.13-rc4/include/net/tcp.h2005-07-29 11:14

Re: Merging relayfs?

2005-07-12 Thread Baruch Even
Tomasz Kłoczko wrote: > On Mon, 11 Jul 2005, Tom Zanussi wrote: > >> >> Hi Andrew, can you please merge relayfs? It provides a low-overhead >> logging and buffering capability, which does not currently exist in >> the kernel. >> >> relayfs key features: >> >> - Extremely efficient high-speed

Re: Merging relayfs?

2005-07-12 Thread Baruch Even
Tom Zanussi wrote: > Andrew Morton writes: > > Tom Zanussi <[EMAIL PROTECTED]> wrote: > > > > > > Hi Andrew, can you please merge relayfs? > > > > I guess so. Would you have time to prepare a list of existing and planned > > applications? > > I've also added a couple of people to the cc:

Re: Merging relayfs?

2005-07-12 Thread Baruch Even
Tom Zanussi wrote: Andrew Morton writes: Tom Zanussi [EMAIL PROTECTED] wrote: Hi Andrew, can you please merge relayfs? I guess so. Would you have time to prepare a list of existing and planned applications? I've also added a couple of people to the cc: list that I've

Re: Merging relayfs?

2005-07-12 Thread Baruch Even
Tomasz Kłoczko wrote: On Mon, 11 Jul 2005, Tom Zanussi wrote: Hi Andrew, can you please merge relayfs? It provides a low-overhead logging and buffering capability, which does not currently exist in the kernel. relayfs key features: - Extremely efficient high-speed logging/buffering

Re: Exploit in 2.6 kernels

2005-04-12 Thread Baruch Even
You can find the source at http://www.securiteam.com/exploits/5VP0N0UF5U.html The fix: http://linux.bkbits.net:8080/linux-2.6/[EMAIL PROTECTED]|[EMAIL PROTECTED] CAN: http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0736 John M Collins wrote: Please CC any reply to jmc AT xisl.com as

Re: Exploit in 2.6 kernels

2005-04-12 Thread Baruch Even
You can find the source at http://www.securiteam.com/exploits/5VP0N0UF5U.html The fix: http://linux.bkbits.net:8080/linux-2.6/[EMAIL PROTECTED]|[EMAIL PROTECTED] CAN: http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0736 John M Collins wrote: Please CC any reply to jmc AT xisl.com as

[PATCH] Spelling mistake threshoulds -> thresholds

2005-04-05 Thread Baruch Even
Hi, Just a simple spelling mistake fix. Signed-Off-By: Baruch Even <[EMAIL PROTECTED]> diff -Nurp -X dontdiff 2.6.11.orig/include/net/tcp.h 2.6.11/include/net/tcp.h --- 2.6.11.orig/include/net/tcp.h 2005-03-16 00:09:00.0 + +++ 2.6.11/include/net/tcp.h 2005-04-05 14:33:13.473

[PATCH] Spelling mistake threshoulds - thresholds

2005-04-05 Thread Baruch Even
Hi, Just a simple spelling mistake fix. Signed-Off-By: Baruch Even [EMAIL PROTECTED] diff -Nurp -X dontdiff 2.6.11.orig/include/net/tcp.h 2.6.11/include/net/tcp.h --- 2.6.11.orig/include/net/tcp.h 2005-03-16 00:09:00.0 + +++ 2.6.11/include/net/tcp.h 2005-04-05 14:33:13.473828484 +0100

Re: Relayfs question

2005-03-19 Thread Baruch Even
Jan Engelhardt wrote: according to the relayfs description on opersys.com, |As the Linux kernel matures, there is an ever increasing number of facilities |and tools that need to relay large amounts of data from kernel space to user |space. Up to this point, each of these has had its own mechanism

Re: Relayfs question

2005-03-19 Thread Baruch Even
Jan Engelhardt wrote: according to the relayfs description on opersys.com, |As the Linux kernel matures, there is an ever increasing number of facilities |and tools that need to relay large amounts of data from kernel space to user |space. Up to this point, each of these has had its own mechanism

Re: bonnie++ uninterruptible under heavy I/O load

2005-03-11 Thread Baruch Even
Fabio Coatti wrote: Alle 12:35, venerdì 11 marzo 2005, Denis Vlasenko ha scritto: Unresponsiveness is not 2.6.11 specific (we've seen the same thing on 2.6.10 and 2.6.8), not I/O scheduler specific ("as" and "deadline" behave the same) and not CPU/SMP specific (reproduced on single P4 HT and

Re: bonnie++ uninterruptible under heavy I/O load

2005-03-11 Thread Baruch Even
Fabio Coatti wrote: Alle 12:35, venerdì 11 marzo 2005, Denis Vlasenko ha scritto: Unresponsiveness is not 2.6.11 specific (we've seen the same thing on 2.6.10 and 2.6.8), not I/O scheduler specific (as and deadline behave the same) and not CPU/SMP specific (reproduced on single P4 HT and single

Re: Time Drift Compensation on Linux Clusters

2005-03-03 Thread Baruch Even
Dror Cohen wrote: Hi all, While working on a Linux cluster with kernel version 2.4.27 we've encountered a consistent clock drift problem. We have devised a fix for this problem which is based on the Pentium's TSC clock. We'd appreciate any comments on the validity of the proposed solution and on

Re: Time Drift Compensation on Linux Clusters

2005-03-03 Thread Baruch Even
Dror Cohen wrote: Hi all, While working on a Linux cluster with kernel version 2.4.27 we've encountered a consistent clock drift problem. We have devised a fix for this problem which is based on the Pentium's TSC clock. We'd appreciate any comments on the validity of the proposed solution and on

Re: Network speed Linux-2.6.10

2005-03-02 Thread Baruch Even
Paul Dickson wrote: On Wed, 02 Mar 2005 01:02:50 +, Baruch Even wrote: Might this be related to the broken BicTCP implementations in the 2.6.6+ kernels? A fix was added around 2.6.11-rc3 or 4. Unlikely, the problem with BIC would have shown itself only at high speeds over long latency links

Re: Network speed Linux-2.6.10

2005-03-02 Thread Baruch Even
Paul Dickson wrote: On Wed, 02 Mar 2005 01:02:50 +, Baruch Even wrote: Might this be related to the broken BicTCP implementations in the 2.6.6+ kernels? A fix was added around 2.6.11-rc3 or 4. Unlikely, the problem with BIC would have shown itself only at high speeds over long latency links

Re: Network speed Linux-2.6.10

2005-03-01 Thread Baruch Even
Paul Dickson wrote: On Tue, 1 Mar 2005 14:29:24 -0500 (EST), linux-os wrote: Intel NIC e100 device driver. Two identical machines. Private network, no other devices. Connected using a Netgear switch. Test data is the same thing sent from memory on one machine to a discard server on another, using

Re: Network speed Linux-2.6.10

2005-03-01 Thread Baruch Even
Paul Dickson wrote: On Tue, 1 Mar 2005 14:29:24 -0500 (EST), linux-os wrote: Intel NIC e100 device driver. Two identical machines. Private network, no other devices. Connected using a Netgear switch. Test data is the same thing sent from memory on one machine to a discard server on another, using

Re: [PATCH] TCP-Hybla proposal

2005-02-22 Thread Baruch Even
Stephen Hemminger wrote: On Tue, 22 Feb 2005 15:34:42 +0100 Daniele Lacamera <[EMAIL PROTECTED]> wrote: One last note: IMHO we really need a better way to select congestion avoidance scheme between those available, instead of switching each one on and off. I.e., we can't say how vegas and

Re: [PATCH] TCP-Hybla proposal

2005-02-22 Thread Baruch Even
Stephen Hemminger wrote: On Tue, 22 Feb 2005 15:34:42 +0100 Daniele Lacamera [EMAIL PROTECTED] wrote: One last note: IMHO we really need a better way to select congestion avoidance scheme between those available, instead of switching each one on and off. I.e., we can't say how vegas and westwood

Re: [PATCH] /proc/kmalloc

2005-02-20 Thread Baruch Even
Matt Mackall wrote: I've been sitting on this for over a year now, kicking it out in the hopes that someone finds it useful. kernel.org was down when I was tidying this up so it's against 2.6.10 which is what I had handy. /proc/kmalloc allocation tracing This quick hack adds accounting for

Re: [PATCH] /proc/kmalloc

2005-02-20 Thread Baruch Even
Matt Mackall wrote: I've been sitting on this for over a year now, kicking it out in the hopes that someone finds it useful. kernel.org was down when I was tidying this up so it's against 2.6.10 which is what I had handy. /proc/kmalloc allocation tracing This quick hack adds accounting for