On Sun, 14 Aug 2005, Pavel Machek wrote:
> > Ok perhaps on the resume side instead. When trying to resume can you try
> > booting with 'dyntick=disable'. Note this isn't meant to be a long term fix
> > but once we figure out where the problem is we should be able to code
> > around
> > it.
>
On Sun, 14 Aug 2005, Pavel Machek wrote:
Ok perhaps on the resume side instead. When trying to resume can you try
booting with 'dyntick=disable'. Note this isn't meant to be a long term fix
but once we figure out where the problem is we should be able to code
around
it.
Can you
On Sun, 14 Aug 2005, Rafael J. Wysocki wrote:
I've got the following BUG on Asus L5D (x86-64) with the 2.6.13-rc5-mm1
kernel:
BUG: rwlock recursion on CPU#0, nscd/3668, 8817d4a0
Call Trace:80241ca9{add_preempt_count+105}
80241682{rwlock_bug+114}
On Sun, 14 Aug 2005, Phil Dier wrote:
I just got this:
Unable to handle kernel paging request at virtual address eeafefc0
printing eip:
c0188487
*pde = 00681067
*pte = 2eafe000
Oops: [#1]
SMP DEBUG_PAGEALLOC
Modules linked in:
CPU:1
EIP:0060:[c0188487]Not tainted
On Sun, 14 Aug 2005, Robert Love wrote:
On Sun, 2005-08-14 at 20:40 -0600, Zwane Mwaikambo wrote:
I'm new here, if the inode isn't being watched, what's to stop d_delete
from removing the inode before fsnotify_unlink proceeds to use it?
Nothing. But check out
http://kernel.org/git
On Sun, 14 Aug 2005, James Cleverdon wrote:
+static int next_irq = 16;
Won't this need a lock for hotplug later?
That's what I thought originally, but maybe not. We initialize all RTEs
and assign IRQs+vectors fairly early in boot, plus store the results in
arrays. Thereafter the
On Thu, 11 Aug 2005, Protasevich, Natalie wrote:
> > I added some of the suggestions brought forward (dynamically
> > allocated IDTs, percpu IDT) last night, all that's left is
> > MSI, which does work right now, but gets all its vectors
> > allocated on the first irq handling domain. I should
Hello Bharata,
On Thu, 11 Aug 2005, Bharata B Rao wrote:
> I don't know the context of your work here, but a couple of
> observations.
>
> Since you populate cpu_possible_map with NR_CPUS, alloc_percpu()
> would end up allocating for all NR_CPUS. Wouldn't you have achieved
> the same thing by
On Thu, 11 Aug 2005, Steven Rostedt wrote:
> On Thu, 2005-08-11 at 13:46 -0400, linux-os (Dick Johnson) wrote:
>
> >
> > I was talking about the one who had the glibc support to use
> > the newer system-call entry (who's name can confuse).
> >
> > You are looking at code that uses int 0x80.
On Wed, 10 Aug 2005, Protasevich, Natalie wrote:
> our systems we are just about to use up all 224 interrupts, but not
> quiet.
> I have to mention that as far as I know Zwane is about to release his
> vector sharing mechanism, he had it implemented and working for i386 (I
> tested it on ES7000
On Thu, 11 Aug 2005, Andi Kleen wrote:
> On Wed, Aug 10, 2005 at 10:59:28PM -0600, Zwane Mwaikambo wrote:
> > for_each_cpu walks through all processors in cpu_possible_map, which is
> > defined as cpu_callout_map on i386 and isn't initialised until all
> > proces
On Wed, 10 Aug 2005, Zachary Amsden wrote:
> Thanks for the feedback. I believe the binary compilation is the same. It is
> superfluous in the sense that there is not yet a real use for it, but it is
> needed for later developement.
>
> Xen requires page isolation of system data structures
On Wed, 10 Aug 2005, Zachary Amsden wrote:
Thanks for the feedback. I believe the binary compilation is the same. It is
superfluous in the sense that there is not yet a real use for it, but it is
needed for later developement.
Xen requires page isolation of system data structures that
On Thu, 11 Aug 2005, Andi Kleen wrote:
On Wed, Aug 10, 2005 at 10:59:28PM -0600, Zwane Mwaikambo wrote:
for_each_cpu walks through all processors in cpu_possible_map, which is
defined as cpu_callout_map on i386 and isn't initialised until all
processors have been booted. This breaks
On Wed, 10 Aug 2005, Protasevich, Natalie wrote:
our systems we are just about to use up all 224 interrupts, but not
quiet.
I have to mention that as far as I know Zwane is about to release his
vector sharing mechanism, he had it implemented and working for i386 (I
tested it on ES7000
On Thu, 11 Aug 2005, Steven Rostedt wrote:
On Thu, 2005-08-11 at 13:46 -0400, linux-os (Dick Johnson) wrote:
I was talking about the one who had the glibc support to use
the newer system-call entry (who's name can confuse).
You are looking at code that uses int 0x80. It's an
Hello Bharata,
On Thu, 11 Aug 2005, Bharata B Rao wrote:
I don't know the context of your work here, but a couple of
observations.
Since you populate cpu_possible_map with NR_CPUS, alloc_percpu()
would end up allocating for all NR_CPUS. Wouldn't you have achieved
the same thing by
On Thu, 11 Aug 2005, Protasevich, Natalie wrote:
I added some of the suggestions brought forward (dynamically
allocated IDTs, percpu IDT) last night, all that's left is
MSI, which does work right now, but gets all its vectors
allocated on the first irq handling domain. I should be done
On Wed, 10 Aug 2005 [EMAIL PROTECTED] wrote:
> Add an accessor function for getting the per-CPU gdt. Callee must already
> have the CPU.
This one seems superfluous to me, does accessing it indirectly generate
better code too?
> Patch-base: 2.6.13-rc5-mm1
> Patch-keys: i386 desc xen
>
(+), 1 deletion(-)
Signed-off-by: Zwane Mwaikambo <[EMAIL PROTECTED]>
Index: linux-2.6.13-rc5-mm1/arch/i386/kernel/smpboot.c
===
RCS file: /home/cvsroot/linux-2.6.13-rc5-mm1/arch/i386/kernel/smpboot.c,v
retrieving revision 1.1.1.
(+), 1 deletion(-)
Signed-off-by: Zwane Mwaikambo [EMAIL PROTECTED]
Index: linux-2.6.13-rc5-mm1/arch/i386/kernel/smpboot.c
===
RCS file: /home/cvsroot/linux-2.6.13-rc5-mm1/arch/i386/kernel/smpboot.c,v
retrieving revision 1.1.1.1
diff -u
On Wed, 10 Aug 2005 [EMAIL PROTECTED] wrote:
Add an accessor function for getting the per-CPU gdt. Callee must already
have the CPU.
This one seems superfluous to me, does accessing it indirectly generate
better code too?
Patch-base: 2.6.13-rc5-mm1
Patch-keys: i386 desc xen
Some folks have been emailing me and having trouble due to these stale
addresses;
Signed-off-by: Zwane Mwaikambo <[EMAIL PROTECTED]>
Index: linux-2.6.13-rc5-mm1/CREDITS
===
RCS file: /home/cvsroot/linux-2.6.13-rc5-mm1/CRE
On Mon, 8 Aug 2005, Tony Lindgren wrote:
> As far as I remember enabling AMD stop grant disconnects all cpus. This
> means the system won't be able to do any work until the dyntick timer
> interrupt wakes up the system.
>
> > Both requirements (idling all CPUs together vs individually) I think
>
On Mon, 8 Aug 2005, Alexander Nyberg wrote:
> > IRQ_PER_CPU is not used by all architectures.
> > This patch introduces the macros
> > ARCH_HAS_IRQ_PER_CPU and CHECK_IRQ_PER_CPU() to avoid the generation of
> > dead code in __do_IRQ().
> >
> > ARCH_HAS_IRQ_PER_CPU is defined by architectures
On Mon, 8 Aug 2005, Alexander Nyberg wrote:
IRQ_PER_CPU is not used by all architectures.
This patch introduces the macros
ARCH_HAS_IRQ_PER_CPU and CHECK_IRQ_PER_CPU() to avoid the generation of
dead code in __do_IRQ().
ARCH_HAS_IRQ_PER_CPU is defined by architectures using
On Mon, 8 Aug 2005, Tony Lindgren wrote:
As far as I remember enabling AMD stop grant disconnects all cpus. This
means the system won't be able to do any work until the dyntick timer
interrupt wakes up the system.
Both requirements (idling all CPUs together vs individually) I think
will
Some folks have been emailing me and having trouble due to these stale
addresses;
Signed-off-by: Zwane Mwaikambo [EMAIL PROTECTED]
Index: linux-2.6.13-rc5-mm1/CREDITS
===
RCS file: /home/cvsroot/linux-2.6.13-rc5-mm1/CREDITS,v
On Sun, 7 Aug 2005, Lee Revell wrote:
> > It's most likely bad SMM code in the BIOS that blocks the CPU too long
> > and is triggered in idle. You can verify that by using idle=poll
> > (not recommended for production, just for testing) and see if it goes away.
> >
>
> WTF, since when do
On Sun, 7 Aug 2005, Lee Revell wrote:
It's most likely bad SMM code in the BIOS that blocks the CPU too long
and is triggered in idle. You can verify that by using idle=poll
(not recommended for production, just for testing) and see if it goes away.
WTF, since when do *desktops* use
On Mon, 11 Jul 2005, Oleg Nesterov wrote:
> Oleg Nesterov wrote:
> >
> > Probably it makes sense to change it to
> > pushl $vector - 0x - 1
> >
>
> Please note that entry.S:BUILD_INTERRUPT() also does this trick:
> pushl $nr-256;
>
> so it should be changed as well.
I was
On Mon, 11 Jul 2005, Oleg Nesterov wrote:
Oleg Nesterov wrote:
Probably it makes sense to change it to
pushl $vector - 0x - 1
Please note that entry.S:BUILD_INTERRUPT() also does this trick:
pushl $nr-256;
so it should be changed as well.
I was making these
On Sat, 30 Jul 2005, Lee Revell wrote:
> So it looks like artsd wastes way more power DMAing a bunch of silent
> pages to the sound card than HZ=1000.
>
> There's nothing the ALSA layer can do about this, it's a KDE bug.
>
> I think this is a good argument for leaving HZ at 1000 until some of
>
wrmsr(MSR_IA32_UCODE_REV, 0, 0);
- __asm__ __volatile__ ("cpuid" : : : "ax", "bx", "cx", "dx");
+ /* see 1.07. Apprent chip bug */
+ serialize_cpu();
1.07 in which document? Also, please just spell 'apparent' correctly,
saving 1 byte really just looks lazy.
-
To
On Sat, 30 Jul 2005, Brian Schau wrote:
> Hi Michael (and others),
>
>
> Thanks for the info. Well, the reason why I didn't inline the patch
> was due to the size of it - in terms of lines. However, here it is:
> +static void wsl_irq_in(struct urb *urb, struct pt_regs *regs)
> +{
> +
On Sat, 30 Jul 2005, Brian Schau wrote:
Hi Michael (and others),
Thanks for the info. Well, the reason why I didn't inline the patch
was due to the size of it - in terms of lines. However, here it is:
+static void wsl_irq_in(struct urb *urb, struct pt_regs *regs)
+{
+ struct
wrmsr(MSR_IA32_UCODE_REV, 0, 0);
- __asm__ __volatile__ (cpuid : : : ax, bx, cx, dx);
+ /* see 1.07. Apprent chip bug */
+ serialize_cpu();
1.07 in which document? Also, please just spell 'apparent' correctly,
saving 1 byte really just looks lazy.
-
To unsubscribe
On Sat, 30 Jul 2005, Lee Revell wrote:
So it looks like artsd wastes way more power DMAing a bunch of silent
pages to the sound card than HZ=1000.
There's nothing the ALSA layer can do about this, it's a KDE bug.
I think this is a good argument for leaving HZ at 1000 until some of
these
On Thu, 28 Jul 2005, Andrew Morton wrote:
> Michael Krufky <[EMAIL PROTECTED]> wrote:
> >
> > Sadly, I must report that yes, the problem still intermittently occurs
> > in 2.6.13-rc4 :-( I'm the one that tested on the Shuttle FT61
> > Motherboard. Never has a problem in windows and never
On Thu, 28 Jul 2005, Andrew Morton wrote:
Michael Krufky [EMAIL PROTECTED] wrote:
Sadly, I must report that yes, the problem still intermittently occurs
in 2.6.13-rc4 :-( I'm the one that tested on the Shuttle FT61
Motherboard. Never has a problem in windows and never in 2.6.11
On Wed, 27 Jul 2005, Lee Revell wrote:
> On Wed, 2005-07-27 at 02:13 -0600, Zwane Mwaikambo wrote:
> > > What about audio? If there is a sound server running then you're going
> > > to have a constant stream of interrupts and DMA activity from the sound
> > > ca
On Mon, 25 Jul 2005, Lee Revell wrote:
> On Mon, 2005-07-25 at 17:19 -0400, Brown, Len wrote:
> > >>>Question one, are there other actions to consider?
> > >>
> > >>
> > >> Yes.
> > >> Speaking for ACPI C3 state, note that DMA also
> > >> wakes up the CPU -- even if there was no device
On Mon, 25 Jul 2005, Lee Revell wrote:
On Mon, 2005-07-25 at 17:19 -0400, Brown, Len wrote:
Question one, are there other actions to consider?
Yes.
Speaking for ACPI C3 state, note that DMA also
wakes up the CPU -- even if there was no device interrupt.
(aka, the trouble
On Wed, 27 Jul 2005, Lee Revell wrote:
On Wed, 2005-07-27 at 02:13 -0600, Zwane Mwaikambo wrote:
What about audio? If there is a sound server running then you're going
to have a constant stream of interrupts and DMA activity from the sound
card even if the machine is idle
On Sat, 23 Jul 2005, [koi8-r] ? ? wrote:
> The letter itself is in an attached file.
Run memtest, it sounds like you have failing hardware.
On Sat, 23 Jul 2005, Russell King wrote:
> On Sat, Jul 23, 2005 at 02:29:24AM +0200, Pavel Machek wrote:
> > > Is it necessary to do free_irq for suspend? Shouldn't disable_irq
> > > be enough?
> >
> > Due to recent changes in ACPI, yes, it is neccessary.
>
> What if some other driver is
On Sat, 23 Jul 2005, Russell King wrote:
On Sat, Jul 23, 2005 at 02:29:24AM +0200, Pavel Machek wrote:
Is it necessary to do free_irq for suspend? Shouldn't disable_irq
be enough?
Due to recent changes in ACPI, yes, it is neccessary.
What if some other driver is sharing the IRQ,
On Sat, 23 Jul 2005, [koi8-r] ? ? wrote:
The letter itself is in an attached file.
Run memtest, it sounds like you have failing hardware.
On Fri, 15 Jul 2005, Andi Kleen wrote:
> On Fri, 15 Jul 2005 05:04:57 -0600 (MDT)
> Zwane Mwaikambo <[EMAIL PROTECTED]> wrote:
>
>
> > void show_regs(struct pt_regs *regs)
> > {
> > + printk("CPU %d:", smp_processor_id());
>
> Isn't ther
On Fri, 15 Jul 2005, Zwane Mwaikambo wrote:
> Up to date i've been using the GS value to determine the processor number
> in dumps from show_regs, however this can be cumbersome to do if you don't
> have the vmlinux to verify with the address of cpu_pda, how about the
> following?
already dereference current so we're already relying on MSR_GS_BASE being
sane.
Signed-off-by: Zwane Mwaikambo <[EMAIL PROTECTED]>
Index: linux-2.6.13-rc2-mm1/arch/x86_64/kernel/process.c
===
RCS file: /home/cvsroot/linux-2.6.
already dereference current so we're already relying on MSR_GS_BASE being
sane.
Signed-off-by: Zwane Mwaikambo [EMAIL PROTECTED]
Index: linux-2.6.13-rc2-mm1/arch/x86_64/kernel/process.c
===
RCS file: /home/cvsroot/linux-2.6.13-rc2-mm1
On Fri, 15 Jul 2005, Zwane Mwaikambo wrote:
Up to date i've been using the GS value to determine the processor number
in dumps from show_regs, however this can be cumbersome to do if you don't
have the vmlinux to verify with the address of cpu_pda, how about the
following? I considered
On Fri, 15 Jul 2005, Andi Kleen wrote:
On Fri, 15 Jul 2005 05:04:57 -0600 (MDT)
Zwane Mwaikambo [EMAIL PROTECTED] wrote:
void show_regs(struct pt_regs *regs)
{
+ printk(CPU %d:, smp_processor_id());
Isn't there a space after the : missing here?
I don't believe so
On Fri, 15 Jul 2005, Lee Revell wrote:
> On Fri, 2005-07-15 at 14:08 +1000, Con Kolivas wrote:
> > Audio did show slightly larger max latencies but nothing that would be of
> > significance.
> >
> > On video, maximum latencies are only slightly larger at HZ 250, all the
> > desired cpu was
On Fri, 15 Jul 2005, Lee Revell wrote:
On Fri, 2005-07-15 at 14:08 +1000, Con Kolivas wrote:
Audio did show slightly larger max latencies but nothing that would be of
significance.
On video, maximum latencies are only slightly larger at HZ 250, all the
desired cpu was achieved, but
Hello Oleg,
On Mon, 11 Jul 2005, Oleg Nesterov wrote:
> Zwane Mwaikambo wrote:
> >
> > --- linux-2.6.13-rc1-mm1/arch/i386/kernel/entry.S 3 Jul 2005 13:20:43
> > - 1.1.1.1
> > +++ linux-2.6.13-rc1-mm1/arch/i386/kernel/entry.S 10 Jul 2005 22:33:37
&g
On Mon, 11 Jul 2005, Brian Gerst wrote:
> Zwane Mwaikambo wrote:
> > On Sun, 11 Jul 2005, Andi Kleen wrote:
> >
> >
> > > Why per node? Why not go the whole way and make it per CPU?
> > >
> > > I would also not define it statically, but all
Hi Oleg,
On Mon, 11 Jul 2005, Oleg Nesterov wrote:
> > The change is so that we can send IRQs higher than 256 to do_IRQ. That
> > looks like it tries to check if we came in via system_call since we'd save
> > the system call number as orig_eax. Now that i think about it, doesn't
> > that path
On Mon, 11 Jul 2005, Arjan van de Ven wrote:
> On Mon, 2005-07-11 at 03:59 +0200, Andi Kleen wrote:
> > Why per node? Why not go the whole way and make it per CPU?
>
> Agreed, for two reasons even
> 1) Per cpu allows for even more devices and cache locality
> 2) While few people have a NUMA
On Sun, 11 Jul 2005, Andi Kleen wrote:
> Why per node? Why not go the whole way and make it per CPU?
>
> I would also not define it statically, but allocate it at boot time
> in node local memory.
I went per node so that it would be minimal/zero impact for the no-node
case, it would also
On Sun, 11 Jul 2005, Andi Kleen wrote:
Why per node? Why not go the whole way and make it per CPU?
I would also not define it statically, but allocate it at boot time
in node local memory.
I went per node so that it would be minimal/zero impact for the no-node
case, it would also simplify
On Mon, 11 Jul 2005, Arjan van de Ven wrote:
On Mon, 2005-07-11 at 03:59 +0200, Andi Kleen wrote:
Why per node? Why not go the whole way and make it per CPU?
Agreed, for two reasons even
1) Per cpu allows for even more devices and cache locality
2) While few people have a NUMA system,
Hi Oleg,
On Mon, 11 Jul 2005, Oleg Nesterov wrote:
The change is so that we can send IRQs higher than 256 to do_IRQ. That
looks like it tries to check if we came in via system_call since we'd save
the system call number as orig_eax. Now that i think about it, doesn't
that path always
On Mon, 11 Jul 2005, Brian Gerst wrote:
Zwane Mwaikambo wrote:
On Sun, 11 Jul 2005, Andi Kleen wrote:
Why per node? Why not go the whole way and make it per CPU?
I would also not define it statically, but allocate it at boot time
in node local memory.
I went per node
Hello Oleg,
On Mon, 11 Jul 2005, Oleg Nesterov wrote:
Zwane Mwaikambo wrote:
--- linux-2.6.13-rc1-mm1/arch/i386/kernel/entry.S 3 Jul 2005 13:20:43
- 1.1.1.1
+++ linux-2.6.13-rc1-mm1/arch/i386/kernel/entry.S 10 Jul 2005 22:33:37
-
-
+/* Build the IRQ entry stubs
As most are aware there is a growing need for more devices on i386/x86_64
based platforms and with that, support for interrupt servicing for all
these devices. The proliferation of MSI based devices will also drive that
requirement higher due to some devices requiring multiple vectors. Natalie
s from
set_cpus_allowed as set_cpus_allowed ensures that you're executing on the
target processor on return.
Signed-off-by: Zwane Mwaikambo <[EMAIL PROTECTED]>
Index: linux-2.6.13-rc1-mm1/arch/i386/kernel/cpu/cpufreq/powernow-k8.c
===
RCS
set_cpus_allowed as set_cpus_allowed ensures that you're executing on the
target processor on return.
Signed-off-by: Zwane Mwaikambo [EMAIL PROTECTED]
Index: linux-2.6.13-rc1-mm1/arch/i386/kernel/cpu/cpufreq/powernow-k8.c
===
RCS file:
/home
As most are aware there is a growing need for more devices on i386/x86_64
based platforms and with that, support for interrupt servicing for all
these devices. The proliferation of MSI based devices will also drive that
requirement higher due to some devices requiring multiple vectors. Natalie
On Wed, 6 Jul 2005, Nigel Cunningham wrote:
> I've just noticed that all the subject lines are off by one. Sorry.
> Shall I repost with it right this time?
Yes the subject lines did look a bit confusing, it may be easier in future
to add a short description of the patch instead of relying on
On Wed, 6 Jul 2005, Nigel Cunningham wrote:
> On Wed, 2005-07-06 at 13:35, Zwane Mwaikambo wrote:
> >
> > Isn't this covered by Shaohua Li's patch?
>
> I believe so, but Shaohua Li's patch isn't merged in 2.6.12 (is it yet
> at all). This is the solution I've been usi
On Wed, 6 Jul 2005, Nigel Cunningham wrote:
> On Wed, 2005-07-06 at 13:34, Zwane Mwaikambo wrote:
> > On Wed, 6 Jul 2005, Nigel Cunningham wrote:
> >
> > > diff -ruNp
> > > 353-disable-highmem-tlb-flush-for-copyback.patch-old/mm/highmem.c
> > > 353-di
On Wed, 6 Jul 2005, Nigel Cunningham wrote:
On Wed, 2005-07-06 at 13:34, Zwane Mwaikambo wrote:
On Wed, 6 Jul 2005, Nigel Cunningham wrote:
diff -ruNp
353-disable-highmem-tlb-flush-for-copyback.patch-old/mm/highmem.c
353-disable-highmem-tlb-flush-for-copyback.patch-new/mm
On Wed, 6 Jul 2005, Nigel Cunningham wrote:
On Wed, 2005-07-06 at 13:35, Zwane Mwaikambo wrote:
Isn't this covered by Shaohua Li's patch?
I believe so, but Shaohua Li's patch isn't merged in 2.6.12 (is it yet
at all). This is the solution I've been using for... can't remember how
long
On Wed, 6 Jul 2005, Nigel Cunningham wrote:
I've just noticed that all the subject lines are off by one. Sorry.
Shall I repost with it right this time?
Yes the subject lines did look a bit confusing, it may be easier in future
to add a short description of the patch instead of relying on the
On Wed, 6 Jul 2005, Nigel Cunningham wrote:
> diff -ruNp 602-smp.patch-old/kernel/power/suspend2_core/smp.c
> 602-smp.patch-new/kernel/power/suspend2_core/smp.c
> --- 602-smp.patch-old/kernel/power/suspend2_core/smp.c1970-01-01
> 10:00:00.0 +1000
> +++
On Wed, 6 Jul 2005, Nigel Cunningham wrote:
> + /*
> + * eflags
> + */
> + asm volatile ("pushfl ; popl (%0)" : "=m"
> (suspend2_saved_context.eflags));
To be future proof you probably want to do pushfq/popq
> +
> + /*
> + * control registers
> + */
> + asm
On Wed, 6 Jul 2005, Nigel Cunningham wrote:
> diff -ruNp 402-mtrr-remove-sysdev.patch-old/arch/i386/kernel/cpu/mtrr/main.c
> 402-mtrr-remove-sysdev.patch-new/arch/i386/kernel/cpu/mtrr/main.c
> --- 402-mtrr-remove-sysdev.patch-old/arch/i386/kernel/cpu/mtrr/main.c
> 2005-06-20 11:46:42.0
On Wed, 6 Jul 2005, Nigel Cunningham wrote:
> diff -ruNp 353-disable-highmem-tlb-flush-for-copyback.patch-old/mm/highmem.c
> 353-disable-highmem-tlb-flush-for-copyback.patch-new/mm/highmem.c
> --- 353-disable-highmem-tlb-flush-for-copyback.patch-old/mm/highmem.c
> 2005-06-20 11:47:32.0
On Wed, 6 Jul 2005, Nigel Cunningham wrote:
diff -ruNp 353-disable-highmem-tlb-flush-for-copyback.patch-old/mm/highmem.c
353-disable-highmem-tlb-flush-for-copyback.patch-new/mm/highmem.c
--- 353-disable-highmem-tlb-flush-for-copyback.patch-old/mm/highmem.c
2005-06-20 11:47:32.0
On Wed, 6 Jul 2005, Nigel Cunningham wrote:
diff -ruNp 402-mtrr-remove-sysdev.patch-old/arch/i386/kernel/cpu/mtrr/main.c
402-mtrr-remove-sysdev.patch-new/arch/i386/kernel/cpu/mtrr/main.c
--- 402-mtrr-remove-sysdev.patch-old/arch/i386/kernel/cpu/mtrr/main.c
2005-06-20 11:46:42.0
On Wed, 6 Jul 2005, Nigel Cunningham wrote:
+ /*
+ * eflags
+ */
+ asm volatile (pushfl ; popl (%0) : =m
(suspend2_saved_context.eflags));
To be future proof you probably want to do pushfq/popq
+
+ /*
+ * control registers
+ */
+ asm volatile
On Wed, 6 Jul 2005, Nigel Cunningham wrote:
diff -ruNp 602-smp.patch-old/kernel/power/suspend2_core/smp.c
602-smp.patch-new/kernel/power/suspend2_core/smp.c
--- 602-smp.patch-old/kernel/power/suspend2_core/smp.c1970-01-01
10:00:00.0 +1000
+++
On Mon, 4 Jul 2005, Martin Mokrejs wrote:
> Hi,
> I use on i686 architecture Gentoo linux with XFS filesystem.
> Recently it happened to me 3 time that the machine locked,
> although at least once sys-rq+b worked. Here is the log
> from remote console. I don't remeber having such problems
>
On Mon, 4 Jul 2005, Martin Mokrejs wrote:
Hi,
I use on i686 architecture Gentoo linux with XFS filesystem.
Recently it happened to me 3 time that the machine locked,
although at least once sys-rq+b worked. Here is the log
from remote console. I don't remeber having such problems
with
On Tue, 12 Apr 2005, Li Shaohua wrote:
> On Tue, 2005-04-12 at 20:17, Zwane Mwaikambo wrote:
> > On Tue, 12 Apr 2005, Li Shaohua wrote:
> >
> > > #ifdef CONFIG_HOTPLUG_CPU
> > > +int __attribute__ ((weak)) smp_prepare_cpu(int cpu)
> > > +{
> >
On Tue, 12 Apr 2005, [EMAIL PROTECTED] wrote:
> The machine crashed again twice today. I have vga=791 so i caugh a bit more
> of the crash. i enabled serial redirection in the bios so i'm hoping to
> catch the full dump next time.
Cool, can you also try Cc'ing [EMAIL PROTECTED]
Thanks,
On Tue, 12 Apr 2005, Li Shaohua wrote:
> #ifdef CONFIG_HOTPLUG_CPU
> +int __attribute__ ((weak)) smp_prepare_cpu(int cpu)
> +{
> + return 0;
> +}
> +
Any way for you to avoid using weak attribute?
Thanks,
Zwane
-
To unsubscribe from this list: send the line "unsubscribe
Hello Shaohua,
On Tue, 12 Apr 2005, Li Shaohua wrote:
> These patches (together with 5 patches followed this one) are updated
> suspend/resume SMP patches. The patches fixed some bugs and do clean up
> as suggested. Now they work for both suspend-to-ram and suspend-to-disk.
> Patches are against
Hello Shaohua,
On Tue, 12 Apr 2005, Li Shaohua wrote:
These patches (together with 5 patches followed this one) are updated
suspend/resume SMP patches. The patches fixed some bugs and do clean up
as suggested. Now they work for both suspend-to-ram and suspend-to-disk.
Patches are against
On Tue, 12 Apr 2005, Li Shaohua wrote:
#ifdef CONFIG_HOTPLUG_CPU
+int __attribute__ ((weak)) smp_prepare_cpu(int cpu)
+{
+ return 0;
+}
+
Any way for you to avoid using weak attribute?
Thanks,
Zwane
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
On Tue, 12 Apr 2005, [EMAIL PROTECTED] wrote:
The machine crashed again twice today. I have vga=791 so i caugh a bit more
of the crash. i enabled serial redirection in the bios so i'm hoping to
catch the full dump next time.
Cool, can you also try Cc'ing [EMAIL PROTECTED]
Thanks,
On Tue, 12 Apr 2005, Li Shaohua wrote:
On Tue, 2005-04-12 at 20:17, Zwane Mwaikambo wrote:
On Tue, 12 Apr 2005, Li Shaohua wrote:
#ifdef CONFIG_HOTPLUG_CPU
+int __attribute__ ((weak)) smp_prepare_cpu(int cpu)
+{
+ return 0;
+}
+
Any way for you to avoid using weak
On Wed, 6 Apr 2005, [EMAIL PROTECTED] wrote:
> No, sorry, i have to run with bridging support other wise the guests(UML's)
> wont be able to communicate with the outside world.
Ok in that case, can you connect a serial console so that you can capture
the entire output?
Thanks,
Zwane
-
On Wed, 6 Apr 2005, Jeff Garzik wrote:
> On Thu, Apr 07, 2005 at 11:40:23AM +1000, Martin Pool wrote:
> > On Wed, 06 Apr 2005 23:39:11 +0400, Paul P Komkoff Jr wrote:
> >
> > > http://bazaar-ng.org/
> >
> > I'd like bazaar-ng to be considered too. It is not ready for adoption
> > yet, but I am
On Thu, 7 Apr 2005, Magnus Damm wrote:
> On Apr 6, 2005 4:28 PM, Malcolm Rowe <[EMAIL PROTECTED]> wrote:
> > Magnus Damm writes:
> > > And I guess the idea of replacing the initcall pointer with NULL will
> > > work both with and without function descriptors, right? So we should
> > > be safe on
On Thu, 7 Apr 2005, Magnus Damm wrote:
On Apr 6, 2005 4:28 PM, Malcolm Rowe [EMAIL PROTECTED] wrote:
Magnus Damm writes:
And I guess the idea of replacing the initcall pointer with NULL will
work both with and without function descriptors, right? So we should
be safe on IA64 and
On Wed, 6 Apr 2005, Jeff Garzik wrote:
On Thu, Apr 07, 2005 at 11:40:23AM +1000, Martin Pool wrote:
On Wed, 06 Apr 2005 23:39:11 +0400, Paul P Komkoff Jr wrote:
http://bazaar-ng.org/
I'd like bazaar-ng to be considered too. It is not ready for adoption
yet, but I am working (more
On Wed, 6 Apr 2005, [EMAIL PROTECTED] wrote:
No, sorry, i have to run with bridging support other wise the guests(UML's)
wont be able to communicate with the outside world.
Ok in that case, can you connect a serial console so that you can capture
the entire output?
Thanks,
Zwane
-
101 - 200 of 335 matches
Mail list logo
