[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 <[email protected]>
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 <[email protected]>
Signed-off-by: Dan Hecht <[email protected]>
---
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);
* Alok Kataria <[email protected]> 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
On Tue, Jul 8, 2008 at 11:13 PM, Ingo Molnar <[email protected]> wrote:
>
> * Alok Kataria <[email protected]> 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
On Wed, 2008-07-09 at 00:20 -0700, Yinghai Lu wrote:
> On Tue, Jul 8, 2008 at 11:13 PM, Ingo Molnar <[email protected]> wrote:
> >
> > * Alok Kataria <[email protected]> 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
On Wed, Jul 9, 2008 at 10:30 AM, Alok Kataria <[email protected]> wrote:
> On Wed, 2008-07-09 at 00:20 -0700, Yinghai Lu wrote:
>> On Tue, Jul 8, 2008 at 11:13 PM, Ingo Molnar <[email protected]> wrote:
>> >
>> > * Alok Kataria <[email protected]> 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
* Yinghai Lu <[email protected]> wrote:
> On Wed, Jul 9, 2008 at 10:30 AM, Alok Kataria <[email protected]> wrote:
> > On Wed, 2008-07-09 at 00:20 -0700, Yinghai Lu wrote:
> >> On Tue, Jul 8, 2008 at 11:13 PM, Ingo Molnar <[email protected]> wrote:
> >> >
> >> > * Alok Kataria <[email protected]> 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
On Thu, Jul 10, 2008 at 12:22 AM, Ingo Molnar <[email protected]> wrote:
>
> * Yinghai Lu <[email protected]> wrote:
>
>> On Wed, Jul 9, 2008 at 10:30 AM, Alok Kataria <[email protected]> wrote:
>> > On Wed, 2008-07-09 at 00:20 -0700, Yinghai Lu wrote:
>> >> On Tue, Jul 8, 2008 at 11:13 PM, Ingo Molnar <[email protected]> wrote:
>> >> >
>> >> > * Alok Kataria <[email protected]> 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
* Yinghai Lu <[email protected]> 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
On Thu, Jul 10, 2008 at 12:50 AM, Ingo Molnar <[email protected]> wrote:
>
> * Yinghai Lu <[email protected]> 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
On Thu, Jul 10, 2008 at 1:04 AM, Yinghai Lu <[email protected]> wrote:
> On Thu, Jul 10, 2008 at 12:50 AM, Ingo Molnar <[email protected]> wrote:
>>
>> * Yinghai Lu <[email protected]> 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
* Yinghai Lu <[email protected]> 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
On Thu, Jul 10, 2008 at 1:11 AM, Yinghai Lu <[email protected]> wrote:
> On Thu, Jul 10, 2008 at 1:04 AM, Yinghai Lu <[email protected]> wrote:
>> On Thu, Jul 10, 2008 at 12:50 AM, Ingo Molnar <[email protected]> wrote:
>>>
>>> * Yinghai Lu <[email protected]> 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
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