[PATCH 05/05] x86: Rename paravirtualized TSC functions - Kernel

This is a discussion on [PATCH 05/05] x86: Rename paravirtualized TSC functions - Kernel ; [VMware, Inc. is providing the following patch to you under the terms of the GPL version 2 and no later version. This patch is provided as is, with no warranties or support. VMware disclaims all liability in connection with the ...

+ Reply to Thread
Results 1 to 13 of 13

Thread: [PATCH 05/05] x86: Rename paravirtualized TSC functions

  1. [PATCH 05/05] x86: Rename paravirtualized TSC functions

    [VMware, Inc. is providing the following patch to you under the terms of the
    GPL version 2 and no later version. This patch is provided as is, with no
    warranties or support. VMware disclaims all liability in connection with
    the use/inability to use this patch. Any use of the attached is considered
    acceptance of the above.]

    From: Alok N Kataria

    Rename the paravirtualized calculate_cpu_khz to calibrate_tsc.
    In all cases, we actually calibrate_tsc and use that as the cpu_khz value.


    Signed-off-by: Alok N Kataria
    Signed-off-by: Dan Hecht

    ---

    arch/x86/kernel/paravirt.c | 2 +-
    arch/x86/kernel/tsc.c | 18 +++++++-----------
    arch/x86/kernel/vmi_32.c | 2 +-
    arch/x86/kernel/vmiclock_32.c | 4 ++--
    arch/x86/lguest/boot.c | 4 ++--
    arch/x86/xen/enlighten.c | 2 +-
    arch/x86/xen/time.c | 4 ++--
    arch/x86/xen/xen-ops.h | 2 +-
    include/asm-x86/paravirt.h | 4 ++--
    include/asm-x86/timer.h | 4 ++--
    include/asm-x86/vmi_time.h | 2 +-
    11 files changed, 22 insertions(+), 26 deletions(-)


    diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
    index 7d37b7a..abe30e0 100644
    --- a/arch/x86/kernel/paravirt.c
    +++ b/arch/x86/kernel/paravirt.c
    @@ -282,7 +282,7 @@ struct pv_time_ops pv_time_ops = {
    .get_wallclock = native_get_wallclock,
    .set_wallclock = native_set_wallclock,
    .sched_clock = native_sched_clock,
    - .get_cpu_khz = native_calculate_cpu_khz,
    + .get_tsc_khz = native_calibrate_tsc,
    };

    struct pv_irq_ops pv_irq_ops = {
    diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
    index 94c16bd..3c36f92 100644
    --- a/arch/x86/kernel/tsc.c
    +++ b/arch/x86/kernel/tsc.c
    @@ -123,9 +123,9 @@ static u64 __init tsc_read_refs(u64 *pm, u64 *hpet)
    }

    /**
    - * tsc_calibrate - calibrate the tsc on boot
    + * native_calibrate_tsc - calibrate the tsc on boot
    */
    -static unsigned int __init tsc_calibrate(void)
    +unsigned long native_calibrate_tsc(void)
    {
    unsigned long flags;
    u64 tsc1, tsc2, tr1, tr2, delta, pm1, pm2, hpet1, hpet2;
    @@ -195,10 +195,6 @@ out:
    return tsc_khz_val;
    }

    -unsigned long native_calculate_cpu_khz(void)
    -{
    - return tsc_calibrate();
    -}

    #ifdef CONFIG_X86_32
    /* Only called from the Powernow K7 cpu freq driver */
    @@ -208,8 +204,8 @@ int recalibrate_cpu_khz(void)
    unsigned long cpu_khz_old = cpu_khz;

    if (cpu_has_tsc) {
    - cpu_khz = calculate_cpu_khz();
    - tsc_khz = cpu_khz;
    + tsc_khz = calibrate_tsc();
    + cpu_khz = tsc_khz;
    cpu_data(0).loops_per_jiffy =
    cpufreq_scale(cpu_data(0).loops_per_jiffy,
    cpu_khz_old, cpu_khz);
    @@ -487,10 +483,10 @@ void __init tsc_init(void)
    if (!cpu_has_tsc)
    return;

    - cpu_khz = calculate_cpu_khz();
    - tsc_khz = cpu_khz;
    + tsc_khz = calibrate_tsc();
    + cpu_khz = tsc_khz;

    - if (!cpu_khz) {
    + if (!tsc_khz) {
    mark_tsc_unstable("could not calculate TSC khz");
    return;
    }
    diff --git a/arch/x86/kernel/vmi_32.c b/arch/x86/kernel/vmi_32.c
    index 01d687d..b11e7ac 100644
    --- a/arch/x86/kernel/vmi_32.c
    +++ b/arch/x86/kernel/vmi_32.c
    @@ -934,7 +934,7 @@ static inline int __init activate_vmi(void)
    pv_apic_ops.setup_secondary_clock = vmi_time_ap_init;
    #endif
    pv_time_ops.sched_clock = vmi_sched_clock;
    - pv_time_ops.get_cpu_khz = vmi_cpu_khz;
    + pv_time_ops.get_tsc_khz = vmi_tsc_khz;

    /* We have true wallclock functions; disable CMOS clock sync */
    no_sync_cmos_clock = 1;
    diff --git a/arch/x86/kernel/vmiclock_32.c b/arch/x86/kernel/vmiclock_32.c
    index ba7d19e..6953859 100644
    --- a/arch/x86/kernel/vmiclock_32.c
    +++ b/arch/x86/kernel/vmiclock_32.c
    @@ -69,8 +69,8 @@ unsigned long long vmi_sched_clock(void)
    return cycles_2_ns(vmi_timer_ops.get_cycle_counter(VMI_CY CLES_AVAILABLE));
    }

    -/* paravirt_ops.get_cpu_khz = vmi_cpu_khz */
    -unsigned long vmi_cpu_khz(void)
    +/* paravirt_ops.get_tsc_khz = vmi_tsc_khz */
    +unsigned long vmi_tsc_khz(void)
    {
    unsigned long long khz;
    khz = vmi_timer_ops.get_cycle_frequency();
    diff --git a/arch/x86/lguest/boot.c b/arch/x86/lguest/boot.c
    index 2248848..e369cae 100644
    --- a/arch/x86/lguest/boot.c
    +++ b/arch/x86/lguest/boot.c
    @@ -607,7 +607,7 @@ static unsigned long lguest_get_wallclock(void)
    * what speed it runs at, or 0 if it's unusable as a reliable clock source.
    * This matches what we want here: if we return 0 from this function, the x86
    * TSC clock will give up and not register itself. */
    -static unsigned long lguest_cpu_khz(void)
    +static unsigned long lguest_tsc_khz(void)
    {
    return lguest_data.tsc_khz;
    }
    @@ -999,7 +999,7 @@ __init void lguest_init(void)
    /* time operations */
    pv_time_ops.get_wallclock = lguest_get_wallclock;
    pv_time_ops.time_init = lguest_time_init;
    - pv_time_ops.get_cpu_khz = lguest_cpu_khz;
    + pv_time_ops.get_tsc_khz = lguest_tsc_khz;

    /* Now is a good time to look at the implementations of these functions
    * before returning to the rest of lguest_init(). */
    diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
    index 4736d0e..fcc0f38 100644
    --- a/arch/x86/xen/enlighten.c
    +++ b/arch/x86/xen/enlighten.c
    @@ -1061,7 +1061,7 @@ static const struct pv_time_ops xen_time_ops __initdata = {

    .set_wallclock = xen_set_wallclock,
    .get_wallclock = xen_get_wallclock,
    - .get_cpu_khz = xen_cpu_khz,
    + .get_tsc_khz = xen_tsc_khz,
    .sched_clock = xen_sched_clock,
    };

    diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
    index 64f0038..685b774 100644
    --- a/arch/x86/xen/time.c
    +++ b/arch/x86/xen/time.c
    @@ -197,8 +197,8 @@ unsigned long long xen_sched_clock(void)
    }


    -/* Get the CPU speed from Xen */
    -unsigned long xen_cpu_khz(void)
    +/* Get the TSC speed from Xen */
    +unsigned long xen_tsc_khz(void)
    {
    u64 xen_khz = 1000000ULL << 32;
    const struct pvclock_vcpu_time_info *info =
    diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
    index 9a05559..d852ddb 100644
    --- a/arch/x86/xen/xen-ops.h
    +++ b/arch/x86/xen/xen-ops.h
    @@ -32,7 +32,7 @@ void __init xen_build_dynamic_phys_to_machine(void);

    void xen_setup_timer(int cpu);
    void xen_setup_cpu_clockevents(void);
    -unsigned long xen_cpu_khz(void);
    +unsigned long xen_tsc_khz(void);
    void __init xen_time_init(void);
    unsigned long xen_get_wallclock(void);
    int xen_set_wallclock(unsigned long time);
    diff --git a/include/asm-x86/paravirt.h b/include/asm-x86/paravirt.h
    index 60601d8..1d87c0d 100644
    --- a/include/asm-x86/paravirt.h
    +++ b/include/asm-x86/paravirt.h
    @@ -84,7 +84,7 @@ struct pv_time_ops {
    int (*set_wallclock)(unsigned long);

    unsigned long long (*sched_clock)(void);
    - unsigned long (*get_cpu_khz)(void);
    + unsigned long (*get_tsc_khz)(void);
    };

    struct pv_cpu_ops {
    @@ -734,7 +734,7 @@ static inline unsigned long long paravirt_sched_clock(void)
    {
    return PVOP_CALL0(unsigned long long, pv_time_ops.sched_clock);
    }
    -#define calculate_cpu_khz() (pv_time_ops.get_cpu_khz())
    +#define calibrate_tsc() (pv_time_ops.get_tsc_khz())

    static inline unsigned long long paravirt_read_pmc(int counter)
    {
    diff --git a/include/asm-x86/timer.h b/include/asm-x86/timer.h
    index 4f6fcb0..fb2a4dd 100644
    --- a/include/asm-x86/timer.h
    +++ b/include/asm-x86/timer.h
    @@ -7,14 +7,14 @@
    #define TICK_SIZE (tick_nsec / 1000)

    unsigned long long native_sched_clock(void);
    -unsigned long native_calculate_cpu_khz(void);
    +unsigned long native_calibrate_tsc(void);

    extern int timer_ack;
    extern int no_timer_check;
    extern int recalibrate_cpu_khz(void);

    #ifndef CONFIG_PARAVIRT
    -#define calculate_cpu_khz() native_calculate_cpu_khz()
    +#define calibrate_tsc() native_calibrate_tsc()
    #endif

    /* Accelerators for sched_clock()
    diff --git a/include/asm-x86/vmi_time.h b/include/asm-x86/vmi_time.h
    index 4781881..c3118c3 100644
    --- a/include/asm-x86/vmi_time.h
    +++ b/include/asm-x86/vmi_time.h
    @@ -50,7 +50,7 @@ extern void __init vmi_time_init(void);
    extern unsigned long vmi_get_wallclock(void);
    extern int vmi_set_wallclock(unsigned long now);
    extern unsigned long long vmi_sched_clock(void);
    -extern unsigned long vmi_cpu_khz(void);
    +extern unsigned long vmi_tsc_khz(void);

    #ifdef CONFIG_X86_LOCAL_APIC
    extern void __devinit vmi_time_bsp_init(void);


    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: [PATCH 05/05] x86: Rename paravirtualized TSC functions


    * Alok Kataria wrote:

    > Rename the paravirtualized calculate_cpu_khz to calibrate_tsc. In all
    > cases, we actually calibrate_tsc and use that as the cpu_khz value.


    thanks Alok, i've applied all 5 unification patches to tip/x86/core:

    Alok Kataria (5):
    x86: merge sched_clock handling
    x86: merge tsc calibration
    x86: merge the TSC cpu-freq code
    x86: merge tsc_init and clocksource code
    x86: rename paravirtualized TSC functions

    they are looking good in testing so far.

    Ingo
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. Re: [PATCH 05/05] x86: Rename paravirtualized TSC functions

    On Tue, Jul 8, 2008 at 11:13 PM, Ingo Molnar wrote:
    >
    > * Alok Kataria wrote:
    >
    >> Rename the paravirtualized calculate_cpu_khz to calibrate_tsc. In all
    >> cases, we actually calibrate_tsc and use that as the cpu_khz value.

    >
    > thanks Alok, i've applied all 5 unification patches to tip/x86/core:
    >
    > Alok Kataria (5):
    > x86: merge sched_clock handling
    > x86: merge tsc calibration
    > x86: merge the TSC cpu-freq code
    > x86: merge tsc_init and clocksource code
    > x86: rename paravirtualized TSC functions
    >
    > they are looking good in testing so far.


    got
    calling ixgb_init_module+0x0/0x76
    Intel(R) PRO/10GbE Network Driver - version 1.0.126-k4
    Copyright (c) 1999-2006 Intel Corporation.
    vendor=1022 device=7458
    ACPI: PCI Interrupt 0000:0c:01.0[A] -> GSI 56 (level, low) -> IRQ 56
    ixgb: eth18: ixgb_probe: Intel(R) PRO/10GbE Network Connection
    BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
    IP: [] hrtick_start_fair+0x89/0x173
    PGD 0
    Oops: 0000 [1] SMP
    CPU 4
    Modules linked in:
    Pid: 103, comm: events/4 Not tainted 2.6.26-rc9-tip-00026-geae1aa0-dirty #240
    RIP: 0010:[] []
    hrtick_start_fair+0x89/0x173
    RSP: 0018:ffff88082481fbd0 EFLAGS: 00010046
    RAX: 0000000000000000 RBX: ffff880824828000 RCX: 0000000000000006
    RDX: ffff88084423e700 RSI: ffff880824828000 RDI: ffff88084423e700
    RBP: ffff88082481fc00 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000000 R12: ffff88084423e700
    R13: ffff880844239700 R14: ffff880824828000 R15: 0000000000000c1a
    FS: 0000000000000000(0000) GS:ffff881024c39600(0000) knlGS:0000000000000000
    CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
    CR2: 0000000000000000 CR3: 0000000000201000 CR4: 00000000000006e0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    Process events/4 (pid: 103, threadinfo ffff88082481e000, task ffff880824814230)
    Stack: ffff880844248118 000000005c0ee9e3 ffff880844239700 ffff88082490d878
    ffff88084423e700 0000000000000000 ffff88082481fc40 ffffffff80256591
    ffff88082481fc30 ffffffff80516fc5 000000005c0ee9e3 ffff88082490d840
    Call Trace:
    [] dequeue_task_fair+0x5f/0x7e
    [] ? __first_cpu+0x26/0x49
    [] dequeue_task+0xce/0xf0
    [] deactivate_task+0x31/0x50
    [] pull_task+0x2c/0x78
    [] load_balance_fair+0x18d/0x277
    [] schedule+0x3db/0x962
    [] ? vmstat_update+0x0/0x5e
    [] ? schedule_delayed_work+0x31/0x48
    [] worker_thread+0xbb/0x114
    [] ? autoremove_wake_function+0x0/0x63
    [] ? worker_thread+0x0/0x114
    [] kthread+0x61/0xa4
    [] ? schedule_tail+0x36/0x81
    [] child_rip+0xa/0x11
    [] ? kthread+0x0/0xa4
    [] ? child_rip+0x0/0x11


    Code: c3 80 e8 86 04 01 00 80 3d 76 52 c0 00 00 0f 89 e1 00 00 00 41
    f6 84 24 70 08 00 00 04 0f 85 d2 00 00 00 49 8b 84 24 a8 08 00 00 <48>
    8b 00 83 b8 c0 00 00 00 00 0f 84 ba 00 00 00 49 83 7d 10 01
    RIP [] hrtick_start_fair+0x89/0x173
    RSP
    CR2: 0000000000000000
    ---[ end trace c05d5c1f5b126388 ]---

    yesterday tip/mater with tip/x86/modules
    tip-history-2008-07-08_16.08_Tue works well.

    others traps merge seems not to cause the problem..

    YH
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  4. Re: [PATCH 05/05] x86: Rename paravirtualized TSC functions

    On Wed, 2008-07-09 at 00:20 -0700, Yinghai Lu wrote:
    > On Tue, Jul 8, 2008 at 11:13 PM, Ingo Molnar wrote:
    > >
    > > * Alok Kataria wrote:
    > >


    > got
    > calling ixgb_init_module+0x0/0x76
    > Intel(R) PRO/10GbE Network Driver - version 1.0.126-k4
    > Copyright (c) 1999-2006 Intel Corporation.
    > vendor=1022 device=7458
    > ACPI: PCI Interrupt 0000:0c:01.0[A] -> GSI 56 (level, low) -> IRQ 56
    > ixgb: eth18: ixgb_probe: Intel(R) PRO/10GbE Network Connection
    > BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
    > IP: [] hrtick_start_fair+0x89/0x173
    > PGD 0
    > Oops: 0000 [1] SMP
    > CPU 4
    > Modules linked in:
    > Pid: 103, comm: events/4 Not tainted 2.6.26-rc9-tip-00026-geae1aa0-dirty #240
    > RIP: 0010:[] []
    > hrtick_start_fair+0x89/0x173
    > RSP: 0018:ffff88082481fbd0 EFLAGS: 00010046
    > RAX: 0000000000000000 RBX: ffff880824828000 RCX: 0000000000000006
    > RDX: ffff88084423e700 RSI: ffff880824828000 RDI: ffff88084423e700
    > RBP: ffff88082481fc00 R08: 0000000000000000 R09: 0000000000000000
    > R10: 0000000000000000 R11: 0000000000000000 R12: ffff88084423e700
    > R13: ffff880844239700 R14: ffff880824828000 R15: 0000000000000c1a
    > FS: 0000000000000000(0000) GS:ffff881024c39600(0000) knlGS:0000000000000000
    > CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
    > CR2: 0000000000000000 CR3: 0000000000201000 CR4: 00000000000006e0
    > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    > DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    > Process events/4 (pid: 103, threadinfo ffff88082481e000, task ffff880824814230)
    > Stack: ffff880844248118 000000005c0ee9e3 ffff880844239700 ffff88082490d878
    > ffff88084423e700 0000000000000000 ffff88082481fc40 ffffffff80256591
    > ffff88082481fc30 ffffffff80516fc5 000000005c0ee9e3 ffff88082490d840
    > Call Trace:
    > [] dequeue_task_fair+0x5f/0x7e
    > [] ? __first_cpu+0x26/0x49
    > [] dequeue_task+0xce/0xf0
    > [] deactivate_task+0x31/0x50
    > [] pull_task+0x2c/0x78
    > [] load_balance_fair+0x18d/0x277
    > [] schedule+0x3db/0x962
    > [] ? vmstat_update+0x0/0x5e
    > [] ? schedule_delayed_work+0x31/0x48
    > [] worker_thread+0xbb/0x114
    > [] ? autoremove_wake_function+0x0/0x63
    > [] ? worker_thread+0x0/0x114
    > [] kthread+0x61/0xa4
    > [] ? schedule_tail+0x36/0x81
    > [] child_rip+0xa/0x11
    > [] ? kthread+0x0/0xa4
    > [] ? child_rip+0x0/0x11
    >
    >
    > Code: c3 80 e8 86 04 01 00 80 3d 76 52 c0 00 00 0f 89 e1 00 00 00 41
    > f6 84 24 70 08 00 00 04 0f 85 d2 00 00 00 49 8b 84 24 a8 08 00 00 <48>
    > 8b 00 83 b8 c0 00 00 00 00 0f 84 ba 00 00 00 49 83 7d 10 01
    > RIP [] hrtick_start_fair+0x89/0x173
    > RSP
    > CR2: 0000000000000000
    > ---[ end trace c05d5c1f5b126388 ]---
    >
    > yesterday tip/mater with tip/x86/modules
    > tip-history-2008-07-08_16.08_Tue works well.
    >
    > others traps merge seems not to cause the problem..
    >


    Hi Yinghai,

    Are we sure that these patches cause this null pointer dereference ?
    The panic in scheduler seems to be totally disconnected to the changes
    that these patches make. The only scheduler bit that we touch is the
    sched_clock thingy....but that too looks harmless to me.

    Can you please bisect and see if the first patch in the series is the
    problem ?

    Thanks,
    Alok


    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  5. Re: [PATCH 05/05] x86: Rename paravirtualized TSC functions

    On Wed, Jul 9, 2008 at 10:30 AM, Alok Kataria wrote:
    > On Wed, 2008-07-09 at 00:20 -0700, Yinghai Lu wrote:
    >> On Tue, Jul 8, 2008 at 11:13 PM, Ingo Molnar wrote:
    >> >
    >> > * Alok Kataria wrote:
    >> >

    >
    >> got
    >> calling ixgb_init_module+0x0/0x76
    >> Intel(R) PRO/10GbE Network Driver - version 1.0.126-k4
    >> Copyright (c) 1999-2006 Intel Corporation.
    >> vendor=1022 device=7458
    >> ACPI: PCI Interrupt 0000:0c:01.0[A] -> GSI 56 (level, low) -> IRQ 56
    >> ixgb: eth18: ixgb_probe: Intel(R) PRO/10GbE Network Connection
    >> BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
    >> IP: [] hrtick_start_fair+0x89/0x173
    >> PGD 0
    >> Oops: 0000 [1] SMP
    >> CPU 4
    >> Modules linked in:
    >> Pid: 103, comm: events/4 Not tainted 2.6.26-rc9-tip-00026-geae1aa0-dirty #240
    >> RIP: 0010:[] []
    >> hrtick_start_fair+0x89/0x173
    >> RSP: 0018:ffff88082481fbd0 EFLAGS: 00010046
    >> RAX: 0000000000000000 RBX: ffff880824828000 RCX: 0000000000000006
    >> RDX: ffff88084423e700 RSI: ffff880824828000 RDI: ffff88084423e700
    >> RBP: ffff88082481fc00 R08: 0000000000000000 R09: 0000000000000000
    >> R10: 0000000000000000 R11: 0000000000000000 R12: ffff88084423e700
    >> R13: ffff880844239700 R14: ffff880824828000 R15: 0000000000000c1a
    >> FS: 0000000000000000(0000) GS:ffff881024c39600(0000) knlGS:0000000000000000
    >> CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
    >> CR2: 0000000000000000 CR3: 0000000000201000 CR4: 00000000000006e0
    >> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    >> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    >> Process events/4 (pid: 103, threadinfo ffff88082481e000, task ffff880824814230)
    >> Stack: ffff880844248118 000000005c0ee9e3 ffff880844239700 ffff88082490d878
    >> ffff88084423e700 0000000000000000 ffff88082481fc40 ffffffff80256591
    >> ffff88082481fc30 ffffffff80516fc5 000000005c0ee9e3 ffff88082490d840
    >> Call Trace:
    >> [] dequeue_task_fair+0x5f/0x7e
    >> [] ? __first_cpu+0x26/0x49
    >> [] dequeue_task+0xce/0xf0
    >> [] deactivate_task+0x31/0x50
    >> [] pull_task+0x2c/0x78
    >> [] load_balance_fair+0x18d/0x277
    >> [] schedule+0x3db/0x962
    >> [] ? vmstat_update+0x0/0x5e
    >> [] ? schedule_delayed_work+0x31/0x48
    >> [] worker_thread+0xbb/0x114
    >> [] ? autoremove_wake_function+0x0/0x63
    >> [] ? worker_thread+0x0/0x114
    >> [] kthread+0x61/0xa4
    >> [] ? schedule_tail+0x36/0x81
    >> [] child_rip+0xa/0x11
    >> [] ? kthread+0x0/0xa4
    >> [] ? child_rip+0x0/0x11
    >>
    >>
    >> Code: c3 80 e8 86 04 01 00 80 3d 76 52 c0 00 00 0f 89 e1 00 00 00 41
    >> f6 84 24 70 08 00 00 04 0f 85 d2 00 00 00 49 8b 84 24 a8 08 00 00 <48>
    >> 8b 00 83 b8 c0 00 00 00 00 0f 84 ba 00 00 00 49 83 7d 10 01
    >> RIP [] hrtick_start_fair+0x89/0x173
    >> RSP
    >> CR2: 0000000000000000
    >> ---[ end trace c05d5c1f5b126388 ]---
    >>
    >> yesterday tip/mater with tip/x86/modules
    >> tip-history-2008-07-08_16.08_Tue works well.
    >>
    >> others traps merge seems not to cause the problem..
    >>

    >
    > Hi Yinghai,
    >
    > Are we sure that these patches cause this null pointer dereference ?
    > The panic in scheduler seems to be totally disconnected to the changes
    > that these patches make. The only scheduler bit that we touch is the
    > sched_clock thingy....but that too looks harmless to me.
    >
    > Can you please bisect and see if the first patch in the series is the
    > problem ?


    tries last night, it seems pgtable related patches cause that.

    YH
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  6. Re: [PATCH 05/05] x86: Rename paravirtualized TSC functions


    * Yinghai Lu wrote:

    > On Wed, Jul 9, 2008 at 10:30 AM, Alok Kataria wrote:
    > > On Wed, 2008-07-09 at 00:20 -0700, Yinghai Lu wrote:
    > >> On Tue, Jul 8, 2008 at 11:13 PM, Ingo Molnar wrote:
    > >> >
    > >> > * Alok Kataria wrote:
    > >> >

    > >
    > >> got
    > >> calling ixgb_init_module+0x0/0x76
    > >> Intel(R) PRO/10GbE Network Driver - version 1.0.126-k4
    > >> Copyright (c) 1999-2006 Intel Corporation.
    > >> vendor=1022 device=7458
    > >> ACPI: PCI Interrupt 0000:0c:01.0[A] -> GSI 56 (level, low) -> IRQ 56
    > >> ixgb: eth18: ixgb_probe: Intel(R) PRO/10GbE Network Connection
    > >> BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
    > >> IP: [] hrtick_start_fair+0x89/0x173
    > >> PGD 0
    > >> Oops: 0000 [1] SMP
    > >> CPU 4
    > >> Modules linked in:
    > >> Pid: 103, comm: events/4 Not tainted 2.6.26-rc9-tip-00026-geae1aa0-dirty #240
    > >> RIP: 0010:[] []
    > >> hrtick_start_fair+0x89/0x173
    > >> RSP: 0018:ffff88082481fbd0 EFLAGS: 00010046
    > >> RAX: 0000000000000000 RBX: ffff880824828000 RCX: 0000000000000006
    > >> RDX: ffff88084423e700 RSI: ffff880824828000 RDI: ffff88084423e700
    > >> RBP: ffff88082481fc00 R08: 0000000000000000 R09: 0000000000000000
    > >> R10: 0000000000000000 R11: 0000000000000000 R12: ffff88084423e700
    > >> R13: ffff880844239700 R14: ffff880824828000 R15: 0000000000000c1a
    > >> FS: 0000000000000000(0000) GS:ffff881024c39600(0000) knlGS:0000000000000000
    > >> CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
    > >> CR2: 0000000000000000 CR3: 0000000000201000 CR4: 00000000000006e0
    > >> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    > >> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    > >> Process events/4 (pid: 103, threadinfo ffff88082481e000, task ffff880824814230)
    > >> Stack: ffff880844248118 000000005c0ee9e3 ffff880844239700 ffff88082490d878
    > >> ffff88084423e700 0000000000000000 ffff88082481fc40 ffffffff80256591
    > >> ffff88082481fc30 ffffffff80516fc5 000000005c0ee9e3 ffff88082490d840
    > >> Call Trace:
    > >> [] dequeue_task_fair+0x5f/0x7e
    > >> [] ? __first_cpu+0x26/0x49
    > >> [] dequeue_task+0xce/0xf0
    > >> [] deactivate_task+0x31/0x50
    > >> [] pull_task+0x2c/0x78
    > >> [] load_balance_fair+0x18d/0x277
    > >> [] schedule+0x3db/0x962
    > >> [] ? vmstat_update+0x0/0x5e
    > >> [] ? schedule_delayed_work+0x31/0x48
    > >> [] worker_thread+0xbb/0x114
    > >> [] ? autoremove_wake_function+0x0/0x63
    > >> [] ? worker_thread+0x0/0x114
    > >> [] kthread+0x61/0xa4
    > >> [] ? schedule_tail+0x36/0x81
    > >> [] child_rip+0xa/0x11
    > >> [] ? kthread+0x0/0xa4
    > >> [] ? child_rip+0x0/0x11
    > >>
    > >>
    > >> Code: c3 80 e8 86 04 01 00 80 3d 76 52 c0 00 00 0f 89 e1 00 00 00 41
    > >> f6 84 24 70 08 00 00 04 0f 85 d2 00 00 00 49 8b 84 24 a8 08 00 00 <48>
    > >> 8b 00 83 b8 c0 00 00 00 00 0f 84 ba 00 00 00 49 83 7d 10 01
    > >> RIP [] hrtick_start_fair+0x89/0x173
    > >> RSP
    > >> CR2: 0000000000000000
    > >> ---[ end trace c05d5c1f5b126388 ]---
    > >>
    > >> yesterday tip/mater with tip/x86/modules
    > >> tip-history-2008-07-08_16.08_Tue works well.
    > >>
    > >> others traps merge seems not to cause the problem..
    > >>

    > >
    > > Hi Yinghai,
    > >
    > > Are we sure that these patches cause this null pointer dereference ?
    > > The panic in scheduler seems to be totally disconnected to the changes
    > > that these patches make. The only scheduler bit that we touch is the
    > > sched_clock thingy....but that too looks harmless to me.
    > >
    > > Can you please bisect and see if the first patch in the series is the
    > > problem ?

    >
    > tries last night, it seems pgtable related patches cause that.


    that would be the tip/xen64 stuff, right? Does this revert:

    | Revert "x86_64: there's no need to preallocate level1_fixmap_pgt"
    |
    | This reverts commit 033786969d1d1b5af12a32a19d3a760314d05329.
    |
    | Suresh Siddha reported that this broke booting on his 2GB testbox.

    solve your problems, or are there other problems still?

    Ingo
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  7. Re: [PATCH 05/05] x86: Rename paravirtualized TSC functions

    On Thu, Jul 10, 2008 at 12:22 AM, Ingo Molnar wrote:
    >
    > * Yinghai Lu wrote:
    >
    >> On Wed, Jul 9, 2008 at 10:30 AM, Alok Kataria wrote:
    >> > On Wed, 2008-07-09 at 00:20 -0700, Yinghai Lu wrote:
    >> >> On Tue, Jul 8, 2008 at 11:13 PM, Ingo Molnar wrote:
    >> >> >
    >> >> > * Alok Kataria wrote:
    >> >> >
    >> >
    >> >> got
    >> >> calling ixgb_init_module+0x0/0x76
    >> >> Intel(R) PRO/10GbE Network Driver - version 1.0.126-k4
    >> >> Copyright (c) 1999-2006 Intel Corporation.
    >> >> vendor=1022 device=7458
    >> >> ACPI: PCI Interrupt 0000:0c:01.0[A] -> GSI 56 (level, low) -> IRQ 56
    >> >> ixgb: eth18: ixgb_probe: Intel(R) PRO/10GbE Network Connection
    >> >> BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
    >> >> IP: [] hrtick_start_fair+0x89/0x173
    >> >> PGD 0
    >> >> Oops: 0000 [1] SMP
    >> >> CPU 4
    >> >> Modules linked in:
    >> >> Pid: 103, comm: events/4 Not tainted 2.6.26-rc9-tip-00026-geae1aa0-dirty #240
    >> >> RIP: 0010:[] []
    >> >> hrtick_start_fair+0x89/0x173
    >> >> RSP: 0018:ffff88082481fbd0 EFLAGS: 00010046
    >> >> RAX: 0000000000000000 RBX: ffff880824828000 RCX: 0000000000000006
    >> >> RDX: ffff88084423e700 RSI: ffff880824828000 RDI: ffff88084423e700
    >> >> RBP: ffff88082481fc00 R08: 0000000000000000 R09: 0000000000000000
    >> >> R10: 0000000000000000 R11: 0000000000000000 R12: ffff88084423e700
    >> >> R13: ffff880844239700 R14: ffff880824828000 R15: 0000000000000c1a
    >> >> FS: 0000000000000000(0000) GS:ffff881024c39600(0000) knlGS:0000000000000000
    >> >> CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
    >> >> CR2: 0000000000000000 CR3: 0000000000201000 CR4: 00000000000006e0
    >> >> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    >> >> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    >> >> Process events/4 (pid: 103, threadinfo ffff88082481e000, task ffff880824814230)
    >> >> Stack: ffff880844248118 000000005c0ee9e3 ffff880844239700 ffff88082490d878
    >> >> ffff88084423e700 0000000000000000 ffff88082481fc40 ffffffff80256591
    >> >> ffff88082481fc30 ffffffff80516fc5 000000005c0ee9e3 ffff88082490d840
    >> >> Call Trace:
    >> >> [] dequeue_task_fair+0x5f/0x7e
    >> >> [] ? __first_cpu+0x26/0x49
    >> >> [] dequeue_task+0xce/0xf0
    >> >> [] deactivate_task+0x31/0x50
    >> >> [] pull_task+0x2c/0x78
    >> >> [] load_balance_fair+0x18d/0x277
    >> >> [] schedule+0x3db/0x962
    >> >> [] ? vmstat_update+0x0/0x5e
    >> >> [] ? schedule_delayed_work+0x31/0x48
    >> >> [] worker_thread+0xbb/0x114
    >> >> [] ? autoremove_wake_function+0x0/0x63
    >> >> [] ? worker_thread+0x0/0x114
    >> >> [] kthread+0x61/0xa4
    >> >> [] ? schedule_tail+0x36/0x81
    >> >> [] child_rip+0xa/0x11
    >> >> [] ? kthread+0x0/0xa4
    >> >> [] ? child_rip+0x0/0x11
    >> >>
    >> >>
    >> >> Code: c3 80 e8 86 04 01 00 80 3d 76 52 c0 00 00 0f 89 e1 00 00 00 41
    >> >> f6 84 24 70 08 00 00 04 0f 85 d2 00 00 00 49 8b 84 24 a8 08 00 00 <48>
    >> >> 8b 00 83 b8 c0 00 00 00 00 0f 84 ba 00 00 00 49 83 7d 10 01
    >> >> RIP [] hrtick_start_fair+0x89/0x173
    >> >> RSP
    >> >> CR2: 0000000000000000
    >> >> ---[ end trace c05d5c1f5b126388 ]---
    >> >>
    >> >> yesterday tip/mater with tip/x86/modules
    >> >> tip-history-2008-07-08_16.08_Tue works well.
    >> >>
    >> >> others traps merge seems not to cause the problem..
    >> >>
    >> >
    >> > Hi Yinghai,
    >> >
    >> > Are we sure that these patches cause this null pointer dereference ?
    >> > The panic in scheduler seems to be totally disconnected to the changes
    >> > that these patches make. The only scheduler bit that we touch is the
    >> > sched_clock thingy....but that too looks harmless to me.
    >> >
    >> > Can you please bisect and see if the first patch in the series is the
    >> > problem ?

    >>
    >> tries last night, it seems pgtable related patches cause that.

    >
    > that would be the tip/xen64 stuff, right? Does this revert:
    >
    > | Revert "x86_64: there's no need to preallocate level1_fixmap_pgt"
    > |
    > | This reverts commit 033786969d1d1b5af12a32a19d3a760314d05329.
    > |
    > | Suresh Siddha reported that this broke booting on his 2GB testbox.
    >
    > solve your problems, or are there other problems still?


    still is bisecting it now...

    YH
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  8. Re: [PATCH 05/05] x86: Rename paravirtualized TSC functions


    * Yinghai Lu wrote:

    > > that would be the tip/xen64 stuff, right? Does this revert:
    > >
    > > | Revert "x86_64: there's no need to preallocate level1_fixmap_pgt"
    > > |
    > > | This reverts commit 033786969d1d1b5af12a32a19d3a760314d05329.
    > > |
    > > | Suresh Siddha reported that this broke booting on his 2GB testbox.
    > >
    > > solve your problems, or are there other problems still?

    >
    > still is bisecting it now...


    ok. I have no mystery crash on my test-systems.

    by the looks of it, your crashes seem to be pagetable related. If it's
    in the tip/xen-64bit branch, my candidates would be:

    0f38c08: x86: use __page_aligned_data/bss
    0337869: x86_64: there's no need to preallocate level1_fixmap_pgt
    89d7bb5: x86_64: add workaround for no %gs-based percpu

    0337869 is reverted already.

    Or if it's an older commit, two candidates would be:

    b50efd2: x86: introduce page_size_mask for 64bit
    3a9e189: x86: map UV chipset space - pagetable

    do you know the sha1 of the first broken tree? We know that
    tip-history-2008-07-08_16.08_Tue is known-good.

    Ingo
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  9. Re: [PATCH 05/05] x86: Rename paravirtualized TSC functions

    On Thu, Jul 10, 2008 at 12:50 AM, Ingo Molnar wrote:
    >
    > * Yinghai Lu wrote:
    >
    >> > that would be the tip/xen64 stuff, right? Does this revert:
    >> >
    >> > | Revert "x86_64: there's no need to preallocate level1_fixmap_pgt"
    >> > |
    >> > | This reverts commit 033786969d1d1b5af12a32a19d3a760314d05329.
    >> > |
    >> > | Suresh Siddha reported that this broke booting on his 2GB testbox.
    >> >
    >> > solve your problems, or are there other problems still?

    >>
    >> still is bisecting it now...

    >
    > ok. I have no mystery crash on my test-systems.
    >
    > by the looks of it, your crashes seem to be pagetable related. If it's
    > in the tip/xen-64bit branch, my candidates would be:
    >
    > 0f38c08: x86: use __page_aligned_data/bss
    > 0337869: x86_64: there's no need to preallocate level1_fixmap_pgt
    > 89d7bb5: x86_64: add workaround for no %gs-based percpu
    >
    > 0337869 is reverted already.
    >
    > Or if it's an older commit, two candidates would be:
    >
    > b50efd2: x86: introduce page_size_mask for 64bit
    > 3a9e189: x86: map UV chipset space - pagetable
    >
    > do you know the sha1 of the first broken tree? We know that
    > tip-history-2008-07-08_16.08_Tue is known-good.


    first round bisect all works..

    it seems make oldconfig change setting between different setting...

    diff .config config.full.good
    4c4
    < # Thu Jul 10 00:52:52 2008
    ---
    > # Thu Jul 10 00:40:03 2008

    295,296c295
    < CONFIG_CC_STACKPROTECTOR_ALL=y
    < CONFIG_CC_STACKPROTECTOR=y
    ---
    > # CONFIG_CC_STACKPROTECTOR is not set


    it seems some recent change doesn't like stackprotector.

    YH
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  10. Re: [PATCH 05/05] x86: Rename paravirtualized TSC functions


    * Yinghai Lu wrote:

    > first round bisect all works..
    >
    > it seems make oldconfig change setting between different setting...


    yeah. The thing i do is this: i create a .config.bisect and at every
    bisection step i copy it into .config and do a 'make oldconfig'.

    this means that options are picked up again, even if a 'dive back into
    the past' causes a bisection point to lose a config setting.

    >
    > diff .config config.full.good
    > 4c4
    > < # Thu Jul 10 00:52:52 2008
    > ---
    > > # Thu Jul 10 00:40:03 2008

    > 295,296c295
    > < CONFIG_CC_STACKPROTECTOR_ALL=y
    > < CONFIG_CC_STACKPROTECTOR=y
    > ---
    > > # CONFIG_CC_STACKPROTECTOR is not set

    >
    > it seems some recent change doesn't like stackprotector.


    then my guess would be on:

    89d7bb5: x86_64: add workaround for no %gs-based percpu

    you might want to try your luck and revert that one alone from latest
    tip/master.

    Ingo
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  11. Re: [PATCH 05/05] x86: Rename paravirtualized TSC functions

    On Thu, Jul 10, 2008 at 1:04 AM, Yinghai Lu wrote:
    > On Thu, Jul 10, 2008 at 12:50 AM, Ingo Molnar wrote:
    >>
    >> * Yinghai Lu wrote:
    >>
    >>> > that would be the tip/xen64 stuff, right? Does this revert:
    >>> >
    >>> > | Revert "x86_64: there's no need to preallocate level1_fixmap_pgt"
    >>> > |
    >>> > | This reverts commit 033786969d1d1b5af12a32a19d3a760314d05329.
    >>> > |
    >>> > | Suresh Siddha reported that this broke booting on his 2GB testbox.
    >>> >
    >>> > solve your problems, or are there other problems still?
    >>>
    >>> still is bisecting it now...

    >>
    >> ok. I have no mystery crash on my test-systems.
    >>
    >> by the looks of it, your crashes seem to be pagetable related. If it's
    >> in the tip/xen-64bit branch, my candidates would be:
    >>
    >> 0f38c08: x86: use __page_aligned_data/bss
    >> 0337869: x86_64: there's no need to preallocate level1_fixmap_pgt
    >> 89d7bb5: x86_64: add workaround for no %gs-based percpu
    >>
    >> 0337869 is reverted already.
    >>
    >> Or if it's an older commit, two candidates would be:
    >>
    >> b50efd2: x86: introduce page_size_mask for 64bit
    >> 3a9e189: x86: map UV chipset space - pagetable
    >>
    >> do you know the sha1 of the first broken tree? We know that
    >> tip-history-2008-07-08_16.08_Tue is known-good.

    >
    > first round bisect all works..
    >
    > it seems make oldconfig change setting between different setting...
    >
    > diff .config config.full.good
    > 4c4
    > < # Thu Jul 10 00:52:52 2008
    > ---
    >> # Thu Jul 10 00:40:03 2008

    > 295,296c295
    > < CONFIG_CC_STACKPROTECTOR_ALL=y
    > < CONFIG_CC_STACKPROTECTOR=y
    > ---
    >> # CONFIG_CC_STACKPROTECTOR is not set

    >
    > it seems some recent change doesn't like stackprotector.


    reeing unused kernel memory: 996k freed
    INIT: version 2.86 booting
    init[1]: segfault at 28 ip ffffffffff600108 sp 00007fff71647a40 error 4
    init[1]: segfault at 28 ip ffffffffff600108 sp 00007fff71646fc0 error 4
    Kernel panic - not syncing: Attempted to kill init!
    Pid: 1, comm: init Not tainted 2.6.26-rc9-tip-01539-g7ef7459 #280

    Call Trace:
    [] ? do_exit+0x84/0x6ce
    [] ? do_group_exit+0x86/0xb3
    [] ? get_signal_to_deliver+0x309/0x33d
    [] ? send_signal+0x23b/0x26e
    [] ? do_notify_resume+0xd3/0x8fd
    [] ? print_vma_addr+0x110/0x12f
    [] ? do_page_fault+0x8ac/0x8fe
    [] ? mcount_call+0x5/0x31
    [] ? mcount_call+0x5/0x31
    [] ? sigprocmask+0xbe/0xf6
    [] ? retint_signal+0x3d/0x85
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  12. Re: [PATCH 05/05] x86: Rename paravirtualized TSC functions

    On Thu, Jul 10, 2008 at 1:11 AM, Yinghai Lu wrote:
    > On Thu, Jul 10, 2008 at 1:04 AM, Yinghai Lu wrote:
    >> On Thu, Jul 10, 2008 at 12:50 AM, Ingo Molnar wrote:
    >>>
    >>> * Yinghai Lu wrote:
    >>>
    >>>> > that would be the tip/xen64 stuff, right? Does this revert:
    >>>> >
    >>>> > | Revert "x86_64: there's no need to preallocate level1_fixmap_pgt"
    >>>> > |
    >>>> > | This reverts commit 033786969d1d1b5af12a32a19d3a760314d05329.
    >>>> > |
    >>>> > | Suresh Siddha reported that this broke booting on his 2GB testbox.
    >>>> >
    >>>> > solve your problems, or are there other problems still?
    >>>>
    >>>> still is bisecting it now...
    >>>
    >>> ok. I have no mystery crash on my test-systems.
    >>>
    >>> by the looks of it, your crashes seem to be pagetable related. If it's
    >>> in the tip/xen-64bit branch, my candidates would be:
    >>>
    >>> 0f38c08: x86: use __page_aligned_data/bss
    >>> 0337869: x86_64: there's no need to preallocate level1_fixmap_pgt
    >>> 89d7bb5: x86_64: add workaround for no %gs-based percpu
    >>>
    >>> 0337869 is reverted already.
    >>>
    >>> Or if it's an older commit, two candidates would be:
    >>>
    >>> b50efd2: x86: introduce page_size_mask for 64bit
    >>> 3a9e189: x86: map UV chipset space - pagetable
    >>>
    >>> do you know the sha1 of the first broken tree? We know that
    >>> tip-history-2008-07-08_16.08_Tue is known-good.

    >>
    >> first round bisect all works..
    >>
    >> it seems make oldconfig change setting between different setting...
    >>
    >> diff .config config.full.good
    >> 4c4
    >> < # Thu Jul 10 00:52:52 2008
    >> ---
    >>> # Thu Jul 10 00:40:03 2008

    >> 295,296c295
    >> < CONFIG_CC_STACKPROTECTOR_ALL=y
    >> < CONFIG_CC_STACKPROTECTOR=y
    >> ---
    >>> # CONFIG_CC_STACKPROTECTOR is not set

    >>
    >> it seems some recent change doesn't like stackprotector.

    >
    > reeing unused kernel memory: 996k freed
    > INIT: version 2.86 booting
    > init[1]: segfault at 28 ip ffffffffff600108 sp 00007fff71647a40 error 4
    > init[1]: segfault at 28 ip ffffffffff600108 sp 00007fff71646fc0 error 4
    > Kernel panic - not syncing: Attempted to kill init!
    > Pid: 1, comm: init Not tainted 2.6.26-rc9-tip-01539-g7ef7459 #280
    >
    > Call Trace:
    > [] ? do_exit+0x84/0x6ce
    > [] ? do_group_exit+0x86/0xb3
    > [] ? get_signal_to_deliver+0x309/0x33d
    > [] ? send_signal+0x23b/0x26e
    > [] ? do_notify_resume+0xd3/0x8fd
    > [] ? print_vma_addr+0x110/0x12f
    > [] ? do_page_fault+0x8ac/0x8fe
    > [] ? mcount_call+0x5/0x31
    > [] ? mcount_call+0x5/0x31
    > [] ? sigprocmask+0xbe/0xf6
    > [] ? retint_signal+0x3d/0x85
    >


    bisecting get lost between the branch... some time it allows
    STACKPROTECTOR... sometime it doesn't

    git-bisect log
    git-bisect start
    # bad: [5c929086ab3c2e42554099930c352c584b09fb49] Merge branch
    'timers/clocksource'
    git-bisect bad 5c929086ab3c2e42554099930c352c584b09fb49
    # good: [fc9036ea1a4b14229788e6df3936b451a6abac98] x86: let
    early_reserve_e820 update e820_saved too
    git-bisect good fc9036ea1a4b14229788e6df3936b451a6abac98
    # good: [e624188cbd347f134b4827c201cac7e59cd6cf46] Merge branch
    'auto-core-next' into auto-generic-ipi-next
    git-bisect good e624188cbd347f134b4827c201cac7e59cd6cf46
    # bad: [6412367fe22dc54cc727e7bec5bd65c36c1a0754] x86,
    paravirt-spinlocks: fix boot hang
    git-bisect bad 6412367fe22dc54cc727e7bec5bd65c36c1a0754
    # good: [db8e85a69d45f1692e216392a652f9652232016e] Merge branch
    'generic-ipi-mergefixups' into auto-generic-ipi-next
    git-bisect good db8e85a69d45f1692e216392a652f9652232016e
    # good: [a0ba7c30f129d94f8a5e97ed065b510996f813b2] Merge branch
    'x86/core' into xen-64bit
    git-bisect good a0ba7c30f129d94f8a5e97ed065b510996f813b2
    # bad: [c370cb1843a68485e64fb956b6a2beb0c6f7f5f1] xen: fix truncation
    of machine address
    git-bisect bad c370cb1843a68485e64fb956b6a2beb0c6f7f5f1
    # bad: [9ed13f242bb9d30bb7502a69a67fefb909d2842e] xen64: fix calls
    into hypercall page
    git-bisect bad 9ed13f242bb9d30bb7502a69a67fefb909d2842e
    # bad: [3ab876c861e0bc631f5cda803ddd435a45b4d1b4] x86_64: unstatic get_local_pda
    git-bisect bad 3ab876c861e0bc631f5cda803ddd435a45b4d1b4
    # bad: [033786969d1d1b5af12a32a19d3a760314d05329] x86_64: there's no
    need to preallocate level1_fixmap_pgt
    git-bisect bad 033786969d1d1b5af12a32a19d3a760314d05329
    # bad: [c2fb47e5163096e238853ff551e69d24d4084633] x86/paravirt: call
    paravirt_pagetable_setup_{start, done}
    git-bisect bad c2fb47e5163096e238853ff551e69d24d4084633
    # bad: [adbb486a333bffdde8821d09dd5a75493a4abe8c] manual merge of
    auto-generic-ipi-next
    git-bisect bad adbb486a333bffdde8821d09dd5a75493a4abe8c


    anyway to convert tip/master to be one linear git tree locally.?

    YH
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  13. Re: [PATCH 05/05] x86: Rename paravirtualized TSC functions

    Ingo Molnar wrote:
    > then my guess would be on:
    >
    > 89d7bb5: x86_64: add workaround for no %gs-based percpu
    >


    I'd be surprised. That patch just moves some code around, and adds a
    couple of macros that only Xen uses.

    J
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread