DPDK patches and discussions
 help / color / mirror / Atom feed
* [dpdk-dev] UIO RTE_INTR_MODE_NONE issue.
@ 2015-07-03 10:07 Prathap T
  2015-07-03 22:58 ` Stephen Hemminger
  0 siblings, 1 reply; 6+ messages in thread
From: Prathap T @ 2015-07-03 10:07 UTC (permalink / raw)
  To: dev

Hi:



If INTX fails, igb_uio falls back to running without IRQ ( refer to the
implementation in igbuio_pci_probe).

On QEMU 0.12.0, the INTX seems to have broken, and the intr_mode falls to
RTE_INTR_MODE_NONE

However this sets the udev->info.irq = 0;



Setting of udev->info.irq  to ‘0’ does not work on *2.6.36 and lower
kernels*, because the UIO_IRQ_NONE is defined as



#define UIO_IRQ_NONE   -2



Because the udev->info.irq  is set to ‘0’, on *2.6.36 and below*
implementation, the *__uio_register_device* invokes request_irq



if (idev->info->irq >= 0) {
 ret = request_irq(idev->info->irq, uio_interrupt,

and it fails with the following dump



IRQ handler type mismatch for IRQ 0

current handler: timer

Pid: 3106, comm: dpdk_nic_bind.p Not tainted 2.6.32-504.23.4.el6.x86_64 #1

Call Trace:

[<ffffffff810ebd62>] ? __setup_irq+0x382/0x3c0

[<ffffffffa033f2a0>] ? uio_interrupt+0x0/0x48 [uio]

[<ffffffff810ec563>] ? request_threaded_irq+0x133/0x230

[<ffffffffa033f193>] ? __uio_register_device+0x553/0x610 [uio]

[<ffffffffa0345652>] ? igbuio_pci_probe+0x3a7/0x4a0 [igb_uio]

[<ffffffff8128e58a>] ? kobject_get+0x1a/0x30

[<ffffffff812af417>] ? local_pci_probe+0x17/0x20

[<ffffffff812b0601>] ? pci_device_probe+0x101/0x120

[<ffffffff8136c992>] ? driver_sysfs_add+0x62/0x90

[<ffffffff8136cc2c>] ? driver_probe_device+0x9c/0x3e0

[<ffffffff8136bd6a>] ? driver_bind+0xca/0x110

[<ffffffff8136ae3c>] ? drv_attr_store+0x2c/0x30

[<ffffffff8120a4c5>] ? sysfs_write_file+0xe5/0x170

[<ffffffff8118e1c8>] ? vfs_write+0xb8/0x1a0

[<ffffffff8118eb91>] ? sys_write+0x51/0x90

[<ffffffff8100b0f2>] ? system_call_fastpath+0x16/0x1b

igb_uio 0000:00:03.0: PCI INT A disabled

igb_uio: probe of 0000:00:03.0 failed with error -16



On kernel *2.6.37* and above, the definition is,



#define UIO_IRQ_NONE   0



And the check is,



if (info->irq && (info->irq != UIO_IRQ_CUSTOM)) {
               ret = request_irq(info->irq, uio_interrupt,
                                 info->irq_flags, info->name, idev);



So to handle the ‘RTE_INTR_MODE_NONE’ in these different kernel versions,

We are proposing the following change to the code in igbuio_pci_probe
function,



case RTE_INTR_MODE_NONE:

                udev->mode = RTE_INTR_MODE_NONE;

#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 37)

         udev->info.irq = -2;

#else

        udev->info.irq = 0;

#endif



Please let me  know your opinion. If it is correct, we will go ahead and
generate a patch for review.



Regards,

Prathap

^ permalink raw reply	[flat|nested] 6+ messages in thread
* [dpdk-dev] UIO RTE_INTR_MODE_NONE issue.
@ 2015-07-02  3:23 Prathap Thammanna
  0 siblings, 0 replies; 6+ messages in thread
From: Prathap Thammanna @ 2015-07-02  3:23 UTC (permalink / raw)
  To: dev

Hi:

If INTX fails, igb_uio falls back to running without IRQ ( refer to the implementation in igbuio_pci_probe).
On QEMU 0.12.0, the INTX seems to have broken, and the intr_mode falls to RTE_INTR_MODE_NONE
However this sets the udev->info.irq = 0;

Setting of udev->info.irq  to '0' does not work on 2.6.36 and lower kernels, because the UIO_IRQ_NONE is defined as

#define UIO_IRQ_NONE   -2

Because the udev->info.irq  is set to '0', on 2.6.36 and below implementation, the __uio_register_device invokes request_irq

if (idev->info->irq >= 0) {
 ret = request_irq(idev->info->irq, uio_interrupt,
and it fails with the following dump

IRQ handler type mismatch for IRQ 0
current handler: timer
Pid: 3106, comm: dpdk_nic_bind.p Not tainted 2.6.32-504.23.4.el6.x86_64 #1
Call Trace:
[<ffffffff810ebd62>] ? __setup_irq+0x382/0x3c0
[<ffffffffa033f2a0>] ? uio_interrupt+0x0/0x48 [uio]
[<ffffffff810ec563>] ? request_threaded_irq+0x133/0x230
[<ffffffffa033f193>] ? __uio_register_device+0x553/0x610 [uio]
[<ffffffffa0345652>] ? igbuio_pci_probe+0x3a7/0x4a0 [igb_uio]
[<ffffffff8128e58a>] ? kobject_get+0x1a/0x30
[<ffffffff812af417>] ? local_pci_probe+0x17/0x20
[<ffffffff812b0601>] ? pci_device_probe+0x101/0x120
[<ffffffff8136c992>] ? driver_sysfs_add+0x62/0x90
[<ffffffff8136cc2c>] ? driver_probe_device+0x9c/0x3e0
[<ffffffff8136bd6a>] ? driver_bind+0xca/0x110
[<ffffffff8136ae3c>] ? drv_attr_store+0x2c/0x30
[<ffffffff8120a4c5>] ? sysfs_write_file+0xe5/0x170
[<ffffffff8118e1c8>] ? vfs_write+0xb8/0x1a0
[<ffffffff8118eb91>] ? sys_write+0x51/0x90
[<ffffffff8100b0f2>] ? system_call_fastpath+0x16/0x1b
igb_uio 0000:00:03.0: PCI INT A disabled
igb_uio: probe of 0000:00:03.0 failed with error -16

On kernel 2.6.37 and above, the definition is,

#define UIO_IRQ_NONE   0

And the check is,

if (info->irq && (info->irq != UIO_IRQ_CUSTOM)) {
               ret = request_irq(info->irq, uio_interrupt,
                                 info->irq_flags, info->name, idev);

So to handle the 'RTE_INTR_MODE_NONE' in these different kernel versions,
We are proposing the following change to the code in igbuio_pci_probe function,

case RTE_INTR_MODE_NONE:
                udev->mode = RTE_INTR_MODE_NONE;
#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 37)
         udev->info.irq = -2;
#else
        udev->info.irq = 0;
#endif

Please let us  know your opinion. If it is correct, we will go ahead and generate a patch for review.

Regards,
Prathap

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2015-07-06 17:36 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-07-03 10:07 [dpdk-dev] UIO RTE_INTR_MODE_NONE issue Prathap T
2015-07-03 22:58 ` Stephen Hemminger
2015-07-04  3:34   ` Prathap Thammanna
2015-07-04 12:36   ` Thomas Monjalon
2015-07-06 17:36     ` Stephen Hemminger
  -- strict thread matches above, loose matches on Subject: below --
2015-07-02  3:23 Prathap Thammanna

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).