On 03/01/2013 02:48 PM, Jan Kiszka wrote:
> On 2013-03-01 12:15, Manuel Huber wrote:
>> On 2013-02-25 23:02, Jan Kiszka wrote:
>>> On 2013-02-25 21:09, Anders Blomdell wrote:
>>>> On 2013-02-25 20:10, Jan Kiszka wrote:
>>>>> On 2013-02-25 20:07, Anders Blomdell wrote:
>>>>>> On 2013-02-25 18:08, Jan Kiszka wrote:
>>>>>>> As 3.5 is dead, this fix will never make it there unless we
>>>>>>> back-port.
>>>>>>> While I'm doing this, could you try if
>>>>>>>
>>>>>>> git://git.xenomai.org/ipipe-jki.git for-upstream/master
>>>>>> I'm probably more stupid than normal (i.e I can't find any ipipe for
>>>>>> x86_64):
>>>>>>
>>>>>> # git clone git://git.xenomai.org/ipipe-jki.git for-upstream/master
>>>>> git clone git://git.xenomai.org/ipipe-jki.git
>>>>> git checkout -b for-upstream/master origin/for-upstream/master
>>>> OK, thanks. Do I need to setup xenomai in order to gain any useful
>>>> information, or is:
>>>>
>>>> CONFIG_IPIPE=y
>>>> CONFIG_IPIPE_LEGACY=y
>>>> CONFIG_IPIPE_CORE=y
>>>> CONFIG_IPIPE_CORE_APIREV=2
>>>> CONFIG_IPIPE_TARGET_APIREV=1
>>>> CONFIG_IPIPE_HAVE_HOSTRT=y
>>>> CONFIG_IPIPE_DELAYED_ATOMICSW=y
>>>> # CONFIG_IPIPE_DEBUG is not set
>>>>
>>>> sufficient?
>>> Plain I-pipe will suffice as the the interrupt virtualization is
>>> unconditional, thus __ipipe_handle_irq is always taken.
>>>
>>> Alternatively, here is the backported patch over 3.5.7:
>>>
>>> diff --git a/arch/x86/kernel/apic/io_apic.c
>>> b/arch/x86/kernel/apic/io_apic.c
>>> index 08e5ad4..aade7f0 100644
>>> --- a/arch/x86/kernel/apic/io_apic.c
>>> +++ b/arch/x86/kernel/apic/io_apic.c
>>> @@ -234,11 +234,11 @@ int __init arch_early_irq_init(void)
>>> zalloc_cpumask_var_node(&cfg[i].old_domain, GFP_KERNEL, node);
>>> /*
>>> * For legacy IRQ's, start with assigning irq0 to irq15 to
>>> - * IRQ0_VECTOR to IRQ15_VECTOR on cpu 0.
>>> + * IRQ0_VECTOR to IRQ15_VECTOR for all cpu's.
>>> */
>>> if (i < legacy_pic->nr_legacy_irqs) {
>>> cfg[i].vector = IRQ0_VECTOR + i;
>>> - cpumask_set_cpu(0, cfg[i].domain);
>>> + cpumask_setall(cfg[i].domain);
>>> }
>>> }
>>> @@ -1181,8 +1181,9 @@ next:
>>> current_vector = vector;
>>> current_offset = offset;
>>> if (old_vector) {
>>> - cfg->move_in_progress = 1;
>>> cpumask_copy(cfg->old_domain, cfg->domain);
>>> + cfg->move_in_progress =
>>> + cpumask_intersects(cfg->old_domain, cpu_online_mask);
>>> }
>>> for_each_cpu_and(new_cpu, tmp_mask, cpu_online_mask)
>>> per_cpu(vector_irq, new_cpu)[vector] = irq;
>>> @@ -1250,12 +1251,6 @@ void __setup_vector_irq(int cpu)
>>> cfg = irq_get_chip_data(irq);
>>> if (!cfg)
>>> continue;
>>> - /*
>>> - * If it is a legacy IRQ handled by the legacy PIC, this cpu
>>> - * will be part of the irq_cfg's domain.
>>> - */
>>> - if (irq < legacy_pic->nr_legacy_irqs && !IO_APIC_IRQ(irq))
>>> - cpumask_set_cpu(cpu, cfg->domain);
>>> if (!cpumask_test_cpu(cpu, cfg->domain))
>>> continue;
>>> @@ -1380,13 +1375,6 @@ static void setup_ioapic_irq(unsigned int irq,
>>> struct irq_cfg *cfg,
>>> if (!IO_APIC_IRQ(irq))
>>> return;
>>> - /*
>>> - * For legacy irqs, cfg->domain starts with cpu 0 for legacy
>>> - * controllers like 8259. Now that IO-APIC can handle this irq,
>>> update
>>> - * the cfg->domain.
>>> - */
>>> - if (irq < legacy_pic->nr_legacy_irqs && cpumask_test_cpu(0,
>>> cfg->domain))
>>> - apic->vector_allocation_domain(0, cfg->domain);
>>> if (assign_irq_vector(irq, cfg, apic->target_cpus()))
>>> return;
>>>
>>>
>>> Jan
>>>
>>>
>> Hey!
>>
>> I applied your patch and rebooted several times with and without serial
>> console and it seems to have finally fixed the problem (but I've said
>> that a lot recently... sorry again...). I've also tried the version of
>> your branch and it compiled and booted.
>
> OK, perfect. Will send a pull request for I-pipe 3.5.7 to push this fix
> upstream.
Hi Jan,
did this patch make it to one of the branches in the ipipe-jki repository?
Regards.
--
Gilles.
_______________________________________________
Xenomai mailing list
[email protected]
http://www.xenomai.org/mailman/listinfo/xenomai
