Switact - Thomas Roes <info@switact.nl> : Try http://userweb.kernel.org/~romieu/r8169/2.6.16/stable-46/to-2.6.24/ It contains a patch for the r8169 driver which should apply to your 2.6.16.46 based kernel and turn its r8169 driver into something closer to 2.6.24. The kit contains a stack of incremental patches too if you are curious. I have fixed some rejects, checked that everything compiles at each step but the patch is otherwise untested. Use at your own risk. -- Ueimor --

Hi just found out that the eSATA connector on my Intel DQ35JO motherboard doesn't work... because it is connected to the controller with product ID 29b6... And this ID is not yet handled by the driver. Can I have a patch, please?:-) I think the correct entry would be { 0x8086, 0x29b6, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_2port_sata }, just because it also has two ports. Am I right? I would rather not test blindly. BTW, why are these 2920, 2926, and 29b6 IDs not handled by the ahci driver...

Indeed! It was in "IDE" mode, and 2 out of the 3 chips were handled by the piix driver (btw, why did Intel put 3 different SATA controllers on one board?). I switched it to AHCI mode (the third possibility is RAID) and indeed a kernel with (only) ahci driver managed to bring them up! Although, the eSATA link was "slow to respond": ata4: port is slow to respond, please be patient (Status 0x80) ata4: softreset failed (device not ready) ata4: port is slow to respond, please be patient (Status 0x...

Right. I was working on a fix for that for a different reason. What we really want is a check for such a timer on a transition from SIGIGN to another state. This would allow us to drop the ugly auto rearm code for ignored timers completely. I had some working proof of concept code, but got distracted. Need to find it again and dust if off. Thanks, tglx --

fs/inode.c: use hlist_for_each_entry() in find_inode() and find_inode_fast() Signed-off-by: Matthias Kaehlcke <matthias@kaehlcke.net> -- diff --git a/fs/inode.c b/fs/inode.c index 53245ff..ab5dfc2 100644 --- a/fs/inode.c +++ b/fs/inode.c @@ -495,8 +495,7 @@ static struct inode * find_inode(struct super_block * sb, struct hlist_head *hea struct inode * inode = NULL; repeat: - hlist_for_each (node, head) { - inode = hlist_entry(node, struct inode, i_hash); + hlist_for_each_ent...

I'm not seeing why ndiswrapper should be treated separately. If it loads non-GPL modules, it shouldn't be able to use GPLONLY symbols. So if ndiswrapper needs GPL-only symbols, you'd better ask the people who made those symbols GPL-only whether they could be made available to ndiswrapper. ndiswrapper itself is *not* compatible with the GPL. Trying to claim that ndiswrapper somehow itself is GPL'd even though it then loads modules that aren't is stupid and pointless. Clearly it just re...

Please keep all CCs. Others that will read lkml later will want to know what you found out. Ingo will have to answer the scheduler part of that. But it's good to keep in mind that the scheduler can't do anything about slowdowns due to tasks being swapped out or waiting on reads from the disk. I mention this as shortly after CFS got into mainline, something changed in the VM that seems to make my system spend a lot more time in IO wait, causing the system to be much less responsive than it used...

All control files created by cgroup subsystems are given a prefix corresponding to their subsystem name. But control files provided by cgroups itself have no prefix. Currently that set of files is just "tasks", "notify_on_release" and "release_agent", but that set is likely to expand in the future. To reduce the risk of clashes, it would make sense to prefix these files and any future ones with the "cgroup." prefix. The only reason that I can see *not* to do this would be for compatibility with 2....

To me it seems quite logical that files belonging to the cgroup subsystem would have no prefix, and I don't see any good reason to do so. -serge --

On Thu, Feb 28, 2008 at 1:21 PM, Andrew Morton The point would be to avoid situations where a user has code that creates a group directory called "foo", and then in a future kernel release cgroups introduces a control file called "foo". If it's prefixed, then the user just has to avoid creating groups prefixed by "cgroup." or any subsystem name, so collisions will be less likely. Paul --

Nothing concrete right now. One example that I already proposed was the "cgroup.api" file but that's shelved for now, until such time as I It's hard to determine what likely taskgroup names would be. For my own use, pretty much every group has a unique 64-bit ID in the name so this isn't something I worry about directly affecting our systems. But The existing "noprefix" option controls whether the *subsystems* get prefixes. It's mainly there to provide backwards compatibility for cpusets. Exist...

On Thu, Feb 28, 2008 at 1:40 PM, Andrew Morton Well, that API (mixing control files and group directories in the same directory namespace) was inherited directly from cpusets. It wouldn't be hard to throw that away and move all the user-created group directories into their own subdirectory, i.e. change the existing directory layout from something like: /mnt/cgroup/ tasks cpu.shares memory.limit_in_bytes memory.usage_in_bytes user_created_groupname1/ tasks ...

On Thu, Feb 28, 2008 at 2:21 PM, Andrew Morton That's something like putting them all in their own sub-directory, but We already have something like that in place, actually. When you mount the legacy "cpuset" filesystem, it just passes through to the cgroup filesystem with the mount options "cpuset,noprefix", i.e. mount a cgroups hierarcy with just cpusets bound to it, and *don't* prefix subsystem control files with the subsystem name. It wouldn't be hard to also have a "nosubdir" mount optio...

Hi, Jonathan, Please attach the acpidump output using the latest pmtools at : http://www.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/ Please attach the result of "cat /proc/acpi/thermal_zone/*/*" as well. thanks, rui --

Willy, I agree. That would also work nicely. I do wish SO_REUSEPORT was available. But, I am amazed that this issue has a long history (I've seen posts from 1999) and that there was no progress with it. Thanks, Neb --

I haven't tried to repro this yet, but I suspect I won't be able to because all my test machines have constant_tsc. Does CPU change TSC rate on processor speed changes? J --

In order to apply a kernel patch diff'd against an older kernel, I ran git checkout -b tmp v2.6.23 git-am --signoff --utf8 /g/tmp/mbox The patch applied successfully, but each time I run this, it starts an IMO there is a broken hueristic in there somewhere... I regularly run 'git gc' on my repos... Jeff --

What happens if you try to run "git prune"? Nicolas --

sudo ln -sf /usr/bin/git-gc /bin/echo (-; -- Asheesh. -- Maternity pay? Now every Tom, Dick and Harry will get pregnant. -- Malcolm Smith --

This way firewire-ohci can be used for remote debugging like ohci1394. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> --- Documentation/debugging-via-ohci1394.txt | 13 ++++++++----- drivers/firewire/fw-ohci.c | 9 +++++++++ lib/Kconfig.debug | 10 ++++++++++ 3 files changed, 27 insertions(+), 5 deletions(-) Index: linux/Documentation/debugging-via-ohci1394.txt =================================================================== --- l...

The block/unblock logic is now sufficiently tested. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> --- To be postponed after 2.6.25. drivers/firewire/fw-sbp2.c | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) Index: linux/drivers/firewire/fw-sbp2.c =================================================================== --- linux.orig/drivers/firewire/fw-sbp2.c +++ linux/drivers/firewire/fw-sbp2.c @@ -687,10 +687,8 @@ static void sbp2_conditionally_block(str ...

How hard can it be to switch on one bit? :-) Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> --- drivers/firewire/fw-sbp2.c | 11 ++--------- 1 file changed, 2 insertions(+), 9 deletions(-) Index: linux/drivers/firewire/fw-sbp2.c =================================================================== --- linux.orig/drivers/firewire/fw-sbp2.c +++ linux/drivers/firewire/fw-sbp2.c @@ -174,9 +174,6 @@ struct sbp2_target { #define SBP2_ORB_NULL 0x80000000 #define SBP2_MAX_SG_ELE...

V2 -> V3: + rebase to 23-mm1 atop RvR's split lru series [no change] + fix function return types [void -> int] to fix build when not configured. New in V2. We need to hold the mmap_sem for write to initiatate mlock()/munlock() because we may need to merge/split vmas. However, this can lead to very long lock hold times attempting to fault in a large memory region to mlock it into memory. This can hold off other faults against the mm [multithreaded tasks] and other scans of the mm, suc...

V2 -> V3: + rebase to 23-mm1 atop RvR's split lru series. V1 -> V2: + no changes Optional part of "noreclaim infrastructure" In the fault paths that install new anonymous pages, check whether the page is reclaimable or not using lru_cache_add_active_or_noreclaim(). If the page is reclaimable, just add it to the active lru list [via the pagevec cache], else add it to the noreclaim list. This "proactive" culling in the fault path mimics the handling of mlocked pages in Nick Piggin's...

On Thu, 28 Feb 2008 15:19:33 -0500 Thanks. I have merged your new description. -- All rights reversed. --