Andi Kleen <ak@suse.de> writes:Possible. So far I have not seen a hardware setup that would force interrupts to cpu #0 in legacy mode. But I would not be truly surprised if it happened that there was hardware that only worked that way. (Do not use legacy mode in the kdump kernel. removing it from shutdown is just minor optimization) Exactly. If we can work out the details that should be a much more reliable mode of operation. My real problem was the failure case was obscure (a bad interaction with ACPI on Linus's laptop) and I didn't have the time to track it down when it showed up. My patch had two parts. Some cleanups to enable the code to be enabled early, and the actually early enable. I figure if we can get the cleanups in one major kernel version and then in the next enable the apic mode before we start getting interrupts we should be in good shape. I expect with x86 becoming an embedded platform with multiple cpus we may start seeing systems that don't actually support legacy PIC mode for interrupt delivery. Eric -
| Parag Warudkar | BUG: soft lockup - CPU#1 stuck for 15s! [swapper:0] |
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Greg Kroah-Hartman | [PATCH 010/196] Chinese: add translation of Codingstyle |
| Andrew Morton | -mm merge plans for 2.6.23 |
git: | |
| Gerrit Renker | [PATCH 24/37] dccp: Processing Confirm options |
| David Miller | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Alexey Dobriyan | Re: [GIT]: Networking |
| david | Re: iptables very slow after commit 784544739a25c30637397ace5489eeb6e15d7d49 |
