<html>
<head>
<base href="https://bugs.dpdk.org/">
</head>
<body><table border="1" cellspacing="0" cellpadding="8" class="bz_new_table">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_UNCONFIRMED "
title="UNCONFIRMED - Bug in resource allocation in netuio_map_hw_resources"
href="https://bugs.dpdk.org/show_bug.cgi?id=1767">1767</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Bug in resource allocation in netuio_map_hw_resources
</td>
</tr>
<tr>
<th>Product</th>
<td>DPDK
</td>
</tr>
<tr>
<th>Version</th>
<td>unspecified
</td>
</tr>
<tr>
<th>Hardware</th>
<td>All
</td>
</tr>
<tr>
<th>OS</th>
<td>Windows
</td>
</tr>
<tr>
<th>Status</th>
<td>UNCONFIRMED
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>Normal
</td>
</tr>
<tr>
<th>Component</th>
<td>netuio
</td>
</tr>
<tr>
<th>Assignee</th>
<td>dev@dpdk.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>repin.dmitry7@gmail.com
</td>
</tr>
<tr>
<th>Target Milestone</th>
<td>---
</td>
</tr></table>
<p>
<div class="bz_comment_block">
<pre class="bz_comment_text">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
</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
<div itemscope itemtype="http://schema.org/EmailMessage">
<div itemprop="action" itemscope itemtype="http://schema.org/ViewAction">
<link itemprop="url" href="https://bugs.dpdk.org/show_bug.cgi?id=1767">
<meta itemprop="name" content="View bug">
</div>
<meta itemprop="description" content="Bugzilla bug update notification">
</div>
</body>
</html>