Date: Tue, 03 Oct 2023 20:28:34 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 274252] sys/vm: less-than-ideal handling of memory requests that cannot be fulfilled Message-ID: <bug-274252-227@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D274252 Bug ID: 274252 Summary: sys/vm: less-than-ideal handling of memory requests that cannot be fulfilled Product: Base System Version: Unspecified Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: kevans@freebsd.org Splitting off from PR 274237, because I haven't actually created a PR for t= his previously, but it'd be nice to track. With at least some ARM machines, it's possible to get stuck in a nice loop = in xhci attach because the VM bits don't handle some class of requests that ca= nnot be satisfied very well. In particular, consider this system: Physical memory chunk(s):=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20 0x000008010a8000 - 0x00000802313fff, 19316736 bytes (1179 pages)=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20 0x000008023d8000 - 0x0000080389bfff, 21774336 bytes (1329 pages)=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20 0x000008038b8000 - 0x00000808f97fff, 91095040 bytes (5560 pages)=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20 0x00000808fb8000 - 0x0000080ba03fff, 44351488 bytes (2707 pages)=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20 0x0000080c12c000 - 0x000009d036ffff, 7585677312 bytes (462993 pages)=20=20= =20=20=20=20=20=20=20=20=20=20 0x000009d4f68000 - 0x000009db93bfff, 110968832 bytes (6773 pages)=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20 0x000009db944000 - 0x000009e096ffff, 84066304 bytes (5131 pages)=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20 0x000009e0980000 - 0x000009e0a37fff, 753664 bytes (46 pages)=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 avail memory =3D 7955300352 (7586 MB)=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20 Note that there's absolutely no RAM in the lower 4G of the address space. There's an XHCI controller that can only do 32-bit DMA (allegedly) and it h= as an associated IOMMU that isn't hooked up just yet. Right now, busdma will request some pages below 4G (IIRC, it's with kmem_alloc_contig here[0]), but that request cannot be satisfied -- there's absolutely no memory there. Instead, it ends up hanging in the VM layer try= ing to fulfill an allocation that isn't physically possible. I think it'd be better to fail the request and let busdma kick back an ENOM= EM. The XHCI controller will not be functional, but that's both expected and no= t a deal-breaker for getting the machine into a usable state. [0] https://cgit.freebsd.org/src/tree/sys/arm64/arm64/busdma_bounce.c#n572 --=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-274252-227>