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

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

[Alok Kataria]

[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 <akataria@vmware.com>

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 <akataria@vmware.com>
Signed-off-by: Dan Hecht <dhecht@vmware.com>

---

 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_CYCLES_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);

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

[Ingo Molnar]

* Alok Kataria <akataria@vmware.com> 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

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

[Yinghai Lu]

On Tue, Jul 8, 2008 at 11:13 PM, Ingo Molnar <mingo@elte.hu> wrote:
>
> * Alok Kataria <akataria@vmware.com> 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: [<ffffffff80253b17>] 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:[<ffffffff80253b17>]  [<ffffffff80253b17>]
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:
 [<ffffffff80256591>] dequeue_task_fair+0x5f/0x7e
 [<ffffffff80516fc5>] ? __first_cpu+0x26/0x49
 [<ffffffff80252792>] dequeue_task+0xce/0xf0
 [<ffffffff80252835>] deactivate_task+0x31/0x50
 [<ffffffff80252b93>] pull_task+0x2c/0x78
 [<ffffffff80254c04>] load_balance_fair+0x18d/0x277
 [<ffffffff80a49f02>] schedule+0x3db/0x962
 [<ffffffff802c0f0f>] ? vmstat_update+0x0/0x5e
 [<ffffffff802787c9>] ? schedule_delayed_work+0x31/0x48
 [<ffffffff802779ee>] worker_thread+0xbb/0x114
 [<ffffffff8027c5ec>] ? autoremove_wake_function+0x0/0x63
 [<ffffffff80277933>] ? worker_thread+0x0/0x114
 [<ffffffff8027c147>] kthread+0x61/0xa4
 [<ffffffff802614e5>] ? schedule_tail+0x36/0x81
 [<ffffffff8022b509>] child_rip+0xa/0x11
 [<ffffffff8027c0e6>] ? kthread+0x0/0xa4
 [<ffffffff8022b4ff>] ? 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  [<ffffffff80253b17>] hrtick_start_fair+0x89/0x173
 RSP <ffff88082481fbd0>
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

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

[Alok Kataria]

On Wed, 2008-07-09 at 00:20 -0700, Yinghai Lu wrote:
> On Tue, Jul 8, 2008 at 11:13 PM, Ingo Molnar <mingo@elte.hu> wrote:
> >
> > * Alok Kataria <akataria@vmware.com> 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: [<ffffffff80253b17>] 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:[<ffffffff80253b17>]  [<ffffffff80253b17>]
> 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:
>  [<ffffffff80256591>] dequeue_task_fair+0x5f/0x7e
>  [<ffffffff80516fc5>] ? __first_cpu+0x26/0x49
>  [<ffffffff80252792>] dequeue_task+0xce/0xf0
>  [<ffffffff80252835>] deactivate_task+0x31/0x50
>  [<ffffffff80252b93>] pull_task+0x2c/0x78
>  [<ffffffff80254c04>] load_balance_fair+0x18d/0x277
>  [<ffffffff80a49f02>] schedule+0x3db/0x962
>  [<ffffffff802c0f0f>] ? vmstat_update+0x0/0x5e
>  [<ffffffff802787c9>] ? schedule_delayed_work+0x31/0x48
>  [<ffffffff802779ee>] worker_thread+0xbb/0x114
>  [<ffffffff8027c5ec>] ? autoremove_wake_function+0x0/0x63
>  [<ffffffff80277933>] ? worker_thread+0x0/0x114
>  [<ffffffff8027c147>] kthread+0x61/0xa4
>  [<ffffffff802614e5>] ? schedule_tail+0x36/0x81
>  [<ffffffff8022b509>] child_rip+0xa/0x11
>  [<ffffffff8027c0e6>] ? kthread+0x0/0xa4
>  [<ffffffff8022b4ff>] ? 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  [<ffffffff80253b17>] hrtick_start_fair+0x89/0x173
>  RSP <ffff88082481fbd0>
> 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

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

[Yinghai Lu]

On Wed, Jul 9, 2008 at 10:30 AM, Alok Kataria <akataria@vmware.com> wrote:
> On Wed, 2008-07-09 at 00:20 -0700, Yinghai Lu wrote:
>> On Tue, Jul 8, 2008 at 11:13 PM, Ingo Molnar <mingo@elte.hu> wrote:
>> >
>> > * Alok Kataria <akataria@vmware.com> 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: [<ffffffff80253b17>] 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:[<ffffffff80253b17>]  [<ffffffff80253b17>]
>> 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:
>>  [<ffffffff80256591>] dequeue_task_fair+0x5f/0x7e
>>  [<ffffffff80516fc5>] ? __first_cpu+0x26/0x49
>>  [<ffffffff80252792>] dequeue_task+0xce/0xf0
>>  [<ffffffff80252835>] deactivate_task+0x31/0x50
>>  [<ffffffff80252b93>] pull_task+0x2c/0x78
>>  [<ffffffff80254c04>] load_balance_fair+0x18d/0x277
>>  [<ffffffff80a49f02>] schedule+0x3db/0x962
>>  [<ffffffff802c0f0f>] ? vmstat_update+0x0/0x5e
>>  [<ffffffff802787c9>] ? schedule_delayed_work+0x31/0x48
>>  [<ffffffff802779ee>] worker_thread+0xbb/0x114
>>  [<ffffffff8027c5ec>] ? autoremove_wake_function+0x0/0x63
>>  [<ffffffff80277933>] ? worker_thread+0x0/0x114
>>  [<ffffffff8027c147>] kthread+0x61/0xa4
>>  [<ffffffff802614e5>] ? schedule_tail+0x36/0x81
>>  [<ffffffff8022b509>] child_rip+0xa/0x11
>>  [<ffffffff8027c0e6>] ? kthread+0x0/0xa4
>>  [<ffffffff8022b4ff>] ? 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  [<ffffffff80253b17>] hrtick_start_fair+0x89/0x173
>>  RSP <ffff88082481fbd0>
>> 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

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

[Ingo Molnar]

* Yinghai Lu <yhlu.kernel@gmail.com> wrote:

> On Wed, Jul 9, 2008 at 10:30 AM, Alok Kataria <akataria@vmware.com> wrote:
> > On Wed, 2008-07-09 at 00:20 -0700, Yinghai Lu wrote:
> >> On Tue, Jul 8, 2008 at 11:13 PM, Ingo Molnar <mingo@elte.hu> wrote:
> >> >
> >> > * Alok Kataria <akataria@vmware.com> 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: [<ffffffff80253b17>] 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:[<ffffffff80253b17>]  [<ffffffff80253b17>]
> >> 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:
> >>  [<ffffffff80256591>] dequeue_task_fair+0x5f/0x7e
> >>  [<ffffffff80516fc5>] ? __first_cpu+0x26/0x49
> >>  [<ffffffff80252792>] dequeue_task+0xce/0xf0
> >>  [<ffffffff80252835>] deactivate_task+0x31/0x50
> >>  [<ffffffff80252b93>] pull_task+0x2c/0x78
> >>  [<ffffffff80254c04>] load_balance_fair+0x18d/0x277
> >>  [<ffffffff80a49f02>] schedule+0x3db/0x962
> >>  [<ffffffff802c0f0f>] ? vmstat_update+0x0/0x5e
> >>  [<ffffffff802787c9>] ? schedule_delayed_work+0x31/0x48
> >>  [<ffffffff802779ee>] worker_thread+0xbb/0x114
> >>  [<ffffffff8027c5ec>] ? autoremove_wake_function+0x0/0x63
> >>  [<ffffffff80277933>] ? worker_thread+0x0/0x114
> >>  [<ffffffff8027c147>] kthread+0x61/0xa4
> >>  [<ffffffff802614e5>] ? schedule_tail+0x36/0x81
> >>  [<ffffffff8022b509>] child_rip+0xa/0x11
> >>  [<ffffffff8027c0e6>] ? kthread+0x0/0xa4
> >>  [<ffffffff8022b4ff>] ? 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  [<ffffffff80253b17>] hrtick_start_fair+0x89/0x173
> >>  RSP <ffff88082481fbd0>
> >> 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

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

[Yinghai Lu]

