Hi Andreas,
On Wed, Jun 15, 2016 at 12:00:59PM +0200, Andreas Ziegler wrote:
>
> your patch "s390/crc32-vx: add crypto API module for optimized CRC-32
> algorithms" showed up in linux-next today (next-20160615) as commit
> 364148e0b195.
>
> The patch defines the Kconfig option CRYPTO_CRC32_S3
On 06/15/16 03:00, Andreas Ziegler wrote:
> Hi Hendrik,
>
> your patch "s390/crc32-vx: add crypto API module for optimized CRC-32
> algorithms" showed up in linux-next today (next-20160615) as commit
> 364148e0b195.
>
> The patch defines the Kconfig option CRYPTO_CRC32_S390 which 'select's CRC
I've posted a patch to fix this and a bunch of other refs.
David
Hi,
Yes, please make a patch.
Thanks for noticing,
Dmitry
From: Andreas Ziegler [andreas.zieg...@fau.de]
Sent: Tuesday, January 26, 2016 5:39 PM
To: Dmitry Kasatkin
Cc: David Howells; James Morris; Serge E. Hallyn; linux-kernel@vger.kernel.org
Subject: 's
On Mon, Jan 25, 2016 at 11:52:04AM +0100, Andreas Ziegler wrote:
> Hi Chris,
>
> your commit 5bab6f60cb4d ("drm/i915: Serialise updates to GGTT with
> access through GGTT on Braswell") added a select to STOP_MACHINE to the
> DRM_I915 Kconfig option.
>
> In 4.5-rc1, your commit 86fffe4a61dd ("kern
Hi Valentin,
On Wed, Mar 04, 2015 at 01:19:25PM +, Valentin Rothberg wrote:
> your commit 8754d5115693 ("thermal: introduce the Power Allocator
> governor") is included in today's linux-next tree (i.e.,
> next-20150304).
>
> This patch adds a select on the Kconfig symbol THERMAL_POWER_ACTOR.
On 14/03/2014 06:39, Lan Tianyu wrote:
2014-03-12 6:20 GMT+08:00 Matthew Garrett :
The existing SBS code explicitly sets the selected battery in the SBS
manager regardless of whether the battery in question is already selected.
This causes bus timeouts on Apple hardware. Check for this case and
2014-03-12 6:20 GMT+08:00 Matthew Garrett :
> The existing SBS code explicitly sets the selected battery in the SBS
> manager regardless of whether the battery in question is already selected.
> This causes bus timeouts on Apple hardware. Check for this case and avoid
> it.
>
Hi Matthew:
The existing SBS code explicitly sets the selected battery in the SBS
manager regardless of whether the battery in question is already selected.
This causes bus timeouts on Apple hardware. Check for this case and avoid
it.
Signed-off-by: Matthew Garrett
---
drivers/acpi/sbs.c | 18 +-
Commit-ID: e02e60c109ca70935bad1131976bdbf5160cf576
Gitweb: http://git.kernel.org/tip/e02e60c109ca70935bad1131976bdbf5160cf576
Author: Joonsoo Kim
AuthorDate: Tue, 23 Apr 2013 17:27:42 +0900
Committer: Ingo Molnar
CommitDate: Wed, 24 Apr 2013 08:52:46 +0200
sched: Prevent to re-select
Commit 88b8dac0 makes load_balance() consider other cpus in its group.
But, in that, there is no code for preventing to re-select dst-cpu.
So, same dst-cpu can be selected over and over.
This patch add functionality to load_balance() in order to exclude
cpu which is selected once. We prevent to
On Tue, 2013-03-26 at 15:01 +0900, Joonsoo Kim wrote:
> Commit 88b8dac0 makes load_balance() consider other cpus in its group.
> But, in that, there is no code for preventing to re-select dst-cpu.
> So, same dst-cpu can be selected over and over.
>
> This patch add functionality
Commit 88b8dac0 makes load_balance() consider other cpus in its group.
But, in that, there is no code for preventing to re-select dst-cpu.
So, same dst-cpu can be selected over and over.
This patch add functionality to load_balance() in order to exclude
cpu which is selected once. We prevent to
cpus in its group.
>> > > But, in that, there is no code for preventing to re-select dst-cpu.
>> > > So, same dst-cpu can be selected over and over.
>> > >
>> > > This patch add functionality to load_balance() in order to exclude
>> > &g
that, there is no code for preventing to re-select dst-cpu.
> > > So, same dst-cpu can be selected over and over.
> > >
> > > This patch add functionality to load_balance() in order to exclude
> > > cpu which is selected once.
> >
> > Oh man.. seri
On Tue, Mar 19, 2013 at 04:05:46PM +0100, Peter Zijlstra wrote:
> On Thu, 2013-02-14 at 14:48 +0900, Joonsoo Kim wrote:
> > Commit 88b8dac0 makes load_balance() consider other cpus in its group.
> > But, in that, there is no code for preventing to re-select dst-cpu.
> > So
On Thu, 2013-02-14 at 14:48 +0900, Joonsoo Kim wrote:
> Commit 88b8dac0 makes load_balance() consider other cpus in its group.
> But, in that, there is no code for preventing to re-select dst-cpu.
> So, same dst-cpu can be selected over and over.
>
> This patch add functionality
Commit 88b8dac0 makes load_balance() consider other cpus in its group.
But, in that, there is no code for preventing to re-select dst-cpu.
So, same dst-cpu can be selected over and over.
This patch add functionality to load_balance() in order to exclude
cpu which is selected once.
Cc: Srivatsa
Robert Hancock wrote:
It's because you haven't done anything to handle the error which is
still persisting. Likely the only thing sane you can do in this case is
close the fd and try to reopen it later.
This seems to be true, but not for what you might think.
It appears that if u plug the U
> David Schwartz wrote:
> >> The misunderstanding is from the docs.
> >> The select() does not report device errors.
> >> Select will just "more precisely, to see if a read will not block".
> > This is a much slighter misunderstanding. The result of the 'select'
> > function tells you nothing ab
David Schwartz wrote:
The misunderstanding is from the docs.
The select() does not report device errors.
Select will just "more precisely, to see if a read will not block".
This is a much slighter misunderstanding. The result of the 'select'
function tells you nothing about what a particular 'r
> The misunderstanding is from the docs.
> The select() does not report device errors.
> Select will just "more precisely, to see if a read will not block".
This is a much slighter misunderstanding. The result of the 'select'
function tells you nothing about what a particular 'read' will or will
David Schwartz wrote:
David Schwartz wrote:
Nope. An errored connection is always ready for read/write -- there is
nothing to wait for as far as the kernel is concerned. Your code keeps
asking the kernel if something interesting has happened, the
kernel keeps
telling it yes, and it refuses to
> David Schwartz wrote:
> > Nope. An errored connection is always ready for read/write -- there is
> > nothing to wait for as far as the kernel is concerned. Your code keeps
> > asking the kernel if something interesting has happened, the
> > kernel keeps
> > telling it yes, and it refuses to do
Uncle George <[EMAIL PROTECTED]> wrote:
> i am using the GARMIN_GPS/usb driver to read a gps receiver.
> In testing the ability of my software to recover from various errors, I
> try this: unplug the gps/USB cable from the usb hub.
>
> Interestingly enough the thread spins.
> the SELECT() waits f
David Schwartz wrote:
In this case what, will reset the "something interesting has happened"
report from the SELECT call? Will it ever be reset in this case?
Nope. An errored connection is always ready for read/write -- there is
nothing to wait for as far as the kernel is concerned. Your code
Uncle George wrote:
David Schwartz wrote:
Nope. An errored connection is always ready for read/write -- there is
nothing to wait for as far as the kernel is concerned. Your code keeps
asking the kernel if something interesting has happened, the kernel keeps
telling it yes, and it refuses to do
David Schwartz wrote:
Nope. An errored connection is always ready for read/write -- there is
nothing to wait for as far as the kernel is concerned. Your code keeps
asking the kernel if something interesting has happened, the kernel keeps
telling it yes, and it refuses to do anything about it.
T
> i am using the GARMIN_GPS/usb driver to read a gps receiver.
> In testing the ability of my software to recover from various errors, I
> try this: unplug the gps/USB cable from the usb hub.
>
> Interestingly enough the thread spins.
> the SELECT() waits for something to happen, and I get one cha
On Tue, 2007-05-22 at 07:34 -0700, Nishanth Aravamudan wrote:
> On 22.05.2007 [09:16:37 -0500], Steve Fox wrote:
> >
> > Andy put this through a couple machines on test.kernel.org and elm3b6
> > was fixed, however elm3b239 still had a boot error.
> >
> > BUG: at mm/slab.c:777 __find_general_cache
On 22.05.2007 [09:16:37 -0500], Steve Fox wrote:
> On Wed, 2007-05-16 at 17:59 -0700, Badari Pulavarty wrote:
>
> > Here it is ..
> >
> > Should I do one for poll() also ?
> >
> > Thanks,
> > Badari
> >
> > Optimize select by a using stack space for small fd sets.
> > core_sys_select() already
On Wed, 2007-05-16 at 17:59 -0700, Badari Pulavarty wrote:
> Here it is ..
>
> Should I do one for poll() also ?
>
> Thanks,
> Badari
>
> Optimize select by a using stack space for small fd sets.
> core_sys_select() already has this optimization. This is
> for compat version.
>
> Signed-off-b
On 5/18/07, Andi Kleen <[EMAIL PROTECTED]> wrote:
On Wednesday 16 May 2007 17:37, Anton Blanchard wrote:
> Hi Hugh,
>
> > It's interesting that compat_core_sys_select() shows this kmalloc(0)
> > failure but core_sys_select() does not. That's because core_sys_select()
> > avoids kmalloc by using
On Wednesday 16 May 2007 17:37, Anton Blanchard wrote:
> Hi Hugh,
>
> > It's interesting that compat_core_sys_select() shows this kmalloc(0)
> > failure but core_sys_select() does not. That's because core_sys_select()
> > avoids kmalloc by using a buffer on the stack for small allocations (and
> >
On Wed, 2007-05-16 at 10:37 -0500, Anton Blanchard wrote:
> Hi Hugh,
>
> > It's interesting that compat_core_sys_select() shows this kmalloc(0)
> > failure but core_sys_select() does not. That's because core_sys_select()
> > avoids kmalloc by using a buffer on the stack for small allocations (and
Hi Hugh,
> It's interesting that compat_core_sys_select() shows this kmalloc(0)
> failure but core_sys_select() does not. That's because core_sys_select()
> avoids kmalloc by using a buffer on the stack for small allocations (and
> 0 sure is small). Shouldn't compat_core_sys_select() do just th
On Tue, 15 May 2007, Christoph Lameter wrote:
> On Tue, 15 May 2007, Andrew Morton wrote:
>
> > I _think_ we can just do
> >
> > --- a/fs/compat.c~a
> > +++ a/fs/compat.c
> > @@ -1566,9 +1566,13 @@ int compat_core_sys_select(int n, compat
> > */
> > ret = -ENOMEM;
> > size = FDS_BYTE
On Tue, 15 May 2007, Andrew Morton wrote:
> Perhaps putting a size=0 detector into slab also would speed this
> process up.
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
Index: linux-2.6/mm/slab.c
===
--- linux-2.6.orig/mm/sl
On Tue, 15 May 2007 11:10:22 -0700 (PDT)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> On Tue, 15 May 2007, Andrew Morton wrote:
>
> > I _think_ we can just do
> >
> > --- a/fs/compat.c~a
> > +++ a/fs/compat.c
> > @@ -1566,9 +1566,13 @@ int compat_core_sys_select(int n, compat
> > */
> >
On Tue, 15 May 2007, Andrew Morton wrote:
> I _think_ we can just do
>
> --- a/fs/compat.c~a
> +++ a/fs/compat.c
> @@ -1566,9 +1566,13 @@ int compat_core_sys_select(int n, compat
>*/
> ret = -ENOMEM;
> size = FDS_BYTES(n);
> - bits = kmalloc(6 * size, GFP_KERNEL);
> -
On Tue, 2007-05-15 at 10:44 -0700, Andrew Morton wrote:
> On Tue, 15 May 2007 10:29:18 -0700
> Badari Pulavarty <[EMAIL PROTECTED]> wrote:
>
> > Hi,
> >
> > Is select(0, ..) is a valid operation ?
>
> Probably - it becomes an elaborate way of doing a sleep. Whatever - we
> used to permit it wit
On Tue, 15 May 2007 10:29:18 -0700
Badari Pulavarty <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Is select(0, ..) is a valid operation ?
Probably - it becomes an elaborate way of doing a sleep. Whatever - we
used to permit it without error, so we should continue to do so.
> I see that there is no chec
Badari Pulavarty wrote:
> Hi,
>
> Is select(0, ..) is a valid operation ?
>
> I see that there is no check to prevent this or return
> success early, without doing any work. Do we need one ?
>
> slub code is complaining that we are doing kmalloc(0).
>
select(0, ...) is valid, and is functional
On Tue, 15 May 2007 10:29:18 -0700
Badari Pulavarty <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Is select(0, ..) is a valid operation ?
Yes. It's a fairly classic old BSD way to do timeouts
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAI
Badari Pulavarty napsal(a):
> Hi,
>
> Is select(0, ..) is a valid operation ?
Yes, it was (is) sometimes used for measuring (sleeping for) short time slices.
regards,
--
http://www.fi.muni.cz/~xslaby/Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby g
On Tue, 15 May 2007 10:29:18 -0700
Badari Pulavarty <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Is select(0, ..) is a valid operation ?
select(0, ..) is rather commonly used as a portable sleep() with
microsecond granularity. Disabling it will break lots of things.
Mark
-
To unsubscribe from this lis
On Wed, 9 May 2007, Russell King wrote:
> drivers/net/Kconfig:2279:warning: 'select' used by config symbol 'UCC_GETH'
> refers to undefined symbol 'UCC_FAST'
> drivers/input/keyboard/Kconfig:170:warning: 'select' used by config symbol
> 'KEYBOARD_ATARI' refers to undefined symbol 'ATARI_KBD_CORE
AM
To: Robert Hancock
Cc: Eitan Richardson; linux-kernel
Subject: Re: select-like implementation for kernel sockets
Importance: Low
On 5/6/07, Robert Hancock <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > Hi,
> >
> > I'm using kernel sockets to Tx and Rx
On 5/6/07, Robert Hancock <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] wrote:
> Hi,
>
> I'm using kernel sockets to Tx and Rx UDP packets between my hardware
> device (DSP) to the external network (this is part of a VoIP
> implementation). The motivation for using kernel sockets rather than
> use
[EMAIL PROTECTED] wrote:
Hi,
I'm using kernel sockets to Tx and Rx UDP packets between my hardware
device (DSP) to the external network (this is part of a VoIP
implementation). The motivation for using kernel sockets rather than
user-space sockets is to avoid the copying of data between kernel a
On Thu, Jan 11, 2007 at 11:22:46PM +0100, bert hubert wrote:
>Anything else relevant? Do you know which signal interrupted select? Is this
>a single or multithreaded application? And where did the signal come from?
It is, AFAIK, a multi-threaded application. I don't have any information
on which
On Thu, Jan 11, 2007 at 01:25:16AM -0700, Sean Reifschneider wrote:
> Nope, I haven't looked in strace at all. It's definitely making it to
> user-space. The code in question is (abbreviated):
>
>if (select(0, (fd_set *)0, (fd_set *)0, (fd_set *)0, &t) != 0) {
> PyErr_SetFromErrno(PyE
On Thursday 11 January 2007 02:02, Neil Brown wrote:
> If regs->rax is unsigned long, then I would think the compiler would
> be allowed to convert
>
>switch (regs->rax) {
> case -514 : whatever;
>}
>
> to a no-op, as regs->rax will never have a negative value.
In C, you never actu
On Wed, Jan 10, 2007 at 05:15:20PM -0800, David Miller wrote:
>If you're only seeing it in strace, that's expected due to some
Nope, I haven't looked in strace at all. It's definitely making it to
user-space. The code in question is (abbreviated):
if (select(0, (fd_set *)0, (fd_set *)0, (fd_
On Thu, Jan 11, 2007 at 12:02:53PM +1100, Neil Brown wrote:
>On Thursday January 11, [EMAIL PROTECTED] wrote:
>> Normally it should be only visible in strace. Did you see it without
>> strace?
>
>No, only in strace.
I am absolutely seeing it outside of strace. It is showing up as an errno
to the
On Thursday 11 January 2007 02:02, Neil Brown wrote:
> On Thursday January 11, [EMAIL PROTECTED] wrote:
> > > Just a 'me too' at this point.
> > > The X server on my shiny new notebook (Core 2 Duo) occasionally dies
> > > with 'select' repeatedly returning ERESTARTNOHAND. It is most
> > > annoyin
From: Sean Reifschneider <[EMAIL PROTECTED]>
Date: Wed, 10 Jan 2007 18:04:29 -0700
> On Wed, Jan 10, 2007 at 04:27:47PM -0800, David Miller wrote:
> >It gets caught by the return into userspace code.
>
> Ok, so somehow it is leaking. I have a system in the lab that is the same
> hardware as prod
On Wed, Jan 10, 2007 at 04:27:47PM -0800, David Miller wrote:
>It gets caught by the return into userspace code.
Ok, so somehow it is leaking. I have a system in the lab that is the same
hardware as production, but it currently has no, you know, hard drives in
it, so some assembly is required. I
On Thursday January 11, [EMAIL PROTECTED] wrote:
> > Just a 'me too' at this point.
> > The X server on my shiny new notebook (Core 2 Duo) occasionally dies
> > with 'select' repeatedly returning ERESTARTNOHAND. It is most
> > annoying!
>
> Normally it should be only visible in strace. Did you s
From: Neil Brown <[EMAIL PROTECTED]>
Date: Thu, 11 Jan 2007 11:37:05 +1100
> On x86-64, regs->rax is "unsigned long", so the following is
> needed
>
> I haven't tried it yet.
Doesn't type promotion take care of that? Did you verify
that assember?
I checked the assembler on sparc64 for simi
On Thursday 11 January 2007 01:37, Neil Brown wrote:
> On Wednesday January 10, [EMAIL PROTECTED] wrote:
> >
> > In looking at the Linux code for ERESTARTNOHAND, I see that
> > include/linux/errno.h says this errno should never make it to the user.
> > However, in this instance we ARE seeing it.
On Wednesday January 10, [EMAIL PROTECTED] wrote:
>
> In looking at the Linux code for ERESTARTNOHAND, I see that
> include/linux/errno.h says this errno should never make it to the user.
> However, in this instance we ARE seeing it. Looking around on google shows
> others are seeing it as well,
From: Sean Reifschneider <[EMAIL PROTECTED]>
Date: Wed, 10 Jan 2007 16:42:38 -0700
> In looking at the select() code, I see that there are definitely cases
> where sys_select() or sys_pselect7() can return -ERESTARTNOHAND. However,
> I don't know if this is expected to be caught elsewhere, or if
Davide Libenzi wrote:
There is no known problem in using epoll_ctl() in one thread while
another does epoll_wait().
I suggest you to ask Valgrind to take a look at you binary. Since I
have no clue of what your software does, please create the *minimal*
code snippet that exploit the eventual
On Tue, 23 Aug 2005, Davy Durham wrote:
Davide Libenzi wrote:
I should mention that the 2.4 patch is old WRT mainline epoll in 2.6 (I
stopped maintaining it when 2.6 went "stable"). I'd definitely suggest to
use 2.6 if you are looking at epoll.
I am using linux-2.6.11 and glibc-2.3.4 ..
Jari Sundell wrote:
On 8/23/05, Davy Durham <[EMAIL PROTECTED]> wrote:
I was hoping you would mention in your reply that you knew
epoll_data_t was an union and you didn't touch epoll_data::fd, so i
wouldn't have to say it explicitly. ;)
Oh!.. unless the epoll_data_t is a union just for
Jari Sundell wrote:
On 8/23/05, Davy Durham <[EMAIL PROTECTED]> wrote:
I was hoping you would mention in your reply that you knew
epoll_data_t was an union and you didn't touch epoll_data::fd, so i
wouldn't have to say it explicitly. ;)
No, I saw that epoll_data_t was a union (although,
Davide Libenzi wrote:
I should mention that the 2.4 patch is old WRT mainline epoll in 2.6
(I stopped maintaining it when 2.6 went "stable"). I'd definitely
suggest to use 2.6 if you are looking at epoll.
I am using linux-2.6.11 and glibc-2.3.4 .. and using select() in it's
place seems to
On Tue, 23 Aug 2005, Willy Tarreau wrote:
On Tue, Aug 23, 2005 at 06:55:26AM -0500, Davy Durham wrote:
Thanks for the info.. I did find this thread and was wondering if this
patch ever got put in
http://www.ussg.iu.edu/hypermail/linux/kernel/0303.3/1139.html
Interesting ! At least it does n
On 8/23/05, Davy Durham <[EMAIL PROTECTED]> wrote:
> Yes, that is what I was thinking and is why I mentioned that. But I'm
> apparently not overwriting the pointers with FDs.. it seems that epoll
> is the cause at this point (unless I'm misusing the epoll API). I've
> made some changes to now us
On Tue, Aug 23, 2005 at 06:55:26AM -0500, Davy Durham wrote:
> Thanks for the info.. I did find this thread and was wondering if this
> patch ever got put in
>
> http://www.ussg.iu.edu/hypermail/linux/kernel/0303.3/1139.html
>
Interesting ! At least it does not seem to be present in the
epoll-2
Thanks for the info.. I did find this thread and was wondering if this
patch ever got put in
http://www.ussg.iu.edu/hypermail/linux/kernel/0303.3/1139.html
Willy Tarreau wrote:
On Tue, Aug 23, 2005 at 06:24:42AM -0500, Davy Durham wrote:
That's probably a good idea. Where would I find o
Jari Sundell wrote:
On 8/23/05, Davy Durham <[EMAIL PROTECTED]> wrote:
However, I'm getting segfaults because some pointers in places are
getting set to low integer values (which didn't used to have those values).
Is it possible that you are overwritting the pointers with file
descrip
On Tue, Aug 23, 2005 at 06:24:42AM -0500, Davy Durham wrote:
> That's probably a good idea. Where would I find out what other projects
> use it?
I use it in my load-balancer (haproxy), and it could somewhat match your
needs, because I ported the select()-based earlier version to epoll() with
the
On 8/23/05, Davy Durham <[EMAIL PROTECTED]> wrote:
>
> However, I'm getting segfaults because some pointers in places are
> getting set to low integer values (which didn't used to have those values).
Is it possible that you are overwritting the pointers with file
descriptors, as those would have
That's probably a good idea. Where would I find out what other projects
use it?
Willy Tarreau wrote:
Hi,
On Tue, Aug 23, 2005 at 06:01:15AM -0500, Davy Durham wrote:
I just mean that when I debug and catch the segv, it's dies because
some pointers now have corrupted values. (usually be
Davy Durham wrote:
I'm currently re-writing some code to make it use select() instead of
epoll_wait() and see if everything is suddently fixed. If so, then I
will suspect that epoll has a problem. But it's still not ruled out
being my fault since it could be a timing issue that makes the c
Hi,
On Tue, Aug 23, 2005 at 06:01:15AM -0500, Davy Durham wrote:
> I just mean that when I debug and catch the segv, it's dies because
> some pointers now have corrupted values. (usually because something is
> overwriting some memory some where)
>
> I'm currently re-writing some code to make
bert hubert wrote:
On Tue, Aug 23, 2005 at 04:49:14AM -0500, Davy Durham wrote:
However, I'm getting segfaults because some pointers in places are
getting set to low integer values (which didn't used to have those values).
epoll is pretty heavily benchmarked and hence tested. I don't
On Tue, Aug 23, 2005 at 04:49:14AM -0500, Davy Durham wrote:
> However, I'm getting segfaults because some pointers in places are
> getting set to low integer values (which didn't used to have those values).
epoll is pretty heavily benchmarked and hence tested. I don't entirely
understand the re
So, I've been trying to use epoll.. on linux-2.6.11-6mdk
However, I'm getting segfaults because some pointers in places are
getting set to low integer values (which didn't used to have those values).
The deal is that my application is multi-threaded, and I was wondering
if epoll had issues i
On Fri, Jul 22, 2005 at 04:18:46PM -0500, Davy Durham wrote:
> Please forgive and redirect me if this is not the right place to ask
> this question:
>
> I'm looking to write a sort of messaging system that would take input
> from any number of entities that "register" with it.. it would then
>
Lutz Vieweg <[EMAIL PROTECTED]> wrote:
I'm currently investigating the following problem, which seems to indicate
a misbehaviour of the kernel:
A server software we implemented is sporadically "hanging" in a select()
call since we upgraded from kernel 2.4 to (currently) 2.6.9 (we have to wait
for 2
Andrew Morton wrote:
Lutz Vieweg <[EMAIL PROTECTED]> wrote:
I'm currently investigating the following problem, which seems to indicate
a misbehaviour of the kernel:
A server software we implemented is sporadically "hanging" in a select()
call since we upgraded from kernel 2.4 to (currently) 2.6.9 (
Lutz Vieweg <[EMAIL PROTECTED]> wrote:
>
> I'm currently investigating the following problem, which seems to indicate
> a misbehaviour of the kernel:
>
> A server software we implemented is sporadically "hanging" in a select()
> call since we upgraded from kernel 2.4 to (currently) 2.6.9 (we have
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Felix Matathias
Sent: Friday, March 11, 2005 12:27 PM
> Isn't a significant reduction in the amount of read operations
> a real gain in high speed networking ?
In a word? No.
Here at my company we make
In article <[EMAIL PROTECTED]> (at Mon, 14 Mar 2005 13:24:24 +), Alan Cox
<[EMAIL PROTECTED]> says:
> 1003.1g both agree with your expectations. The right list is probably
> netdev@oss.sgi.com however.
I've just forwarded this thread to netdev.
--yoshfuji
-
To unsubscribe from this list: se
On Gwe, 2005-03-11 at 20:26, Felix Matathias wrote:
> Dear Alan,
>
> I am positive. I can setsockopt, and then, getsockopt returns the value
> that I requested.
Ok I misremembered - its SNDLOWAT that is locked to one in Linux.
> Stevens very clearly states that SO_RCVLOWAT has a direct impact o
Dear Alan,
I am positive. I can setsockopt, and then, getsockopt returns the value
that I requested.
Stevens very clearly states that SO_RCVLOWAT has a direct impact on
select() and I assumed that this would be the case for Linux.
What is the rationale for not complying with that ? Is it the mic
On Iau, 2005-03-10 at 21:58, Felix Matathias wrote:
> Dear all,
>
> I am running a 2.4.21-9.0.3.ELsmp #1 kernel and I can setsockopt and
> getsockopt correctly the SO_RCVLOWAT option
The only value the code at least used to support was setting it to 1.
Are you sure you are actually setting/check
On Thu, Mar 10, 2005 at 04:58:51PM -0500, Felix Matathias wrote:
>
> I am running a 2.4.21-9.0.3.ELsmp #1 kernel and I can setsockopt and
> getsockopt correctly the SO_RCVLOWAT option, but select() seems to mark a
> socket readable even if a single byte is ready to be read. Then, a read()
> blo
Robert Hancock wrote:
> I thought this (hangup on remove [jpo]) had been merged, but I could be
> wrong.
I just checked bitkeeper. The patch went in some time ago:
4 months eolson 1.126 usb-serial: add tty_hangup on disconnect
Regards
Joerg
___
Robert Hancock wrote:
> There was discussion at one point about doing a tty_hangup() when the >
USB device was disconnected (this causes the read() to return with 0 > >
bytes and future open attempts to fail), and a patch was put out to do >
this. I thought this had been merged, but I could be
Joerg Pommnitz wrote:
Hello all,
currently it seems that select keeps blocking when the USB device behind
ttyUSBx gets unplugged. My understanding is, that select should return
when the next call to one of the operations (read/write) will not block.
This is certainly true for failing with ENODEV. S
On Tue, 8 Mar 2005, Joerg Pommnitz wrote:
Hello all,
currently it seems that select keeps blocking when the USB device behind
ttyUSBx gets unplugged. My understanding is, that select should return
when the next call to one of the operations (read/write) will not block.
This is certainly true for fa
> I would have said just the opposite. That if it you have a large
> number of
> handles you're waiting on, and you have to go back through and
> set the bits
> everytime you timeout that you would incur a larger overhead. From the
> perspective of my application, it would have been more effici
On Sat, Jun 02, 2001 at 10:47:49PM -0400, John Chris Wren wrote:
> I would have said just the opposite. That if it you have a large number of
> handles you're waiting on, and you have to go back through and set the bits
> everytime you timeout that you would incur a larger overhead. From the
Us
>
> [EMAIL PROTECTED] wrote:
> > Of course, not looking at the sets upon a zero return is a
> fairly obvious
> > optimization as there is little point in doing so.
>
> No; a fairly obvious optimisation is to avoid calling FD_ZERO if you
> can clear the bits individually when you test them.
>
> Wh
On Sat, 2 Jun 2001, Jamie Lokier wrote:
> [EMAIL PROTECTED] wrote:
> > Of course, not looking at the sets upon a zero return is a fairly obvious
> > optimization as there is little point in doing so.
>
> No; a fairly obvious optimisation is to avoid calling FD_ZERO if you
> can clear the bits in
[EMAIL PROTECTED] wrote:
> Of course, not looking at the sets upon a zero return is a fairly obvious
> optimization as there is little point in doing so.
No; a fairly obvious optimisation is to avoid calling FD_ZERO if you
can clear the bits individually when you test them.
When you examine the
1 - 100 of 129 matches
Mail list logo
