From nobody Tue Oct 03 20:28:34 2023 X-Original-To: bugs@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4S0TtB5YMcz4vxcN for ; Tue, 3 Oct 2023 20:28:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4S0TtB3Lctz4hQx for ; Tue, 3 Oct 2023 20:28:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1696364914; a=rsa-sha256; cv=none; b=cIowAylKJ6aCtCAYWoY5yhkNLPwK8aQIwfihT42pXvKHJzJLxSR7srSx/U0oTHQUeNXT6K W2SUac+Qu+KN2god6rusQZIxFljbWaE9/oymWAKWT3ZIYoY2zbNxTfndNSL3YGw0fmscv8 XGLlzX4Ekjy7Spxv3Z+2cMqsyVvZ6fVZkGgjUpuqhvmxQecA8pB/w2c0VF22PgZ4kT7PKI Of5H39/2B6mH13be1lk/VYc8TnWS3ZBm9tm0VGgqNAPNCcHHjxC02zko4BjY0A3RU+UAwn aaPCSaVsHF0EuSXIQ3G7bPGcjxCZtX/8c76sFcdGZwujoAnNCkmIAVVka3bTKQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1696364914; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=vPS5wYJmBfQDxcWFwHfuSgHg+5dbRKEMGvZGfDO3uK4=; b=H3sengbEzjOnsexTesym7OK5Ev48z0TletYfQFBEOHkma5QZCRCKtNHxWXGzFsunwMjq3o vH6bZBguGjY3u21SYzjzeUHLUi1QJ+rtaAvCQ5FtyYB7GJCjhxMI+H1n++07qqM1lv3tJH xWkNi0os9BUK+kUttfguYfz17bJpURpz7Kz3aE1O7JWCITPg01f6Rr0jOe1o+OcnTJs6cD pR0MkeGmwWwkbA2dSUfkDkicfXH9el3oqqZXW5fY2VoFL8oILNGjQ57tujy9NB7lYkXSOY x0GWBq7qcr3JEYtU0lQuWfA4nqBwzO8MVHYTzwlfWT58EY+BM3doeNjYm1uEYA== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4S0TtB2PgJz17yH for ; Tue, 3 Oct 2023 20:28:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 393KSYeC036483 for ; Tue, 3 Oct 2023 20:28:34 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 393KSYwF036482 for bugs@FreeBSD.org; Tue, 3 Oct 2023 20:28:34 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f 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 Date: Tue, 03 Oct 2023 20:28:34 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: Unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: kevans@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Bug reports List-Archive: https://lists.freebsd.org/archives/freebsd-bugs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-bugs@freebsd.org MIME-Version: 1.0 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.=