Messages in this thread | | | From | (Eric W. Biederman) | Subject | Re: [PATCH] kexec: force x86_64 arches to boot kdump kernels on boot cpu | Date | Wed, 28 Nov 2007 16:27:43 -0700 |
| |
Neil Horman <nhorman@redhat.com> writes:
> On Wed, Nov 28, 2007 at 12:42:22PM -0700, Eric W. Biederman wrote: >> Vivek Goyal <vgoyal@redhat.com> writes: >> >> > Ok. Got it. So in this case we route the interrupts directly through LAPIC >> > and put LVT0 in ExtInt mode and IOAPIC is bypassed. >> > >> > I am looking at Intel Multiprocessor specification v1.4 and as per figure >> > 3-3 on page 3-9, 8259 is connected to LINTIN0 line, which in turn is >> > connected to LINTIN0 pin on all processors. If that is the case, even in >> > this mode, all the CPU should see the timer interrupts (which is coming >> > from 8259)? >> >> However things are implemented completely differently now. I don't think >> the coherent hypertransport domain of AMD processors actually routes >> ExtINT interrupts to all cpus but instead one (the default route?) is >> picked. >> > > http://www.hypertransport.org/docs/tech/HTC20051222-0046-0008-Final-4-21-06.pdf > Table 143 suggest to me that legacy interrupts should be routed to all cpus, > which certainly doesn't seem to be the case in this situation. Perhaps Nvidia > goofed on that part of the specification?
Once it hits the coherent hypertransport fabric only AMD has control. The packet does not have a destination field that could specify which cpu. So Nvidia could not have goofed. It is a magic property of the coherent hypertransport domain as which cpu gets it.
>> So I think for the kdump case we pretty much need to use an IOAPIC >> in virtual wire mode for recent AMD systems. >> >> For current Intel systems I believe either scenario still works. >> >> > Can you print the LAPIC registers (print_local_APIC) during normal boot >> > and during kdump boot and paste here? >> >> It's worth a look. >> >> I still think we need to just use apic mode at kernel startup, and >> be done with it. >> > Certainly, this seems like the best solution long term. > > So I'm looking at the implementation for 64 bit system, and it seems a little > cleaner than 32 bit setup. I'm wondering if we can just call setup_IO_APIC > immediately after init_IRQ in start_kernel? Could it be that straightforward?
Pretty much.
The essence of what I did last round was put at the end of init_IRQ():
if (!disable_apic && cpu_has_apic) { /* * Switch to APIC mode. */ setup_local_APIC();
/* * Now start the IO-APICs */ if (smp_found_config && !skip_ioapic_setup && nr_ioapics) setup_IO_APIC(); else nr_ioapics = 0; }
Beyond that it is just dotting i's and crossing t's.
Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |