On 08/18/2017 10:37 PM, Jeff Webb wrote:
> On 08/15/2017 08:40 AM, Philippe Gerum wrote:
>> On 08/02/2017 10:55 PM, Jeff Webb wrote:
>>> On 08/02/2017 01:51 PM, Philippe Gerum wrote:
>>>> On 08/02/2017 08:28 PM, Jeff Webb wrote:
>>>>> On 08/02/2017 12:04 PM, Philippe Gerum wrote:
>>>>>> On 08/02/2017 06:43 PM, Jeff Webb wrote:
>>>>>>> I am attempting to upgrade our x86/64 PC systems running
>>>>>>> linux-3.14.17/xenomai-2.6.4 to xenomai-3.x. I have successfully
>>>>>>> built and booted a linux-4.1.18/xenomai-3.0.5 kernel on one of
>>>>>>> them using:
>>>>>>>
>>>>>>> ipipe-core-4.1.18-x86-9.patch
>>>>>>>
>>>>>>> however, I cannot boot systems based on:
>>>>>>>
>>>>>>> ipipe-core-4.4.43-x86-8.patch
>>>>>>> ipipe-core-4.4.71-x86-8.patch
>>>>>>> ipipe-core-4.9.24-x86-2.patch
>>>>>>>
>>>>>>> with the CONFIG_IPIPE=y. I can get these configurations to boot
>>>>>>> by disabling CONFIG_IPIPE. The main issue seems to be that
>>>>>>> the primary hard drive does not work. There also seems to be an
>>>>>>> issue with some of the USB ports.
>>>>>>>
>>>>>>> I have attached several files:
>>>>>>>
>>>>>>> - cpuinfo.txt: cpuinfo for the first core
>>>>>>> - boot-4.4.43-ipipeoff.notime: serial boot log (system works)
>>>>>>> - boot-4.4.43-ipipeon.notime.matchup: serial boot log (system hangs)
>>>>>>> - config-4.4.43-ipipeoff: (system works)
>>>>>>> - config-4.4.43-ipipeon: (system hangs)
>>>>>>>
>>>>>>> The times have been stripped from the boot logs and the second
>>>>>>> boot log has been slightly rearranged to make diffing with the two
>>>>>>> logseasier. I can send the raw logs instead, if that is helpful.
>>>>>>>
>>>>>>> Any help on getting later kernels to work would be appreciated.
>>>>>>
>>>>>> Maybe an issue with a secondary interrupt controller.
>>>>>>
>>>>>> - the output of /proc/interrupts on a booting kernel (say 4.9.24)
>>>>>> would
>>>>>> help figuring out which ICs are active on this hw.
>>>>>
>>>>> Please see the interrupts.txt attachment.
>>>>
>>>> Ah, looks like yet another issue with interrupt remapping. Could you
>>>> try
>>>> without CONFIG_IRQ_REMAP in your Kconfig to check this?
>>>
>>> Yes, it boots when I turn off CONFIG_IRQ_REMAP.
>>>
>>>>>> As a matter of fact,
>>>>>> the driver has issues receiving events from the SATA controller once
>>>>>> the
>>>>>> interrupt pipeline is engaged. Likewise for the USB part as you
>>>>>> mentioned as well.
>>>>>>
>>>>>> - does it boot in uniprocessor mode?
>>>>>>
>>>>>
>>>>> Yes, it boots with maxcpus=0 or noapic, but not maxcpus=1.
>>>>>
>>>>
>>>> This affects IR, so this would make sense.
>>>>
>>>
>>> Thanks,
>>>
>>
>> Although I could not reproduce the original issue on the couple of
>> x86 SoCs I have access to, I believe this patch should help. At any
>> rate, the current implementation is broken wrt to holding remappable
>> interrupts. If you can give this a try, any feedback welcome.
>> Thanks.
>>
>> diff --git a/arch/x86/kernel/apic/io_apic.c
>> b/arch/x86/kernel/apic/io_apic.c
>> index f26d949..d800e58 100644
>> --- a/arch/x86/kernel/apic/io_apic.c
>> +++ b/arch/x86/kernel/apic/io_apic.c
>> @@ -1954,6 +1954,16 @@ static void hold_ioapic_irq(struct irq_data
>> *irq_data)
>> ioapic_ack_level(irq_data);
>> }
>> +static void hold_ioapic_ir_irq(struct irq_data *irq_data)
>> +{
>> + struct mp_chip_data *data = irq_data->chip_data;
>> +
>> + raw_spin_lock(&ioapic_lock);
>> + __mask_ioapic(data);
>> + raw_spin_unlock(&ioapic_lock);
>> + ioapic_ir_ack_level(irq_data);
>> +}
>> +
>> static void release_ioapic_irq(struct irq_data *irq_data)
>> {
>> struct mp_chip_data *data = irq_data->chip_data;
>> @@ -1997,7 +2007,7 @@ static struct irq_chip ioapic_ir_chip
>> __read_mostly = {
>> #ifdef CONFIG_SMP
>> .irq_move = move_xxapic_irq,
>> #endif
>> - .irq_hold = hold_ioapic_irq,
>> + .irq_hold = hold_ioapic_ir_irq,
>> .irq_release = release_ioapic_irq,
>> #endif
>> .irq_retrigger = irq_chip_retrigger_hierarchy,
>>
>
> Thanks for trying to reproduce the issue, Philippe. This fix allows the
> system to boot and run with CONFIG_IRQ_REMAP turned back on. At first
> glance, I don't see anything strange in the boot log. I haven't tried
> anything more than the latency test with Xenomai though, but so far, so
> good.
>
Nice, thanks.
--
Philippe.
_______________________________________________
Xenomai mailing list
[email protected]
https://xenomai.org/mailman/listinfo/xenomai
