Balbir Singh wrote:
Nick Piggin wrote:
And strangely, this example does not go outside the parameters of
what you asked for AFAIKS. In the worst case of one container getting
_all_ the shared pages, they will still remain inside their maximum
rss limit.
When that does happen and if a
On Tuesday 13 of March 2007, Adrian Bunk wrote:
> Subject: ThinkPad Z60m: usb mouse stops working after suspend to ram
> References : http://lkml.org/lkml/2007/2/21/413
> http://lkml.org/lkml/2007/2/28/172
> Submitter : Arkadiusz Miskiewicz <[EMAIL PROTECTED]>
> Caused-By :
On Tue, 2007-03-13 at 21:39 -0700, Jeremy Fitzhardinge wrote:
> Rusty Russell wrote:
> > This is called "pissing in the corners". Don't do it: we don't need to
> > touch that code and I actually prefer the original anyway (explicit is
> > *good*).
> >
> > The habit of extracting cpu number once
Daniel Walker wrote:
> The adjustments that I spoke of above are working regardless of ntp ..
> The stability of the TSC directly effects the clock mult adjustments in
> timekeeping, as does interrupt latency since the clock is essentially
> validated against the timer interrupt.
>
Yep. But
On Tue, 2007-03-13 at 21:55 +0100, Andi Kleen wrote:
> On Tue, Mar 13, 2007 at 10:31:27AM -0700, Jeremy Fitzhardinge wrote:
> > Andi Kleen wrote:
> > > On Tue, Mar 13, 2007 at 05:39:36PM +1100, Rusty Russell wrote:
> > >
> > >> GCC (4.1 at least) unrolls it anyway, but I can't believe this code
Nick Piggin wrote:
Eric W. Biederman wrote:
Nick Piggin <[EMAIL PROTECTED]> writes:
Eric W. Biederman wrote:
First touch page ownership does not guarantee give me anything useful
for knowing if I can run my application or not. Because of page
sharing my application might run inside the
On Tue, 2007-03-13 at 14:50 +0100, Andi Kleen wrote:
> On Tue, Mar 13, 2007 at 05:39:36PM +1100, Rusty Russell wrote:
> > GCC (4.1 at least) unrolls it anyway, but I can't believe this code
>
> Are you sure? Normally it doesn't unroll without -funroll-loops which
> the kernel does normally not
> On Wednesday 14 March 2007, William Lee Irwin III wrote:
> >On Tue, Mar 13, 2007 at 11:31:53PM -0400, Gene Heskett wrote:
> >> Now, can someone suggest a patch I can revert that might fix this?
> >> The total number of patches between 2.6.20 and 2.6.21-rc1 will have me
> >> building kernels to
On Wednesday 14 March 2007, William Lee Irwin III wrote:
>On Tue, Mar 13, 2007 at 11:31:53PM -0400, Gene Heskett wrote:
>> Now, can someone suggest a patch I can revert that might fix this?
>> The total number of patches between 2.6.20 and 2.6.21-rc1 will have me
>> building kernels to bisect
Hello,
Mathieu Bérard wrote:
> [ 15.031823] ata1.00: taskfile_load_raw: (0x1f1-1f7): hex: 10 03 00 00
> 00 a0 ef
Okay, this is interesting. This is Enable Device-Initiated Interface
Power State Transitions. So, after this command is executed the device
will try to transit to partial/slumber
On Wed, Mar 14, 2007 at 05:49:22AM +0530, Syed Ahemed wrote:
> Hello all.
> I have a tricky problem on hand and a straight forward question.
>
> Tricky problem:
> -
> While debugging a simple multithreaded application using gdb linux
> 2.4.28 , i noticed the thread that has
On Tue, Mar 13, 2007 at 11:31:53PM -0400, Gene Heskett wrote:
>> Now, can someone suggest a patch I can revert that might fix this? The
>> total number of patches between 2.6.20 and 2.6.21-rc1 will have me
>> building kernels to bisect this till the middle of June at this rate.
On Tue, Mar 13,
From: Bill Irwin <[EMAIL PROTECTED]>
Date: Tue, 13 Mar 2007 22:40:18 -0700
> I'm still trying to get on this.
See a response I just gave in this thread, I gave some tips that might
help track down what's going wrong here.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
On Tue, Mar 13, 2007 at 05:29:17PM -0700, Nish Aravamudan wrote:
> Ok, truly bizarre, I found that I was not running stock 2.6.20.3, but
> had your small hugetlb patch on top.
> So I went back and patched 2.6.20.1 with your patch, rebooted, got a
> soft lockup. Went back to stock 2.6.20.1 and did
This little code snippet seems to have a page_lock recursion, in
addition to overall looking particularly fragile to me. It seems to
be handling the case where a page needs to be brought uptodate because
a partial page write is being done. The page gets locked as many as 3
times, each checking
From: "Nish Aravamudan" <[EMAIL PROTECTED]>
Date: Tue, 13 Mar 2007 17:29:17 -0700
> Ok, truly bizarre, I found that I was not running stock 2.6.20.3, but
> had your small hugetlb patch on top.
>
> So I went back and patched 2.6.20.1 with your patch, rebooted, got a
> soft lockup. Went back to
> Yes It works with acpi=off (2.6.21-rc1):
> Please notice that IRQ is changed from 19 with ACPI to 11 without.
Please verify the problem still exists in the latest 2.6.21 git.
If yes, please file a bug here:
http://bugzilla.kernel.org/enter_bug.cgi?product=ACPI
For 2.6.20.stable, please
Merge the oprofile configs.
Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
Cc: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
Cc: Rusty Russell <[EMAIL PROTECTED]>
Cc: Chris Wright <[EMAIL PROTECTED]>
Cc: Andi Kleen <[EMAIL PROTECTED]>
Cc: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
diff --git
Create the Makefile in the common hold and adjust the i386 and
x86_64 code accordingly.
Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
Cc: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
Cc: Rusty Russell <[EMAIL PROTECTED]>
Cc: Chris Wright <[EMAIL PROTECTED]>
Cc: Andi Kleen <[EMAIL PROTECTED]>
Create the Makefile in the common hold and adjust the i386 and
x86_64 code accordingly.
Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
Cc: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
Cc: Rusty Russell <[EMAIL PROTECTED]>
Cc: Chris Wright <[EMAIL PROTECTED]>
Cc: Andi Kleen <[EMAIL
Remove the C file with just the include that points to the
i386 msr-on-cpu.c file.
Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
Cc: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
Cc: Rusty Russell <[EMAIL PROTECTED]>
Cc: Chris Wright <[EMAIL PROTECTED]>
Cc: Andi Kleen <[EMAIL PROTECTED]>
Cc:
Create the arch/x86/acpi/Makefile, and remove the associate stuff
from the i386 and x86_64.
Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
Cc: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
Cc: Rusty Russell <[EMAIL PROTECTED]>
Cc: Chris Wright <[EMAIL PROTECTED]>
Cc: Andi Kleen <[EMAIL
Move kernel/cpu/cpufreq/speedstep-lib.c to the common hold.
Also has the slight change to reference speedstep-lib.h that is being moved
to include/asm-i386.
Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
Cc: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
Cc: Rusty Russell <[EMAIL PROTECTED]>
Move kernel/cpu/cpufreq/p4-clockmod.c to the common hold.
Also has the slight change to reference speedstep-lib.h that is being moved
to include/asm-i386.
Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
Cc: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
Cc: Rusty Russell <[EMAIL PROTECTED]>
Cc:
Create the Makefile in the common hold and adjust the i386 and
x86_64 code accordingly.
Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
Cc: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
Cc: Rusty Russell <[EMAIL PROTECTED]>
Cc: Chris Wright <[EMAIL PROTECTED]>
Cc: Andi Kleen <[EMAIL PROTECTED]>
Here's a list of files that were moved from either i386 or x86_64 over
to the arch/x86 directory. Since I now used the git-diff -M option
(thanks Linus!), and to spare LKML with a lot of patches, I put all
the renames that were unmodified (strictly renamed) into this file,
with one exception. I
Create a toplevel Kconfig for arch/x86 and update the i386
and x86_64 Kconfigs as well.
Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
Cc: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
Cc: Rusty Russell <[EMAIL PROTECTED]>
Cc: Chris Wright <[EMAIL PROTECTED]>
Cc: Andi Kleen <[EMAIL PROTECTED]>
[Hopefully fixed email client to make it to the list this time]
[This series has changed by using git-diff -M]
Recently I've been doing some work that will affect both the i386 and x86_64
architectures. So there will be common code for both, as well as code
that will be unique for the specific
Remove the C file with just the include that points to the
x86_64 early_printk.c file.
Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
Cc: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
Cc: Rusty Russell <[EMAIL PROTECTED]>
Cc: Chris Wright <[EMAIL PROTECTED]>
Cc: Andi Kleen <[EMAIL PROTECTED]>
OK, this one is a little different.
Move arch/i386/kernel/cpu/cpufreq/speedstep-lib.h to include/asm-i386.h
This file is used by files in arch/i386/kernel/cpu/cpufreq that are not moved.
So we move it into a more global area, to keep the includes from going a bit
crazy.
Note, the moved files
Create the arch/x86/kernel/Makefile and change the i386 and x86_64
Makefiles accordingly.
Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
Cc: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
Cc: Rusty Russell <[EMAIL PROTECTED]>
Cc: Chris Wright <[EMAIL PROTECTED]>
Cc: Andi Kleen <[EMAIL
Remove the C file with just the include that points to the
x86_64 tsc_sync.c file.
Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
Cc: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
Cc: Rusty Russell <[EMAIL PROTECTED]>
Cc: Chris Wright <[EMAIL PROTECTED]>
Cc: Andi Kleen <[EMAIL PROTECTED]>
Cc:
Create the Makefile in the common hold and adjust the i386 and
x86_64 code accordingly.
Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
Cc: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
Cc: Rusty Russell <[EMAIL PROTECTED]>
Cc: Chris Wright <[EMAIL PROTECTED]>
Cc: Andi Kleen <[EMAIL
Create the Makefile in the common hold and adjust the i386 and
x86_64 code accordingly.
Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
Cc: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
Cc: Rusty Russell <[EMAIL PROTECTED]>
Cc: Chris Wright <[EMAIL PROTECTED]>
Cc: Andi Kleen <[EMAIL PROTECTED]>
Create the arch/x86/kernel/cpu/cpufreq/Makefile and update the
i386 and x86_64 accordingly.
Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
Cc: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
Cc: Rusty Russell <[EMAIL PROTECTED]>
Cc: Chris Wright <[EMAIL PROTECTED]>
Cc: Andi Kleen <[EMAIL
Create the arch/x86/Makefile and modify the i386 and x86_64
Makefiles accordingly.
Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
Cc: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
Cc: Rusty Russell <[EMAIL PROTECTED]>
Cc: Chris Wright <[EMAIL PROTECTED]>
Cc: Andi Kleen <[EMAIL PROTECTED]>
Cc:
On Tue, Mar 13, 2007 at 11:31:53PM -0400, Gene Heskett wrote:
> Now, can someone suggest a patch I can revert that might fix this? The
> total number of patches between 2.6.20 and 2.6.21-rc1 will have me
> building kernels to bisect this till the middle of June at this rate.
4 billion patches
Hi all,
With latest GIT tree I am getting the following oops when I try to suspend to
RAM:
BUG: unable to handle kernel NULL pointer dereference at virtual address
0094
printing eip:
c0222af4
*pde =
Oops: [#1]
PREEMPT
Modules linked in: i915 drm snd_pcm_oss snd_mixer_oss
Rusty Russell wrote:
> This is called "pissing in the corners". Don't do it: we don't need to
> touch that code and I actually prefer the original anyway (explicit is
> *good*).
>
> The habit of extracting cpu number once then using it is an optimization
> which we should be aiming to get rid
Dan Hecht wrote:
> With your previous definition of work time, would it be that:
>
> monotonic_time == work_time + stolen_time ??
(By monotonic time, I presume you mean monotonic real time.) Yes, I
suppose you could, but I don't think that's terribly useful. I think
work_time is probably most
FYI, I'm seeing the following oops with 2.6.21-rc3-mm1 (and -mm2)
on the HP rx2600 and an Intel Tiger (both ia64 boxes).
I haven't investigated this other than to determine that it
does not occur with 2.6.21-rc3 or 2.6.20-rc3-mm1, and the
instruction at move_freepages+0x10 is a load of the value
Eric W. Biederman wrote:
Nick Piggin <[EMAIL PROTECTED]> writes:
Eric W. Biederman wrote:
First touch page ownership does not guarantee give me anything useful
for knowing if I can run my application or not. Because of page
sharing my application might run inside the rss limit only because
On Tuesday 13 March 2007, Gene Heskett wrote:
>On Tuesday 13 March 2007, Gene Heskett wrote:
>>Greetings;
>>Someone suggested a fresh thread for this.
>>
>>I now have my scripts more or less under control, and I can report that
>>kernel-2.6.20.1 with no other patches does not exhibit the
[EMAIL PROTECTED] wrote:
On Mon, 12 Mar 2007 17:38:38 BST, Kasper Sandberg said:
with latest xorg, xlib will be using xcb internally,
Out of curiosity, when is this "latest" Xorg going to escape to distros,
Already is .. Xorg 7.2+ libx11 build with xcb enabled..
and is it far
> Yes, the code could be reworked by moving some of the data from the CPU
> hw-breakpoint info into the thread's info. I'll see how much simpler it
> ends up being.
I don't quite understand that characterization of the kind of change I'm
advocating. If the common case path in context switch has
On Thu, Mar 08, 2007 at 05:58:16PM -0500, Mimi Zohar wrote:
> This is a request for comments for a new Integrity Based Access
> Control(IBAC) LSM module which bases access control decisions
> on the new integrity framework services.
Thanks Mimi, nice to see an example of how the integrity
On Tue, 2007-03-13 at 10:15 -0700, Jeremy Fitzhardinge wrote:
> Rusty Russell wrote:
> > + pack_descriptor((u32 *)[GDT_ENTRY_PERCPU].a,
> > + (u32 *)[GDT_ENTRY_PERCPU].b,
> > + __per_cpu_offset[cpu], 0xF,
> > 0x80 | DESCTYPE_S | 0x2,
On Mon, 12 Mar 2007 17:38:38 BST, Kasper Sandberg said:
> with latest xorg, xlib will be using xcb internally,
Out of curiosity, when is this "latest" Xorg going to escape to distros,
and is it far enough along that beta testers can gather usable numbers?
pgpt7KqlXv9Rp.pgp
Description: PGP
On Tue, 2007-03-13 at 13:48 -0700, Jeremy Fitzhardinge wrote:
> Rusty Russell wrote:
> > Hi all,
> >
> > The GDT stuff on x86 is a little more complex than it need be, but
> > playing with boot code is always dangerous. These compile and boot on
> > UP and SMP for me, but Andrew should let
From: Samuel Ortiz <[EMAIL PROTECTED]>
Date: Wed, 14 Mar 2007 02:50:03 +0200
> On Mon, Mar 12, 2007 at 04:49:21PM -0700, David Miller wrote:
> > I would strongly caution against adding any run-time overhead just to
> > cure a false lockdep warning. Even adding a new function argument
> > is too
On Tue, 2007-03-13 at 16:57 +0100, Andi Kleen wrote:
> On Tue, Mar 13, 2007 at 05:23:52PM +1100, Rusty Russell wrote:
> > In particular, it's been put in GCC 4.1 for
> > CONFIG_CC_STACKPROTECTOR, which assumes %gs:40 will give the stack
> > canary.
>
> Yes that was always ugly, but I don't know a
On Tue, 2007-03-13 at 14:59 -0700, Jeremy Fitzhardinge wrote:
> Daniel Walker wrote:
> > The frequency tracking you mention is done to some extent inside the
> > timekeeping adjustment functions, but I'm not sure it's totally accurate
> > for non-timekeeping, and it also tracks things like
Pavel Machek wrote:
> Hi1
>
>> I've chased one of the 'Suspend to RAM' resume problems to a specific
>> line in drivers/char/vt.c, see attached 2.6.21-rc3 diff with
>
> Has suspend/resume ever worked on that hardware?
>
>> TRACE_RESUME() instrumentation. The macro scr_writew resolves to '*addr
many changes since 2.6.20.3-rc1?
On 3/14/07, Greg KH <[EMAIL PROTECTED]> wrote:
We (the -stable team) are announcing the release of the 2.6.20.3 kernel.
It contains a number of bugfixes and all 2.6.20 users are recommended to
upgrade.
The diffstat and short summary of the fixes are below.
-
On Tue, 13 Mar 2007, Roland McGrath wrote:
>
> Ok, fine. But PATH_MAX is a real constant that has some meaning in the
> kernel. It's perfectly correct to use PATH_MAX as a constant on a system
> like Linux that defines it and means what it says. Conversely, OPEN_MAX
> has no useful
On Tue, Mar 13, 2007 at 04:47:56AM -0800, Andrew Morton wrote:
> I'm trying to remember why we ever would have needed to zero out the
> pagetable pages if we're taking down the whole mm? Maybe it's
> because "oh, the arch wants to put this page into a quicklist to
> recycle it", which is all
On Tue, 2007-03-13 at 08:31 -0700, Jeremy Fitzhardinge wrote:
> Paul Mackerras wrote:
> > There is a fundamental problem with using __thread, which is that gcc
> > assumes that the addresses of __thread variables are constant within
> > one thread, and that therefore it can cache the result of
On 3/13/07, Eric Dumazet <[EMAIL PROTECTED]> wrote:
Nish Aravamudan a écrit :
> On 3/12/07, Anton Blanchard <[EMAIL PROTECTED]> wrote:
>>
>> Hi Nick,
>>
>> > Anyway, I'll keep experimenting. If anyone from MySQL wants to help
>> look
>> > at this, send me a mail (eg. especially with the
On Tue, 2007-03-13 at 14:45 -0700, Chris Wright wrote:
> what about asm-x86/ dir? the asm/ symlink would still point to relevant
> arch, but the file there could be simply #include ?
Would it be acceptable to have an include/asm-x86/ dir with one file?
Of course it will open the door to merge
On Tue, 2007-03-13 at 14:39 -0700, Linus Torvalds wrote:
>
> On Tue, 13 Mar 2007, Steven Rostedt wrote:
> >
> > What we have currently is a bunch of hacks. Seems that people can't make
> > up their mind to what to do.
>
> I don't mind the patches, but I'd be a lot happier if it also was a
Nish Aravamudan a écrit :
On 3/12/07, Anton Blanchard <[EMAIL PROTECTED]> wrote:
Hi Nick,
> Anyway, I'll keep experimenting. If anyone from MySQL wants to help
look
> at this, send me a mail (eg. especially with the sched_setscheduler
issue,
> you might be able to do something better).
I
> I'd actually prefer this as part of the "remove OPEN_MAX" patch.
Ok. (But now you're going to argue with me about "remove OPEN_MAX",
and you haven't said you have any problem with changing SCM_MAX_FD,
so why make it wait?)
> That said, it actually worries me that you should call
On Tue, 2007-03-13 at 14:32 -0700, Linus Torvalds wrote:
>
> On Tue, 13 Mar 2007, Steven Rostedt wrote:
> >
> > Move kernel/acpi/processor.c to the common hold.
>
> Please use
>
> git diff -M
OK, thanks! I'm still quite a git-nubie.
I'll update all the move patches. It may take a bit
On Mon, Mar 12, 2007 at 04:49:21PM -0700, David Miller wrote:
> I would strongly caution against adding any run-time overhead just to
> cure a false lockdep warning. Even adding a new function argument
> is too much IMHO.
>
> Make the cost show up for lockdep only, perhaps by putting each
>
On 03/13/2007 02:59 PM, Jeremy Fitzhardinge wrote:
Daniel Walker wrote:
The frequency tracking you mention is done to some extent inside the
timekeeping adjustment functions, but I'm not sure it's totally accurate
for non-timekeeping, and it also tracks things like interrupt latency.
Tracking
On Mon, Mar 12, 2007 at 03:51:57PM -0700, David Miller wrote:
> Someone with some extreme patience could do the sparc 32-bit port too,
> in fact it's lacking the cached PGD update logic that x86 et al. have
> so it would even end up being a bug fix :-) This lack is why sparc32
> pre-initializes
On 3/12/07, Anton Blanchard <[EMAIL PROTECTED]> wrote:
Hi Nick,
> Anyway, I'll keep experimenting. If anyone from MySQL wants to help look
> at this, send me a mail (eg. especially with the sched_setscheduler issue,
> you might be able to do something better).
I took a look at this today and
On 3/13/07, Nish Aravamudan <[EMAIL PROTECTED]> wrote:
On 3/13/07, David Miller <[EMAIL PROTECTED]> wrote:
> From: "Nish Aravamudan" <[EMAIL PROTECTED]>
> Date: Tue, 13 Mar 2007 14:58:24 -0700
>
> > On 3/13/07, Nish Aravamudan <[EMAIL PROTECTED]> wrote:
> > > On 3/13/07, Greg KH <[EMAIL
Hello all.
I have a tricky problem on hand and a straight forward question.
Tricky problem:
-
While debugging a simple multithreaded application using gdb linux
2.4.28 , i noticed the thread that has crashed after sigsegv has
complete information on the gdb (both address
In case anyone cares, this is a snippet of my work-in-progress
read_write.c illustrating how I might handle f_pos. Can anyone point
me to data showing whether it's worth avoiding the spinlock when the
"struct file" is not shared between threads? (In my world,
correctness comes before
Andrew Morton writes:
> Plus, we can get in a situation where take a cache-cold, known-zero page
> from the pte quicklist when there is a cache-hot, non-zero page sitting in
> the page allocator. I suspect that zeroing the cache-hot page would take a
> similar amount of time to a single miss
On Tue, Mar 13, 2007 at 11:28:20PM +0530, Srivatsa Vaddagiri wrote:
> On Tue, Mar 13, 2007 at 05:24:59PM +0100, Herbert Poetzl wrote:
> > what about identifying different resource categories and
> > handling them according to the typical usage pattern?
> >
> > like the following:
> >
> > - cpu
Jeremy Fitzhardinge writes:
> Or do you mean that if you have:
>
> preempt_disable();
> use_my_percpu++;
> preempt_enable();
> // switch cpus
> preempt_disable();
> use_my_percpu++;
> preempt_enable();
>
> then it will still use the old pointer to
On Tue, Mar 06, 2007 at 10:46:56AM -0600, Eric Sandeen wrote:
> Ulrich Drepper wrote:
> > Christoph Hellwig wrote:
> >> fallocate with the whence argument and flags is already quite complicated,
> >> I'd rather have another call for placement decisions, that would
> >> be called on an fd to do
> a previous discussion that said 4 was the default...I don't see
> why. nice uses +10 by default on all linux distro...So I suspect
> that if Mike just used "nice lame" instead of "nice +5 lame", he
> would have got what he wanted.
tcsh, and probably csh, has a builtin 'nice' with default +4.
On 3/13/07, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
Michael, please stop spreading this utter bullshit _now_. You're so
full of half-knowledge that it's not funny anymore, and you try
to insult people knowing a few magniutes more than you left and right.
Thank you Christoph for that
This patch adds all the "tm_new" laptops information that is in acerhk
to wistron_btns. That's about 25 more laptops. Obviously, I couldn't try
them all. I've just tried the Aspire 3020. For this reason, I've also
added a printk which ask the users of those laptops to confirm me it
works (or
On Wednesday 14 March 2007 07:58, Con Kolivas wrote:
> On Wednesday 14 March 2007 03:03, Con Kolivas wrote:
> > On Wednesday 14 March 2007 02:31, Con Kolivas wrote:
> > > On Monday 12 March 2007 22:26, Al Boldi wrote:
> > > > I think, it should be possible to spread this max expiration latency
> >
On Tue, Mar 13, 2007 at 06:49:50PM +, Paulo Marques wrote:
> Alexey Dobriyan wrote:
> >[...]
> >What happens is that module_get_kallsym() drops module_mutex,
> >returns "struct module *", module unloaded, "struct module *"
> >used.
>
> The only use for the "struct module *" is to display the
This patch adds a generic map. That is, a keymap that should output the
correct keycodes for most laptops. This is simply based on the
observation of all those keymaps already gathered, as most of the
wistron codes are always mapped to the same keycode.
Hopefully, this way users which have a
Hello,
As a sequel to my patch "Wistron button support for TravelMate 610" of
last week, here is a bigger addition of keymaps for the wistron_btns.
Patch 1 adds all the database of acerhk which fits this driver (about 25
more laptops).
Patch 2 adds a generic map that should fit most users
On 3/13/07, David Miller <[EMAIL PROTECTED]> wrote:
From: "Nish Aravamudan" <[EMAIL PROTECTED]>
Date: Tue, 13 Mar 2007 14:58:24 -0700
> On 3/13/07, Nish Aravamudan <[EMAIL PROTECTED]> wrote:
> > On 3/13/07, Greg KH <[EMAIL PROTECTED]> wrote:
> > > We (the -stable team) are announcing the
On Tue, Mar 13, 2007 at 10:38:43PM +0100, Rodolfo Giometti wrote:
> here my new patch for PPS support in Linux.
>
> I tried to follow your suggestions as much possible! Please let me
> know if this new version could be more acceptable.
I have tried out 3.0.0-rc2 which seems to work pretty well
Hi,
On Tue, Mar 13, 2007 at 04:56:24PM +0100, Tomáš Janoušek wrote:
> On Tue, Mar 13, 2007 at 04:51:39PM +0100, [EMAIL PROTECTED] wrote:
> > Can you please try to compile without nohz and without hrtimers and try it
> > again?
>
> A colleage told me to try this yesterday and if I remember
On Wed, 14 Mar 2007, Alexey Dobriyan wrote:
> On Mon, Mar 12, 2007 at 12:59:20PM -0400, Robert P. J. Day wrote:
> > to my surprise, i learned only today that module.h includes
> > moduleparam.h, which flies in the face of all of the documentation
> > i've ever read which was adamant that i
The jsm driver doesn't currently use the uart_handle_*_change helper
functions, which are the obvious place for things like linuxpps to tie
into (which it now does of course), and as a result the jsm driver can
not be used with linuxpps and anything else that ties into the
serial_core helper
The jsm driver fails when you try to use the TIOCSSERIAL ioctl. The
reason is that the driver never sets uart_port.uartclk, causing the data
received using TIOCGSERIAL to not match the internal state of the driver.
This patch fixes this problem by settings the uartclk to the value used
by the
> "Jeremy" == Jeremy Fitzhardinge <[EMAIL PROTECTED]> writes:
Jeremy> And do the same in pte pages for actual mapped pages? Or do
Jeremy> you think they would be too densely populated for it to be
Jeremy> worthwhile?
We've been doing some measurements on how densely clumped ptes are.
On
From: "Nish Aravamudan" <[EMAIL PROTECTED]>
Date: Tue, 13 Mar 2007 14:58:24 -0700
> On 3/13/07, Nish Aravamudan <[EMAIL PROTECTED]> wrote:
> > On 3/13/07, Greg KH <[EMAIL PROTECTED]> wrote:
> > > We (the -stable team) are announcing the release of the 2.6.20.3 kernel.
> > > It contains a number
Why did you remove all Cced people? Anyway I filtered some of them out
johann deneux napsal(a):
You are right, the direction in ff_effect is meant to be an angle.
A dirty solution would be to use the 16 bits as two 8-bits angles. Or
That would be a problem as I need 3x 16bits.
maybe we
This is an experimental to the iproute2 command set.
The version number includes the kernel version to denote what features are
supported. The same source should build on older systems, but obviously the
newer kernel features won't be available. As much as possible, this package
tries to be
On Tue, Mar 13, 2007 at 09:21:59AM +0100, Miklos Szeredi wrote:
> > > read request
> > > sys_write
> > > mutex_lock(i_mutex)
> > > ...
> > > balance_dirty_pages
> > > submit write requests
> > > loop ... write requests completed ... dirty still over limit ...
> > > ...
Con Kolivas wrote:
On Wednesday 14 March 2007 05:21, Mark Lord wrote:
Con Kolivas wrote:
Can you try the new version of RSDL. Assuming it doesn't oops on you it
has some accounting bugfixes which may have been biting you.
Retesting today with 2.6.21-rc3-git7 +
On Mon, Mar 12, 2007 at 12:59:20PM -0400, Robert P. J. Day wrote:
> to my surprise, i learned only today that module.h includes
> moduleparam.h, which flies in the face of all of the documentation
> i've ever read which was adamant that i *had* to include moduleparam.h
> if i was using
Daniel Walker wrote:
> The frequency tracking you mention is done to some extent inside the
> timekeeping adjustment functions, but I'm not sure it's totally accurate
> for non-timekeeping, and it also tracks things like interrupt latency.
> Tracking frequency changes where it's important to get
On 3/13/07, Greg KH <[EMAIL PROTECTED]> wrote:
We (the -stable team) are announcing the release of the 2.6.20.3 kernel.
It contains a number of bugfixes and all 2.6.20 users are recommended to
upgrade.
The diffstat and short summary of the fixes are below.
I'll also be replying to this message
On 3/13/07, Nish Aravamudan <[EMAIL PROTECTED]> wrote:
On 3/13/07, Greg KH <[EMAIL PROTECTED]> wrote:
> We (the -stable team) are announcing the release of the 2.6.20.3 kernel.
> It contains a number of bugfixes and all 2.6.20 users are recommended to
> upgrade.
>
> The diffstat and short
* Steven Rostedt ([EMAIL PROTECTED]) wrote:
> Recently I've been doing some work that will affect both the i386 and x86_64
> architectures. So there will be common code for both, as well as code
> that will be unique for the specific arch. So I was looking into a way
> to do this cleanly, and
From: Matt Mackall <[EMAIL PROTECTED]>
Date: Tue, 13 Mar 2007 16:14:35 -0500
> Well you -could- do this:
>
> - reuse a long in struct page as a used map that divides the page up
> into 32 or 64 segments
> - every time you set a PTE, set the corresponding bit in the mask
> - when we zap, only
On Tue, 13 Mar 2007, Steven Rostedt wrote:
>
> What we have currently is a bunch of hacks. Seems that people can't make
> up their mind to what to do.
I don't mind the patches, but I'd be a lot happier if it also was a stated
intention to actually make it be buildable as "x86", the same way
1 - 100 of 802 matches
Mail list logo
