On Sat, Apr 21, 2007 at 02:17:02PM -0400, Gene Heskett wrote:
CFS-v4 is quite smooth in terms of the users experience but after prolonged
observations approaching 24 hours, it appears to choke the cpu hog off a bit
even when the system has nothing else to do. My amanda runs went from 1 to
From: Miklos Szeredi [EMAIL PROTECTED]
Add sysctl variables for accounting and limiting the number of user
mounts.
The maximum number of user mounts is set to 1024 by default. This
won't in itself enable user mounts, setting a mount to be owned by a
user is first needed
On Tue, 17 Apr 2007 03:15:51 -0400 Rik van Riel [EMAIL PROTECTED] wrote:
Make it possible for applications to have the kernel free memory
lazily. This reduces a repeated free/malloc cycle from freeing
pages and allocating them, to just marking them freeable. If the
application wants to
On Apr 21 2007 10:57, Eric W. Biederman wrote:
tmpfs!
tmpfs is a possible problem because it can consume lots of ram/swap.
Which is why it has limits on the amount of space it can consume.
Users can gobble up all RAM and swap already today. (Unless they are
confined into an
i'm pleased to announce release -v4 of the CFS patchset. The patch
against v2.6.21-rc7 can be downloaded from:
http://redhat.com/~mingo/cfs-scheduler/
I can't get 2.6.21-rc7-CFS-v4 to boot. Immediately after selecting
this kernel I see a very fast scrolling (loop?) sequence of addrs
On Sun, 22 Apr 2007 10:39:41 +0200 Bastian Blank [EMAIL PROTECTED] wrote:
The commit 34f5a39899f3f3e815da64f48ddb72942d86c366 restricted reading
of the tainted value. The attached patch changes this back to a
write-only check and restores the read behaviour of older versions.
Signed-off-by:
On Sunday 22 April 2007 18:06, Willy Tarreau wrote:
On Sun, Apr 22, 2007 at 05:31:58PM +1000, Con Kolivas wrote:
On Sunday 22 April 2007 17:27, Con Kolivas wrote:
On Sunday 22 April 2007 17:00, Willy Tarreau wrote:
On Sun, Apr 22, 2007 at 02:41:48PM +1000, Con Kolivas wrote:
A
On 4/22/07, William Lee Irwin III [EMAIL PROTECTED] wrote:
I'm just looking for what people want the API to be here. With that in
hand we can just go out and do whatever needs to be done.
On Sun, Apr 22, 2007 at 12:17:31AM -0700, Ulrich Drepper wrote:
I think a sched_yield_to is one interface:
On Sun, Apr 22, 2007 at 01:50:45AM -0700, Andrew Morton wrote:
On Sun, 22 Apr 2007 10:39:41 +0200 Bastian Blank [EMAIL PROTECTED] wrote:
The commit 34f5a39899f3f3e815da64f48ddb72942d86c366 restricted reading
of the tainted value. The attached patch changes this back to a
write-only check
On Sun, 2007-04-22 at 00:19 -0700, Andrew Morton wrote:
It could be that we never call test_clear_page_writeback() against
!bdi_cap_writeback_dirty() pages anwyay. I can't think why we would, but
the relationships there aren't very clear. Does don't account for dirty
memory imply doesn't
On Sat, Apr 21, 2007 at 09:04:06PM +0200, Andreas Gruenbacher wrote:
It is unspecified whether all members of the statvfs structure have
meaningful values on all file systems.
In my opinion, the advantage of not reporting bogus pathnames in /proc/mounts
by far outweighs the problems is
The commit 34f5a39899f3f3e815da64f48ddb72942d86c366 restricted reading
of the tainted value. The attached patch changes this back to a
write-only check and restores the read behaviour of older versions.
Signed-off-by: Bastian Blank [EMAIL PROTECTED]
--
The joys of love made her human and the
Disable stacktrace filter support for x86-64 for now.
Will be enable when we can get the dwarf2 unwinder back.
Signed-off-by: Akinobu Mita [EMAIL PROTECTED]
---
lib/Kconfig.debug |1 +
1 file changed, 1 insertion(+)
Index: 2.6-git/lib/Kconfig.debug
Currently failslab injects failures into cache_alloc().
But with enabling CONFIG_NUMA it's not enough to let actual
slab allocator functions (kmalloc, kmem_cache_alloc, ...) return NULL.
This patch moves fault injection hook inside of __cache_alloc() and
__cache_alloc_node(). These are lower
On Sun, Apr 22, 2007 at 01:18:10AM -0700, Andrew Morton wrote:
On Tue, 17 Apr 2007 03:15:51 -0400 Rik van Riel [EMAIL PROTECTED] wrote:
Make it possible for applications to have the kernel free memory
lazily. This reduces a repeated free/malloc cycle from freeing
pages and allocating
Add maintainer for fault injection support.
Signed-off-by: Akinobu Mita [EMAIL PROTECTED]
---
MAINTAINERS |5 +
1 file changed, 5 insertions(+)
Index: 2.6-git/MAINTAINERS
===
--- 2.6-git.orig/MAINTAINERS
+++
On Sun, Apr 22, 2007 at 06:53:58PM +1000, Con Kolivas wrote:
On Sunday 22 April 2007 18:06, Willy Tarreau wrote:
On Sun, Apr 22, 2007 at 05:31:58PM +1000, Con Kolivas wrote:
On Sunday 22 April 2007 17:27, Con Kolivas wrote:
On Sunday 22 April 2007 17:00, Willy Tarreau wrote:
On Sun,
On Sat, Apr 21, 2007 at 02:06:22PM -0700, Andrew Morton wrote:
On Sat, 21 Apr 2007 22:01:47 +0100 Alan Cox [EMAIL PROTECTED] wrote:
+#define lower_32_bits(n) (sizeof(n) == 8 ? (u32)(n) : (n))
n0x would be simpler.
Do we actually have any call for this?
The only
KVM shadow page tables are always in pae mode, regardless of the guest
setting. This means that a guest pde (mapping 4MB of memory) is mapped
to two shadow pdes (mapping 2MB each).
When the guest writes to a pte or pde, we intercept the write and emulate it.
We also remove any shadowed mappings
PAGE_MASK is an unsigned long, so using it to mask physical addresses on
i386 (which are 64-bit wide) leads to truncation. This can result in
page-private of unrelated memory pages being modified, with disasterous
results.
Fix by not using PAGE_MASK for physical addresses; instead calculate
the
On Sunday 22 April 2007 09:53, Martin Schwidefsky wrote:
On Sun, 2007-04-22 at 01:19 +0200, Arnd Bergmann wrote:
diff -urpN linux-2.6/drivers/ssb/Kconfig
linux-2.6-patched/drivers/ssb/Kconfig
--- linux-2.6/drivers/ssb/Kconfig 2007-04-19 15:24:40.0
+0200
+++
On Sunday 22 April 2007 19:14, Willy Tarreau wrote:
On Sun, Apr 22, 2007 at 06:53:58PM +1000, Con Kolivas wrote:
On Sunday 22 April 2007 18:06, Willy Tarreau wrote:
On Sun, Apr 22, 2007 at 05:31:58PM +1000, Con Kolivas wrote:
On Sunday 22 April 2007 17:27, Con Kolivas wrote:
On
So after a cheerful five hours making all the new crap with which they have
inflicted me actually compile, first up is powerpc:
initcall 0xc06dc650: .scsi_complete_async_scans+0x0/0x1dc() returned 0.
initcall 0xc06dc650 ran for 0 msecs:
.scsi_complete_async_scans+0x0/0x1dc()
Hi all,
Back to 2.4... I've just released Linux 2.4.35-pre3.
We're getting closer to 2.4.35. It is in good shape, and the major
change I was most afraid of (e1000 driver update) works like a charm.
Kudos to intel people on this one !
I will still have to see whether the skge/sky2 drivers are
I've just released Linux 2.4.34.3.
Nothing critical, just a bunch of bugfixes and small security fix.
The patch and changelog will appear soon at the following locations:
ftp://ftp.kernel.org/pub/linux/kernel/v2.4/
ftp://ftp.kernel.org/pub/linux/kernel/v2.4/patch-2.4.34.3.bz2
On 4/22/07, oliver pinter [EMAIL PROTECTED] wrote:
Hello
I have ASUS P4C800, P4 3GHz HT (Nortwood), 512RAM and I have nothing errors
in my cpu.
in bios have you HT option enabled
Sure, and the hardware is fine as other kernels and other systems (as
WinXP) work fine.
or im =2.6.21-rc7
Andrew Morton wrote:
On Sat, 21 Apr 2007 11:26:31 -0400 Jeff Mahoney [EMAIL PROTECTED] wrote:
The listxattr() and getxattr() operations are only protected by a read
lock. As a result, if either of these operations run in parallel, a race
condition exists where the xattr_root will end up
irq values are u32, not u8. Large irq numbers will be truncated,
free_irq may free a different irq.
Remove incorrectly sized struct member and use the one from pci_dev.
Signed-off-by: Olaf Hering [EMAIL PROTECTED]
---
drivers/serial/icom.c |5 ++---
drivers/serial/icom.h |1 -
2 files
On Sunday 22 April 2007 18:02, Michael Gerdau wrote:
Hi Con,
I now have 2.6.21-rc7-sd-0.45 running on my Intel Core2 T7600 2.33
machine and there is something I don't understand.
For testing I have a Perl script that does some numbercrunching
and runs a couple of hours.
I have two
On Sunday 22 April 2007, William Lee Irwin III wrote:
On Sat, Apr 21, 2007 at 02:17:02PM -0400, Gene Heskett wrote:
CFS-v4 is quite smooth in terms of the users experience but after
prolonged observations approaching 24 hours, it appears to choke the cpu
hog off a bit even when the system has
Hi Ogawa :)
* OGAWA Hirofumi [EMAIL PROTECTED] dixit:
DervishD [EMAIL PROTECTED] writes:
A mount option to force walking the FAT and getting the real
info could be interesting. That way, it will be only done for
certain devices (small disks, for example).
Yes. It seems that Windows
On Sunday 22 April 2007 20:48, Martin Steigerwald wrote:
Am Montag 09 April 2007 schrieb Mike Galbraith:
On Mon, 2007-04-09 at 07:26 -0400, Ed Tomlinson wrote:
On Monday 09 April 2007 01:38, Mike Galbraith wrote:
On Sun, 2007-04-08 at 09:08 -0400, Ed Tomlinson wrote:
Hi,
I
Am Montag 09 April 2007 schrieb Mike Galbraith:
On Mon, 2007-04-09 at 07:26 -0400, Ed Tomlinson wrote:
On Monday 09 April 2007 01:38, Mike Galbraith wrote:
On Sun, 2007-04-08 at 09:08 -0400, Ed Tomlinson wrote:
Hi,
I am one of those who have been happily testing Con's patches.
Hi Ogawa (and Andrew) :)
* OGAWA Hirofumi [EMAIL PROTECTED] dixit:
Andrew Morton [EMAIL PROTECTED] writes:
Is there some way in which we can work out what's happened and fix
it up?
It seems that the recent Windows changed specification, and it's
undocumented. Windows doesn't update
Hi,
On Sunday 22 April 2007 00:42, OGAWA Hirofumi wrote:
Yes. It seems that Windows does not update the -free_clusters correctly.
Probably, I think the option is good for now. What do you think about
an attached patch?
Please don't ask me, because I'm not a filesystem expert. Sorry. My
On Sunday 22 April 2007 19:14, Willy Tarreau wrote:
On Sun, Apr 22, 2007 at 06:53:58PM +1000, Con Kolivas wrote:
On Sunday 22 April 2007 18:06, Willy Tarreau wrote:
On Sun, Apr 22, 2007 at 05:31:58PM +1000, Con Kolivas wrote:
On Sunday 22 April 2007 17:27, Con Kolivas wrote:
On
DervishD [EMAIL PROTECTED] writes:
The problem is that if a program writes a file onto the filesystem
without using statfs first to check for free space, the free_clusters
entry won't have the real value and the driver may report disk full (I
haven't read the code for the vfat driver,
On Thu, Apr 19, 2007 at 12:55:29AM -0600, Eric W. Biederman wrote:
From: Eric W. Biederman [EMAIL PROTECTED] - unquoted
kthread_run replaces the kernel_thread and daemonize calls
during thread startup.
Calls to signal_pending were also removed as it is currently
impossible for the
On Thu, Apr 19, 2007 at 12:55:30AM -0600, Eric W. Biederman wrote:
From: Eric W. Biederman [EMAIL PROTECTED] - unquoted
kthread_run replaces kernel_thread and dameonize.
allow_signal is unnecessary and has been removed.
tid_poll was unused and has been removed.
Thread handling in this
On Thu, Apr 19, 2007 at 12:55:31AM -0600, Eric W. Biederman wrote:
From: Eric W. Biederman [EMAIL PROTECTED] - unquoted
This patch changes cpqphp to use kthread_run and not
kernel_thread and daemonize to startup and setup
the cpqphp thread.
Thread handling in this driver (and actually
The created a warning storm:
Hmm, yes good idea to fix that. Probably for x86-64 too.
I worry rather a lot about how well runtime tested this very late change
was,
I tested it with oprofile and checked the nmi watchdog.
and whether it works correctly even with this fix applied.
Hi,
Finally, tifm_sd module needs to be manually inserted.
By the way, the driver emits custom uevent when the new card is detected. I was
going to look at
this some day in the future, but if you want to mess a little with hotplug
scripts the issue can
be easily solved.
It would be nice
Looks like you were missing at least the pcie hotplug driver. Another
one of the horrible thread abuses in drivers/pci/hotpug.
- full conversion to kthread infrastructure
- use wake_up_process to wake the thread up
Like most pci hotplug drivers it still uses very race non-atomic variable
On Sunday 22 April 2007 21:42, Con Kolivas wrote:
Willy I'm still investigating the idle time and fluctuating load as a separate
issue. Is it possible the multiple ocbench processes are naturally
synchronising and desynchronising and choosing to sleep and/or run at the
same time? I can remove
Am 22.04.2007 00:10 schrieb David Miller:
From: Alan Cox [EMAIL PROTECTED]
Date: Sat, 21 Apr 2007 21:58:44 +0100
On Sat, 21 Apr 2007 15:07:51 +0200
Tilman Schmidt [EMAIL PROTECTED] wrote:
From: Tilman Schmidt [EMAIL PROTECTED]
The obsolete label on the ISDN_I4L Kconfig option is not, and
On Thu, Apr 19, 2007 at 12:55:28AM -0600, Eric W. Biederman wrote:
From: Eric W. Biederman [EMAIL PROTECTED] - unquoted
thread_run is used intead of kernel_thread, daemonize, and mucking
around blocking signals directly.
This is the full conversion I sent to Dave in April 2006, but never got
On Thu, Apr 19, 2007 at 01:58:45AM -0600, Eric W. Biederman wrote:
From: Eric W. Biederman [EMAIL PROTECTED]
This patch modifies the startup of eehd to use kthread_run
not a combination of kernel_thread and daemonize. Making
the code slightly simpler and more maintainable.
This one has the
On Thu, Apr 19, 2007 at 01:58:46AM -0600, Eric W. Biederman wrote:
From: Eric W. Biederman [EMAIL PROTECTED]
This patch modifies the startup of rtasd to use kthread_run instaed of
a combination of kernel_thread and daemonize. Making the code a little
simpler and more maintainble.
Looks
On Sun, Apr 22, 2007 at 01:38:23PM +0100, Alan Cox wrote:
over-engineering. Call it sector_upper32() do it the simple way and stop
trying to solve a problem we don't have
James said we have the same problem with dma_addr_t.
Yes. It's in fact the far more common case and we
over-engineering. Call it sector_upper32() do it the simple way and stop
trying to solve a problem we don't have
James said we have the same problem with dma_addr_t.
Yes. It's in fact the far more common case and we have a bread of
macros dealing with the issue in various drivers.
Hi,
I just wondered if the below type of crash was a known thing, and if
there are any obvious things I can do to prevent/fix it ?
BUG: spinlock bad magic on CPU#0, kswapd0/242 (Not tainted)
lock: c06c9380, .magic: c06c9380, .owner:
[c06eba2a] _raw_spin_lock+0x1a/0xd9
[c061e72f]
On 4/22/07, oliver pinter [EMAIL PROTECTED] wrote:
I have CC the kernel
Did you?
and the result is:
your'e config : failed smp
your'e config + power managment : ok
Interesting, can anyone tell me why does not SMP work without Power
Managment? Should it be that way?
--
Miguel Ojeda
Just to throw another possibly-overlooked variable into the mess:
My system here is using the on-demand cpufreq policy governor.
I wonder how that interacts with the various schedulers here?
I suppose for the make kernel case, after a couple of seconds
the cpufreq would hit max and stay there
If it isn't obsolete then fix the code to use the newer APIs
Why should that be a precondition for removing the incorrect
obsolete label?
Because if we remove the obsolete label the users are going to be
suprised when it goes away entirely with BROKEN or !HOTPLUG or
similar.
to end up
On 4/19/07, Dmitry Torokhov [EMAIL PROTECTED] wrote:
On 4/19/07, Jiri Slaby [EMAIL PROTECTED] wrote:
Dmitry Torokhov napsal(a):
If we are interested in using FF API we need to come up with a way
to express this effect without exposing implementation details of
one particular device.
On Sunday 22 April 2007 22:54, Mark Lord wrote:
Just to throw another possibly-overlooked variable into the mess:
My system here is using the on-demand cpufreq policy governor.
I wonder how that interacts with the various schedulers here?
I suppose for the make kernel case, after a couple of
On Sun, 2007-04-22 at 13:24 +0100, Christoph Hellwig wrote:
This is the full conversion I sent to Dave in April 2006, but never
got any feedback to:
Sorry about that; I need prodding sometimes. I'll provide some now...
Can you show me why the thread won't now miss a wakeup if it goes to
sleep
Con Kolivas wrote:
Oh I definitely was not advocating against renicing X, I just suspect that
virtually all the users who gave glowing reports to CFS comparing it to SD
had no idea it had reniced X to -19 behind their back and that they were
comparing it to SD running X at nice 0.
I really
Bodo Eggert [EMAIL PROTECTED] writes:
Windows _does_ care*, it will pretend the disk to be full.
Did you test on 2000 or XP? (e.g. write 0 to free_clusters, then
create new file.)
- usefree is a bad name (I'd suggest recalc_free instead),
Is it about nofree option?
and your description is
On 4/22/07, Mark Lord [EMAIL PROTECTED] wrote:
Opcode 0xb0 is WIN_SMART.
Error 0x04 is command aborted/rejected/unsupported.
Something on your system is issuing S.M.A.R.T. commands from userspace
to the drive, and the drive either (1) doesn't support S.M.A.R.T.,
or (2) currently does not have
Am 22.04.2007 14:58 schrieb Alan Cox:
If it isn't obsolete then fix the code to use the newer APIs
Why should that be a precondition for removing the incorrect
obsolete label?
Because if we remove the obsolete label the users are going to be
suprised when it goes away entirely with BROKEN
OGAWA Hirofumi [EMAIL PROTECTED] writes:
- You forgot to update Documentation/
Sure. If you can post the patch, it'll be great.
Updated patch is here.
Thanks.
--
OGAWA Hirofumi [EMAIL PROTECTED]
It seems that the recent Windows changed specification, and it's
undocumented. Windows
Anyway the more important part is... Can you test this patch please? Dump
all the other patches I sent you post 045. Michael, if you could test too
please?
Have it up running for 40 minutes now and my perljobs show a constant
cpu utilization of 100/50/50 in top most of the time. When the 100%
The task load_weight needs to be set every time the quota is set and wasn't
being set in activate_task which assumed it would not have changed. Due to
changes in where the default rr_interval is set on SMP this assumption
failed. Also if one were to change rr_interval on the fly it would break
On 4/22/07, Len Brown [EMAIL PROTECTED] wrote:
This is an AML run-time error from a PCI Interrupt Link
trying to find its Present Resource Settings --
ie. the current IRQ for a programmable IRQ.
Please open up a bug report here:
http://bugzilla.kernel.org/enter_bug.cgi?product=ACPI
Yep,
On Sun, Apr 22, 2007 at 10:18:32PM +1000, Con Kolivas wrote:
On Sunday 22 April 2007 21:42, Con Kolivas wrote:
Willy I'm still investigating the idle time and fluctuating load as a
separate
issue. Is it possible the multiple ocbench processes are naturally
synchronising and
Andreas Schwab [EMAIL PROTECTED] writes:
OGAWA Hirofumi [EMAIL PROTECTED] writes:
diff -puN
Documentation/filesystems/vfat.txt~fat_dont-use_free_clusters-for-fat32
Documentation/filesystems/vfat.txt
---
linux-2.6/Documentation/filesystems/vfat.txt~fat_dont-use_free_clusters-for-fat32
On 4/22/07, Andrew Morton [EMAIL PROTECTED] wrote:
(added linux-acpi)
Are any other problems observeable due to this?
This issue I did observe with 2.6.20.7 2.6.21-rc7. Should I try anymore tests?
Anyway, here is the dmesg of 2.6.21-rc7:-
Linux version 2.6.21-rc7-Akula2 ([EMAIL
OGAWA Hirofumi [EMAIL PROTECTED] wrote:
* Juergen Beisert [EMAIL PROTECTED] dixit:
So the last free sector count is also stored. When mounting this
filesystem you don't need to walk through the whole FAT to calculate
the available space, you can use this cached value instead. And this
On Fri, 20 Apr 2007, Alan Cox wrote:
I'm looking for some testers for a revamp of the initio driver. No real
code changes other than to hopefully stop it exploding on load on 64bit,
but a major reorganisation, commenting and de-windowsification so the
code is actually readable and I can do
Ingo Molnar wrote:
* Jan Engelhardt [EMAIL PROTECTED] wrote:
i've attached it below in a standalone form, feel free to put it
into SD! :)
Assume X went crazy (lacking any statistics, I make the unproven
statement that this happens more often than kthreads going berserk),
then having it niced
Sunil Naidu wrote:
Hello,
I am facing a strange problems with an old 1.2 GHz P-III machine with
a 10 GB disk (used as a dedicated web server, later retired out of
service!).
Out of interest to implement some wireless solution (experiment), I
did compile 2.6.20.7 for my requirement. Strangely,
On Sun, Apr 22, 2007 at 10:18:32PM +1000, Con Kolivas wrote:
On Sunday 22 April 2007 21:42, Con Kolivas wrote:
Willy I'm still investigating the idle time and fluctuating load as a
separate
issue.
OK.
Is it possible the multiple ocbench processes are naturally
synchronising and
* Mark Lord [EMAIL PROTECTED] wrote:
i've not experienced a 'runaway X' personally, at most it would
crash or lock up ;) The value is boot-time and sysctl configurable
as well back to 0.
Mmmm.. I've had to kill off the odd X that was locking in 100% CPU
usage. In the past, this has
Ingo Molnar wrote:
well, i just simulated a runaway X at nice -19 on CFS (on a UP box), and
while the box was a tad laggy, i was able to killall it without
problems, within 2 seconds that also included a 'su'. So it's not an
issue in CFS, it can be turned off, and because every distro has
We were simply reinventing the wheel until now. Here's the final version of the
patch which is also the simplest solution (if you hold your eyes open at all
time, you'll see that KERNELVERSION is already exported by the main Makefile and
there's no need for changing the build string in
simple and fundamental (which you haven't answered as yet). Why, or
rather how, were the writers of newer APIs _allowed_ to push *their*
stuff into the kernel _without_ even bothering to convert the
*existing* users of the older APIs in the kernel? This goes against
Because to convert the
I've just released Linux 2.4.34.4, previous one did not build.
Thanks to Urs Thuermann for reporting the problem (and fix).
The patch and changelog will appear soon at the following locations:
ftp://ftp.kernel.org/pub/linux/kernel/v2.4/
obsolete and correctly re-labelled as such. As for the !HOTPLUG
menace you keep touting, that might perhaps be applied to some of
the individual hardware device drivers but certainly not to the
In my tree its just the drivers that still use pci_find_device.
Want to be on that. There is
On Fri, Apr 20, 2007 at 07:49:33PM +0200, Jean Delvare wrote:
The scx200_acb driver was heavily modified in 2.6.17 and 2.6.18, not
much since then. I am not familiar with the hardware so I can't comment
on which chips are supposed to work and which aren't.
Well 2.6.18's scx200_acb works on the
Hello.
Bartlomiej Zolnierkiewicz wrote:
[PATCH] ide: fix UDMA/MWDMA/SWDMA masks
* use 0x00 instead of 0x80 to disable -{ultra,mwdma,swdma}_mask
* add udma_mask field to ide_pci_device_t and use it to initialize
-ultra_mask in aec62xx, cmd64x, pdc202xx_{new,old} and piix drivers
* fix UDMA
On Monday 23 April 2007 00:27, Michael Gerdau wrote:
Anyway the more important part is... Can you test this patch please? Dump
all the other patches I sent you post 045. Michael, if you could test too
please?
Have it up running for 40 minutes now and my perljobs show a constant
cpu
+
+uid_t mnt_uid; /* owner of the mount */
Can we please make this a user struct. That requires a bit of
reference counting but it has uid namespace benefits as well
as making it easy to implement per user mount rlimits.
OK, can you ellaborate, what
On Fri, Apr 20, 2007 at 10:38:49AM +0100, Alan Cox wrote:
I'm looking for some testers for a revamp of the initio driver. No real
code changes other than to hopefully stop it exploding on load on 64bit,
but a major reorganisation, commenting and de-windowsification so the
code is actually
On Sun, Apr 22, 2007 at 03:33:58PM +0200, Urs Thuermann wrote:
Willy Tarreau [EMAIL PROTECTED] writes:
I've just released Linux 2.4.34.3.
Nothing critical, just a bunch of bugfixes and small security fix.
I get the following compile error:
[snip]
Grrr... I'm very sorry. Thanks for
Yet another significant bugfix for SMP balancing was just posted for the
staircase deadline cpu scheduler which improves behaviour dramatically on any
SMP machine.
Thanks to Willy Tarreau for noticing more bugs.
As requested was a version in the Makefile so this version of the patch
adds
I've just released Linux 2.4.35-pre4, previous one did not build.
Thanks to Urs Thermann for reporting the problem (and fix).
The patch and changelog will appear soon at the following locations:
ftp://ftp.kernel.org/pub/linux/kernel/v2.4/testing/
Miguel Ojeda [EMAIL PROTECTED] ha scritto:
On 4/22/07, oliver pinter [EMAIL PROTECTED] wrote:
I have CC the kernel
Did you?
and the result is:
your'e config : failed smp
your'e config + power managment : ok
Interesting, can anyone tell me why does not SMP work without Power
Once again a pci_get_device conversation isn't all that helpfull at all.
fortunately in this case I've done a patch to convert this driver to
proper pci probing in 2004, and I've attached the forward-ported version
below now that we've actually found some testers that weren't locatable
back
On 4/22/07, William Lee Irwin III [EMAIL PROTECTED] wrote:
On Sun, Apr 22, 2007 at 12:17:31AM -0700, Ulrich Drepper wrote:
For futex(), the extension is needed for the FUTEX_WAIT operation. We
need a new operation FUTEX_WAIT_FOR or so which takes another (the
fourth) parameter which is the
On Sunday 22 April 2007 11:10, Christoph Hellwig wrote:
So what about stopping the flaming here and implementing real statvfs/
fstatvfs syscalls instead of these horrible hacks glibc has to do
currently?
I could imagine two approaches to that: either add statvfs and fstatvfs
syscalls, or use
Hi Alan,
On 4/22/07, Alan Cox [EMAIL PROTECTED] wrote:
No risk of deadlock. It'll progress to BROKEN which will either cause
sufficient pain for someone to get off their arse and fix it, for enough
of a vendors users to get the vendor to do the work or for someone who
cares to pay a
Hello David,
Thanks for this patch you sent me. This patch will also increase the
clock resolution which is good in RT context.
But, unfortunately, I have some problems with compiling the kernel, as
this patch does not enable CONFIG_GENERIC_TIME, while the patch you
published earlier did.
Is
On Fri, 2007-04-13 at 20:08 +0200, Guennadi Liakhovetski wrote:
Either I've finally gone blind on this Friday 13th or... Looks like this
almost 3 year old function has a bug. Patch below compile-tested... in a
way.
No, it's a longstanding bug in the x86 implementation, thanks for
finding it.
Il Wed, Apr 18, 2007 at 01:50:29AM +0200, Luca Tettamanti ha scritto:
I'm sure you've seen these:
http://lists.lm-sensors.org/pipermail/lm-sensors/2005-October/014050.html
http://www.lm-sensors.org/wiki/AsusFormulaHacking
Actually I haven't, I've happily ignored ACPI until now ;-) My
On 4/22/07, Christoph Hellwig [EMAIL PROTECTED] wrote:
Why isn't MADV_FREE defined to 5 for linux? It's our first free madv
value? Also the behaviour should better match the one in solaris or BSD,
the last thing we need is slightly different behaviour from operating
systems supporting this for
On 4/22/07, Len Brown [EMAIL PROTECTED] wrote:
This is an AML run-time error from a PCI Interrupt Link
trying to find its Present Resource Settings --
ie. the current IRQ for a programmable IRQ.
Please open up a bug report here:
http://bugzilla.kernel.org/enter_bug.cgi?product=ACPI
For
This doesn't change much outside the initialization and irq code, so
any additional de-crappyfication will hopefully apply ontop.
This will actually clash horribly with the rest of the rework, so it does
need to be applied after the other changes. The driver in my tree no
longer looks much like
On Monday 23 April 2007 00:22, Willy Tarreau wrote:
On Sun, Apr 22, 2007 at 10:18:32PM +1000, Con Kolivas wrote:
On Sunday 22 April 2007 21:42, Con Kolivas wrote:
Willy I'm still investigating the idle time and fluctuating load as a
separate issue. Is it possible the multiple ocbench
On Sunday 22 April 2007 23:07, Willy Tarreau wrote:
On Sun, Apr 22, 2007 at 10:18:32PM +1000, Con Kolivas wrote:
On Sunday 22 April 2007 21:42, Con Kolivas wrote:
Willy I'm still investigating the idle time and fluctuating load as a
separate issue.
OK.
Is it possible the multiple
301 - 400 of 533 matches
Mail list logo
