Date: Wed, 9 Jun 2021 12:52:18 -0500 From: David Bright <david@bright-family.net> To: John Baldwin <jhb@FreeBSD.org> Cc: "src-committers@freebsd.org" <src-committers@FreeBSD.org>, "dev-commits-src-all@freebsd.org" <dev-commits-src-all@FreeBSD.org>, "dev-commits-src-main@freebsd.org" <dev-commits-src-main@FreeBSD.org> Subject: Re: git: 2f176a2b2010 - main - pciconf: Fix up pciconf -lc output Message-ID: <6E4EA1A3-BEEB-4D7B-BB21-EAB13A07A9C2@FreeBSD.org> In-Reply-To: <93b7adea-1980-b097-cdf1-d3426dd0d531@FreeBSD.org> References: <202106011556.151Fu6ZE084734@gitrepo.freebsd.org> <93b7adea-1980-b097-cdf1-d3426dd0d531@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jun 1, 2021, at 12:44 PM, John Baldwin <jhb@FreeBSD.org> wrote: >=20 > On 6/1/21 8:56 AM, David Bright wrote: >> The branch main has been updated by dab: >> URL: = https://cgit.FreeBSD.org/src/commit/?id=3D2f176a2b20107f7a9132242223e9eef6= 57400514 >> commit 2f176a2b20107f7a9132242223e9eef657400514 >>=20 >> pciconf: Fix up pciconf -lc output >> The pciconf command fails to emit newlines when particular = ecap field >> values are seen. Fix them up. This has been seen on several = systems at >> $JOB. The documentation for PCI capabilities says that capability >> type 0 should not be used once the spec for PCI capabilities was >> published, but that seems more wishful-thinking than reality. = pciconf >> also chooses not to print fields related to field values that are >> zero, but it seems several of these fields are zero on actual >> hardware. >>=20 >=20 > Are the ecap registers actually valid for version 1 in this case? = That is, > should we treat version 0 as being version 1? The current checks are = just > defensive coding for not parsing something unless we know it is valid. > If the only version 0 caps in practice are always compatible with = version 1 > we could just treat 0 as if it were 1. I think the answer is =E2=80=9Cmaybe, but we don=E2=80=99t know for = sure=E2=80=9D. Robert Herndon did some looking at this; his findings are = paraphrased below: ----- Searching on version fields in PCI caps and ecaps doesn=E2=80=99t = produce a lot of information. There are references to particular devices = indicating that =E2=80=98version=E2=80=99 should be =E2=80=981=E2=80=99, = or that it should not be =E2=80=980=E2=80=99, but there=E2=80=99s = nothing that says so for any generic case, or in the standards I=E2=80=99v= e found. The version field is only four bits, so it seems a little odd = that zero wouldn=E2=80=99t be a reasonable-ish value. Internally we have = only found two hosts exhibiting this issue and both exhibit the same = behavior. When the early return on version 0 is disabled they show = multiple instances of: cap 10[40] =3D PCI-Express 2 root endpoint max data 128(128) ecap 000b[100] =3D Vendor 0 ID 1 none114@pci0:93:15:0: class=3D0x110100 card=3D0x00008086 = chip=3D0x20588086 rev=3D0x07 hdr=3D0x00 So they appear to be mainstream vendor (Intel) devices. All instances = showed =E2=80=98Vendor 0 ID 1=E2=80=99. In this particular instance, the = current FreeBSD code would print this much information and a little more = before refusing to dump more detailed information, printing printf("Vendor [%d] ID %04x Rev %d Length %d\n", ver, PCIR_VSEC_ID(hdr), PCIR_VSEC_REV(hdr), len); before returning. (After the return, it does read more registers out of = the capability, and prints more detailed information for extra registers = as found). It=E2=80=99s conceivable that reading these registers when a particular = field is zero could cause it to print erroneous or misleading = information, but there is a reasonable probability that it would be = helpful in real usage.=20 ----- --=20 David Bright dab@FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6E4EA1A3-BEEB-4D7B-BB21-EAB13A07A9C2>