x86: unify crash_32/64.c
Subsystems (3)
cover x86: unify crash_32/64.c
Hi,
I made patches to unify crash_32/64.c. There are three patches;
1. add lapic_shutdown for x86_64
2. add safe_smp_processor_id for x86_64
3. unify crash_32/64.c
I'm not sure that it's good to split to these patches.
I've compiled on both of 32bit and 64bit, and tested kdump on 64bit.
Thanks
Hiroshi Shimamoto
Re: [PATCH 1/3] x86: add lapic_shutdown for x86_64
From: Hiroshi Shimamoto <[email protected]>
--- arch/x86/kernel/apic_64.c | 14 ++++++++++++++ include/asm-x86/apic_64.h | 1 + 2 files changed, 15 insertions(+), 0 deletions(-)
arch/x86/kernel/apic_64.c +14 -0
@@ -287,6 +287,20 @@ void disable_local_APIC(void)apic_write (APIC_SPIV , value); } +void lapic_shutdown (void ) +{ +unsigned long flags; + +if (!cpu_has_apic) +return ; + +local_irq_save (flags); + +disable_local_APIC (); + +local_irq_restore (flags); +} +/* * This is to verify that we're looking at a real local APIC. * Check these against your board if the CPUs aren't getting
include/asm-x86/apic_64.h +1 -0
@@ -69,6 +69,7 @@ extern void clear_local_APIC (void);extern void connect_bsp_APIC (void );extern void disconnect_bsp_APIC (int virt_wire_setup);extern void disable_local_APIC (void ); +extern void lapic_shutdown (void );extern int verify_local_APIC (void );extern void cache_APIC_registers (void );extern void sync_Arb_IDs (void );
Signature · 1 line
1.5.2.3
Re: [PATCH 1/3] x86: add lapic_shutdown for x86_64
Quoted 21 lines · Hiroshi Shimamoto
From: Hiroshi Shimamoto <[email protected]>
Signed-off-by Hiroshi Shimamoto <[email protected]>--- arch/x86/kernel/apic_64.c | 14 ++++++++++++++ include/asm-x86/apic_64.h | 1 + 2 files changed, 15 insertions(+), 0 deletions(-)arch/x86/kernel/apic_64.c +5
-0@@ -287,6 +287,20 @@ void disable_local_APIC(void)apic_write (APIC_SPIV , value); } +void lapic_shutdown (void ) +{ +unsigned long flags; + +if (!cpu_has_apic)
arch/x86/kernel/apic_64.c void disable_local_APIC(void) · line 304
Quoted 10 lines
arch/x86/kernel/apic_64.c +9
-0+return ; + +local_irq_save (flags); + +disable_local_APIC (); + +local_irq_restore (flags); +} +/*
Do we really have to introduce this function for 64bit? I remember some issues were faced on i386 w.r.t kernel enabling the LAPIC against the wishes of BIOS hence kernel was disabling it while shutting down. No such problems were reported for x86_64 hence this function existed only for i386.
If that is the case, probably we don't have to introduce lapic_shutdown() for x86_64. Instead call lapic_shutdown() for X86_32, and disble_local_APIC() otherwise?
Thanks
Vivek
Re: [PATCH 1/3] x86: add lapic_shutdown for x86_64
Quoted 30 lines · Vivek Goyal
Quoted 29 lines · Hiroshi Shimamoto
From: Hiroshi Shimamoto <[email protected]>
Signed-off-by Hiroshi Shimamoto <[email protected]>--- arch/x86/kernel/apic_64.c | 14 ++++++++++++++ include/asm-x86/apic_64.h | 1 + 2 files changed, 15 insertions(+), 0 deletions(-)arch/x86/kernel/apic_64.c +13
-0@@ -287,6 +287,20 @@ void disable_local_APIC(void)apic_write (APIC_SPIV , value); } +void lapic_shutdown (void ) +{ +unsigned long flags; + +if (!cpu_has_apic) +return ; + +local_irq_save (flags); + +disable_local_APIC (); + +local_irq_restore (flags); +}
Quoted 8 lines
arch/x86/kernel/apic_64.c void disable_local_APIC(void) · line 304
Quoted 2 lines
arch/x86/kernel/apic_64.c +1
-0+/* Do we really have to introduce this function for 64bit? I remember some issues were faced on i386 w.r.t kernel enabling the LAPIC against the wishes of BIOS hence kernel was disabling it while shutting down. No such problems were reported for
x86_64hence this function existed only for i386.
Thanks for the comment. I didn't know the issues, so I'd simply added this function for unification.
Quoted 3 lines
If that is the case, probably we don't have to introduce
lapic_shutdown()forx86_64. Instead calllapic_shutdown()forX86_32, anddisble_local_APIC()otherwise?
I will do that. I was thinking which is good when posting these patches.
Thanks
Hiroshi Shimamoto
Re: [PATCH 1/3] x86: add lapic_shutdown for x86_64
Quoted 6 lines · Hiroshi Shimamoto
Quoted 5 lines
Do we really have to introduce this function for 64bit? I remember some issues were faced on i386 w.r.t kernel enabling the LAPIC against the wishes of BIOS hence kernel was disabling it while shutting down. No such problems were reported for
x86_64hence this function existed only for i386.
Quoted 8 lines
Thanks for the comment. I didn't know the issues, so I'd simply added this function for unification.
Quoted 3 lines
If that is the case, probably we don't have to introduce
lapic_shutdown()forx86_64. Instead calllapic_shutdown()forX86_32, anddisble_local_APIC()otherwise?I will do that. I was thinking which is good when posting these patches.
I'm a little concerned here. This sounds like forced unification. If we can't clean up the infrastructure so things are obviously better and cleanly factored for both architectures we should not unify the files.
As a general principle I would rather have two crudy files side by side the one super crudy file.
So for unification I suggest finally fixing this right and taking the apics completely out of the kexec on panic path.
Eric
_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 1/3] x86: add lapic_shutdown for x86_64
Quoted 19 lines · Eric W. Biederman
Quoted 5 lines · Hiroshi Shimamoto
Quoted 5 lines
Do we really have to introduce this function for 64bit? I remember some issues were faced on i386 w.r.t kernel enabling the LAPIC against the wishes of BIOS hence kernel was disabling it while shutting down. No such problems were reported for
x86_64hence this function existed only for i386.Quoted 7 lines
Thanks for the comment. I didn't know the issues, so I'd simply added this function for unification.
Quoted 3 lines
If that is the case, probably we don't have to introduce
lapic_shutdown()forx86_64. Instead calllapic_shutdown()forX86_32, anddisble_local_APIC()otherwise?I will do that. I was thinking which is good when posting these patches.
I'm a little concerned here. This sounds like forced unification. If we can't clean up the infrastructure so things are obviously better and cleanly factored for both architectures we should not unify the files.
Quoted 5 lines
As a general principle I would rather have two crudy files side by side the one super crudy file.
So for unification I suggest finally fixing this right and taking the apics completely out of the kexec on panic path.
Thanks for the suggestion.
But it's hard for me to imagine.
I'll try to consider about it.
Thanks
Hiroshi Shimamoto
PATCH 1/1 Revert x86: add lapic_shutdown for x86_64
In reply to Vivek Goyallapic_shutdown is useless on x86_64.
--- arch/x86/kernel/apic_64.c | 14 -------------- arch/x86/kernel/crash.c | 5 +++++ include/asm-x86/apic_64.h | 1 - 3 files changed, 5 insertions(+), 15 deletions(-)
arch/x86/kernel/apic_64.c +0 -14
@@ -287,20 +287,6 @@ void disable_local_APIC(void)apic_write (APIC_SPIV , value); } -void lapic_shutdown (void ) -{ -unsigned long flags; - -if (!cpu_has_apic) -return ; - -local_irq_save (flags); - -disable_local_APIC (); - -local_irq_restore (flags); -} -/* * This is to verify that we're looking at a real local APIC. * Check these against your board if the CPUs aren't getting
arch/x86/kernel/crash.c +5 -0
@@ -136,7 +136,12 @@ void machine_crash_shutdown(struct pt_regs *regs)/* Make a note of crashing cpu. Will be used in NMI callback.*/ crashing_cpu =safe_smp_processor_id ();nmi_shootdown_cpus (); +#ifdef CONFIG_X86_32 lapic_shutdown (); +#else +if (cpu_has_apic) +disable_local_APIC (); +#endif #if defined(CONFIG_X86_IO_APIC )disable_IO_APIC ();#endif
include/asm-x86/apic_64.h +0 -1
@@ -69,7 +69,6 @@ extern void clear_local_APIC (void);extern void connect_bsp_APIC (void );extern void disconnect_bsp_APIC (int virt_wire_setup);extern void disable_local_APIC (void ); -extern void lapic_shutdown (void );extern int verify_local_APIC (void );extern void cache_APIC_registers (void );extern void sync_Arb_IDs (void );
Signature · 1 line
1.5.3.4
Re: [PATCH] Revert x86: add lapic_shutdown for x86_64
Quoted 2 lines · On Mon, 29 Oct 2007 15:39:46 -0700 Hiroshi Shimamoto…
lapic_shutdownis useless onx86_64.
.... but since the goal is to get apic_32.c and apic_64.c to be more converging (to the point of becoming the same file)... isn't your patch going in the opposite direction?
Signature · 8 lines
If you want to reach me at my work email, use [email protected] For development, discussion and tips for power savings, visit http://www.lesswatts.org _______________________________________________ kexec mailing list [email protected] http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH] Revert x86: add lapic_shutdown for x86_64
Quoted 10 lines · Arjan van de Ven
Quoted 2 lines · On Mon, 29 Oct 2007 15:39:46 -0700 Hiroshi Shimamoto…
lapic_shutdownis useless onx86_64..... but since the goal is to get
apic_32.candapic_64.cto be more converging (to the point of becoming the same file)... isn't your patch going in the opposite direction?
Hmm, I'm not sure that this revert affects x86 unification.
Vivek said that probably we don't have to introduce lapic_shutdown() for 64bit. So I submitted this patch which reverts my previous post, it was applied before the comment.
Thanks
Hiroshi Shimamoto
Re: [PATCH] Revert x86: add lapic_shutdown for x86_64
Quoted 7 lines · Hiroshi Shimamoto
Quoted 6 lines · Arjan van de Ven
Quoted 2 lines · On Mon, 29 Oct 2007 15:39:46 -0700 Hiroshi Shimamoto…
lapic_shutdownis useless onx86_64.
Quoted 8 lines
Quoted 4 lines
.... but since the goal is to get
apic_32.candapic_64.cto be more converging (to the point of becoming the same file)... isn't your patch going in the opposite direction?Hmm, I'm not sure that this revert affects x86 unification.
Vivek said that probably we don't have to introducelapic_shutdown()for 64bit. So I submitted this patch which reverts my previous post, it was applied before the comment.
Don't worry, we sort this out. There is some inevitable friction loss for now, but we are getting closer. I gave the apic code some care to get a readable diff out of it. Result is in:
git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git cleanup
Thanks,
tglx
_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
PATCH 2/3 x86: add safe_smp_processor_id for x86_64
In reply to Hiroshi ShimamotoFrom: Hiroshi Shimamoto <[email protected]>
--- include/asm-x86/smp_64.h | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-)
include/asm-x86/smp_64.h +2 -0
@@ -76,6 +76,8 @@ extern unsigned __cpuinitdata disabled_cpus;#endif /* CONFIG_SMP */ +#define safe_smp_processor_id () smp_processor_id() +static inline int hard_smp_processor_id (void ) {/* we don't want to mark this access volatile - bad code generation */
Signature · 1 line
1.5.2.3
Re: [PATCH 2/3] x86: add safe_smp_processor_id for x86_64
Quoted 12 lines · Hiroshi Shimamoto
From: Hiroshi Shimamoto <[email protected]>
Signed-off-by Hiroshi Shimamoto <[email protected]>--- include/asm-x86/smp_64.h | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-)include/asm-x86/smp_64.h +0
-0
include/asm-x86/smp_64.h extern unsigned __cpuinitdata disabled_cpus; · line 80
Quoted 5 lines
include/asm-x86/smp_64.h +2
-0@@ -76,6 +76,8 @@ extern unsigned __cpuinitdata disabled_cpus;#endif /* CONFIG_SMP */ +#define safe_smp_processor_id () smp_processor_id() +
Can you please implement a patch for safe_smp_processor_id() instead of using smp_processor_id(). safe_smp_processor_id() was introduced to make sure that we are not dependent on the stack of threads after kernel has crashed instead read the apic id and convert it to cpu id with other data structures. This helped in stack overflow case.
Hardcoding it to smp_processor_id() will give the false impression.
Thanks
Vivek
Re: [PATCH 2/3] x86: add safe_smp_processor_id for x86_64
Quoted 25 lines · Vivek Goyal
Quoted 12 lines · Hiroshi Shimamoto
From: Hiroshi Shimamoto <[email protected]>
Signed-off-by Hiroshi Shimamoto <[email protected]>--- include/asm-x86/smp_64.h | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-)include/asm-x86/smp_64.h +0
-0include/asm-x86/smp_64.h extern unsigned __cpuinitdata disabled_cpus; · line 80
Quoted 5 lines
include/asm-x86/smp_64.h +2
-0@@ -76,6 +76,8 @@ extern unsigned __cpuinitdata disabled_cpus;#endif /* CONFIG_SMP */ +#define safe_smp_processor_id () smp_processor_id() +Can you please implement a patch for
safe_smp_processor_id()instead of usingsmp_processor_id().safe_smp_processor_id()was introduced to make sure that we are not dependent on the stack of threads after kernel has crashed instead read the apic id and convert it to cpu id with other data structures. This helped in stack overflow case.
Quoted 2 lines
Hardcoding it to
smp_processor_id()will give the false impression.
Just now Aneesh pointed that x86_64 using pda for retrieving processor id and not kernel stack.
I think it is fine then.
Thanks
Vivek
PATCH 3/3 x86: unify crash_32/64.c
In reply to Hiroshi ShimamotoFrom: Hiroshi Shimamoto <[email protected]>
Most of contents in crash are same.
--- arch/x86/kernel/Makefile_32 | 2 +- arch/x86/kernel/Makefile_64 | 2 +- arch/x86/kernel/crash.c | 144 +++++++++++++++++++++++++++++++++++++++++++ arch/x86/kernel/crash_32.c | 137 ---------------------------------------- arch/x86/kernel/crash_64.c | 135 ---------------------------------------- 5 files changed, 146 insertions(+), 274 deletions(-) create mode 100644 arch/x86/kernel/crash.c delete mode 100644 arch/x86/kernel/crash_32.c delete mode 100644 arch/x86/kernel/crash_64.c
arch/x86/kernel/Makefile_32 +1 -1
@@ -26,7 +26,7 @@ obj-$(CONFIG_X86_MPPARSE) += mpparse_32.o obj-$(CONFIG_X86_LOCAL_APIC) += apic_32.o nmi_32.o obj-$(CONFIG_X86_IO_APIC) += io_apic_32.o obj-$(CONFIG_X86_REBOOTFIXUPS) += reboot_fixups_32.o -obj-$(CONFIG_KEXEC) += machine_kexec_32.o relocate_kernel_32.o crash_32.o +obj-$(CONFIG_KEXEC) += machine_kexec_32.o relocate_kernel_32.o crash.o obj-$(CONFIG_CRASH_DUMP) += crash_dump_32.o obj-$(CONFIG_X86_NUMAQ) += numaq_32.o obj-$(CONFIG_X86_SUMMIT_NUMA) += summit_32.o
arch/x86/kernel/Makefile_64 +1 -1
@@ -23,7 +23,7 @@ obj-$(CONFIG_X86_CPUID) += cpuid.o obj-$(CONFIG_SMP) += smp_64.o smpboot_64.o trampoline_64.o tsc_sync.o obj-y += apic_64.o nmi_64.o obj-y += io_apic_64.o mpparse_64.o genapic_64.o genapic_flat_64.o -obj-$(CONFIG_KEXEC) += machine_kexec_64.o relocate_kernel_64.o crash_64.o +obj-$(CONFIG_KEXEC) += machine_kexec_64.o relocate_kernel_64.o crash.o obj-$(CONFIG_CRASH_DUMP) += crash_dump_64.o obj-$(CONFIG_PM) += suspend_64.o obj-$(CONFIG_HIBERNATION) += suspend_asm_64.o
arch/x86/kernel/crash.c new file +144 -0
144 lines not on this page · raw message
arch/x86/kernel/crash_32.c deleted +0 -137
137 lines not on this page · raw message
arch/x86/kernel/crash_64.c deleted +0 -135
135 lines not on this page · raw message
Signature · 1 line
1.5.2.3
Thomas Gleixner
AppliedQuoted 9 lines · Hiroshi Shimamoto
Hi,
I made patches to unify crash_32/64.c. There are three patches;
1. addlapic_shutdownforx86_64
2. addsafe_smp_processor_idforx86_64
3. unify crash_32/64.cI'm not sure that it's good to split to these patches.
It's fine. So the steps leading to unification are clear.
Applied. Thanks,
tglx
_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
Quoted 8 lines · Hiroshi Shimamoto
Hi,
I made patches to unify crash_32/64.c. There are three patches;
1. addlapic_shutdownforx86_64
2. addsafe_smp_processor_idforx86_64
3. unify crash_32/64.c
Quoted 5 lines
I'm not sure that it's good to split to these patches.
I've compiled on both of 32bit and 64bit, and tested kdump on 64bit.
Hi Hiroshi,
Thanks for the patches. Can you please also test it on 32bit to make sure nothing is broken.
Thanks
Vivek
Quoted 11 lines · Vivek Goyal
Quoted 10 lines · Hiroshi Shimamoto
Hi,
I made patches to unify crash_32/64.c. There are three patches;
1. addlapic_shutdownforx86_64
2. addsafe_smp_processor_idforx86_64
3. unify crash_32/64.cI'm not sure that it's good to split to these patches.
Quoted 8 lines
Quoted 3 lines
I've compiled on both of 32bit and 64bit, and tested kdump on 64bit.
Hi Hiroshi,
Thanks for the patches. Can you please also test it on 32bit to make sure nothing is broken.
Okay, I'll test it on 32bit.
A build problem already has been found on 32bit.
Thanks,
Hiroshi
_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
Quoted 15 lines · Hiroshi Shimamoto
Quoted 14 lines · Vivek Goyal
Quoted 13 lines · Hiroshi Shimamoto
Hi,
I made patches to unify crash_32/64.c. There are three patches;
1. addlapic_shutdownforx86_64
2. addsafe_smp_processor_idforx86_64
3. unify crash_32/64.cI'm not sure that it's good to split to these patches.
I've compiled on both of 32bit and 64bit, and tested kdump on 64bit.
Quoted 8 lines
Quoted 4 lines
Hi Hiroshi,
Thanks for the patches. Can you please also test it on 32bit to make sure nothing is broken.
Okay, I'll test it on 32bit.
A build problem already has been found on 32bit.
I'm now testing crash on 32bit, but there is an issue before applying the patches. My machine stopped at checking 'hlt' after kexec, showing below message.
CPU: Intel(R) Xeon(TM) CPU 3.80GHz stepping 0a
Checking 'hlt' instruction...
v2.6.23.1 works fine for 1st kernel.
I'm investigating it..
Thanks
Hiroshi Shimamoto
Quoted 9 lines
I'm now testing crash on 32bit, but there is an issue before applying the patches. My machine stopped at checking 'hlt' after kexec, showing below message.
CPU: Intel(R) Xeon(TM) CPU 3.80GHz stepping 0a
Checking 'hlt' instruction...v2.6.23.1 works fine for 1st kernel.
I'm investigating it..
I found that the following patch makes my machine stopped. bfe0c1cc6456bba1f4e3cc1fe29c0ea578ac763a
x86: HPET force enable for ICH5
It means that after applied this patch, HPET is enabled automatically on 1st kernel and after crash/kexec the 2nd kernel stopped at checking 'hlt'.
I also tested the latest kernel(2.6.24-rc1-gec3b67c1). Boot parameter "nohpet" resolves this issue and kdump works well on 32bit.
So I guess HPET affects this.
But I don't know why 64bit kernel with HPET is OK.
Thanks
Hiroshi Shimamoto
On Fri, 26 Oct 2007, Hiroshi Shimamoto wrote:
Added Venki to CC
Quoted 18 lines
Quoted 7 lines
I'm now testing crash on 32bit, but there is an issue before applying the patches. My machine stopped at checking 'hlt' after kexec, showing below message.
CPU: Intel(R) Xeon(TM) CPU 3.80GHz stepping 0a
Checking 'hlt' instruction...v2.6.23.1 works fine for 1st kernel.
Quoted 1 line
I'm investigating it..
I found that the following patch makes my machine stopped.
bfe0c1cc6456bba1f4e3cc1fe29c0ea578ac763a
x86: HPET force enable for ICH5It means that after applied this patch, HPET is enabled automatically on 1st kernel and after crash/kexec the 2nd kernel stopped at checking 'hlt'.
Quoted 5 lines
I also tested the latest kernel(2.6.24-rc1-gec3b67c1). Boot parameter "nohpet" resolves this issue and kdump works well on 32bit.
So I guess HPET affects this.
But I don't know why 64bit kernel with HPET is OK.
Hmm. Does the 64 bit code shutdown HPET and restore the IRQ routing to PIT and 32 bit is missing this ?
tglx
_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
Quoted 21 lines · Thomas Gleixner
On Fri, 26 Oct 2007, Hiroshi Shimamoto wrote:
Added Venki to CC
Quoted 17 lines
Quoted 7 lines
I'm now testing crash on 32bit, but there is an issue before applying the patches. My machine stopped at checking 'hlt' after kexec, showing below message.
CPU: Intel(R) Xeon(TM) CPU 3.80GHz stepping 0a
Checking 'hlt' instruction...v2.6.23.1 works fine for 1st kernel.
Quoted 1 line
I'm investigating it..
I found that the following patch makes my machine stopped.
bfe0c1cc6456bba1f4e3cc1fe29c0ea578ac763a
x86: HPET force enable for ICH5It means that after applied this patch, HPET is enabled automatically on 1st kernel and after crash/kexec the 2nd kernel stopped at checking 'hlt'.
Quoted 8 lines
Quoted 5 lines
I also tested the latest kernel(2.6.24-rc1-gec3b67c1). Boot parameter "nohpet" resolves this issue and kdump works well on 32bit.
So I guess HPET affects this.
But I don't know why 64bit kernel with HPET is OK.Hmm. Does the 64 bit code shutdown HPET and restore the IRQ routing to PIT and 32 bit is missing this ?
Sorry, I'm not sure how I can get these informations. Can you please tell me what I should do?
I'll continue to dig the issue.
I also have the following message. ..MP-BIOS bug: 8254 timer not connected to IO-APIC
Kernel panic - not syncing: IO-APIC + timer doesn't work! Try using the 'noapic' kernel parameter
It appeared only on 64bit and the 2nd kernel without boot parameter noapic.
Thanks
Hiroshi Shimamoto
Quoted 27 lines · Hiroshi Shimamoto
Quoted 26 lines · Thomas Gleixner
On Fri, 26 Oct 2007, Hiroshi Shimamoto wrote:
Added Venki to CC
Quoted 22 lines
Quoted 7 lines
I'm now testing crash on 32bit, but there is an issue before applying the patches. My machine stopped at checking 'hlt' after kexec, showing below message.
CPU: Intel(R) Xeon(TM) CPU 3.80GHz stepping 0a
Checking 'hlt' instruction...v2.6.23.1 works fine for 1st kernel.
Quoted 1 line
I'm investigating it..
I found that the following patch makes my machine stopped.
bfe0c1cc6456bba1f4e3cc1fe29c0ea578ac763a
x86: HPET force enable for ICH5It means that after applied this patch, HPET is enabled automatically on 1st kernel and after crash/kexec the 2nd kernel stopped at checking 'hlt'.
I also tested the latest kernel(2.6.24-rc1-gec3b67c1). Boot parameter "nohpet" resolves this issue and kdump works well on 32bit.
So I guess HPET affects this.
But I don't know why 64bit kernel with HPET is OK.
Quoted 6 lines
Quoted 2 lines
Hmm. Does the 64 bit code shutdown HPET and restore the IRQ routing to PIT and 32 bit is missing this ?
Sorry, I'm not sure how I can get these informations. Can you please tell me what I should do?
I'll continue to dig the issue.
I attached the .config files and console logs.
config32/64 are for 1st kernel, and cap32/64 are for 2nd capture kernel. kdump1.log is boot with nohpet on 32bit.
kdump2.log is boot without nohpet on 32bit and the 2nd kernel hangs. kdump3.log is on 64bit. And the first kdump is failed because of without noapic.
Thanks
Hiroshi Shimamoto