On Fri, Jan 05, 2007 at 09:37:22AM -0500, Benjamin Romer wrote:
> As you suspected, the vector field was not necessary for the timer to
> work in the kexec kernel - I only needed to reset the logical
> destination. I've emailed our platform group to get some more
> information about how our IO-APIC is set up. I've also attached the
> successful boot log, with print_IO_APIC() modified to call
> print_local_APIC() first. I'll post again when I've got some information
> about the IO-APIC.
>
Hi Ben,
I was going thorough the successful boot log. Looks like you have printed
the LAPIC value for second kernel (after your modification of setting
the logical id field to 20 in IOAPIC).
Some thoughts.
printing local APIC contents on CPU#0/32:
... APIC ID: 20000000 (20)
... APIC VERSION: 00050014
... APIC TASKPRI: 00000000 (00)
... APIC ARBPRI: 00000000 (00)
... APIC PROCPRI: 00000000
... APIC EOI: 00000000
... APIC RRR: 00000000
... APIC LDR: 20000000
... APIC DFR: ffffffff
Here APIC ID is set to 0x20 (decimal 32). If you are using kexec you would
relocatable to boot cpu and generally it would have APIC ID 0. I am not sure
if it is always true.
Looking at LDR and DFR. They seem to have been setup for flat logical mode.
Now we are not sure that the message IOAPIC sent on the bus, whether it
mentioned physical destination mode or logical destination mode. If it
was physical destination mode (which it should be based on IOAPIC settings),
then APIC would compare APIC ID register value with MDA contained in the
message.
If it is logical destination mode, then APIC will do logical AND of LDR
register top 8 bits to determine if it should be receiving the message.
Anyway, What my concern here is, that when we down, we assume that IOAPIC
will be working in physical destination mode and set the physical apic id
field to APIC ID.
entry.dest.physical.physical_dest =
GET_APIC_ID(apic_read(APIC_ID));
Was it set properly in your case?
Another thing I just realized that in IOAPIC, physical apic id field seems
to be 4bit only. So if can address up to 16 APICs only. But in this case
APIC ID is 32, so it will overflow?
My hunch is that in your setup LPAIC/IOAPIC is supporting 8bit APIC
ids in physical destination mode. And at boot up IOAPIC/LAPIC are working
in physcial destination mode only.
Somehow APIC ID is 32 for the boot CPU. In software we are trying to setup
32 in 4bit field. Which will overflow. That's the reason you don't get
interrupts in second kernel and problem gets rectified when you set all the
8bits to 32 using logical field of the union.
I think try modifying kexec code so that you go down and boot on a cpu whose
APIC ID is between 0-15 and things might work without modifications.
Thanks
Vivek
_______________________________________________
fastboot mailing list
[email protected]
https://lists.osdl.org/mailman/listinfo/fastboot
