On Tue, 5 Apr 2005, shaun wrote:
> +Hardware Specs
> Dual Xeon 800FSB
> Intel Server Board
> 4GB ECC DDR
> 3ware 9500 Sata Raid Card
> 5x200 GB sata drives in a raid 10 Config (1 hot spare)
> Dual Nic
>
> +OS Specs
> CentOS 3.4 running a custom 2.6.x kernel patched with UML SKA's Patch
> eth0 is
On Tue, 5 Apr 2005, shaun wrote:
+Hardware Specs
Dual Xeon 800FSB
Intel Server Board
4GB ECC DDR
3ware 9500 Sata Raid Card
5x200 GB sata drives in a raid 10 Config (1 hot spare)
Dual Nic
+OS Specs
CentOS 3.4 running a custom 2.6.x kernel patched with UML SKA's Patch
eth0 is 0.0.0.0
On Tue, 5 Apr 2005, Li Shaohua wrote:
> On Tue, 2005-04-05 at 03:10, Zwane Mwaikambo wrote:
> > On Mon, 4 Apr 2005, Li Shaohua wrote:
> >
> > > linux-2.6.11-root/arch/i386/kernel/smpboot.c |6 ++
> > > linux-2.6.11-root/arch/i386/
On Tue, 5 Apr 2005, Esben Nielsen wrote:
> > I'm sure a lot of the yield() users could be converted to
> > schedule_timeout(), some of the users i saw were for low memory conditions
> > where we want other tasks to make progress and complete so that we a bit
> > more free memory.
> >
>
>
On Tue, 5 Apr 2005, Esben Nielsen wrote:
I'm sure a lot of the yield() users could be converted to
schedule_timeout(), some of the users i saw were for low memory conditions
where we want other tasks to make progress and complete so that we a bit
more free memory.
Easy, but damn
On Tue, 5 Apr 2005, Li Shaohua wrote:
On Tue, 2005-04-05 at 03:10, Zwane Mwaikambo wrote:
On Mon, 4 Apr 2005, Li Shaohua wrote:
linux-2.6.11-root/arch/i386/kernel/smpboot.c |6 ++
linux-2.6.11-root/arch/i386/kernel/sysenter.c | 10 ++
linux
On Mon, 4 Apr 2005, Steven Rostedt wrote:
> On Mon, 2005-04-04 at 22:47 +0200, Ingo Molnar wrote:
>
> > > Currently my fix is in yield to lower the priority of the task calling
> > > yield and raise it after the schedule. This is NOT a proper fix. It's
> > > just a hack so I can get by it and
On Mon, 28 Mar 2005, Jesper Juhl wrote:
> On Sun, 27 Mar 2005, Zwane Mwaikambo wrote:
>
> > On Sun, 27 Mar 2005, Jesper Juhl wrote:
> >
> > > I've now been running kernels (both PREEMPT, SMP, both and without both)
> > > with the patch below applied for a fe
Hi Pavel!
On Mon, 4 Apr 2005, Pavel Machek wrote:
> > > > The patches are against 2.6.11-rc1 with Zwane's CPU hotplug patch in -mm
> > > > tree.
> > >
> > > Should I merge that thing into mainline? It seems that a few people are
> > > needing it.
> >
> > Perhaps we should address the MTRR
On Mon, 4 Apr 2005, Li Shaohua wrote:
> Clean up all CPU states including its runqueue and idle thread,
> so we can use boot time code without any changes.
> Note this makes /sys/devices/system/cpu/cpux/online unworkable.
>
> #ifdef CONFIG_HOTPLUG_CPU
> #include
> +
> +#ifdef CONFIG_STR_SMP
On Mon, 4 Apr 2005, Li Shaohua wrote:
> linux-2.6.11-root/arch/i386/kernel/smpboot.c |6 ++
> linux-2.6.11-root/arch/i386/kernel/sysenter.c | 10 ++
> linux-2.6.11-root/arch/i386/mach-voyager/voyager_smp.c |6 ++
> 3 files changed, 18 insertions(+), 4
On Mon, 4 Apr 2005, Li Shaohua wrote:
Clean up all CPU states including its runqueue and idle thread,
so we can use boot time code without any changes.
Note this makes /sys/devices/system/cpu/cpux/online unworkable.
#ifdef CONFIG_HOTPLUG_CPU
#include asm/nmi.h
+
+#ifdef
Hi Pavel!
On Mon, 4 Apr 2005, Pavel Machek wrote:
The patches are against 2.6.11-rc1 with Zwane's CPU hotplug patch in -mm
tree.
Should I merge that thing into mainline? It seems that a few people are
needing it.
Perhaps we should address the MTRR issue first.
I've
On Mon, 28 Mar 2005, Jesper Juhl wrote:
On Sun, 27 Mar 2005, Zwane Mwaikambo wrote:
On Sun, 27 Mar 2005, Jesper Juhl wrote:
I've now been running kernels (both PREEMPT, SMP, both and without both)
with the patch below applied for a few days and I see no ill effects. I'm
still
On Mon, 4 Apr 2005, Steven Rostedt wrote:
On Mon, 2005-04-04 at 22:47 +0200, Ingo Molnar wrote:
Currently my fix is in yield to lower the priority of the task calling
yield and raise it after the schedule. This is NOT a proper fix. It's
just a hack so I can get by it and test other
On Wed, 30 Mar 2005, Pavel Machek wrote:
> Hi!
>
> > > This is against -mm kernel; it is smp swsusp done right, and it
> > > actually works for me. Unlike previous hacks, it uses cpu hotplug
> > > infrastructure. Disable CONFIG_MTRR before you try this...
> > >
> > > Test this if you can, and
On Wed, 23 Mar 2005, Pavel Machek wrote:
> This is against -mm kernel; it is smp swsusp done right, and it
> actually works for me. Unlike previous hacks, it uses cpu hotplug
> infrastructure. Disable CONFIG_MTRR before you try this...
>
> Test this if you can, and report any problems. If not
On Wed, 23 Mar 2005, Pavel Machek wrote:
This is against -mm kernel; it is smp swsusp done right, and it
actually works for me. Unlike previous hacks, it uses cpu hotplug
infrastructure. Disable CONFIG_MTRR before you try this...
Test this if you can, and report any problems. If not enough
On Wed, 30 Mar 2005, Pavel Machek wrote:
Hi!
This is against -mm kernel; it is smp swsusp done right, and it
actually works for me. Unlike previous hacks, it uses cpu hotplug
infrastructure. Disable CONFIG_MTRR before you try this...
Test this if you can, and report any
On Sun, 27 Mar 2005, Jesper Juhl wrote:
> I've now been running kernels (both PREEMPT, SMP, both and without both)
> with the patch below applied for a few days and I see no ill effects. I'm
> still interrested in comments about wether or not something like this
> makes sense and is acceptable
On Sun, 27 Mar 2005, Jesper Juhl wrote:
I've now been running kernels (both PREEMPT, SMP, both and without both)
with the patch below applied for a few days and I see no ill effects. I'm
still interrested in comments about wether or not something like this
makes sense and is acceptable ?
On Wed, 16 Mar 2005, Nathan Lynch wrote:
> On Wed, Mar 16, 2005 at 02:21:52PM +0100, Pavel Machek wrote:
>
> > I tried to solve long-standing uglyness in swsusp cmp code by calling
> > cpu hotplug... only to find out that CONFIG_CPU_HOTPLUG is not
> > available on i386. Is there way to enable
On Wed, 16 Mar 2005, Nathan Lynch wrote:
On Wed, Mar 16, 2005 at 02:21:52PM +0100, Pavel Machek wrote:
I tried to solve long-standing uglyness in swsusp cmp code by calling
cpu hotplug... only to find out that CONFIG_CPU_HOTPLUG is not
available on i386. Is there way to enable CPU_HOTPLUG
Hi Bjorn,
On Tue, 15 Mar 2005, Bjorn Helgaas wrote:
> That seems awfully suspicious to me. So the following is
> probably safe as far as it goes, but not sufficient for all
> cases.
VIA bridges allow for IRQ routing updates by programming
PCI_INTERRUPT_LINE, so it is supposed to work even if
On Tue, 15 Mar 2005, J. Bruce Fields wrote:
> On Sat, Mar 12, 2005 at 08:21:29AM -0700, Zwane Mwaikambo wrote:
> > On Sat, 12 Mar 2005, J. Bruce Fields wrote:
> >
> > > On APM resume this morning on my Thinkpad X31, I got a "spin_lock is
> > > already l
On Tue, 15 Mar 2005, J. Bruce Fields wrote:
On Sat, Mar 12, 2005 at 08:21:29AM -0700, Zwane Mwaikambo wrote:
On Sat, 12 Mar 2005, J. Bruce Fields wrote:
On APM resume this morning on my Thinkpad X31, I got a spin_lock is
already locked error; see below. This doesn't happen on every
Hi Bjorn,
On Tue, 15 Mar 2005, Bjorn Helgaas wrote:
That seems awfully suspicious to me. So the following is
probably safe as far as it goes, but not sufficient for all
cases.
VIA bridges allow for IRQ routing updates by programming
PCI_INTERRUPT_LINE, so it is supposed to work even if we
On Sat, 12 Mar 2005, George Anzinger wrote:
> I agree. Still in all that follows, no one has addressed the apparent race
> described above. The reason the system reported the errors that started this
> thread is that the APM restore code was trying to read the cmos clock (I
> assume to set the
On Sat, 12 Mar 2005, Jon Smirl wrote:
> On Fri, 11 Mar 2005 14:36:10 +1100, Peter Chubb
> <[EMAIL PROTECTED]> wrote:
> >
> > As many of you will be aware, we've been working on infrastructure for
> > user-mode PCI and other drivers. The first step is to be able to
> > handle interrupts from
On Wed, 9 Mar 2005, Francesco Oppedisano wrote:
> On Tue, 8 Mar 2005 12:09:58 -0700 (MST), Zwane Mwaikambo
> <[EMAIL PROTECTED]> wrote:
>
> > At some cpu frequency point on i386 the main cause of your interrupt
> > service latency will be in the interrupt contr
On Sat, 12 Mar 2005, Venkatesh Pallipadi wrote:
> On Sat, Mar 12, 2005 at 09:25:13AM -0700, Zwane Mwaikambo wrote:
> > On Sat, 12 Mar 2005, George Anzinger wrote:
> >
> > > And more... That this occures implies we are attempting to update the cmos
> > > clock
On Sat, 12 Mar 2005, George Anzinger wrote:
> Looks like we need the irq on the read clock also. This is true both before
> and after the prior cmos_time changes.
>
> The attached replaces the patch I sent yesterday.
>
> For those wanting to fix the kernel with out those patches, all that is
e acquired with interrupts
disabled).
Signed-off-by: Zwane Mwaikambo <[EMAIL PROTECTED]>
= arch/i386/kernel/apm.c 1.72 vs edited =
--- 1.72/arch/i386/kernel/apm.c 2005-01-20 22:02:11 -07:00
+++ edited/arch/i386/kernel/apm.c 2005-03-12 08:17:52 -07:00
@@ -1202,10 +1202,1
:
spin_unlock(arch/i386/kernel/time.c:c0603c28) not locked
APM was calling device_power_down and device_power_up with interrupts
enabled, resulting in a few calls to get_cmos_time being done with
interrupts enabled (rtc_lock needs to be acquired with interrupts
disabled).
Signed-off-by: Zwane
On Sat, 12 Mar 2005, George Anzinger wrote:
Looks like we need the irq on the read clock also. This is true both before
and after the prior cmos_time changes.
The attached replaces the patch I sent yesterday.
For those wanting to fix the kernel with out those patches, all that is needed
On Sat, 12 Mar 2005, Venkatesh Pallipadi wrote:
On Sat, Mar 12, 2005 at 09:25:13AM -0700, Zwane Mwaikambo wrote:
On Sat, 12 Mar 2005, George Anzinger wrote:
And more... That this occures implies we are attempting to update the cmos
clock on resume seems wrong. One would presume
On Wed, 9 Mar 2005, Francesco Oppedisano wrote:
On Tue, 8 Mar 2005 12:09:58 -0700 (MST), Zwane Mwaikambo
[EMAIL PROTECTED] wrote:
At some cpu frequency point on i386 the main cause of your interrupt
service latency will be in the interrupt controller and how long from irq
assertion
On Sat, 12 Mar 2005, Jon Smirl wrote:
On Fri, 11 Mar 2005 14:36:10 +1100, Peter Chubb
[EMAIL PROTECTED] wrote:
As many of you will be aware, we've been working on infrastructure for
user-mode PCI and other drivers. The first step is to be able to
handle interrupts from user space.
On Sat, 12 Mar 2005, George Anzinger wrote:
I agree. Still in all that follows, no one has addressed the apparent race
described above. The reason the system reported the errors that started this
thread is that the APM restore code was trying to read the cmos clock (I
assume to set the
ice)
> {
> /* According to Nvidia all timer overrides are bogus. Just ignore
Thanks Chris
Acked-by: Zwane Mwaikambo <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordom
On Thu, 10 Mar 2005, Andi Kleen wrote:
> Zwane Mwaikambo <[EMAIL PROTECTED]> writes:
>
> > Andi noted that during normal runtime cpu_idle_map is bounced around a
> > lot, and occassionally at a higher frequency than the timer interrupt
> > wakeup which we normall
On Thu, 10 Mar 2005, Andi Kleen wrote:
Zwane Mwaikambo [EMAIL PROTECTED] writes:
Andi noted that during normal runtime cpu_idle_map is bounced around a
lot, and occassionally at a higher frequency than the timer interrupt
wakeup which we normally exit pm_idle from. So switch
timer overrides are bogus. Just ignore
Thanks Chris
Acked-by: Zwane Mwaikambo [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read
changed, 70 insertions(+), 35 deletions(-)
Signed-off-by: Zwane Mwaikambo <[EMAIL PROTECTED]>
Index: linux-2.6.11-mm2/arch/i386/kernel/process.c
===
RCS file: /home/cvsroot/linux-2.6.11-mm2/arch/i386/kernel/process.c,v
retr
On Wed, 9 Mar 2005, linux-os wrote:
> We need to retain the spin_lock_init() because not all spin-locks
> are allocated at compile-time. They might be allocated from kmalloc()
> on startup, probably in a structure, along with other so-called
> global data.
Not to worry my good man, it's not
On Wed, 9 Mar 2005, linux-os wrote:
We need to retain the spin_lock_init(lock) because not all spin-locks
are allocated at compile-time. They might be allocated from kmalloc()
on startup, probably in a structure, along with other so-called
global data.
Not to worry my good man, it's not
changed, 70 insertions(+), 35 deletions(-)
Signed-off-by: Zwane Mwaikambo [EMAIL PROTECTED]
Index: linux-2.6.11-mm2/arch/i386/kernel/process.c
===
RCS file: /home/cvsroot/linux-2.6.11-mm2/arch/i386/kernel/process.c,v
retrieving
Hi Francesco,
On Tue, 8 Mar 2005, Francesco Oppedisano wrote:
> i'm trying to estimate the interrupt latency (time between hardware
> interrrupt and the start of the ISR) of a linux kernel 2.4.29 and i used
> a simple tecnique: inside the do_timer_interrupt i read the 8259 counter
> to obtain
On Wed, 9 Mar 2005, Coywolf Qi Hunt wrote:
> On Tue, 08 Mar 2005 12:28:42 -0500, Robert Love <[EMAIL PROTECTED]> wrote:
> > On Tue, 2005-03-08 at 22:57 +0530, Imanpreet Arora wrote:
> >
> > > This has been a doubt for a couple of days, and I am wondering if this
> > > one could also be cleared.
On Wed, 9 Mar 2005, Coywolf Qi Hunt wrote:
On Tue, 08 Mar 2005 12:28:42 -0500, Robert Love [EMAIL PROTECTED] wrote:
On Tue, 2005-03-08 at 22:57 +0530, Imanpreet Arora wrote:
This has been a doubt for a couple of days, and I am wondering if this
one could also be cleared. When you say
Hi Francesco,
On Tue, 8 Mar 2005, Francesco Oppedisano wrote:
i'm trying to estimate the interrupt latency (time between hardware
interrrupt and the start of the ISR) of a linux kernel 2.4.29 and i used
a simple tecnique: inside the do_timer_interrupt i read the 8259 counter
to obtain the
On Thu, 3 Mar 2005, Neil Brown wrote:
> On Wednesday March 2, [EMAIL PROTECTED] wrote:
> > A Linus based odd number
> > might be closer to that if we hope on people unwittingly running them.
>
On Thu, 3 Mar 2005, Neil Brown wrote:
On Wednesday March 2, [EMAIL PROTECTED] wrote:
A Linus based odd number
might be closer to that if we hope on people unwittingly running them.
^^^
On Wed, 2 Mar 2005, Lars Marowsky-Bree wrote:
> On 2005-03-02T14:21:38, Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
> > We'd still do the -rcX candidates as we go along in either case, so as a
> > user you wouldn't even _need_ to know, but the numbering would be a rough
> > guide to
On Wed, 2 Mar 2005, Jeff V. Merkey wrote:
> __Stable__ would be a good thing. The entire 2.6 development has been a
> disaster from a stability viewpoint. I have to maintain a huge tree of
> patches in order to ship appliance builds due to the lack of stability
> for 2.6. I think that the even
On Wed, 2 Mar 2005, Jeff V. Merkey wrote:
__Stable__ would be a good thing. The entire 2.6 development has been a
disaster from a stability viewpoint. I have to maintain a huge tree of
patches in order to ship appliance builds due to the lack of stability
for 2.6. I think that the even
On Wed, 2 Mar 2005, Lars Marowsky-Bree wrote:
On 2005-03-02T14:21:38, Linus Torvalds [EMAIL PROTECTED] wrote:
We'd still do the -rcX candidates as we go along in either case, so as a
user you wouldn't even _need_ to know, but the numbering would be a rough
guide to intentions. Ie I'd
On Tue, 1 Mar 2005, Nathan Lynch wrote:
> On Sun, Feb 27, 2005 at 02:49:28PM -0800, Andrew Morton wrote:
> > Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
> > >
> > > > - if (cpu_is_offline(smp_processor_id()) &&
> > > > + if (cpu_is_offline(_smp_processor_id()) &&
On Tue, 1 Mar 2005, Nathan Lynch wrote:
On Sun, Feb 27, 2005 at 02:49:28PM -0800, Andrew Morton wrote:
Benjamin Herrenschmidt [EMAIL PROTECTED] wrote:
- if (cpu_is_offline(smp_processor_id())
+ if (cpu_is_offline(_smp_processor_id())
Per our discussion, i've ported the 2.6 nforce skip timer override (and
early PCI access) code to 2.4. This fixes an issue whereupon nforce
systems have incorrect override values for irq0. Architectures affected
are i386 and x86_64
Signed-off-by: Zwane Mwaikambo <[EMAIL PROTEC
Per our discussion, i've ported the 2.6 nforce skip timer override (and
early PCI access) code to 2.4. This fixes an issue whereupon nforce
systems have incorrect override values for irq0. Architectures affected
are i386 and x86_64
Signed-off-by: Zwane Mwaikambo [EMAIL PROTECTED
On Thu, 17 Feb 2005, Joshua Kwan wrote:
> Zwane Mwaikambo wrote:
> > Check that the hostap interrupt handler is 2.6 aware (IRQ_HANDLED etc)
>
> It shows up even before the hostap module is loaded (and in fact appears
> to stop showing up when that happens.) Here's the fu
On Tue, 15 Feb 2005, Joseph Cosby wrote:
> Hi,
> Using VMWare 4 with a 2.6.9 kernel I get "IO-APIC + timer doesn't work!" As
> suggested, the noapic option fixes the problem. This resulted after adding
> APIC support to my kernel. My problem is, I need APIC support to boot on a
> separate,
On Thu, 17 Feb 2005, Zwane Mwaikambo wrote:
> On Thu, 17 Feb 2005, Davide Rossetti wrote:
>
> > maybe RTFM...
> > a module:
> > - char device driver for..
> > - a PCI device
> >
> > any clue as to how to protect from module unloading while there is stil
On Thu, 17 Feb 2005, Davide Rossetti wrote:
> maybe RTFM...
> a module:
> - char device driver for..
> - a PCI device
>
> any clue as to how to protect from module unloading while there is still some
> process opening it??? have I to sleep in the remove_one() pci driver function
> till last
On Wed, 16 Feb 2005, Joshua Kwan wrote:
>CPU0
> 0:1073809 XT-PIC timer
> 1: 1291 XT-PIC i8042
> 2: 0 XT-PIC cascade
> 4: 7 XT-PIC serial
> 5: 4366 XT-PIC eth0
> 7: 12
On Wed, 16 Feb 2005, Joshua Kwan wrote:
CPU0
0:1073809 XT-PIC timer
1: 1291 XT-PIC i8042
2: 0 XT-PIC cascade
4: 7 XT-PIC serial
5: 4366 XT-PIC eth0
7: 12 XT-PIC
On Thu, 17 Feb 2005, Davide Rossetti wrote:
maybe RTFM...
a module:
- char device driver for..
- a PCI device
any clue as to how to protect from module unloading while there is still some
process opening it??? have I to sleep in the remove_one() pci driver function
till last process
On Thu, 17 Feb 2005, Zwane Mwaikambo wrote:
On Thu, 17 Feb 2005, Davide Rossetti wrote:
maybe RTFM...
a module:
- char device driver for..
- a PCI device
any clue as to how to protect from module unloading while there is still
some
process opening it??? have I to sleep
On Tue, 15 Feb 2005, Joseph Cosby wrote:
Hi,
Using VMWare 4 with a 2.6.9 kernel I get IO-APIC + timer doesn't work! As
suggested, the noapic option fixes the problem. This resulted after adding
APIC support to my kernel. My problem is, I need APIC support to boot on a
separate, non-VMWare
On Thu, 17 Feb 2005, Joshua Kwan wrote:
Zwane Mwaikambo wrote:
Check that the hostap interrupt handler is 2.6 aware (IRQ_HANDLED etc)
It shows up even before the hostap module is loaded (and in fact appears
to stop showing up when that happens.) Here's the full output of dmesg
On Tue, 15 Feb 2005, Andrew Morton wrote:
> Zwane Mwaikambo <[EMAIL PROTECTED]> wrote:
> >
> > Ensure that we only offline the processor when it's safe and never run
> > softirqs in another processor's ksoftirqd context. This also gets rid of
> > the war
Ensure that we only offline the processor when it's safe and never run
softirqs in another processor's ksoftirqd context. This also gets rid of
the warnings in ksoftirqd on cpu offline.
Signed-off-by: Zwane Mwaikambo <[EMAIL PROTECTED]>
Index: linux-2.6.11-rc3-mm2/kernel/sof
On Mon, 14 Feb 2005, Nathan Lynch wrote:
> It looks as if we need to explicitly bind worker threads to a newly
> onlined cpu. This gets rid of the smp_processor_id warnings from
> cache_reap. Adding a little more instrumentation to the debug
> smp_processor_id showed that new worker threads
On Mon, 14 Feb 2005, Nathan Lynch wrote:
It looks as if we need to explicitly bind worker threads to a newly
onlined cpu. This gets rid of the smp_processor_id warnings from
cache_reap. Adding a little more instrumentation to the debug
smp_processor_id showed that new worker threads were
Ensure that we only offline the processor when it's safe and never run
softirqs in another processor's ksoftirqd context. This also gets rid of
the warnings in ksoftirqd on cpu offline.
Signed-off-by: Zwane Mwaikambo [EMAIL PROTECTED]
Index: linux-2.6.11-rc3-mm2/kernel/softirq.c
On Tue, 15 Feb 2005, Andrew Morton wrote:
Zwane Mwaikambo [EMAIL PROTECTED] wrote:
Ensure that we only offline the processor when it's safe and never run
softirqs in another processor's ksoftirqd context. This also gets rid of
the warnings in ksoftirqd on cpu offline.
I don't get
On Fri, 11 Feb 2005, Nathan Lynch wrote:
> With 2.6.11-rc3-bk7 on ppc64 I am seeing lots of smp_processor_id
> warnings whenever I hotplug cpus:
>
> # echo 0 > /sys/devices/system/cpu/cpu1/online
> cpu 1 (hwid 1) Ready to die...
> BUG: using smp_processor_id() in preemptible [0001] code:
>
On Fri, 11 Feb 2005, Nathan Lynch wrote:
With 2.6.11-rc3-bk7 on ppc64 I am seeing lots of smp_processor_id
warnings whenever I hotplug cpus:
# echo 0 /sys/devices/system/cpu/cpu1/online
cpu 1 (hwid 1) Ready to die...
BUG: using smp_processor_id() in preemptible [0001] code:
management support.
Signed-off-by: Zwane Mwaikambo <[EMAIL PROTECTED]>
= arch/arm/oprofile/op_arm_model.h 1.1 vs edited =
--- 1.1/arch/arm/oprofile/op_arm_model.h2004-04-12 11:55:34 -06:00
+++ edited/arch/arm/oprofile/op_arm_model.h 2005-02-08 23:02:20 -07:00
@@ -24,6
management support.
Signed-off-by: Zwane Mwaikambo [EMAIL PROTECTED]
= arch/arm/oprofile/op_arm_model.h 1.1 vs edited =
--- 1.1/arch/arm/oprofile/op_arm_model.h2004-04-12 11:55:34 -06:00
+++ edited/arch/arm/oprofile/op_arm_model.h 2005-02-08 23:02:20 -07:00
@@ -24,6 +24,6
oprofile_arch_exit
oprofile_arch_init()
oprofile_arch_exit()
__exit nmi_exit()
__exit exit_driverfs()
Signed-off-by: Zwane Mwaikambo <[EMAIL PROTECTED]>
= arch/i386/oprofile/nmi_int.c 1.27 vs edited =
--- 1.27/arch/i386/oprofile/nmi
On Wed, 9 Feb 2005, Marcos D. Marado Torres wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Fri, 4 Feb 2005, Andrew Morton wrote:
>
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc3/2.6.11-rc3-mm1/
>
> Andrew,
>
> Please add to -mm the patch in
On Wed, 9 Feb 2005, Marcos D. Marado Torres wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 4 Feb 2005, Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc3/2.6.11-rc3-mm1/
Andrew,
Please add to -mm the patch in attachment,
oprofile_arch_exit
oprofile_arch_init()
error path
oprofile_arch_exit()
__exit nmi_exit()
__exit exit_driverfs()
Signed-off-by: Zwane Mwaikambo [EMAIL PROTECTED]
= arch/i386/oprofile/nmi_int.c 1.27 vs edited =
--- 1.27/arch/i386/oprofile
On Fri, 4 Feb 2005, Tony Lindgren wrote:
> Yes, it's safer to keep the timer periodic, although it's
> used for oneshot purposes for the skips. If the timer interrupt
> got missed for some reason, the system would be able to recover when
> it's in periodic mode.
>
> And with some timers, we can
On Fri, 4 Feb 2005, Tony Lindgren wrote:
> * Zwane Mwaikambo <[EMAIL PROTECTED]> [050204 09:31]:
> > On Fri, 4 Feb 2005, Tony Lindgren wrote:
> >
> > > Yes, it's safer to keep the timer periodic, although it's
> > > used for oneshot purposes for the skips.
On Fri, 4 Feb 2005, Tony Lindgren wrote:
* Zwane Mwaikambo [EMAIL PROTECTED] [050204 09:31]:
On Fri, 4 Feb 2005, Tony Lindgren wrote:
Yes, it's safer to keep the timer periodic, although it's
used for oneshot purposes for the skips. If the timer interrupt
got missed for some reason
On Fri, 4 Feb 2005, Tony Lindgren wrote:
Yes, it's safer to keep the timer periodic, although it's
used for oneshot purposes for the skips. If the timer interrupt
got missed for some reason, the system would be able to recover when
it's in periodic mode.
And with some timers, we can do the
On Thu, 3 Feb 2005, Tony Lindgren wrote:
> > > > It could also be that the reprogamming of PIT timer does not work on
> > > > your machine. I chopped off the udelays there... Can you try
> > > > something like this:
> > >
> > > I added the udelays, but behaviour did not change.
> >
> > Yeah,
On Thu, 3 Feb 2005, Tony Lindgren wrote:
It could also be that the reprogamming of PIT timer does not work on
your machine. I chopped off the udelays there... Can you try
something like this:
I added the udelays, but behaviour did not change.
Yeah, and if the first patch
(-)
Signed-off-by: Zwane Mwaikambo <[EMAIL PROTECTED]>
Index: linux-2.6.11-rc2-mm2-ppc64/arch/ppc64/Kconfig
===
RCS file: /home/cvsroot/linux-2.6.11-rc2-mm2/arch/ppc64/Kconfig,v
retrieving revision 1.1.1.1
diff -u -p -B -r1.1.1.1 K
(-)
Signed-off-by: Zwane Mwaikambo [EMAIL PROTECTED]
Index: linux-2.6.11-rc2-mm2-ppc64/arch/ppc64/Kconfig
===
RCS file: /home/cvsroot/linux-2.6.11-rc2-mm2/arch/ppc64/Kconfig,v
retrieving revision 1.1.1.1
diff -u -p -B -r1.1.1.1 Kconfig
On Sat, 29 Jan 2005, John Levon wrote:
> Looks like you're still on the broken bkcvs, which is missing this
> patch:
>
> http://linus.bkbits.net:8080/linux-2.5/[EMAIL PROTECTED]|[EMAIL PROTECTED]
>
> which AFAICS is the correct solution to the problem.
Hmm i was actually using BK and not BKCVS
On Sat, 29 Jan 2005, John Levon wrote:
> On Fri, Jan 28, 2005 at 12:06:19PM -0700, Zwane Mwaikambo wrote:
>
> > = drivers/oprofile/oprofile_files.c 1.7 vs edited =
> > --- 1.7/drivers/oprofile/oprofile_files.c 2005-01-04 19:48:23 -07:00
> > +++ edited/drivers/o
On Sat, 29 Jan 2005, John Levon wrote:
On Fri, Jan 28, 2005 at 12:06:19PM -0700, Zwane Mwaikambo wrote:
= drivers/oprofile/oprofile_files.c 1.7 vs edited =
--- 1.7/drivers/oprofile/oprofile_files.c 2005-01-04 19:48:23 -07:00
+++ edited/drivers/oprofile/oprofile_files.c
On Sat, 29 Jan 2005, John Levon wrote:
Looks like you're still on the broken bkcvs, which is missing this
patch:
http://linus.bkbits.net:8080/linux-2.5/[EMAIL PROTECTED]|[EMAIL PROTECTED]
which AFAICS is the correct solution to the problem.
Hmm i was actually using BK and not BKCVS and
We should be using profile_pc in oprofile_add_sample so that lock
contention is attibuted to the correct function in profile output. Also
fix SH7750 support.
Signed-off-by: Zwane Mwaikambo <[EMAIL PROTECTED]>
= drivers/oprofile/cpu_buffer.c 1.17 vs edited =
--- 1.17/drivers/op
GLOBAL_POWER_EVENTS events (time during which processor is not
stopped) with a unit mask of 0x01 (count cycles when processor is active)
count 1
Signed-off-by: Zwane Mwaikambo <[EMAIL PROTECTED]>
= arch/i386/oprofile/nmi_int.c 1.26 vs edited =
--- 1.26/arch/i386/oprofile/nmi_int.c 2005-01
ff
ff ff ff 89 75 f8 89 ce 89 d1 89 7d fc 89 c7 89 04 24 89 d8 ae f7 d1
49 89 4c 24 04 8b 45 f0 89 f2 8b 4d 08 e8 66 e4 c1
->cpu_type is NULL since p4_init skipped this specific processor.
Signed-off-by: Zwane Mwaikambo <[EMAIL PROTECTED]>
= drivers/oprofile/oprofile_files.c 1.7
201 - 300 of 335 matches
Mail list logo
