I know you've seen those work at home programs before, but this one is for real! Selling coffee recipe downloads for $1 each on an affiliate website and you keep all the money! They charge 32.95 for the website for life & give you a refund after you earn $150.00. I signed up & got the refund in 4 days, check it out! www.CoffeeKorner.com/members.htm See ya! Kim -

Hello, I am running a P2P related server, which has many connections to it at one time (about 100,000 at peak times). But I have been getting eserver invoked oom-killer: gfp_mask=0xd0, order=0, oomkilladj=0 errors followed by Out of socket memory I believe this is related to rmem, but I am not sure. Here's my current net related sysctl settings net.core.wmem_max = 8388608 net.core.rmem_max = 8388608 net.core.wmem_default = 104448 net.core.rmem_default = 104448 net.core.dev_weight = 64 net.core...

Still being a little new at this I am not sure if this is an issue at all or not but I noted that while building the 2.6.23-rc6-git8 kernel this afternoon I received the following error message: Building modules, stage 2. MODPOST 1670 modules WARNING: Can't handle masks in drivers/mtd/nand/cafe_nand:FFFF0 I have been building each of the kernels in the 2.6.23-rc series and had not noted this message before. I apologize if this is a non-issue. -

The tcp_check_space() function calls tcp_new_space() only if the SOCK_NOSPACE bit is set in the socket flags. This is causing Edge Triggered EPOLLOUT events to be missed for TCP sockets, as the ep_poll_callback() is not called from the wakeup routine. The SOCK_NOSPACE bit indicates the user's intent to perform writes on that socket (set in tcp_sendmsg and tcp_poll). I believe the idea behind the SOCK_NOSPACE check is to optimize away the tcp_new_space call in cases when user is not intere...

You're not planning of putting the notion of a SOCK_NOSPACE bit inside a completely device-unaware interface like epoll, I hope? - Davide -

Dave, I agree that setting SOCK_NOSPACE would have been a more elegant fix. Infact I thought a lot about that before deciding on this fix. But the point here is that the SOCK_NOSPACE bit can be set when the sndbuf space is really less (less than sk_stream_min_wspace()) and some user action (sendmsg or poll) indicated his intent to write. In the case mentioned none of these is true. Since user wants to manage his tranmit buffers himself, his definition of less may not match with wh...

I'm sure you would have seen value in the check that's why the check is there. Now we have two critical points to discuss 1. How can we achieve the ET EPOLLOUT event with the SOCK_NOSPACE check in place ? 2. How much effect will removing the check have (if we cannot find a way to get the ET EPOLLOUT notification w/ the check in place) ? Regding (2), IMHO for a "fast sender" the SOCK_NOSPACE check will almost always pass as the sender will come back to write (or poll) before ...

Thank you for reviewing my patch. Yes, your approach looks better than mine. I've tested it and it looks working fine in my test case. I attached the test case. Will you write a patch to replace mine? Thanks, Hiroshi Shimamoto

The following is a series of patches related to Unionfs. They represent a few code cleanups (suggested or inspired by comments on the previous set of patches), and a few more bug fixes (esp. to cache coherency). These fixes were tested on our 2.6.23-rc6 latest code, as well as the backports to 2.6.{22,21,20,19,18,9} on ext2/3/4, xfs, reiserfs, nfs, jffs2, ramfs, tmpfs, cramfs, and squashfs (where available). See http://unionfs.filesystems.org/ to download backported unionfs code. Please pull f...

Ensure that our lookup locking is consistent and symmetric: if a lock existed before calling lookup_backend, it should remain so; only if performing a lookup of a known new dentry, should lookup_backend return a newly-locked dentry-inode info (and only if there was no error). Document this behavior. This cleanup allowed us to remove two unnecessary int declarations. Signed-off-by: Erez Zadok <ezk@cs.sunysb.edu> Acked-by: Josef Sipek <jsipek@fsl.cs.sunysb.edu> --- fs/unionfs/inode.c...

Signed-off-by: Erez Zadok <ezk@cs.sunysb.edu> Acked-by: Josef Sipek <jsipek@fsl.cs.sunysb.edu> --- fs/unionfs/commonfops.c | 12 ++++++------ fs/unionfs/dentry.c | 2 +- fs/unionfs/dirfops.c | 4 ++-- fs/unionfs/file.c | 12 ++++++------ fs/unionfs/mmap.c | 6 +++--- fs/unionfs/union.h | 2 +- 6 files changed, 19 insertions(+), 19 deletions(-) diff --git a/fs/unionfs/commonfops.c b/fs/unionfs/commonfops.c index 724128d..87cbb09 100644 --- a/...

