On Wed, May 25, 2022 at 10:50 PM Richard Weinberger <[email protected]> wrote: > > On Thu, May 26, 2022 at 2:08 AM C Smith <[email protected]> wrote: > > > > On Wed, May 25, 2022 at 1:07 AM Richard Weinberger > > <[email protected]> wrote: > > > > > > On Wed, May 25, 2022 at 2:18 AM C Smith via Xenomai <[email protected]> > > > wrote: > > > > We are using Xenomai 3.1.2 on kernel 4.19.229, X86 CPU > > > > We have a (Moxa CP-104ul) serial card on an isolated PCI bus interrupt > > > > 17. > > > > lspci -v confirms that the serial card is isolated and that no other > > > > peripheral uses this interrupt. > > > > > > > > We have the 16550A serial driver loaded, and an external serial device > > > > trying to initiate a serial connection, but no interrupts are being > > > > generated. The interrupt counter in /proc/xenomai/irq stay at 0. > > > > > > > > [user@device~]$ cat /proc/xenomai/irq > > > > IRQ CPU0 CPU1 CPU2 CPU3 > > > > 17: 0 0 0 0 rtser2 > > > > rtser3 rtser4 rtser5 > > > > > > > > As an experiment: if we enable the Azalia sound chip in the BIOS, and > > > > load its Alsa sound driver, the Serial card will then share IRQ 17 > > > > with that sound chip, and then the serial card works. The serial > > > > interrupt counter is incrementing in /proc/xenomai/irq and our serial > > > > peripheral can utilize the serial port OK. > > > > > > I think enabling it in the BIOS is the key. Can you try keeping the sound > > > driver > > > disabled and only enable in the BIOS. > > > > We left the Azalia sound chip enabled in the BIOS, and disabled the > > sound driver. > > Interrupts in /proc/xenomai/irq are still not incrementing when serial > > packets come into the po > > > > > > We don't want the sound driver enabled, but this test indicates that > > > > 16550A somehow failed to enable its interrupt, whereas the sound > > > > driver succeeded in doing so. > > > > > > > > How can we check a PIC, etc. to verify that the serial interrupt is > > > > truly enabled when the 16550A driver is loaded alone? > > > > > > You can enable CONFIG_GENERIC_IRQ_DEBUGFS and then poke into > > > /sys/kernel/debug/irq/. > > > > > > -- > > > Thanks, > > > //richard > > > > We rebuilt our kernel with CONFIG_GENERIC_IRQ_DEBUGFS enabled, booted > > with the sound driver disabled and loaded xeno_16550A: > > > > [root@device~]# cat /sys/kernel/debug/irq/irqs/17 > > cat: /sys/kernel/debug/irq/irqs/17: No such file or directory. > > > > We noticed that /proc/xenomai/irq is not showing IRQ17 immediately > > after xeno_16550A is loaded. > > proc/xenomai/irq only shows IRQ17 after the serial device is opened > > for the first time. > > The driver requests the IRQ only upon open. So that's okay. > > > So /sys/kernel/debug/irq/irqs/17 doesn't become available until the > > sound driver is loaded. > > ...or until you use the xeno_16550A driver by opening the device handle? > > > We also have a (Peak) CAN card installed in this system, and the > > corresponding IRQ shows up immediately in > > /sys/kernel/debug/irq/irqs/18 > > after the xeno_can driver is loaded. > > > > Should we expect to see the IRQ show up in /proc/xenomai/irq > > immediately after loading the xeno_16550A driver? > > No. It depends how the driver works. As I wrote, xeno_16550A does > rtdm_irq_request() > in the open, not the probe function. > > > How can we debug this further, since /sys/kernel/debug/irq/irqs/17 > > does not exist without that sound driver? > > I don't really understand, didn't you write a few lines above that the > IRQ shows also up > when you open the device? Why do you need the IRQ earlier? > -- > Thanks, > //richard
An update: If the 16550A driver is modprobed with no arguments, it apparently probes the PCI subsystem, gets the irq, and interrupts are enabled OK. The serial port can send/receive data. But, if a port= or irq= argument is passed into the 16550A driver, then the driver seems to skip probing the PCI syubsystem, and the driver fails to enable the irq. No data can transmitted or received by the port, even though the driver has done an rtdm_irq_request() of the correct irq level. This is a problem for my application because I have 6 serial ports and some must have different baud_base args, which is now impossible with this inconsistent driver behavior. -C Smith
