[DPDK/netuio Bug 1766] Bug in resource allocation in netuio_map_hw_resources

[bugzilla@dpdk.org]

[-- Attachment #1: Type: text/plain, Size: 2612 bytes --]

https://bugs.dpdk.org/show_bug.cgi?id=1766

            Bug ID: 1766
           Summary: Bug in resource allocation in  netuio_map_hw_resources
           Product: DPDK
           Version: unspecified
          Hardware: All
                OS: Windows
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: netuio
          Assignee: dev@dpdk.org
          Reporter: repin.dmitry7@gmail.com
  Target Milestone: ---

Created attachment 327
  --> https://bugs.dpdk.org/attachment.cgi?id=327&action=edit
corrections

We are using DPDK to work with Intel X520-DA2 under Windows with netuio. After
adding its description to the INF file, we found that the driver fails to load:
netuio_map_hw_resources returns STATUS_DEVICE_CONFIGURATION_ERROR.

This adapter has the following resources (output from lspci -vvv in Linux):

01:00.0 Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+
Network Connection (rev 01)
...
    Region 0: Memory at c3800000 (64-bit, non-prefetchable) [size=512K]  
    Region 2: I/O ports at e020 [size=32]  
    Region 4: Memory at c3a00000 (64-bit, non-prefetchable) [size=16K]  
...

i/o port in Region 2 break the existing algorithm.

After modifying the code, the driver loaded successfully, and the adapter
started working as intended.

In the file netuio_dev.c — our modification of current code.

I’d like to clarify why such a complex algorithm was needed. Do you suspect
that WdfCmResourceListGetDescriptor might behave inconsistently across
different Windows versions?

   /*
    * ResourcesTranslated report MMIO BARs in the correct order, but their
    * indices differ from physical ones.

    * For example:
    * The values returned by WdfCmResourceListGetDescriptor can be condensed
like this:
    * Bar[0] = c840000c
    * Bar[1] = c800000c
    * Bar[2] = c844000c

    * But the BAR array has to be filled like this :
    * Bar[0] = c840000c
    * Bar[1] = null
    * Bar[2] = c800000c
    * Bar[3] = null
    * Bar[4] = c844000c
    * Bar[5] = null

Are you certain this is the case? Our tests don’t confirm this behavior. we see
        descriptor[0].Type = CmResourceTypeMemory
        descriptor[1].Type = CmResourceTypeDevicePrivate
        descriptor[2].Type = CmResourceTypeMemory
        descriptor[3].Type = CmResourceTypeDevicePrivate
        descriptor[4].Type = CmResourceTypeMemory
        descriptor[5].Type = CmResourceTypeDevicePrivate

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #2: Type: text/html, Size: 4608 bytes --]