Signed-off-by: Erez Zadok <ezk@cs.sunysb.edu> Acked-by: Josef Sipek <jsipek@fsl.cs.sunysb.edu> --- fs/unionfs/dentry.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/unionfs/dentry.c b/fs/unionfs/dentry.c index f32922e..91f9780 100644 --- a/fs/unionfs/dentry.c +++ b/fs/unionfs/dentry.c @@ -438,13 +438,13 @@ static void unionfs_d_release(struct dentry *dentry) unionfs_check_dentry(dentry); /* this could be a negative dentry, so check first */ if...

Nice fix! It's a 2.6.23 must-have fix - i'll push it out into the scheduler tree. Thanks! Ingo -

Hi all I migrated one of my server from kernel 2.6.18 to the latest 2.6.22 and I experienced lower disk performance for processes that open file with the O_DIRECT flag. I did a very simple test program that opens two files with O_DIRECT flag and reads the files to end. I monitored the time spent to read the files and I have ~ 40% of difference between 2.6.18 and 2.6.22. For information, the files are stored on a XFS partition which is part of a software raid-5 block device (the raid-5 is made ...

The latest maintenance release GIT 1.5.3.2 is available at the usual places: http://www.kernel.org/pub/software/scm/git/ git-1.5.3.2.tar.{gz,bz2} (tarball) git-htmldocs-1.5.3.2.tar.{gz,bz2} (preformatted docs) git-manpages-1.5.3.2.tar.{gz,bz2} (preformatted docs) RPMS/$arch/git-*-1.5.3.2-1.$arch.rpm (RPM) GIT v1.5.3.2 Release Notes ========================== Fixes since v1.5.3.1 -------------------- * git-push sent thin packs by default, which was not good for the p...

Yes, it does (depending also on what you mean by 'now'). Greetings, Rafael -

Sorry, I have misunderstood your post (the "now" doesn't look as a part of the command). Greetings, -

Recently, the CE Linux forum has been working to revive the Linux-tiny project. At OLS, I asked for interested parties to volunteer to become the new maintainer for the Linux-tiny patchset. A few candidates came forward, but eventually Michael Opdenacker was selected as the new primary maintainer. A few other people, including John Cooper of Wind River and myself are working to support this effort. Recently, many of the Linux-tiny patches have been brought up-to-date and are now available for ...

OK, I'll try to accelerate the effort to send these to you. We'll still need some kind of bucket for the patches that don't apply to recent kernels, but which no one has yet had time to bring up-to-date (or evaluate for permanent dismissal). And dribbling them out, fixing them up, responding to issues - all take time that I can't commit to personally for the next week or so. I'll let Michael respond whether he can get to this sooner rather than later, as planned. ============================= ...

Not sure what the point is of a separate patchkit. If it's a reasonable patch it should just be put into mainline. And hopefully all the patches will be reasonable. -Andi -

Is anybody working on testing that the patchkit "does no harm" for bigger boxes (laptops, desktops, servers)? That would probably be helpful info when pieces are pushed towards mainline.... (Was just looking at the patch details, there's at least a few that look interesting for my purposes even though I'm not an embedded developer)...

Tim is right, Linux-Tiny features are only activated by configuration options. However, that doesn't prevent us from proposing size reduction changes impacting all kernel users, in cases a configuration option doesn't make sense. Extensive testing in the -mm tree will then be required. Cheers, Michael. -- Michael Opdenacker http://free-electrons.com +33 621 604 642 -

Will there be a separate git for testing? Is the idea to still keep moving patches upstream? Luis -

[ The first version of this patch conflicted with the irqstack fix merged last night - this is the fixed version ] Now, the idle loop now longer needs SIGALRM firing - it can just sleep for the requisite amount of time and fake a timer interrupt when it finishes. Any use of ITIMER_REAL now goes away. disable_timer only turns off ITIMER_VIRTUAL. switch_timers is no longer needed, so it, and all calls, goes away. disable_timer now returns the amount of time remaining on the timer. default_i...

There are various uses of powers of 1000, plus the odd BILLION constant in the time code. However, there are perfectly good definitions of *SEC_PER_*SEC in linux/time.h which can be used instaed. These are replaced directly in kernel code. Userspace code imports those constants as UM_*SEC_PER_*SEC and uses these. Signed-off-by: Jeff Dike <jdike@linux.intel.com> --- arch/um/include/common-offsets.h | 4 ++++ arch/um/include/os.h | 2 -- arch/um/kernel/time.c ...