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.
Thanks,
-Jeff
_______________________________________________
Xenomai mailing list
[email protected]
https://xenomai.org/mailman/listinfo/xenomai