On Thu, Jul 10, 2008 at 12:22 AM, Ingo Molnar <mingo@elte.hu> wrote:
>
> * Yinghai Lu <yhlu.kernel@gmail.com> wrote:
>
>> On Wed, Jul 9, 2008 at 10:30 AM, Alok Kataria <akataria@vmware.com> wrote:
>> > On Wed, 2008-07-09 at 00:20 -0700, Yinghai Lu wrote:
>> >> On Tue, Jul 8, 2008 at 11:13 PM, Ingo Molnar <mingo@elte.hu> wrote:
>> >> >
>> >> > * Alok Kataria <akataria@vmware.com> 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: [<ffffffff80253b17>] 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:[<ffffffff80253b17>]  [<ffffffff80253b17>]
>> >> 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:
>> >>  [<ffffffff80256591>] dequeue_task_fair+0x5f/0x7e
>> >>  [<ffffffff80516fc5>] ? __first_cpu+0x26/0x49
>> >>  [<ffffffff80252792>] dequeue_task+0xce/0xf0
>> >>  [<ffffffff80252835>] deactivate_task+0x31/0x50
>> >>  [<ffffffff80252b93>] pull_task+0x2c/0x78
>> >>  [<ffffffff80254c04>] load_balance_fair+0x18d/0x277
>> >>  [<ffffffff80a49f02>] schedule+0x3db/0x962
>> >>  [<ffffffff802c0f0f>] ? vmstat_update+0x0/0x5e
>> >>  [<ffffffff802787c9>] ? schedule_delayed_work+0x31/0x48
>> >>  [<ffffffff802779ee>] worker_thread+0xbb/0x114
>> >>  [<ffffffff8027c5ec>] ? autoremove_wake_function+0x0/0x63
>> >>  [<ffffffff80277933>] ? worker_thread+0x0/0x114
>> >>  [<ffffffff8027c147>] kthread+0x61/0xa4
>> >>  [<ffffffff802614e5>] ? schedule_tail+0x36/0x81
>> >>  [<ffffffff8022b509>] child_rip+0xa/0x11
>> >>  [<ffffffff8027c0e6>] ? kthread+0x0/0xa4
>> >>  [<ffffffff8022b4ff>] ? 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  [<ffffffff80253b17>] hrtick_start_fair+0x89/0x173
>> >>  RSP <ffff88082481fbd0>
>> >> 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

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

[Ingo Molnar]

* Yinghai Lu <yhlu.kernel@gmail.com> 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

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

[Yinghai Lu]

On Thu, Jul 10, 2008 at 12:50 AM, Ingo Molnar <mingo@elte.hu> wrote:
>
> * Yinghai Lu <yhlu.kernel@gmail.com> 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

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

[Yinghai Lu]

On Thu, Jul 10, 2008 at 1:04 AM, Yinghai Lu <yhlu.kernel@gmail.com> wrote:
> On Thu, Jul 10, 2008 at 12:50 AM, Ingo Molnar <mingo@elte.hu> wrote:
>>
>> * Yinghai Lu <yhlu.kernel@gmail.com> 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:
 [<ffffffff80268672>] ? do_exit+0x84/0x6ce
 [<ffffffff80268d42>] ? do_group_exit+0x86/0xb3
 [<ffffffff802745b8>] ? get_signal_to_deliver+0x309/0x33d
 [<ffffffff80272877>] ? send_signal+0x23b/0x26e
 [<ffffffff802297e8>] ? do_notify_resume+0xd3/0x8fd
 [<ffffffff802c292b>] ? print_vma_addr+0x110/0x12f
 [<ffffffff80a4f3af>] ? do_page_fault+0x8ac/0x8fe
 [<ffffffff8022a4f4>] ? mcount_call+0x5/0x31
 [<ffffffff8022a4f4>] ? mcount_call+0x5/0x31
 [<ffffffff80270d34>] ? sigprocmask+0xbe/0xf6
 [<ffffffff8022ac78>] ? retint_signal+0x3d/0x85

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

[Ingo Molnar]

* Yinghai Lu <yhlu.kernel@gmail.com> 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

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

[Yinghai Lu]

On Thu, Jul 10, 2008 at 1:11 AM, Yinghai Lu <yhlu.kernel@gmail.com> wrote:
> On Thu, Jul 10, 2008 at 1:04 AM, Yinghai Lu <yhlu.kernel@gmail.com> wrote:
>> On Thu, Jul 10, 2008 at 12:50 AM, Ingo Molnar <mingo@elte.hu> wrote:
>>>
>>> * Yinghai Lu <yhlu.kernel@gmail.com> 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:
>  [<ffffffff80268672>] ? do_exit+0x84/0x6ce
>  [<ffffffff80268d42>] ? do_group_exit+0x86/0xb3
>  [<ffffffff802745b8>] ? get_signal_to_deliver+0x309/0x33d
>  [<ffffffff80272877>] ? send_signal+0x23b/0x26e
>  [<ffffffff802297e8>] ? do_notify_resume+0xd3/0x8fd
>  [<ffffffff802c292b>] ? print_vma_addr+0x110/0x12f
>  [<ffffffff80a4f3af>] ? do_page_fault+0x8ac/0x8fe
>  [<ffffffff8022a4f4>] ? mcount_call+0x5/0x31
>  [<ffffffff8022a4f4>] ? mcount_call+0x5/0x31
>  [<ffffffff80270d34>] ? sigprocmask+0xbe/0xf6
>  [<ffffffff8022ac78>] ? 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

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

[Jeremy Fitzhardinge]

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