Date: Fri, 18 Mar 2022 16:54:41 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 262638] overly strict check of hpet region size Message-ID: <bug-262638-227-M428t3W6Yq@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-262638-227@https.bugs.freebsd.org/bugzilla/> References: <bug-262638-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D262638 Mark Johnston <markj@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Open CC| |markj@FreeBSD.org --- Comment #3 from Mark Johnston <markj@FreeBSD.org> --- The value of 1024 comes directly from the Intel specification, see section = 2.1: https://www.intel.com/content/dam/www/public/us/en/documents/technical-spec= ifications/software-developers-hpet-spec-1-0a.pdf Some AMD documentation for 16h processors suggests that only three timers a= re available, and the MMIO space for HPET registers is indeed only 512 bytes in size: https://www.amd.com/system/files/TechDocs/52740_16h_Models_30h-3Fh_BKDG.pdf Changing the value of HPET_MEM_WIDTH doesn't seem like the right solution: hpet_identify() uses that constant to initialize the memory resource for the hpet driver if it can't get the resource size from acpi. We could instead modify the check in hpet_attach() to first verify that the resource is large enough to read the capabilities register, then check it again once we have = the number of timers. --=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-262638-227-M428t3W6Yq>