On Fri, 28 Jan 2005, Andi Kleen wrote:
> > Forgive me for not wading through the code, but it really needs to
> > be spelt out in the comments: what's wrong with the existing kernel,
> > with "noapic nolapic" in the distro's bootstring by default?
>
> It's harder to explain and traditionally in
On Fri, 28 Jan 2005, Andi Kleen wrote:
Forgive me for not wading through the code, but it really needs to
be spelt out in the comments: what's wrong with the existing kernel,
with noapic nolapic in the distro's bootstring by default?
It's harder to explain and traditionally in LILO you
Code: 90 90 90 90 90 90 90 55 89 e5 83 ec 18 89 5d f4 31 db 89 55 f0 ba ff
ff ff ff 89 75 f8 89 ce 89 d1 89 7d fc 89 c7 89 04 24 89 d8 f2 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
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-07 22:44
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/oprofile
On Tue, 25 Jan 2005, Matt Mackall wrote:
> On Mon, Jan 24, 2005 at 09:36:37PM -0700, Zwane Mwaikambo wrote:
> > I'm having trouble booting here, were those random-* patches tested?
> >
> > EIP is at __add_entropy_words+0xc5/0x1c0
> > eax: 002d ebx: 000f ec
On Tue, 25 Jan 2005, Andrew Morton wrote:
> OK, thanks. I get what appears to be a use-after-free error.
> CONFIG_DEBUG_PAGEALLOC is set:
>
> Program received signal SIGEMT, Emulation trap.
> 0xc0272bc2 in kbd_keycode (keycode=57, down=1, hw_raw=0, regs=0xc0673f9c)
> at
On Tue, 25 Jan 2005, Andrew Morton wrote:
OK, thanks. I get what appears to be a use-after-free error.
CONFIG_DEBUG_PAGEALLOC is set:
Program received signal SIGEMT, Emulation trap.
0xc0272bc2 in kbd_keycode (keycode=57, down=1, hw_raw=0, regs=0xc0673f9c)
at
On Tue, 25 Jan 2005, Matt Mackall wrote:
On Mon, Jan 24, 2005 at 09:36:37PM -0700, Zwane Mwaikambo wrote:
I'm having trouble booting here, were those random-* patches tested?
EIP is at __add_entropy_words+0xc5/0x1c0
eax: 002d ebx: 000f ecx: 007b edx: f5e5
esi
On Mon, 24 Jan 2005, Andrew Morton wrote:
> I can't reproduce it from a quick test here. I'd assume that the keystroke
> came in before the vt's workqueue is initialised. fn_enter() calls
> put_queue() calls con_schedule_flip() calls schedule_work() which goes BUG:
Boot into runlevel 1
On Mon, 24 Jan 2005, Matt Mackall wrote:
> On Mon, Jan 24, 2005 at 09:36:37PM -0700, Zwane Mwaikambo wrote:
> > I'm having trouble booting here, were those random-* patches tested?
>
> Works here, can you send me a copy of your init script?
#!/bin/bash
#
# randomScr
I pressed a key on a VT during boot and got the following;
usb-storage: device scan complete
[ cut here ]
kernel BUG at kernel/workqueue.c:104!
invalid operand: [#1]
PREEMPT SMP DEBUG_PAGEALLOC
Modules linked in:
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS:
I'm having trouble booting here, were those random-* patches tested?
Initializing random number generator: [ OK ]
Unable to handle kernel paging request at virtual address f5e5
printing eip:
c037a0a5
*pde = 0086e067
Oops: [#1]
PREEMPT SMP DEBUG_PAGEALLOC
Modules linked in:
CPU:0
I'm having trouble booting here, were those random-* patches tested?
Initializing random number generator: [ OK ]
Unable to handle kernel paging request at virtual address f5e5
printing eip:
c037a0a5
*pde = 0086e067
Oops: [#1]
PREEMPT SMP DEBUG_PAGEALLOC
Modules linked in:
CPU:0
I pressed a key on a VT during boot and got the following;
usb-storage: device scan complete
[ cut here ]
kernel BUG at kernel/workqueue.c:104!
invalid operand: [#1]
PREEMPT SMP DEBUG_PAGEALLOC
Modules linked in:
CPU:0
EIP:0060:[c01314af]Not tainted VLI
On Mon, 24 Jan 2005, Matt Mackall wrote:
On Mon, Jan 24, 2005 at 09:36:37PM -0700, Zwane Mwaikambo wrote:
I'm having trouble booting here, were those random-* patches tested?
Works here, can you send me a copy of your init script?
#!/bin/bash
#
# randomScript to snapshot random
On Mon, 24 Jan 2005, Andrew Morton wrote:
I can't reproduce it from a quick test here. I'd assume that the keystroke
came in before the vt's workqueue is initialised. fn_enter() calls
put_queue() calls con_schedule_flip() calls schedule_work() which goes BUG:
Boot into runlevel 1 (console
On Thu, 20 Jan 2005, John Levon wrote:
> On Thu, Jan 20, 2005 at 12:16:52PM -0700, Zwane Mwaikambo wrote:
>
> > > I haven't found any modular usage of profile_pc in the kernel.
> >
> > Oprofile?
>
> We don't actually use it, but it looks like maybe
Hello George,
On Fri, 21 Jan 2005, George Anzinger wrote:
> The VST patch on sourceforge
> (http://sourceforge.net/projects/high-res-timers/) uses the local apic timer
> to do the wake up. This is the same timer that is used for the High Res work.
I've been meaning to look into it, although
On Fri, 21 Jan 2005, Pavel Machek wrote:
> > > > This doesn't seem to cover the local APIC timer, what do you do about
> > > > the
> > > > 1kHz tick which it's programmed to do?
> > >
> > > Sorry for the delay in replaying. Thanks for pointing that out, I
> > > don't know yet what to do with
On Fri, 21 Jan 2005, Tony Lindgren wrote:
> > This doesn't seem to cover the local APIC timer, what do you do about the
> > 1kHz tick which it's programmed to do?
>
> Sorry for the delay in replaying. Thanks for pointing that out, I
> don't know yet what to do with the local APIC timer. Have to
On Fri, 21 Jan 2005, Tony Lindgren wrote:
This doesn't seem to cover the local APIC timer, what do you do about the
1kHz tick which it's programmed to do?
Sorry for the delay in replaying. Thanks for pointing that out, I
don't know yet what to do with the local APIC timer. Have to look
On Fri, 21 Jan 2005, Pavel Machek wrote:
This doesn't seem to cover the local APIC timer, what do you do about
the
1kHz tick which it's programmed to do?
Sorry for the delay in replaying. Thanks for pointing that out, I
don't know yet what to do with the local APIC timer.
Hello George,
On Fri, 21 Jan 2005, George Anzinger wrote:
The VST patch on sourceforge
(http://sourceforge.net/projects/high-res-timers/) uses the local apic timer
to do the wake up. This is the same timer that is used for the High Res work.
I've been meaning to look into it, although it's
On Thu, 20 Jan 2005, John Levon wrote:
On Thu, Jan 20, 2005 at 12:16:52PM -0700, Zwane Mwaikambo wrote:
I haven't found any modular usage of profile_pc in the kernel.
Oprofile?
We don't actually use it, but it looks like maybe we should? It seems
unfortunate that readprofile
On Thu, 20 Jan 2005, Adrian Bunk wrote:
> I haven't found any modular usage of profile_pc in the kernel.
>
> Is the patch below correct?
Oprofile?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Thu, 20 Jan 2005, Adrian Bunk wrote:
I haven't found any modular usage of profile_pc in the kernel.
Is the patch below correct?
Oprofile?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Tue, 18 Jan 2005, Tony Lindgren wrote:
> Hi all,
>
> Attached is the dynamic tick patch for x86 to play with
> as I promised in few threads earlier on this list.[1][2]
>
> The dynamic tick patch does following:
>
> - Separates timer interrupts from updating system time
>
> - Allows
On Tue, 18 Jan 2005, Tony Lindgren wrote:
Hi all,
Attached is the dynamic tick patch for x86 to play with
as I promised in few threads earlier on this list.[1][2]
The dynamic tick patch does following:
- Separates timer interrupts from updating system time
- Allows updating time
On Mon, 17 Jan 2005, Benjamin Herrenschmidt wrote:
> On Sun, 2005-01-16 at 21:37 -0700, Zwane Mwaikambo wrote:
> > Hello Ben,
> >
> > On Sun, 16 Jan 2005, Benjamin Herrenschmidt wrote:
> >
> > > Looks good, but you could do even better :) I still want
On Sat, 15 Jan 2005, Rudolf Usselmann wrote:
> I tried the new kernel, same results. Still can't use the
> extra memory.
Thanks for testing that Rudolf, i'll find a system to reproduce on.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Hello Ben,
On Sun, 16 Jan 2005, Benjamin Herrenschmidt wrote:
> Looks good, but you could do even better :) I still want to look at the
> proper mecanism to flush the CPU cache on 970, but the idea here is to
> flush it, and put the CPU into a NAP loop (the 970 has no SLEEP mode)
> with the
Hello Ben,
On Sun, 16 Jan 2005, Benjamin Herrenschmidt wrote:
Looks good, but you could do even better :) I still want to look at the
proper mecanism to flush the CPU cache on 970, but the idea here is to
flush it, and put the CPU into a NAP loop (the 970 has no SLEEP mode)
with the caches
On Sat, 15 Jan 2005, Rudolf Usselmann wrote:
I tried the new kernel, same results. Still can't use the
extra memory.
Thanks for testing that Rudolf, i'll find a system to reproduce on.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
On Mon, 17 Jan 2005, Benjamin Herrenschmidt wrote:
On Sun, 2005-01-16 at 21:37 -0700, Zwane Mwaikambo wrote:
Hello Ben,
On Sun, 16 Jan 2005, Benjamin Herrenschmidt wrote:
Looks good, but you could do even better :) I still want to look at the
proper mecanism to flush the CPU
301 - 335 of 335 matches
Mail list logo
