Jan Kiska wrote: >Just like under Linux, the driver does not have to worry about that >details. Xenomai will EOI the IRQ when needed. The driver handler just >need to tell if a particular invocation was (also) triggered by the >device it drives.
I trust the EOI is taken care of automatically, as you say. However I am on a special industrial motherboard whose BIOS allows the use of IRQ 5 for certain serial ports. There is no mistake, I chose IRQ 5 in the BIOS (only choices are 5 and 10, but 10 conflicts with a PCI card). Here is the kernel's dmesg at boot: [ 0.536089] 00:05: ttyS1 at I/O 0x2f8 (irq = 5, base_baud = 115200) is a 16550A Here is setserial /dev/ttyS1 after boot: /dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 5 When xeno_16550A module is invoked with one of the ports on IRQ 5 like this: xeno_16550A io=0x02e0,0x02f8,0x3f8 irq=10,5,4 baud_base=115200,115200,115200 The port at 0x02f8 IRQ 5 behaves fine and transmits and receives OK. But when the xeno_16550A module is invoked with more than one of the ports set to IRQ 5 in the BIOS like this: xeno_16550A io=0x02e0,0x02f8,0x03e8,0x02e8 irq=5,5,5,5 baud_base=115200,115200,115200,115200 All those ports fail to work, only one byte can be transmitted or received. On this same motherboard, a Moxa PCI card can share IRQ17 between 4 ports OK using xeno_16550A, demonstrating that the kernel/modules are compiled correctly. But there seems to be a problem with sharing IRQ 5. -C Smith _______________________________________________ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai
