Page MenuHomeFreeBSD

MFC the remainder of nv(9) and pci_iov(9) back to stable/10
AbandonedPublic

Authored by ngie on Jan 3 2016, 9:27 PM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, May 3, 4:58 AM
Unknown Object (File)
Fri, May 3, 4:58 AM
Unknown Object (File)
Fri, May 3, 4:57 AM
Unknown Object (File)
Thu, May 2, 10:41 PM
Unknown Object (File)
Fri, Apr 26, 8:53 PM
Unknown Object (File)
Fri, Apr 26, 8:30 PM
Unknown Object (File)
Mar 22 2024, 8:41 PM
Unknown Object (File)
Jan 4 2024, 12:23 PM

Details

Summary

MFC r264001,r264006,r279437,r279441-r279443,r279445-r279453,r279457-r279461,

r279463-r279466,r279469,r279868,r282248-r282251,r282258,r282282-r282283,
r282337,r282346-r282350,r283155-r283158,r283670,r284107,r284558,r284891,
r285063,r285129,r285139,r285189,r285273,r286642,r286644-r286646,r286796,
r293102,r293112,r293130-r293131,r293134-r293135

This change completes the remainder of the nv(9) backport by bringing in all
missing revisions from head.

Due to the interdependent pieces in various subsystems, pci_iov(9) and some
additional changes to pci(9) related to refactoring on head needed to be
backported.

iovctl(8) and pci_iov(9) changes for pciconf(8) were also backported.

r293112 needed to be MFCed in order to unbreak kernel builds on stable/10 due
to interface changes with ^/projects/ifnet related to if_t.

Some of the diff involved in ObsoleteFiles.inc was skipped because it involved
moving nv(9) from sys/kern to sys/contrib/libnv, etc (these were intermediate
changes that took place on head that are rolled into the overall change
proposed here).

Some of the mdoc changes were also skipped because of other subsystems and
missing MFCs.

This diff will not likely be backported to stable/9 due to interface changes
required in pci(9) that these changes depend on.

There is minor breakage in the struct pci_map KBI as the type of .pm_reg was
increased from uint8_t to uint16_t

__FreeBSD_version will be bumped separately for this change.

This supersedes and completes https://reviews.freebsd.org/D4232 and
https://reviews.freebsd.org/D4249 .

Relnotes: yes
Requested by: rstone
Submitted by: Kevin Bowling <kevin.bowling@kev009.com>,
Sponsored by: EMC / Isilon Storage Division

Test Plan

I've booted up my Haswell machine and have been playing around with it a bit.
pciconf -cl works well with the machine as well.

Unfortunately I don't have hardware that features iov(4) support. I need help
with this from others. The work has been committed to
^/user/ngie/stable-10-libnv .

I've posted an image to freefall that's available here:
https://people.freebsd.org/~ngie/FreeBSD-10.2-STABLE-amd64-disc1-D4767.iso.xz

Please feel free to verify the sha256 here:
https://people.freebsd.org/~ngie/FreeBSD-10.2-STABLE-amd64-disc1-D4767.iso.xz.sha256

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

ngie retitled this revision from to MFC the remainder of nv(9) and pci_iov(9) back to stable/10.
ngie updated this object.
ngie edited the test plan for this revision. (Show Details)
ngie added reviewers: kbowling, oshogbo, rstone.
ngie set the repository for this revision to rS FreeBSD src repository - subversion.
ngie added subscribers: erj, pjd, jhb and 2 others.

kyua test fails now :/.. I'll dig in and figure out why:

nv_array_tests:nvlist_descriptor_array__pack  ->  failed: /usr/src/contrib/atf/atf-c/utils.c:430: WIFEXITED(status) not met  [0.010s]
% ktrace -di kyua debug -k /usr/tests/lib/libnv/Kyuafile nv_array_tests:nvlist_descriptor_array__pack
Files left in work directory after failure: atf_utils_fork_13930_err.txt, atf_utils_fork_13930_out.txt, nv_array_tests.core
% kdump
 14241 nv_array_tests CALL  close(0)
 14241 nv_array_tests RET   close -1 errno 9 Bad file descriptor
 14241 nv_array_tests CALL  close(0)
 14241 nv_array_tests RET   close -1 errno 9 Bad file descriptor
 14241 nv_array_tests CALL  close(0)
 14241 nv_array_tests RET   close -1 errno 9 Bad file descriptor
 14241 nv_array_tests CALL  close(0)
 14241 nv_array_tests RET   close -1 errno 9 Bad file descriptor
 14241 nv_array_tests CALL  close(0)
 14241 nv_array_tests RET   close -1 errno 9 Bad file descriptor
 14241 nv_array_tests CALL  close(0)
 14241 nv_array_tests RET   close -1 errno 9 Bad file descriptor
 14241 nv_array_tests CALL  close(0)
 14241 nv_array_tests RET   close -1 errno 9 Bad file descriptor
 14241 nv_array_tests CALL  close(0)
 14241 nv_array_tests RET   close -1 errno 9 Bad file descriptor
 14241 nv_array_tests CALL  close(0)
 14241 nv_array_tests RET   close -1 errno 9 Bad file descriptor
 14241 nv_array_tests CALL  close(0)
 14241 nv_array_tests RET   close -1 errno 9 Bad file descriptor
 14241 nv_array_tests CALL  close(0)
 14241 nv_array_tests RET   close -1 errno 9 Bad file descriptor
 14241 nv_array_tests CALL  close(0)
 14241 nv_array_tests RET   close -1 errno 9 Bad file descriptor
 14241 nv_array_tests CALL  close(0)
 14241 nv_array_tests RET   close -1 errno 9 Bad file descriptor
 14241 nv_array_tests CALL  close(0)
 14241 nv_array_tests RET   close -1 errno 9 Bad file descriptor
 14241 nv_array_tests CALL  close(0)
 14241 nv_array_tests RET   close -1 errno 9 Bad file descriptor
 14241 nv_array_tests CALL  close(0)
 14241 nv_array_tests RET   close -1 errno 9 Bad file descriptor
 14241 nv_array_tests CALL  close(0)
 14241 nv_array_tests RET   close -1 errno 9 Bad file descriptor
 14241 nv_array_tests CALL  close(0)
 14241 nv_array_tests RET   close -1 errno 9 Bad file descriptor
 14241 nv_array_tests CALL  close(0)
 14241 nv_array_tests RET   close -1 errno 9 Bad file descriptor
 14241 nv_array_tests CALL  close(0)
 14241 nv_array_tests RET   close -1 errno 9 Bad file descriptor
 14241 nv_array_tests CALL  close(0)
 14241 nv_array_tests RET   close -1 errno 9 Bad file descriptor
 14241 nv_array_tests CALL  close(0)
 14241 nv_array_tests RET   close -1 errno 9 Bad file descriptor
 14241 nv_array_tests CALL  close(0)
 14241 nv_array_tests RET   close -1 errno 9 Bad file descriptor
 14241 nv_array_tests CALL  close(0)
 14241 nv_array_tests RET   close -1 errno 9 Bad file descriptor
 14241 nv_array_tests PSIG  SIGBUS SIG_DFL code=BUS_ADRERR
 14241 nv_array_tests NAMI  "nv_array_tests.core"

I changed the ATF_REQUIREs to asserts and I discovered it was failing here:

nvl = nvlist_create(0);
ATF_REQUIRE(nvl != NULL); /* <--- Here */
ATF_REQUIRE(nvlist_empty(nvl));
ATF_REQUIRE(!nvlist_exists_descriptor_array(nvl, key));

It's failing periodically here... once it passed, the other times it failed. I'll dig through dnv.h and a few other things to see if I'm accidentally missing a bugfix.

In D4767#101241, @ngie wrote:
% ktrace -di kyua debug -k /usr/tests/lib/libnv/Kyuafile nv_array_tests:nvlist_descriptor_array__pack
Files left in work directory after failure: atf_utils_fork_13930_err.txt, atf_utils_fork_13930_out.txt, nv_array_tests.core
% kdump
 14241 nv_array_tests CALL  close(0)
 14241 nv_array_tests RET   close -1 errno 9 Bad file descriptor
 14241 nv_array_tests CALL  close(0)
 14241 nv_array_tests RET   close -1 errno 9 Bad file descriptor
 14241 nv_array_tests CALL  close(0)
 14241 nv_array_tests RET   close -1 errno 9 Bad file descriptor
 14241 nv_array_tests CALL  close(0)
 14241 nv_array_tests RET   close -1 errno 9 Bad file descriptor
 14241 nv_array_tests CALL  close(0)
 14241 nv_array_tests RET   close -1 errno 9 Bad file descriptor
 14241 nv_array_tests CALL  close(0)
 14241 nv_array_tests RET   close -1 errno 9 Bad file descriptor
 14241 nv_array_tests CALL  close(0)
 14241 nv_array_tests RET   close -1 errno 9 Bad file descriptor
 14241 nv_array_tests CALL  close(0)
 14241 nv_array_tests RET   close -1 errno 9 Bad file descriptor
 14241 nv_array_tests CALL  close(0)
 14241 nv_array_tests RET   close -1 errno 9 Bad file descriptor
 14241 nv_array_tests CALL  close(0)
 14241 nv_array_tests RET   close -1 errno 9 Bad file descriptor
 14241 nv_array_tests CALL  close(0)
 14241 nv_array_tests RET   close -1 errno 9 Bad file descriptor
 14241 nv_array_tests CALL  close(0)
 14241 nv_array_tests RET   close -1 errno 9 Bad file descriptor
 14241 nv_array_tests CALL  close(0)
 14241 nv_array_tests RET   close -1 errno 9 Bad file descriptor
 14241 nv_array_tests CALL  close(0)
 14241 nv_array_tests RET   close -1 errno 9 Bad file descriptor
 14241 nv_array_tests CALL  close(0)
 14241 nv_array_tests RET   close -1 errno 9 Bad file descriptor
 14241 nv_array_tests CALL  close(0)
 14241 nv_array_tests RET   close -1 errno 9 Bad file descriptor
 14241 nv_array_tests CALL  close(0)
 14241 nv_array_tests RET   close -1 errno 9 Bad file descriptor
 14241 nv_array_tests CALL  close(0)
 14241 nv_array_tests RET   close -1 errno 9 Bad file descriptor
 14241 nv_array_tests CALL  close(0)
 14241 nv_array_tests RET   close -1 errno 9 Bad file descriptor
 14241 nv_array_tests CALL  close(0)
 14241 nv_array_tests RET   close -1 errno 9 Bad file descriptor
 14241 nv_array_tests CALL  close(0)
 14241 nv_array_tests RET   close -1 errno 9 Bad file descriptor
 14241 nv_array_tests CALL  close(0)
 14241 nv_array_tests RET   close -1 errno 9 Bad file descriptor
 14241 nv_array_tests CALL  close(0)
 14241 nv_array_tests RET   close -1 errno 9 Bad file descriptor
 14241 nv_array_tests CALL  close(0)
 14241 nv_array_tests RET   close -1 errno 9 Bad file descriptor
 14241 nv_array_tests PSIG  SIGBUS SIG_DFL code=BUS_ADRERR
 14241 nv_array_tests NAMI  "nv_array_tests.core"

I changed the ATF_REQUIREs to asserts and I discovered it was failing here:

nvl = nvlist_create(0);
ATF_REQUIRE(nvl != NULL); /* <--- Here */
ATF_REQUIRE(nvlist_empty(nvl));
ATF_REQUIRE(!nvlist_exists_descriptor_array(nvl, key));

It's failing periodically here... once it passed, the other times it failed. I'll dig through dnv.h and a few other things to see if I'm accidentally missing a bugfix.

I figured out what the issue was with cppcheck. There were 2 variables that were accessed uninitialized that were causing problems (see this other review for more details): https://reviews.freebsd.org/D4769?vs=11892&id=11895 .

ngie edited edge metadata.

Add nv_array_tests.cc fix from https://reviews.freebsd.org/D4769 .

ngie edited edge metadata.

Does this even build now?

Yessir (minus the LINT-NOINET kernels because of other breakage elsewhere I reported on stable@ 2 weeks ago -- https://lists.freebsd.org/pipermail/freebsd-stable/2015-December/083844.html ):

Tinderbox failed:
i386 LINT-NOINET kernel failed, check _.i386.LINT-NOINET for details
amd64 LINT-NOINET kernel failed, check _.amd64.LINT-NOINET for details
*** [universe_epilogue] Error code 1

make[1]: stopped in /scratch/tmp/ngie/svn
1 error

make[1]: stopped in /scratch/tmp/ngie/svn
*** [tinderbox] Error code 2

make: stopped in /scratch/tmp/ngie/svn
1 error

make: stopped in /scratch/tmp/ngie/svn
$ svn info
Path: .
Working Copy Root Path: /scratch/tmp/ngie/svn
URL: https://ngie@svn.freebsd.org/base/user/ngie/stable-10-libnv
Relative URL: ^/user/ngie/stable-10-libnv
Repository Root: https://ngie@svn.freebsd.org/base
Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Revision: 293137
Node Kind: directory
Schedule: normal
Last Changed Author: ngie
Last Changed Rev: 293137
Last Changed Date: 2016-01-04 03:47:31 +0000 (Mon, 04 Jan 2016)

$ svnversion 
293137
$ hostname
universe10a.freebsd.org

I have access to a couple machines with ixgbe(4) and ixl(4) at $work. I'll try to verify things this week with some basic sanity checks (netperf, iperf, buildworld over NFS, etc). However, I would really appreciate it if someone else (Kevin?) could verify this too..

In the description, the fact that this merges support for IOV seems to be a bigger deal (on first blush) than updating the nvlist API. I would probably mention that first. I'm surprised though that you couldn't pick out just the nvlist changes alone to merge and do IOV as a followup? IIRC, Ryan was pretty good about splitting things up in his original changes.

In D4767#101628, @jhb wrote:

In the description, the fact that this merges support for IOV seems to be a bigger deal (on first blush) than updating the nvlist API. I would probably mention that first. I'm surprised though that you couldn't pick out just the nvlist changes alone to merge and do IOV as a followup? IIRC, Ryan was pretty good about splitting things up in his original changes.

The problem is that they became intertwined around r279441, in particular with the changes oshogbo did moving nv around and some of the changes made by rstone with the nv(9) KPI :(... I tried to reduce this as much as possible, and I can commit the changes in stages, but I can't guarantee that everything will function when merging intermediate changes :(..

I just booted one of kmacy's machines with the ISO and it came up. pciconf -lb worked. I don't have another working machine to test with right now [though] because the other machine seems to be down right now :(...

kbowling edited edge metadata.
This revision is now accepted and ready to land.Jan 30 2016, 12:43 AM

Are you going to get this through RE for 10.3? I think sooner the better so it can be fixed or backed out if something goes wrong.

I'm going to abandon this revision because I lack the hardware to validate this this functions in ^/stable/10 .

I think that is a good call, 10 is pretty long in the tooth these days.