On Tue, Nov 22, 2016 at 05:14:02PM +0100, Vlastimil Babka wrote:
> On 11/22/2016 05:06 PM, Marc MERLIN wrote:
> > On Mon, Nov 21, 2016 at 01:56:39PM -0800, Marc MERLIN wrote:
> >> On Mon, Nov 21, 2016 at 10:50:20PM +0100, Vlastimil Babka wrote:
> 4.9rc5 however seems to be doing better, and
On Tue, Nov 22, 2016 at 05:14:02PM +0100, Vlastimil Babka wrote:
> On 11/22/2016 05:06 PM, Marc MERLIN wrote:
> > On Mon, Nov 21, 2016 at 01:56:39PM -0800, Marc MERLIN wrote:
> >> On Mon, Nov 21, 2016 at 10:50:20PM +0100, Vlastimil Babka wrote:
> 4.9rc5 however seems to be doing better, and
On Mon, Mar 07, 2016 at 07:11:19PM -0800, Andi Kleen wrote:
> > I write this because I would actually find it useful to see the original
> > backtrace, even if it is interruptible, not just the collateral damage.
> > Since the "skipping" of NFS is basically incomplete anyway, how big a
> > deal
On Mon, Mar 07, 2016 at 07:11:19PM -0800, Andi Kleen wrote:
> > I write this because I would actually find it useful to see the original
> > backtrace, even if it is interruptible, not just the collateral damage.
> > Since the "skipping" of NFS is basically incomplete anyway, how big a
> > deal
Hello!
Back in 2008, you committed 316d9679f33caf7e683471647d1472bfe133d858
which changed softlockup.c (now moved to hung_task.c) to avoid logging a
spew of soft lockup warnings when the Ethernet cable is unplugged with
active NFS mounts.
Meanwhile, I've been seeing hung task warnings like this
Hello!
Back in 2008, you committed 316d9679f33caf7e683471647d1472bfe133d858
which changed softlockup.c (now moved to hung_task.c) to avoid logging a
spew of soft lockup warnings when the Ethernet cable is unplugged with
active NFS mounts.
Meanwhile, I've been seeing hung task warnings like this
On Wed, Jan 07, 2015 at 10:48:10PM +0100, Vlastimil Babka wrote:
> On 01/07/2015 10:28 PM, Simon Kirby wrote:
>
> > Hmm...A possibly-related issue...Before trying this, after a fresh boot,
> > /proc/vmstat showed:
> >
> > nr_alloc_batch 4294541205
>
> T
On Wed, Jan 07, 2015 at 10:57:46AM +, Holger Hoffst?tte wrote:
> On Tue, 06 Jan 2015 12:54:43 -0500, Mikulas Patocka wrote:
>
> > I can't reprodce it. It happened just once.
> >
> > That patch is supposed to fix an occasional underflow by a single page -
> > while my meminfo showed
On Mon, Jan 05, 2015 at 06:05:59PM -0500, Mikulas Patocka wrote:
> Hi
>
> I would like to report a memory management bug where the dirty pages count
> underflowed.
Hello!
I've been hitting this problem for a while now. I've seen it on:
3.12.9
3.14.4
3.16
3.16.6
When it occurs, /proc/vmstat
On Mon, Jan 05, 2015 at 06:05:59PM -0500, Mikulas Patocka wrote:
Hi
I would like to report a memory management bug where the dirty pages count
underflowed.
Hello!
I've been hitting this problem for a while now. I've seen it on:
3.12.9
3.14.4
3.16
3.16.6
When it occurs, /proc/vmstat
On Wed, Jan 07, 2015 at 10:48:10PM +0100, Vlastimil Babka wrote:
On 01/07/2015 10:28 PM, Simon Kirby wrote:
Hmm...A possibly-related issue...Before trying this, after a fresh boot,
/proc/vmstat showed:
nr_alloc_batch 4294541205
This can happen, and not be a problem in general
On Wed, Jan 07, 2015 at 10:57:46AM +, Holger Hoffst?tte wrote:
On Tue, 06 Jan 2015 12:54:43 -0500, Mikulas Patocka wrote:
I can't reprodce it. It happened just once.
That patch is supposed to fix an occasional underflow by a single page -
while my meminfo showed underflow by
On Thu, Aug 28, 2014 at 01:46:58PM -0700, Paul E. McKenney wrote:
> On Thu, Aug 28, 2014 at 03:33:42PM -0500, Eric W. Biederman wrote:
>
> > I just want to add a little bit more analysis to this.
> >
> > What we desire to be fast is the copy_net_ns, cleanup_net is batched and
> > asynchronous
On Thu, Aug 28, 2014 at 12:24:31PM -0700, Paul E. McKenney wrote:
> On Tue, Aug 19, 2014 at 10:58:55PM -0700, Simon Kirby wrote:
> > Hello!
> >
> > In trying to figure out what happened to a box running lots of vsftpd
> > since we deployed a CONFIG_NET_
On Thu, Aug 28, 2014 at 12:24:31PM -0700, Paul E. McKenney wrote:
On Tue, Aug 19, 2014 at 10:58:55PM -0700, Simon Kirby wrote:
Hello!
In trying to figure out what happened to a box running lots of vsftpd
since we deployed a CONFIG_NET_NS=y kernel to it, we found that the
(wall) time
On Thu, Aug 28, 2014 at 01:46:58PM -0700, Paul E. McKenney wrote:
On Thu, Aug 28, 2014 at 03:33:42PM -0500, Eric W. Biederman wrote:
I just want to add a little bit more analysis to this.
What we desire to be fast is the copy_net_ns, cleanup_net is batched and
asynchronous which
Hello!
In trying to figure out what happened to a box running lots of vsftpd
since we deployed a CONFIG_NET_NS=y kernel to it, we found that the
(wall) time needed for cleanup_net() to complete, even on an idle box,
can be quite long:
#!/bin/bash
ip netns delete test >&/dev/null
while ip netns
Hello!
In trying to figure out what happened to a box running lots of vsftpd
since we deployed a CONFIG_NET_NS=y kernel to it, we found that the
(wall) time needed for cleanup_net() to complete, even on an idle box,
can be quite long:
#!/bin/bash
ip netns delete test /dev/null
while ip netns
On Wed, Dec 04, 2013 at 01:14:56PM -0800, Linus Torvalds wrote:
> The lock we're moving up isn't the lock that actually protects the
> whole allocation logic (it's the lock that then protects the pipe
> contents when a pipe is *used*). So it's a useless lock, and moving it
> up is a good idea
On Wed, Dec 04, 2013 at 01:14:56PM -0800, Linus Torvalds wrote:
The lock we're moving up isn't the lock that actually protects the
whole allocation logic (it's the lock that then protects the pipe
contents when a pipe is *used*). So it's a useless lock, and moving it
up is a good idea
On Tue, Dec 03, 2013 at 09:52:33AM +0100, Ingo Molnar wrote:
> Indeed: this comes from mutex->count being separate from
> mutex->wait_lock, and this should affect every architecture that has a
> mutex->count fast-path implemented (essentially every architecture
> that matters).
>
> Such bugs
On Tue, Dec 03, 2013 at 10:10:29AM -0800, Linus Torvalds wrote:
> On Tue, Dec 3, 2013 at 12:52 AM, Ingo Molnar wrote:
> >
> > I'd expect such bugs to be more prominent with unlucky object
> > size/alignment: if mutex->count lies on a separate cache line from
> > mutex->wait_lock.
>
> I doubt
On Tue, Dec 03, 2013 at 10:10:29AM -0800, Linus Torvalds wrote:
On Tue, Dec 3, 2013 at 12:52 AM, Ingo Molnar mi...@kernel.org wrote:
I'd expect such bugs to be more prominent with unlucky object
size/alignment: if mutex-count lies on a separate cache line from
mutex-wait_lock.
I doubt
On Tue, Dec 03, 2013 at 09:52:33AM +0100, Ingo Molnar wrote:
Indeed: this comes from mutex-count being separate from
mutex-wait_lock, and this should affect every architecture that has a
mutex-count fast-path implemented (essentially every architecture
that matters).
Such bugs should
On Sat, Nov 30, 2013 at 09:25:33AM -0800, Linus Torvalds wrote:
> On Sat, Nov 30, 2013 at 1:43 AM, Simon Kirby wrote:
>
> > I turned on kmalloc-192 tracing to find what else is using it: struct
> > nfs_fh, struct bio, and struct cred. Poking around those, struct bio has
> &g
On Tue, Nov 26, 2013 at 03:16:09PM -0800, Linus Torvalds wrote:
> On Mon, Nov 25, 2013 at 4:44 PM, Simon Kirby wrote:
> >
> > I was hoping this or something else by 3.12 would have fixed it, so after
> > testing we deployed this everywhere and turned off the rest of the
On Tue, Nov 26, 2013 at 03:16:09PM -0800, Linus Torvalds wrote:
On Mon, Nov 25, 2013 at 4:44 PM, Simon Kirby s...@hostway.ca wrote:
I was hoping this or something else by 3.12 would have fixed it, so after
testing we deployed this everywhere and turned off the rest of the debug
options
On Sat, Nov 30, 2013 at 09:25:33AM -0800, Linus Torvalds wrote:
On Sat, Nov 30, 2013 at 1:43 AM, Simon Kirby s...@hostway.ca wrote:
I turned on kmalloc-192 tracing to find what else is using it: struct
nfs_fh, struct bio, and struct cred. Poking around those, struct bio has
bi_cnt
On Tue, Aug 20, 2013 at 12:51:11AM -0700, Ian Applegate wrote:
> Unfortunately no boxen with CONFIG_DEBUG_MUTEXES among them. I can
> enable on a few and should have some results within the day. These
> mainly serve (quite a bit of) HTTP/S cache traffic.
>
> On Tue, Aug 20, 2013 at 12:21 AM, Al
On Tue, Aug 20, 2013 at 12:51:11AM -0700, Ian Applegate wrote:
Unfortunately no boxen with CONFIG_DEBUG_MUTEXES among them. I can
enable on a few and should have some results within the day. These
mainly serve (quite a bit of) HTTP/S cache traffic.
On Tue, Aug 20, 2013 at 12:21 AM, Al Viro
On Wed, Oct 23, 2013 at 10:10:47AM -0400, Douglas Gilbert wrote:
> On 13-10-23 03:44 AM, James Bottomley wrote:
> >On Tue, 2013-10-22 at 20:41 -0400, Douglas Gilbert wrote:
> >>On 13-10-22 04:56 PM, Simon Kirby wrote:
> >>>Hello!
> >>>
> >>>W
On Wed, Oct 23, 2013 at 10:10:47AM -0400, Douglas Gilbert wrote:
On 13-10-23 03:44 AM, James Bottomley wrote:
On Tue, 2013-10-22 at 20:41 -0400, Douglas Gilbert wrote:
On 13-10-22 04:56 PM, Simon Kirby wrote:
Hello!
While trying to figure out why the request queue to sda (ext4
Hello!
While trying to figure out why the request queue to sda (ext4) was
clogging up on one of our btrfs backup boxes, I noticed a megarc process
in D state, so enabled locking debugging, and got this (on 3.12-rc6):
[ 205.372823]
[ 205.372901]
Hello!
While trying to figure out why the request queue to sda (ext4) was
clogging up on one of our btrfs backup boxes, I noticed a megarc process
in D state, so enabled locking debugging, and got this (on 3.12-rc6):
[ 205.372823]
[ 205.372901]
On Mon, Aug 19, 2013 at 04:31:38PM -0700, Simon Kirby wrote:
> On Mon, Aug 19, 2013 at 05:24:41PM -0400, Chris Mason wrote:
>
> > Quoting Linus Torvalds (2013-08-19 17:16:36)
> > > On Mon, Aug 19, 2013 at 1:29 PM, Christoph Lameter
> > > wrote:
> > > &
On Mon, Aug 19, 2013 at 04:31:38PM -0700, Simon Kirby wrote:
On Mon, Aug 19, 2013 at 05:24:41PM -0400, Chris Mason wrote:
Quoting Linus Torvalds (2013-08-19 17:16:36)
On Mon, Aug 19, 2013 at 1:29 PM, Christoph Lameter c...@gentwo.org
wrote:
On Mon, 19 Aug 2013, Simon Kirby wrote
On Mon, Aug 19, 2013 at 05:24:41PM -0400, Chris Mason wrote:
> Quoting Linus Torvalds (2013-08-19 17:16:36)
> > On Mon, Aug 19, 2013 at 1:29 PM, Christoph Lameter wrote:
> > > On Mon, 19 Aug 2013, Simon Kirby wrote:
> > >
> > >>[... ] The
>
On Sat, Jul 06, 2013 at 11:27:38AM +0300, Pekka Enberg wrote:
> On Sat, Jul 6, 2013 at 3:09 AM, Simon Kirby wrote:
> > We saw two Oopses overnight on two separate boxes that seem possibly
> > related, but both are weird. These boxes typically run btrfs for rsync
> > snapshot
On Sat, Jul 06, 2013 at 11:27:38AM +0300, Pekka Enberg wrote:
On Sat, Jul 6, 2013 at 3:09 AM, Simon Kirby s...@hostway.ca wrote:
We saw two Oopses overnight on two separate boxes that seem possibly
related, but both are weird. These boxes typically run btrfs for rsync
snapshot backups
On Mon, Aug 19, 2013 at 05:24:41PM -0400, Chris Mason wrote:
Quoting Linus Torvalds (2013-08-19 17:16:36)
On Mon, Aug 19, 2013 at 1:29 PM, Christoph Lameter c...@gentwo.org wrote:
On Mon, 19 Aug 2013, Simon Kirby wrote:
[... ] The
alloc/free traces are always the same -- always
We saw two Oopses overnight on two separate boxes that seem possibly
related, but both are weird. These boxes typically run btrfs for rsync
snapshot backups (and usually Oops in btrfs ;), but not this time!
backup02 was running 3.10-rc6 plus btrfs-next at the time, and backup03
was running 3.10
We saw two Oopses overnight on two separate boxes that seem possibly
related, but both are weird. These boxes typically run btrfs for rsync
snapshot backups (and usually Oops in btrfs ;), but not this time!
backup02 was running 3.10-rc6 plus btrfs-next at the time, and backup03
was running 3.10
On Tue, Apr 30, 2013 at 06:41:44PM -0700, Linus Torvalds wrote:
> On Tue, Apr 30, 2013 at 5:57 PM, Linus Torvalds
> wrote:
> >
> > Patch is whitespace-damaged and totally untested! Caveat applicator.
>
> Ok, so it's still whitespace-damaged, but it seems to work. The
> appended has the "8
On Tue, Apr 30, 2013 at 06:41:44PM -0700, Linus Torvalds wrote:
On Tue, Apr 30, 2013 at 5:57 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
Patch is whitespace-damaged and totally untested! Caveat applicator.
Ok, so it's still whitespace-damaged, but it seems to work. The
On Mon, Apr 29, 2013 at 06:37:24PM -0700, Greg Kroah-Hartman wrote:
> On Mon, Apr 29, 2013 at 05:36:40PM -0700, Simon Kirby wrote:
> > On Mon, Apr 29, 2013 at 05:21:17PM -0700, Greg Kroah-Hartman wrote:
> >
> > > On Mon, Apr 29, 2013 at 05:14:45PM -0700, Simon Kirby wrote
7b7f3c76595 introduces an update interval for TTY atime updates, making
"w"'s IDLE column less useful than in the past. Since this is often used
for checking to see if other users are actually using the system, reduce
the time to 10 seconds.
Signed-off-by: Simon Kirby
Cc: # follow 37b7f3c7659
for checking to see if other users are actually using the system, reduce
the time to 10 seconds.
Signed-off-by: Simon Kirby s...@hostway.ca
Cc: sta...@vger.kernel.org # follow 37b7f3c76595e23257f61bd80b223de865
---
drivers/tty/tty_io.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
On Mon, Apr 29, 2013 at 06:37:24PM -0700, Greg Kroah-Hartman wrote:
On Mon, Apr 29, 2013 at 05:36:40PM -0700, Simon Kirby wrote:
On Mon, Apr 29, 2013 at 05:21:17PM -0700, Greg Kroah-Hartman wrote:
On Mon, Apr 29, 2013 at 05:14:45PM -0700, Simon Kirby wrote:
On Mon, Apr 29, 2013 at 12
On Mon, Apr 29, 2013 at 05:21:17PM -0700, Greg Kroah-Hartman wrote:
> On Mon, Apr 29, 2013 at 05:14:45PM -0700, Simon Kirby wrote:
> > On Mon, Apr 29, 2013 at 12:01:44PM -0700, Greg Kroah-Hartman wrote:
> >
> > > 3.8-stable review patch. If anyone has any objections, p
On Mon, Apr 29, 2013 at 12:01:44PM -0700, Greg Kroah-Hartman wrote:
> 3.8-stable review patch. If anyone has any objections, please let me know.
I object. This breaks functionality I use every day (seeing who else is
working on stuff with "w").
Furthermore, the patch does not actually fix the
On Mon, Apr 29, 2013 at 12:01:44PM -0700, Greg Kroah-Hartman wrote:
3.8-stable review patch. If anyone has any objections, please let me know.
I object. This breaks functionality I use every day (seeing who else is
working on stuff with w).
Furthermore, the patch does not actually fix the
On Mon, Apr 29, 2013 at 05:21:17PM -0700, Greg Kroah-Hartman wrote:
On Mon, Apr 29, 2013 at 05:14:45PM -0700, Simon Kirby wrote:
On Mon, Apr 29, 2013 at 12:01:44PM -0700, Greg Kroah-Hartman wrote:
3.8-stable review patch. If anyone has any objections, please let me
know.
I
On Fri, Nov 30, 2012 at 02:00:48AM +, Al Viro wrote:
> OK, that settles it. WARN_ON() and printks in the area can be dropped;
> the right fix is below. However, there's a similar place in cifs that
> also needs to be dealt with and I really, really wonder why the hell do
> we do d_drop() in
On Fri, Nov 30, 2012 at 02:00:48AM +, Al Viro wrote:
OK, that settles it. WARN_ON() and printks in the area can be dropped;
the right fix is below. However, there's a similar place in cifs that
also needs to be dealt with and I really, really wonder why the hell do
we do d_drop() in
Having recently upgraded our Asterisk server, I figured it would be a
good time to try a NO_HZ kernel. Everything was running well, until...
it decided to panic.
All I have is a fuzzy picture of the console to work from. The panic
was a fatal exception in interrupt, with EIP within
Having recently upgraded our Asterisk server, I figured it would be a
good time to try a NO_HZ kernel. Everything was running well, until...
it decided to panic.
All I have is a fuzzy picture of the console to work from. The panic
was a fatal exception in interrupt, with EIP within
On Fri, May 11, 2001 at 09:27:29AM -0400, Dan Mann wrote:
> The server has lots (ok, about 20,000 not counting the os itself) of medium
> sized files on it, ranging in size from 60k to 40MB. When I run gqview
> (image viewing program) on the client and point to a local directory that is
>
On Fri, May 11, 2001 at 09:27:29AM -0400, Dan Mann wrote:
The server has lots (ok, about 20,000 not counting the os itself) of medium
sized files on it, ranging in size from 60k to 40MB. When I run gqview
(image viewing program) on the client and point to a local directory that is
mapped to
Three times now I've had 2.4.3 freeze on my dual CPU box while doing a
"dd if=/dev/zero of=/dev/hdc bs=1024k" (a drive to be RMA'd :)). I got
bored and opened an rxvt, and as the machine was swapping in (I assume),
everything froze. The mouse still moved for about 5 seconds before the
freeze,
Three times now I've had 2.4.3 freeze on my dual CPU box while doing a
"dd if=/dev/zero of=/dev/hdc bs=1024k" (a drive to be RMA'd :)). I got
bored and opened an rxvt, and as the machine was swapping in (I assume),
everything froze. The mouse still moved for about 5 seconds before the
freeze,
On Tue, Mar 20, 2001 at 09:23:14AM -0800, Linus Torvalds wrote:
> It's harmless.
>
> It's really a warning that says: the mm that you allocated a new LDT for
> may have multiple users, and while the LDT is added to all of them, we
> don't guarantee _when_ the other users will actually see the
On Tue, Mar 20, 2001 at 09:23:14AM -0800, Linus Torvalds wrote:
It's harmless.
It's really a warning that says: the mm that you allocated a new LDT for
may have multiple users, and while the LDT is added to all of them, we
don't guarantee _when_ the other users will actually see the LDT.
On Wed, Feb 21, 2001 at 03:52:37PM -0800, David S. Miller wrote:
> There is no reason my patch should have this effect.
>
> All of this is what appears to be a bug in Windows TCP header
> compression, if the ID field of the IPv4 header does not change then
> it drops every other packet.
>
>
On Wed, Feb 21, 2001 at 03:52:37PM -0800, David S. Miller wrote:
There is no reason my patch should have this effect.
All of this is what appears to be a bug in Windows TCP header
compression, if the ID field of the IPv4 header does not change then
it drops every other packet.
The
On Fri, Feb 16, 2001 at 07:08:05PM -0500, Simon Kirby wrote:
> Hello,
>
> Today we put 2.4.1 on our mail server after having see it perform well on
> some other boxes. It seems now we are receiving a few calls every hour
> from customers reporting that the server tends to hang
Hello,
Today we put 2.4.1 on our mail server after having see it perform well on
some other boxes. It seems now we are receiving a few calls every hour
from customers reporting that the server tends to hang and eventually
time out on them when downloading mail. All customers that have reported
Hello,
Today we put 2.4.1 on our mail server after having see it perform well on
some other boxes. It seems now we are receiving a few calls every hour
from customers reporting that the server tends to hang and eventually
time out on them when downloading mail. All customers that have reported
On Fri, Feb 16, 2001 at 07:08:05PM -0500, Simon Kirby wrote:
Hello,
Today we put 2.4.1 on our mail server after having see it perform well on
some other boxes. It seems now we are receiving a few calls every hour
from customers reporting that the server tends to hang and eventually
time
On Tue, Feb 13, 2001 at 06:22:26PM +, Alan Cox wrote:
> > LDT allocated for cloned task!
> >
> > I'm seeing this message come up fairly often while running vanilla
> > 2.4.2-pre3 on my dual Celeron system. I don't think I saw it before
> > while running 2.4.1, but I may have just missed
LDT allocated for cloned task!
I'm seeing this message come up fairly often while running vanilla
2.4.2-pre3 on my dual Celeron system. I don't think I saw it before
while running 2.4.1, but I may have just missed it.
My system has been up around two days and has 11 of these messages in the
LDT allocated for cloned task!
I'm seeing this message come up fairly often while running vanilla
2.4.2-pre3 on my dual Celeron system. I don't think I saw it before
while running 2.4.1, but I may have just missed it.
My system has been up around two days and has 11 of these messages in the
On Tue, Feb 13, 2001 at 06:22:26PM +, Alan Cox wrote:
LDT allocated for cloned task!
I'm seeing this message come up fairly often while running vanilla
2.4.2-pre3 on my dual Celeron system. I don't think I saw it before
while running 2.4.1, but I may have just missed it.
Are
On Fri, Jan 26, 2001 at 07:14:42AM -0800, David S. Miller wrote:
> Jamie Lokier writes:
> > Does ECN provide perceived benefits to the node using it?
>
> Yes, endpoints and intermediate routers can tell the TCP sender about
> congestion instead of TCP having to guess about it based upon
On Fri, Jan 26, 2001 at 07:14:42AM -0800, David S. Miller wrote:
Jamie Lokier writes:
Does ECN provide perceived benefits to the node using it?
Yes, endpoints and intermediate routers can tell the TCP sender about
congestion instead of TCP having to guess about it based upon observed
On Tue, Jan 09, 2001 at 10:47:57AM -0800, Linus Torvalds wrote:
> And this _is_ a downside, there's no question about it. There's the worry
> about the potential loss of locality, but there's also the fact that you
> effectively need a bigger swap partition with 2.4.x - never mind that
> large
On Tue, Jan 09, 2001 at 10:47:57AM -0800, Linus Torvalds wrote:
And this _is_ a downside, there's no question about it. There's the worry
about the potential loss of locality, but there's also the fact that you
effectively need a bigger swap partition with 2.4.x - never mind that
large
On Wed, Nov 08, 2000 at 06:47:40PM +, Alan Cox wrote:
> Ok. Issue settled. So 'rep nop' is safe. Ok that can get into the spinlocks
> for 2.2.18
Just curious... What does "rep nop" actually accomplish, anyway?
Simon-
[ Stormix Technologies Inc. ][ NetNation Communications Inc. ]
[
On Wed, Nov 08, 2000 at 06:47:40PM +, Alan Cox wrote:
Ok. Issue settled. So 'rep nop' is safe. Ok that can get into the spinlocks
for 2.2.18
Just curious... What does "rep nop" actually accomplish, anyway?
Simon-
[ Stormix Technologies Inc. ][ NetNation Communications Inc. ]
[
Hmm... This seems to be happening every 20 minutes or so on a mail server
here. This box handles about 25-35 POP3 logins per second and has 1 GB
of RAM (compiled with the kernel at 1GB currently, oops). I have
2.2.18pre15+VM_global on there ready to go, but we haven't rebooted it to
that yet.
Hmm... This seems to be happening every 20 minutes or so on a mail server
here. This box handles about 25-35 POP3 logins per second and has 1 GB
of RAM (compiled with the kernel at 1GB currently, oops). I have
2.2.18pre15+VM_global on there ready to go, but we haven't rebooted it to
that yet.
On Mon, Oct 30, 2000 at 02:23:56PM +0800, Andrey Savochkin wrote:
> > > > Oct 26 16:38:01 ns29 kernel: eth0: card reports no resources.
> > > >
> > > let me guess: intel eepro100 or similar??
> > > Well known problem with that one. dont know if its fully fixed ... With
> >
> > Happens here
On Mon, Oct 30, 2000 at 02:23:56PM +0800, Andrey Savochkin wrote:
Oct 26 16:38:01 ns29 kernel: eth0: card reports no resources.
let me guess: intel eepro100 or similar??
Well known problem with that one. dont know if its fully fixed ... With
Happens here too, with 2xPPro200,
On Wed, Oct 25, 2000 at 12:23:07PM -0500, Jonathan Lemon wrote:
> Consider a program which reads from point A, writes to point B. If
> the buffer associated with B fills up, then we don't want to continue
> reading from A.
>
> A/B may be network sockets, pipes, or ptys.
Fine, but we
On Wed, Oct 25, 2000 at 07:08:48PM +0200, Jamie Lokier wrote:
> Simon Kirby wrote:
>
> > What applications would do better by postponing some of the reading?
> > I can't think of any reason off the top of my head why an application
> > wouldn't want to read everythin
On Wed, Oct 25, 2000 at 01:02:46AM -0500, Jonathan Lemon wrote:
> Yes, someone pointed me to those today. I would suggest reading
> some of the relevant literature before embarking on a design. My
> paper discusses some of the issues, and Mogul/Banga make some good
> points too.
>
> While an
On Tue, Oct 24, 2000 at 04:12:38PM -0700, Dan Kegel wrote:
> With poll(), it was *not a bug* for the user code to drop events; with
> your proposed interface, it *is a bug* for the user code to drop events.
> I'm just emphasizing this because Simon Kirby ([EMAIL PROTECTED]) posted
>
On Tue, Oct 24, 2000 at 04:12:38PM -0700, Dan Kegel wrote:
With poll(), it was *not a bug* for the user code to drop events; with
your proposed interface, it *is a bug* for the user code to drop events.
I'm just emphasizing this because Simon Kirby ([EMAIL PROTECTED]) posted
incorrectly
On Wed, Oct 25, 2000 at 01:02:46AM -0500, Jonathan Lemon wrote:
Yes, someone pointed me to those today. I would suggest reading
some of the relevant literature before embarking on a design. My
paper discusses some of the issues, and Mogul/Banga make some good
points too.
While an
On Wed, Oct 25, 2000 at 07:08:48PM +0200, Jamie Lokier wrote:
Simon Kirby wrote:
What applications would do better by postponing some of the reading?
I can't think of any reason off the top of my head why an application
wouldn't want to read everything it can.
Pipelined server.
1
On Wed, Oct 25, 2000 at 12:23:07PM -0500, Jonathan Lemon wrote:
Consider a program which reads from point A, writes to point B. If
the buffer associated with B fills up, then we don't want to continue
reading from A.
A/B may be network sockets, pipes, or ptys.
Fine, but we can
On Tue, Oct 24, 2000 at 10:03:04AM -0700, Linus Torvalds wrote:
> Basically, with get_events(), there is a maximum of one event per "bind".
> And the memory for that is statically allocated at bind_event() time.
>...
> But you'd be doing so in a controlled manner: the memory use wouldn't go
>
On Mon, Oct 23, 2000 at 10:39:36PM -0700, Linus Torvalds wrote:
> Actually, forget the mmap, it's not needed.
>
> Here's a suggested "good" interface that would certainly be easy to
> implement, and very easy to use, with none of the scalability issues that
> many interfaces have.
>...
>
On Mon, Oct 23, 2000 at 10:39:36PM -0700, Linus Torvalds wrote:
Actually, forget the mmap, it's not needed.
Here's a suggested "good" interface that would certainly be easy to
implement, and very easy to use, with none of the scalability issues that
many interfaces have.
...
Basically,
On Tue, Oct 24, 2000 at 10:03:04AM -0700, Linus Torvalds wrote:
Basically, with get_events(), there is a maximum of one event per "bind".
And the memory for that is statically allocated at bind_event() time.
...
But you'd be doing so in a controlled manner: the memory use wouldn't go
up
On Thu, Sep 21, 2000 at 09:39:07PM +0200, Torben Mathiasen wrote:
> Ok, small patch cooked up. Not tested, not compiled. Give
> it a try, and if it works please send it off to Linus.
> I really need to get some work done on a project...
This worked, thanks. :)
Simon-
[ Stormix Technologies
On Thu, Sep 21, 2000 at 02:34:01PM -0400, Douglas Gilbert wrote:
> I do nearly all of my testing with sg as a module.
> So this looks like (another recent) breakage.
>
> It is beginning to look like the sg driver is not
> (properly) initialized when it is built into the
> kernel. Perhaps you
On Thu, Sep 21, 2000 at 01:12:27PM -0400, Douglas Gilbert wrote:
> Interesting. 'cat /proc/scsi/scsi' should show the same
> devices as 'cat /proc/scsi/sg/device_strs' [and
> 'cat /proc/scsi/sg/devices']. If not, then the SCSI
> mid-level is not calling sg_detect() [in sg.c] for
> all new scsi
On Thu, Sep 21, 2000 at 01:12:27PM -0400, Douglas Gilbert wrote:
Interesting. 'cat /proc/scsi/scsi' should show the same
devices as 'cat /proc/scsi/sg/device_strs' [and
'cat /proc/scsi/sg/devices']. If not, then the SCSI
mid-level is not calling sg_detect() [in sg.c] for
all new scsi
On Thu, Sep 21, 2000 at 02:34:01PM -0400, Douglas Gilbert wrote:
I do nearly all of my testing with sg as a module.
So this looks like (another recent) breakage.
It is beginning to look like the sg driver is not
(properly) initialized when it is built into the
kernel. Perhaps you could
On Thu, Sep 21, 2000 at 09:39:07PM +0200, Torben Mathiasen wrote:
Ok, small patch cooked up. Not tested, not compiled. Give
it a try, and if it works please send it off to Linus.
I really need to get some work done on a project...
This worked, thanks. :)
Simon-
[ Stormix Technologies Inc.
1 - 100 of 108 matches
Mail list logo
