Bug 270415
| Summary: | ram0 pseudo-driver breaks ARM64 on Hyper-V on CURRENT | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Base System | Reporter: | Wei Hu <weh> | ||||||
| Component: | arm | Assignee: | freebsd-arm (Nobody) <freebsd-arm> | ||||||
| Status: | Closed FIXED | ||||||||
| Severity: | Affects Some People | CC: | emaste, freebsd, kevans, lwhsu, marklmi26-fbsd, mhorne, weh | ||||||
| Priority: | --- | ||||||||
| Version: | CURRENT | ||||||||
| Hardware: | arm64 | ||||||||
| OS: | Any | ||||||||
| URL: | https://reviews.freebsd.org/D39260 | ||||||||
| Attachments: |
|
||||||||
|
Description
Wei Hu
2023-03-23 07:20:26 UTC
Can you share a boot -v (boot_verbose=YES in loader.conf/loader) dmesg, please? (In reply to Kyle Evans from comment #1) This, as well as the output of "show all rman" at the ddb prompt, if possible. There was a later fix that ;ile;y should be tested to see if it avoids the problem: Wed, 15 Mar 2023 . . . git: 8937bd37d07c - main - arm64: limit EFI excluded regions to physical memory types Mitchell Horne (In reply to Mark Millard from comment #3) Sorry; ";ile;y" should have been "likely". (In reply to Mark Millard from comment #3) Yes, I was debugging with someone else that did already have the follow-up Created attachment 241081 [details]
Console output, 3/23 CURRENT, Azure Standard D48ps v5, no boot verbose
(In reply to Mark Millard from comment #3) The problem (panic) still exists on 3/23 CURRENT build. See the attached serial console log with 'show all rman' output. I will upload one with boot verbose enabled shortly. Created attachment 241087 [details]
Console output, 3/23 CURRENT, Azure Standard D48ps v5, boot verbose with show all rman
This is the one with verbose boot.
(In reply to Wei Hu from comment #8) Looks to me like the following might be being classifieed as conflicting via the overlapping ranges: (gic0: <ARM Generic Interrupt Controller v3.0> iomem) 0xffff0000 -0x10000ffff 0x100000000- 0xfc0000000 (ram0: reserving memory region:) (Not that I'm expert at these issues.) (In reply to Wei Hu from comment #8) Thank you very much. I believe I was able to identify the problem based on the overlapping ranges of gic0 and physmem. I posted a review to address this. Please test the change if you are able, and let me know if it solves the problem. https://reviews.freebsd.org/D39260 Mitchell (In reply to Mitchell Horne from comment #10) I tested this patch on the same VM in Azure. It fixes the problem. Thanks for fixing it. A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=3462c371c2562a8144f4245f9967df99874e505f commit 3462c371c2562a8144f4245f9967df99874e505f Author: Mitchell Horne <mhorne@FreeBSD.org> AuthorDate: 2023-03-31 15:32:39 +0000 Commit: Mitchell Horne <mhorne@FreeBSD.org> CommitDate: 2023-03-31 16:26:22 +0000 arm64/gicv3: correct the size of the distributor resource Use the GICD_SIZE macro (0x10000), which is half the size of the current fixed-sized mapping (128 * 1024 == 0x20000). In ARM64 Hyper-V instances, it seems the Distributor's registers are located immediately preceding a range of physical memory in the bus address space. Thus, when ram0 is attaching and attempts to reserve SYS_RES_MEMORY resources corresponding to its physmem ranges, it fails, because the first 0x10000 bytes of this range are already owned by gic0. PR: 270415 Reported by: whu Tested by: whu Differential Revision: https://reviews.freebsd.org/D39260 sys/arm64/arm64/gic_v3_acpi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=98ee3bb87a7a46b2ecae96159258632b8f6f3520 commit 98ee3bb87a7a46b2ecae96159258632b8f6f3520 Author: Mitchell Horne <mhorne@FreeBSD.org> AuthorDate: 2023-03-31 15:32:39 +0000 Commit: Mitchell Horne <mhorne@FreeBSD.org> CommitDate: 2023-04-12 17:08:38 +0000 arm64/gicv3: correct the size of the distributor resource Use the GICD_SIZE macro (0x10000), which is half the size of the current fixed-sized mapping (128 * 1024 == 0x20000). In ARM64 Hyper-V instances, it seems the Distributor's registers are located immediately preceding a range of physical memory in the bus address space. Thus, when ram0 is attaching and attempts to reserve SYS_RES_MEMORY resources corresponding to its physmem ranges, it fails, because the first 0x10000 bytes of this range are already owned by gic0. PR: 270415 Reported by: whu Tested by: whu Differential Revision: https://reviews.freebsd.org/D39260 (cherry picked from commit 3462c371c2562a8144f4245f9967df99874e505f) sys/arm64/arm64/gic_v3_acpi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) |
