Neil Horman <[email protected]> writes:
> On Wed, Nov 28, 2007 at 12:42:22PM -0700, Eric W. Biederman wrote:
>> Vivek Goyal <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
