After a lot of internal discussion with other Unisys employees, I think I've finally got this all figured out. The problem is one line of code in the disable_IO_APIC() function, that says this:
entry.dest.physical.physical_dest = GET_APIC_ID(apic_read(APIC_ID)); The problem seems to be that when the kernel was previously updated to take advantage of the 8-bit IO-APIC physical destination field defined in Intel's xAPIC spec on page 334, downloadable from ftp://download.intel.com/design/chipsets/e8501/datashts/30962001.pdf , this particular piece of code was missed. According to my co-worker Natalie Protasevich, the Linux kernel was updated back when the Xeon processor first came out to use the larger field by merely switching the code to use the logical destination field for everything. (Personally, I would have removed the union from the structure and put in new fields with new names to make the change more obvious, but it's not my code. :) ) Anyway, what it comes down to is we need to switch that one line in disable_IO_APIC() to read entry.dest.logical.logical_dest = GET_APIC_ID(apic_read(APIC_ID)); Natalie also mentioned an upstream patch from Eric Biederman that may also address our problem, but I still need to confirm that it does before I can close things up. I'll post more when I've got it tested. :) -- Ben On Tue, 2007-01-09 at 15:30 -0800, Randy Dunlap wrote: > On Tue, 09 Jan 2007 12:26:20 -0500 Benjamin Romer wrote: > > > While working with the IO-APIC problem I've been having on the ES-7000, > > I noticed something that confuses me about the IO-APIC table entry > > structure. If you look in include/asm-x86_64/io_apic.h, it lists the > > destination field as a union declared like this: > > > > union { struct { __u32 > > __reserved_1 : 24, > > physical_dest : 4, > > __reserved_2 : 4; > > } physical; > > > > struct { __u32 > > __reserved_1 : 24, > > logical_dest : 8; > > } logical; > > } dest; > > > > So, when calling print_IO_APIC(), I would have thought that there would > > be overlap in the Log and Phy fields if there's data in the logical_dest > > field. For instance, my IO-APIC prints out > > > > .... IRQ redirection table: > > NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect: > > 00 020 00 0 0 0 0 0 0 7 00 > > ^^^ ^^ > > > > Since there's an 0x020 in the logical_dest field, shouldn't the Phy > > field be printing out as 0x02, rather than 0x00? Is there a byte > > ordering issue here maybe? > > or a bitfield ordering issue? > > How about printing out the values of physical and logical (32 bits > each) for us? > > --- > ~Randy _______________________________________________ fastboot mailing list [email protected] https://lists.osdl.org/mailman/listinfo/fastboot
