On 2013-04-10 09:05, Gilles Chanteperdrix wrote:
> On 04/10/2013 09:02 AM, Jan Kiszka wrote:
>
>> On 2013-04-10 00:09, Gilles Chanteperdrix wrote:
>>> 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?
>>
>> It's contained in both for-upstream/master and for-upstream/3.5, for a
>> long time.
>
>
> Ok, something curious also in the 3.8 branch:
> http://git.xenomai.org/?p=ipipe-jki.git;a=blob;f=arch/x86/kernel/ipipe.c;h=99e0615ada495fcc69fa34196a3d688d11efcc01;hb=refs/heads/next-x86#l218
>
> Is not there a missing ipipe_apic_vector_irq ?
>
See smp_intr_init, vector and IRQ are the same value. One can argue that
ipipe_apic_vector_irq should be there nevertheless for the sake of
consistency, though.
Jan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL:
<http://www.xenomai.org/pipermail/xenomai/attachments/20130410/4c8e6fda/attachment.pgp>
_______________________________________________
Xenomai mailing list
[email protected]
http://www.xenomai.org/mailman/listinfo/xenomai
