At Wed, 15 Nov 2006 14:15:45 -0500,
Jeff Garzik wrote:
>
> ACK the pci_intx() calls, NAK the obviously overweight spinlock changes.
> The spinlock changes are completely unnecessary. Just look at any
> other (non-ALSA) PCI driver. Existing "spin_lock()" is fine for both
> PCI shared irq
On Thursday 16 November 2006 11:21, Ingo Molnar wrote:
> Subject: [patch] x86_64: UP build fix, arch/x86_64/kernel/mce_amd.c
> From: Ingo Molnar <[EMAIL PROTECTED]>
>
> fix x86_64/kernel/mce_amd.c build bug:
>
> arch/x86_64/kernel/mce_amd.c: In function ‘threshold_remove_bank’:
>
[ Adding e-mail of Andrew Morton, he may have clue about who to ping ;]
[ MAINTAINERS.smbfs seems to be emply ]
On 2006-11-14, Rasmus BЬg Hansen wrote:
[]
> [1.] One line summary of the problem:
>
> Kernel BUG's and freezes after a soft lockup.
>
> [2.] Full
Subject: [patch] x86_64: UP build fix, arch/x86_64/kernel/mce_amd.c
From: Ingo Molnar <[EMAIL PROTECTED]>
fix x86_64/kernel/mce_amd.c build bug:
arch/x86_64/kernel/mce_amd.c: In function ‘threshold_remove_bank’:
arch/x86_64/kernel/mce_amd.c:597: error: ‘shared_bank’ undeclared (first use
in
From: Holger Schurig <[EMAIL PROTECTED]>
Generic calibration support for usbtouchscreen.
Signed-off-by: Holger Schurig <[EMAIL PROTECTED]>
---
With build-in calibration support, the "swap_xy" kernel parameter
vanishes and usbtouchscreen instead gains a new kernel-parameter
which holds 7
On 11/15/06, Phillip Susi <[EMAIL PROTECTED]> wrote:
No, you can not tamper with the underlying data while the kernel has it
mounted.
I don't want to tamper wuith data. I want to raw write back exacty
same raw data that I read in. I only want to make sure that kernel
doesn't write modified data
Subject: [patch] lockdep: show held locks when showing a stackdump
From: Ingo Molnar <[EMAIL PROTECTED]>
lockdep can be used to print held locks when printing a
backtrace. This can be useful when debugging things like
'scheduling while atomic' asserts.
Signed-off-by: Ingo Molnar <[EMAIL
On Thursday 16 November 2006 10:48, Ingo Molnar wrote:
>
> * Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> > On Thursday 16 November 2006 10:17, Andrew Morton wrote:
> > > On Thu, 16 Nov 2006 10:01:01 +0100
> > > Andi Kleen <[EMAIL PROTECTED]> wrote:
> > >
> > > > +#ifdef CONFIG_HOTPLUG_CPU
> > > >
Just in case you want to experiment, i have a working port of ar5k
that works on madwifi-old before the BSD - HEAD merge...
well i'm no good programmer (yet), i did what i could (i'm sure those
define macros are nasty for most people :P) and hope that helps...
you can git clone from the
(forgot to cc: LKML)
Roland Dreier wrote:
> > A whitelist is an awkward solution, the problem is the number of
> > chipsets available with MSI will continue to grow. And the assumption
> > is that after Microsoft OS supports MSI, that newer chipsets will work.
>
> Maybe a whitelist for older
> To further assist anyone wishing to hack on sata_promise.c, I just
> uploaded the long-since-GPL'd vendor drivers for Generation-I and
> Generation-II chipsets to
> http://gkernel.sourceforge.net/specs/promise/
>
> This should help with isolating the proper initialization
> sequence for a
On Thu, 16 Nov 2006 12:37:17 +0300
Alex Tomas <[EMAIL PROTECTED]> wrote:
> > Andrew Morton (AM) writes:
>
> AM> What lock protects the fields in struct ext[234]_reserve_window from
> being
> AM> concurrently modified by two CPUs? None, it seems. Ditto
> AM>
On Thu, 16 Nov 2006 01:48:09 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Thu, 16 Nov 2006 12:37:17 +0300
> Alex Tomas <[EMAIL PROTECTED]> wrote:
>
> > > Andrew Morton (AM) writes:
> >
> > AM> What lock protects the fields in struct ext[234]_reserve_window from
> > being
> > AM>
* Andi Kleen <[EMAIL PROTECTED]> wrote:
> On Thursday 16 November 2006 10:17, Andrew Morton wrote:
> > On Thu, 16 Nov 2006 10:01:01 +0100
> > Andi Kleen <[EMAIL PROTECTED]> wrote:
> >
> > > +#ifdef CONFIG_HOTPLUG_CPU
> > > hotcpu_notifier(cpu_vsyscall_notifier, 0);
> > > +#endif
> >
> > this
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > on_each_cpu() does this and one caller (at least) relies upon it
> > (invalidate_bh_lrus(), iirc).
>
> ok, fair enough. Then this is a (minor) bugfix as well.
ok, this doesnt build on some configs - so the replacement patch below
moves the UP
> Andrew Morton (AM) writes:
AM> What lock protects the fields in struct ext[234]_reserve_window from being
AM> concurrently modified by two CPUs? None, it seems. Ditto
AM> ext[234]_reserve_window_node. i_mutex will cover it for write(), but not
AM> for pageout over a file hole. If we
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > x86_64 does not build cleanly on UP:
>
> updated patch below - i left out the cpu.h bits because they caused
> problems elsewhere.
the cpu-hotplug related warning is solved by the cleanup below.
Identity patch, does not change the code.
* Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Thu, 16 Nov 2006 09:48:55 +0100
> Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> > +static inline int
> > +smp_call_function_single(int cpuid, void (*func) (void *info), void *info,
> > +int retry, int wait)
> > +{
> > +
On Tue, Nov 14, 2006 at 03:19:20PM -0800, Auke Kok wrote:
[]
> try to use `git2.kernel.org` instead of `git.kernel.org`. The second server
> somehow only has an average load of ~4 instead of ~250.
Looking closer, i see all gitweb links (C) on both servers links are poining
to
On Thu, 16 Nov 2006 00:49:20 -0800
Mingming Cao <[EMAIL PROTECTED]> wrote:
> On Wed, 2006-11-15 at 23:22 -0800, Andrew Morton wrote:
> > On Wed, 15 Nov 2006 22:55:43 -0800
> > Mingming Cao <[EMAIL PROTECTED]> wrote:
> >
> > > Hmm, maxblocks, in bitmap_search_next_usable_block(), is the end
On Thursday 16 November 2006 10:17, Andrew Morton wrote:
> On Thu, 16 Nov 2006 10:01:01 +0100
> Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> > +#ifdef CONFIG_HOTPLUG_CPU
> > hotcpu_notifier(cpu_vsyscall_notifier, 0);
> > +#endif
>
> this part isn't needed - the definition handles that.
Thanks.
On Thu, 16 Nov 2006 10:01:01 +0100
Andi Kleen <[EMAIL PROTECTED]> wrote:
> +#ifdef CONFIG_HOTPLUG_CPU
> hotcpu_notifier(cpu_vsyscall_notifier, 0);
> +#endif
this part isn't needed - the definition handles that.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
On Tue, 2006-11-14 at 11:31 -0800, Andrew Morton wrote:
> On Tue, 14 Nov 2006 19:11:22 + (GMT)
> Hugh Dickins <[EMAIL PROTECTED]> wrote:
>
> > On Tue, 14 Nov 2006, Mel Gorman wrote:
> > > 2.6.19-rc5-mm2
> > >
> > > Am seeing errors with systems using ext2. First machine is a plan old x86
> >
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> x86_64 does not build cleanly on UP:
updated patch below - i left out the cpu.h bits because they caused
problems elsewhere.
Ingo
--->
Subject: x86_64: build fixes
From: Ingo Molnar <[EMAIL PROTECTED]>
x86_64 does not build
On Thursday 16 November 2006 09:48, Ingo Molnar wrote:
> arch/x86_64/kernel/vsyscall.c: In function 'cpu_vsyscall_notifier':
> arch/x86_64/kernel/vsyscall.c:282: warning: implicit declaration of function
> 'smp_call_function_single'
> arch/x86_64/kernel/vsyscall.c: At top level:
>
On Thu, 16 Nov 2006 09:48:55 +0100
Ingo Molnar <[EMAIL PROTECTED]> wrote:
> +static inline int
> +smp_call_function_single(int cpuid, void (*func) (void *info), void *info,
> + int retry, int wait)
> +{
> + func(info);
> +
> + return 0;
> +}
> +
Given that on SMP the
Subject: x86_64: UP build fixes
From: Ingo Molnar <[EMAIL PROTECTED]>
x86_64 does not build cleanly on UP:
arch/x86_64/kernel/vsyscall.c: In function 'cpu_vsyscall_notifier':
arch/x86_64/kernel/vsyscall.c:282: warning: implicit declaration of function
'smp_call_function_single'
On Wed, 2006-11-15 at 23:22 -0800, Andrew Morton wrote:
> On Wed, 15 Nov 2006 22:55:43 -0800
> Mingming Cao <[EMAIL PROTECTED]> wrote:
>
> > Hmm, maxblocks, in bitmap_search_next_usable_block(), is the end block
> > number of the range to search, not the lengh of the range. maxblocks
> > get
Tejun Heo wrote:
> Vasily Averin wrote:
>> Alan Cox wrote:
>>> Ar Gwe, 2006-10-27 am 17:17 +0400, ysgrifennodd Vasily Averin:
Could somebody please help me to troubleshoot this issue? I've seen this
issue
on the customer nodes and would like to know how I can work-around this
On 11/15/06, James Simmons <[EMAIL PROTECTED]> wrote:
> Well, we were aware of video/backlight/* (read below). Anyway,
> auxdisplay doesn't create a class; it did in first versions, but right
> now it behaves just like a framebuffer, no classes in the playground
> (maybe you read a old
Hi,
The following two patches introduce a mechanism that should allow us to
avoid suspend-related corruptions of XFS without the freezing of bdevs which
Pavel considers as too invasive (apart from this, the freezing of bdevs may
lead to some undesirable interactions with dm and for now it seems
Make it possible to create a workqueue the worker thread of which will be
frozen during suspend, along with other kernel threads.
Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
---
include/linux/workqueue.h |8 +---
kernel/workqueue.c| 20 ++--
2 files
Make the workqueues used by XFS freezeable, so their worker threads don't
submit any I/O after the suspend image has been created.
Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
---
fs/xfs/linux-2.6/xfs_buf.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index:
From: Holger Schurig <[EMAIL PROTECTED]>
Basic support support for the USB-based DMC TSC-10 touchscreen
controller.
Signed-off-by: Holger Schrig <[EMAIL PROTECTED]>
---
The previous patch was word-wrapped, sorry.
Please review this patch and schedule it for inclusion once
2.6.19 comes out.
From: Holger Schurig <[EMAIL PROTECTED]>
Basic support support for the USB-based DMC TSC-10 touchscreen
controller.
Signed-off-by: Holger Schrig <[EMAIL PROTECTED]>
---
Please review this patch and schedule it for inclusion once
2.6.19 comes out.
The DMC TSC-10 comes in various
Make the workqueues used by XFS freezeable, so their worker threads don't
submit any I/O after the suspend image has been created.
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
---
fs/xfs/linux-2.6/xfs_buf.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index:
Make it possible to create a workqueue the worker thread of which will be
frozen during suspend, along with other kernel threads.
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
---
include/linux/workqueue.h |8 +---
kernel/workqueue.c| 20 ++--
2 files
Hi,
The following two patches introduce a mechanism that should allow us to
avoid suspend-related corruptions of XFS without the freezing of bdevs which
Pavel considers as too invasive (apart from this, the freezing of bdevs may
lead to some undesirable interactions with dm and for now it seems
On 11/15/06, James Simmons [EMAIL PROTECTED] wrote:
Well, we were aware of video/backlight/* (read below). Anyway,
auxdisplay doesn't create a class; it did in first versions, but right
now it behaves just like a framebuffer, no classes in the playground
(maybe you read a old version?).
...
Subject: x86_64: UP build fixes
From: Ingo Molnar [EMAIL PROTECTED]
x86_64 does not build cleanly on UP:
arch/x86_64/kernel/vsyscall.c: In function 'cpu_vsyscall_notifier':
arch/x86_64/kernel/vsyscall.c:282: warning: implicit declaration of function
'smp_call_function_single'
On Thu, 16 Nov 2006 09:48:55 +0100
Ingo Molnar [EMAIL PROTECTED] wrote:
+static inline int
+smp_call_function_single(int cpuid, void (*func) (void *info), void *info,
+ int retry, int wait)
+{
+ func(info);
+
+ return 0;
+}
+
Given that on SMP the function
On Thursday 16 November 2006 09:48, Ingo Molnar wrote:
arch/x86_64/kernel/vsyscall.c: In function 'cpu_vsyscall_notifier':
arch/x86_64/kernel/vsyscall.c:282: warning: implicit declaration of function
'smp_call_function_single'
arch/x86_64/kernel/vsyscall.c: At top level:
On Tue, 2006-11-14 at 11:31 -0800, Andrew Morton wrote:
On Tue, 14 Nov 2006 19:11:22 + (GMT)
Hugh Dickins [EMAIL PROTECTED] wrote:
On Tue, 14 Nov 2006, Mel Gorman wrote:
2.6.19-rc5-mm2
Am seeing errors with systems using ext2. First machine is a plan old x86
using initramfs.
* Ingo Molnar [EMAIL PROTECTED] wrote:
x86_64 does not build cleanly on UP:
updated patch below - i left out the cpu.h bits because they caused
problems elsewhere.
Ingo
---
Subject: x86_64: build fixes
From: Ingo Molnar [EMAIL PROTECTED]
x86_64 does not build cleanly on
On Thu, 16 Nov 2006 10:01:01 +0100
Andi Kleen [EMAIL PROTECTED] wrote:
+#ifdef CONFIG_HOTPLUG_CPU
hotcpu_notifier(cpu_vsyscall_notifier, 0);
+#endif
this part isn't needed - the definition handles that.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
On Thursday 16 November 2006 10:17, Andrew Morton wrote:
On Thu, 16 Nov 2006 10:01:01 +0100
Andi Kleen [EMAIL PROTECTED] wrote:
+#ifdef CONFIG_HOTPLUG_CPU
hotcpu_notifier(cpu_vsyscall_notifier, 0);
+#endif
this part isn't needed - the definition handles that.
Thanks. Updated
* Andrew Morton [EMAIL PROTECTED] wrote:
On Thu, 16 Nov 2006 09:48:55 +0100
Ingo Molnar [EMAIL PROTECTED] wrote:
+static inline int
+smp_call_function_single(int cpuid, void (*func) (void *info), void *info,
+int retry, int wait)
+{
+ func(info);
+
+
On Tue, Nov 14, 2006 at 03:19:20PM -0800, Auke Kok wrote:
[]
try to use `git2.kernel.org` instead of `git.kernel.org`. The second server
somehow only has an average load of ~4 instead of ~250.
Looking closer, i see all gitweb links (C) on both servers links are poining
to
* Ingo Molnar [EMAIL PROTECTED] wrote:
x86_64 does not build cleanly on UP:
updated patch below - i left out the cpu.h bits because they caused
problems elsewhere.
the cpu-hotplug related warning is solved by the cleanup below.
Identity patch, does not change the code.
Ingo
* Ingo Molnar [EMAIL PROTECTED] wrote:
on_each_cpu() does this and one caller (at least) relies upon it
(invalidate_bh_lrus(), iirc).
ok, fair enough. Then this is a (minor) bugfix as well.
ok, this doesnt build on some configs - so the replacement patch below
moves the UP variant to a
* Andi Kleen [EMAIL PROTECTED] wrote:
On Thursday 16 November 2006 10:17, Andrew Morton wrote:
On Thu, 16 Nov 2006 10:01:01 +0100
Andi Kleen [EMAIL PROTECTED] wrote:
+#ifdef CONFIG_HOTPLUG_CPU
hotcpu_notifier(cpu_vsyscall_notifier, 0);
+#endif
this part isn't needed - the
(forgot to cc: LKML)
Roland Dreier wrote:
A whitelist is an awkward solution, the problem is the number of
chipsets available with MSI will continue to grow. And the assumption
is that after Microsoft OS supports MSI, that newer chipsets will work.
Maybe a whitelist for older systems
On Thursday 16 November 2006 10:48, Ingo Molnar wrote:
* Andi Kleen [EMAIL PROTECTED] wrote:
On Thursday 16 November 2006 10:17, Andrew Morton wrote:
On Thu, 16 Nov 2006 10:01:01 +0100
Andi Kleen [EMAIL PROTECTED] wrote:
+#ifdef CONFIG_HOTPLUG_CPU
Subject: [patch] lockdep: show held locks when showing a stackdump
From: Ingo Molnar [EMAIL PROTECTED]
lockdep can be used to print held locks when printing a
backtrace. This can be useful when debugging things like
'scheduling while atomic' asserts.
Signed-off-by: Ingo Molnar [EMAIL PROTECTED]
On 11/15/06, Phillip Susi [EMAIL PROTECTED] wrote:
No, you can not tamper with the underlying data while the kernel has it
mounted.
I don't want to tamper wuith data. I want to raw write back exacty
same raw data that I read in. I only want to make sure that kernel
doesn't write modified data
Subject: [patch] x86_64: UP build fix, arch/x86_64/kernel/mce_amd.c
From: Ingo Molnar [EMAIL PROTECTED]
fix x86_64/kernel/mce_amd.c build bug:
arch/x86_64/kernel/mce_amd.c: In function ‘threshold_remove_bank’:
arch/x86_64/kernel/mce_amd.c:597: error: ‘shared_bank’ undeclared (first use
in
On Thursday 16 November 2006 11:21, Ingo Molnar wrote:
Subject: [patch] x86_64: UP build fix, arch/x86_64/kernel/mce_amd.c
From: Ingo Molnar [EMAIL PROTECTED]
fix x86_64/kernel/mce_amd.c build bug:
arch/x86_64/kernel/mce_amd.c: In function ‘threshold_remove_bank’:
At Wed, 15 Nov 2006 14:15:45 -0500,
Jeff Garzik wrote:
ACK the pci_intx() calls, NAK the obviously overweight spinlock changes.
The spinlock changes are completely unnecessary. Just look at any
other (non-ALSA) PCI driver. Existing spin_lock() is fine for both
PCI shared irq handlers
Subject: [patch] x86_64: fix CONFIG_CC_STACKPROTECTOR build bug
From: Ingo Molnar [EMAIL PROTECTED]
on x86_64, the CONFIG_CC_STACKPROTECTOR build fails if used in a
distcc setup that has CC defined to distcc gcc:
gcc: gcc: linker input file unused because linking not done
gcc: gcc: linker
On 15 Nov 2006 23:24:32 -0500
[EMAIL PROTECTED] wrote:
Well, before giving up entirely, assume that *some* device owns that
interrupt, it's just mis-routed.
So start calling the IRQ handlers for *every* PCI device until the
damn interrupt goes away, or you've really proved that it can't
be
Use vma_policy() and vma_set_policy() macros provided in
include/linux/mempolicy.h.
Cc: Andi Kleen [EMAIL PROTECTED]
Cc: Christoph Lameter [EMAIL PROTECTED]
Signed-off-by: David Rientjes [EMAIL PROTECTED]
---
mm/mempolicy.c | 14 +++---
1 files changed, 7 insertions(+), 7 deletions(-)
Dear Sir,
For Hindu Divine Books, Cds, Cassettes Pooja Articles, Please visit
our website at www.egctraders.com
For any specific requirements, please write to us at
[EMAIL PROTECTED], [EMAIL PROTECTED]
Looking forward to hearing from you.
With Warm Regards,
Mrs. Vanitha S.
EGC has
On Wednesday 15 November 2006 22:10, Mws wrote:
On Wednesday 15 November 2006 21:14, Linus Torvalds wrote:
On Wed, 15 Nov 2006, Mws wrote:
after some small discussions on alsa-user ml i recognised this
thread today.
i thought my problem could also exist on this msi stuff.
i
On Thursday 16 November 2006 12:00, David Rientjes wrote:
Use vma_policy() and vma_set_policy() macros provided in
include/linux/mempolicy.h.
Why? I don't think it makes the code any more readable
-Andi
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a
* Andi Kleen [EMAIL PROTECTED] wrote:
arch/x86_64/kernel/mce_amd.c: In function ‘threshold_remove_bank’:
arch/x86_64/kernel/mce_amd.c:597: error: ‘shared_bank’ undeclared (first
use in this function)
arch/x86_64/kernel/mce_amd.c:597: error: (Each undeclared identifier is
reported
Hi,
How to disable interrupts on pentium 4 (or any
i386)
machine?
I tried to include cli instruction in a kernel
module. But got runtime error.
Thanks in advance.
___
Try the all-new Yahoo! Mail. The New
On Tue, Nov 14, 2006 at 01:41:25AM -0800, Andrew Morton wrote:
...
Changes since 2.6.19-rc5-mm2:
...
+updated-i386-convert-to-clock-event-devices.patch
...
Updated/fixed/reworked/redone hrtimer and dynticks patches.
...
This patch removes the no longer used hpet_reenable()
Signed-off-by:
This patch makes the needlessly global pci_bf_sort static.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
--- linux-2.6.19-rc5-mm2/arch/i386/pci/common.c.old 2006-11-16
00:20:15.0 +0100
+++ linux-2.6.19-rc5-mm2/arch/i386/pci/common.c 2006-11-16 00:20:32.0
+0100
@@ -20,7 +20,7
On Wed, 15 Nov 2006 16:47:59 +, Jan Beulich wrote:
Pointers should not be casted to u32 as this results in compiler warnings
on 64-bit platforms.
NAK. Use %p for formatting pointers. No casts needed.
Indeed, how did I not see this... While at this, I saw that there were a few
more
On 2006-11-15, Fabio Coatti wrote:
Hi all,
I'm just trying to move things forward, i'm not a developer.
I'm seeing a strange behaviour on a dual opteron machine (or, at least it
seem
so to me) and I need some advice.
The hardware is: dual opteron 2.4, dual core, 2GB ram
This machine runs
On Wed, Nov 15, 2006 at 09:49:33PM +0100, Pavel Machek wrote:
Suspending with mounted floppy is a user error.
Huh? How so?
Floppy is removable, and you are expected to umount removable devices
before suspend.
That seems pretty crude. There are lots of cases where an
On Thu, Nov 16, 2006 at 01:16:23PM +0100, Adrian Bunk wrote:
This patch makes the needlessly global pci_bf_sort static.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
Acked-by: Matt Domsch [EMAIL PROTECTED]
--
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com
In gmane.linux.kernel, you wrote:
Hi!
Hallo.
We are building embedded devices based on Linux and we use a ramdisk as
our root device in order to avoid problems with people switching off the
unit without a proper shutdown and to save write-cycles on our flash disc.
Using a 2.6.12 kernel it
I just stumbled across the Month of Kernel Bugs (MoKB) archive -
http://projects.info-pull.com/mokb/
It's a page that will release 1 kernel bug each day for all of this
month. There are some Linux kernel bugs listed as well as bugs for
other OS kernels.
Just wanted to bring it to the attention
* Andi Kleen [EMAIL PROTECTED] wrote:
my hotplug-CPU cleanup patch solves this in a cleaner way: by
removing all those #ifdefs as well.
Fine, but I suspect that late in the release it's better to go for
minimal obvious fixes. Later it can then be cleaned up properly.
we are not /that/
On Thursday 16 November 2006 01:45, Christoph Lameter wrote:
On Thu, 16 Nov 2006, Arnd Bergmann wrote:
- we want to be able to boot with the 'mem=512M' option, which effectively
disables the memory on the second node (each node has 512MiB).
- Each node has 8 SPUs, all of which we want
On Thu, 16 Nov 2006 02:43:30 +0100
Paul Seelig [EMAIL PROTECTED] wrote:
Today i fetched the newest suspend2 patches and rebooted the machine with a
2.6.18.2 kernel containing them. Now let's see if the problem i reported
persists. If yes, i'll report them to Nigel Cunningham instead.
You can
Hi!
Hallo.
We are building embedded devices based on Linux and we use a ramdisk as
our root device in order to avoid problems with people switching off the
unit without a proper shutdown and to save write-cycles on our flash disc.
Using a 2.6.12 kernel it was no problem to boot the
On Wed, Nov 15, 2006 at 08:54:44AM -0800, Christoph Lameter wrote:
On Wed, 15 Nov 2006, Wu Fengguang wrote:
Collect info about the global available memory and its consumption speed.
The data are used by the stateful method to estimate the thrashing
threshold.
Looks like you should use
Good afternoon.
I got your resume from SEEK Australia job-site and it
suites our company requirements.
My name is Roger Longbotham, I represent George Metway
Inc company located in Europe.
Our company is seekeing for a representatives in
Australia for full and part-time jobs.
No relocation is
Alberto Alonso wrote:
Sorry for the long delay, I've been called on too
many issues at work this week.
Anyway, the patch basically made the drives not usable.
Mmm.. Okay, thanks for helping track this down.
It appears that this got broken when the ATA_TFLAG_POLLING
got introduced into
On Wed, Nov 15, 2006 at 12:51:08PM -0600, Maynard Johnson wrote:
+/* This function is called once for all cpus combined */
+static void
+cell_reg_setup(struct op_counter_config *ctr,
+struct op_system_config *sys, int num_ctrs)
+{
[SNIP]
+ for (i = 0; i num_ctrs; ++i) {
+
* Ingo Molnar [EMAIL PROTECTED] wrote:
Subject: [patch] lockdep: show held locks when showing a stackdump
From: Ingo Molnar [EMAIL PROTECTED]
lockdep can be used to print held locks when printing a backtrace.
This can be useful when debugging things like 'scheduling while
atomic'
Andi,
Here is a small patch for x86-64 which adds a cpufeature flag and
detection code for Intel's Branch Trace Store (BTS) feature. This
feature can be found on Intel P4 and Core 2 processors among others.
It can also be used by perfmon.
The patch is relative to 2.6.19-rc5-git7 +
Andi,
Here is a small patch for i386 which adds a cpufeature flag and
detection code for Intel's Branch Trace Store (BTS) feature. This
feature can be found on Intel P4 and Core 2 processors among others.
It can also be used by perfmon.
The patch is relative to 2.6.19-rc5-git7 +
On Thursday 16 November 2006 15:20, Stephane Eranian wrote:
Andi,
Here is a small patch for x86-64 which adds a cpufeature flag and
detection code for Intel's Branch Trace Store (BTS) feature. This
feature can be found on Intel P4 and Core 2 processors among others.
It can also be used by
On Thu, Nov 16, 2006 at 11:23:12AM +, ranjith kumar wrote:
Hi,
How to disable interrupts on pentium 4 (or any
i386)
machine?
I tried to include cli instruction in a kernel
module. But got runtime error.
Read Documentation/cli-sti-removal.txt.
- Heikki
-
To unsubscribe
From: Cornelia Huck [EMAIL PROTECTED]
Introduce device_find_child() to match device_for_each_child().
Signed-off-by: Cornelia Huck [EMAIL PROTECTED]
---
drivers/base/core.c| 33 +
include/linux/device.h |2 ++
2 files changed, 35 insertions(+)
---
Jeff Garzik [EMAIL PROTECTED] writes:
We are referring to the standard PCI 2.2 bit, PCI_COMMAND_INTX_DISABLE.
Yeah, I figured it, I somewhat forgot about it ... it got introduced
in
2.3 though, no ?
It's pretty new. 2.2 or 2.3.
2.3.
PCI 2.2 defines bits 0-9 only (bit 7 = Stepping
From: Cornelia Huck [EMAIL PROTECTED]
Provide a function device_move() to move a device to a new parent device. Add
auxilliary functions kobject_move() and sysfs_move_dir().
kobject_move() generates a new uevent of type KOBJ_MOVE, containing the
previous path (OLD_DEVPATH) in addition to the
Hi,
this is a basically a resend of the driver core patches I already sent
on Nov 14. (They are needed as a base for the s390 cio patches of that
patchset which still are in -mm.)
Patch 1 is unchanged, patch 2 now also contains the KOBJ_MOVE uevent
which will be generated when a kobject has been
On Wed, Nov 15, 2006 at 10:49:23PM +0100, Chris Friedhoff wrote:
| On Wed, 15 Nov 2006 11:06:34 -0600
| Bill O'Donnell [EMAIL PROTECTED] wrote:
|
| - snip -
| | Probably, Bill didn't update libcap.so.
| No, I didn't...
| certify:~/libcap-1.10/progs # ls -altr /lib/libcap*
| -rwxr-xr-x 1 root
Hi,
Don't know if this is the correct place to bring this up but
/pub/linux/kernel/* seems to be unavailable on kernel.org via FTP. Both
my linux box and my work Windows box can connect to kernel.org, but
cding to the directory (I'm on the Windoze machine at the moment) gives:
230 Login
On Sat, 11 Nov 2006 15:41:32 -0800
David Brownell [EMAIL PROTECTED] wrote:
Below, find what I think is a useful proposal, trivially
implementable on many ARMs (at91, omap, pxa, ep93xx, ixp2000,
pnx4008, davinci, more) as well as the new AVR32.
FYI, here's the AVR32 implementation of the API
Despite it being small, there should be the option of making it a
module...
Signed-off-by: Jan Beulich [EMAIL PROTECTED]
--- linux-2.6.19-rc5/drivers/char/hw_random/Kconfig 2006-09-20
05:42:06.0 +0200
+++ 2.6.19-rc5-modular-rng/drivers/char/hw_random/Kconfig 2006-11-16
Hi!
Make the workqueues used by XFS freezeable, so their worker threads don't
submit any I/O after the suspend image has been created.
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
Looks okay to me.
Pavel
--
(english)
Hi!
Make it possible to create a workqueue the worker thread of which will be
frozen during suspend, along with other kernel threads.
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
ACK.
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
On Wed, 2006-11-15 at 14:41 -0800, Christoph Lameter wrote:
On Wed, 15 Nov 2006, Martin Bligh wrote:
A node is an arbitrary container object containing one or more of:
CPUs
Memory
IO bus
It does not have to contain memory.
I have never seen a node on Linux without memory. I
On Wednesday 15 November 2006 02:17, Marty Leisner wrote:
I always want to know WHAT I'm running (or people I'm working with
are running) rather than guessing (do you have the most current
patch I think so)
I've been a proponent of capturing .config information SOMEPLACE where
you can look
Chris wrote:
Don't know if this is the correct place to bring this up but
/pub/linux/kernel/* seems to be unavailable on kernel.org via FTP.
...
www.kernel.org via http seems to be REALLY slow as well.
ftp://ftp.uk.kernel.org/ and http://www.uk.kernel.org/ work.
--
Stefan Richter
301 - 400 of 666 matches
Mail list logo
