Date: Thu, 02 Jun 2022 13:22:23 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 264414] ACPI resource allocation for buggy _CRS entries causes "I/O range not supported" message Message-ID: <bug-264414-227@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D264414 Bug ID: 264414 Summary: ACPI resource allocation for buggy _CRS entries causes "I/O range not supported" message Product: Base System Version: 13.1-STABLE Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: crahman@gmail.com There's detailed background information regarding this in bug #224096. With the MacBook Pro in bug #224096, the range's maximum - minimum was equa= l to the specified length. But in the AMI 'Alaska' BIOS, the maximum is selected so that the length includes both the top and bottom bytes, e.g. maximum - minimum + 1: IO (Decode16, 0x0070, // Range Minimum 0x0077, // Range Maximum 0x01, // Alignment 0x08, // Length ) And so, as a result, the "I/O range not supported" message is generated and= no resource is allocated. This is in a ResourceTemplate for the _CRS for PCI0. An sample ASL from the AMI 'Alaska' BIOS that illustrates the issue may be found here:=20 https://github.com/linuxhw/ACPI/blob/master/Desktop/TONK/TN/TN1402/ABC6298C= B633 I haven't noticed any malfunctions resulting from this other than the error message, and correcting either the ASL or changing acpi_resource.c to set up the resource anyway does not change this. I also don't know enough about h= ow the PCI controller uses this range to know if there should be a problem.=20= =20 However, it appears that perhaps the correct solution to bug #224096 might = be not to check for both (high =3D=3D (low + length)) and (high =3D=3D (low + = length - 1)), but rather to just set up the resource anyway, perhaps making note of = the compensation for the BIOS problem. As this is hardly a new problem, and no one has reported any malfunctions resulting from it, the issue is not so much this particular case but to pro= vide a reference for some future troubleshooter's search. My incomplete understanding of the situation means I am only suggesting that someone who knows more about this examine the issue. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-264414-227>