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,
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
* 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
* 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
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
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
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
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
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
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:
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
30 matches
Mail list logo
