>>> On 05.12.16 at 05:30, wrote:
> On 12/1/16 18:58, Jan Beulich wrote:
> On 01.12.16 at 12:04, wrote:
>> Or otherwise wouldn't it make
>> sense to use the same array slots for a particular IO-APIC in both
>> nr_ioapic_entries[] and ioapic_sbdf[], instead of allocating them via
>> get_next_io
Hi Jan,
On 12/1/16 18:58, Jan Beulich wrote:
On 01.12.16 at 12:04, wrote:
@@ -1028,15 +1036,15 @@ static int __init parse_ivrs_table(struct
acpi_table_header *table)
if ( !nr_ioapic_entries[apic] )
continue;
-if ( !ioapic_sbdf[IO_APIC_ID(apic)].seg &&
+i
>>> On 02.12.16 at 04:48, wrote:
> On 12/01/2016 06:58 PM, Jan Beulich wrote:
> On 01.12.16 at 12:04, wrote:
>>> Currently, the driver uses the APIC ID to index into the ioapic_sbdf array.
>>> The current MAX_IO_APICS is 128, which causes the driver initialization
>>> to fail on the system wi
Hi Jan,
On 12/01/2016 06:58 PM, Jan Beulich wrote:
On 01.12.16 at 12:04, wrote:
Currently, the driver uses the APIC ID to index into the ioapic_sbdf array.
The current MAX_IO_APICS is 128, which causes the driver initialization
to fail on the system with IOAPIC ID >= 128.
Instead, this patch
>>> On 01.12.16 at 12:04, wrote:
> Currently, the driver uses the APIC ID to index into the ioapic_sbdf array.
> The current MAX_IO_APICS is 128, which causes the driver initialization
> to fail on the system with IOAPIC ID >= 128.
>
> Instead, this patch adds APIC ID in the struct ioapic_sbdf,
>
Currently, the driver uses the APIC ID to index into the ioapic_sbdf array.
The current MAX_IO_APICS is 128, which causes the driver initialization
to fail on the system with IOAPIC ID >= 128.
Instead, this patch adds APIC ID in the struct ioapic_sbdf,
which is used to match the entry when searchi
