16550A IRQ not enabled

16550A IRQ not enabled

[C Smith]

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.

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?

Re: 16550A IRQ not enabled

[Richard Weinberger]

On Wed, May 25, 2022 at 2:18 AM C Smith via Xenomai <xenomai@xenomai.org> 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 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

Re: 16550A IRQ not enabled

[C Smith]

On Wed, May 25, 2022 at 1:07 AM Richard Weinberger
<richard.weinberger@gmail.com> wrote:
>
> On Wed, May 25, 2022 at 2:18 AM C Smith via Xenomai <xenomai@xenomai.org> 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.
So /sys/kernel/debug/irq/irqs/17 doesn't become available until the
sound driver is loaded.

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?

How can we debug this further, since /sys/kernel/debug/irq/irqs/17
does not exist without that sound driver?

Re: 16550A IRQ not enabled

[Richard Weinberger]

On Thu, May 26, 2022 at 2:08 AM C Smith <csmithquestions@gmail.com> wrote:
>
> On Wed, May 25, 2022 at 1:07 AM Richard Weinberger
> <richard.weinberger@gmail.com> wrote:
> >
> > On Wed, May 25, 2022 at 2:18 AM C Smith via Xenomai <xenomai@xenomai.org> 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

Re: 16550A IRQ not enabled

[C Smith]

On Wed, May 25, 2022 at 10:50 PM Richard Weinberger
<richard.weinberger@gmail.com> wrote:
>
> On Thu, May 26, 2022 at 2:08 AM C Smith <csmithquestions@gmail.com> wrote:
> >
> > On Wed, May 25, 2022 at 1:07 AM Richard Weinberger
> > <richard.weinberger@gmail.com> wrote:
> > >
> > > On Wed, May 25, 2022 at 2:18 AM C Smith via Xenomai <xenomai@xenomai.org> 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

Re: 16550A IRQ not enabled

[Richard Weinberger]

----- Ursprüngliche Mail -----
> 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.

And just passing baud_base=X,Y,..,Z does not work?
Sure this is still hacky since it depends on the PCI probe order...

We could make baud_base configurable via ioctl, the driver supports already
plenty of them.
Or exposing this and other properties as sysfs attributes.

Further I suggest splitting the driver in at at least two kernel modules.
One for PCI and another one for legacy PIO/PNP.
The current probe interface is IMHO confusing and error prone.

Thanks,
//richard

Re: 16550A IRQ not enabled

[C Smith]

On Fri, May 27, 2022 at 1:34 AM Richard Weinberger <richard@nod.at> wrote:
> ----- Ursprüngliche Mail -----
> > 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.
>
> And just passing baud_base=X,Y,..,Z does not work?
> Sure this is still hacky since it depends on the PCI probe order...
>
> We could make baud_base configurable via ioctl, the driver supports already
> plenty of them.
> Or exposing this and other properties as sysfs attributes.
>
> Further I suggest splitting the driver in at at least two kernel modules.
> One for PCI and another one for legacy PIO/PNP.
> The current probe interface is IMHO confusing and error prone.
>
> Thanks,
> //richard

After a 16550A_pci.h driver modification, I got this all to work
finally, with interrupts enabled for all of my 6 serial ports. This is
the modprobe command line:
modprobe xeno_16550A io=0x3f8,0x2f8 irq=4,3
baud_base=115200,115200,460800,460800,460800,460800
Note that those first two ports above are are legacy (ISA) addresses,
not PCI cards. The last four baud_base args above are for the four
ports on the Moxa PCI card. By not specifying an io=,irq= for the PCI
ports we let the driver do a pci_resource_start() and the interrupts
are automagically enabled.

Here is the code I had to hack to get this to work.
static int rt_16550_pci_probe()
...
    for (i = 0; i < MAX_DEVICES; i++) {
        ...
            baud_base[i] = board->baud_base;

That last line was clobbering baud_base[] with defaults, even if I put
a new baud_base on the modprobe command line. With that last line
commented out the modprobe baud_base arguments succeed.

But per Richard W's other comments, this all only works if the PCI
probe gets things in the same order, but it seems to be consistent on
my system.

-C Smith