Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

no-disk builds failing over a certain size #210

Open
NathanTP opened this issue Sep 2, 2021 · 3 comments
Open

no-disk builds failing over a certain size #210

NathanTP opened this issue Sep 2, 2021 · 3 comments

Comments

@NathanTP
Copy link
Contributor

NathanTP commented Sep 2, 2021

--no-disk builds over about 128mb have begun failing. This used to work so it's a mystery as to why it's happening again.

Issue originally reported here: ucb-bar/chipyard#950

Reproduction instructions:
use a workload like tests/overlay.yaml and dd a large file (>100MB) into the overlay. Building without no-disk should work, with --no-disk will hang early in the boot process. See the original bug report on chipyard for details.

@a0u
Copy link
Member

a0u commented Sep 18, 2021

With older versions of the Linux kernel, the provisional page tables created when virtual memory is first enabled can map at most a certain range, hardcoded to be only 128 MiB by default. If the size of the kernel image exceeds this limit, then setup_vm() simply BUG()s out and enters an infinite loop:
https://github.com/firesim/linux/blob/280191c0a6693bce79bec8ef235f58d5f3de4a47/arch/riscv/mm/init.c#L393

Increase MAX_EARLY_MAPPING_SIZE in boards/default/linux/arch/riscv/mm/init.c to work around this:
https://github.com/firesim/linux/blob/280191c0a6693bce79bec8ef235f58d5f3de4a47/arch/riscv/mm/init.c#L190

#define MAX_EARLY_MAPPING_SIZE	(SZ_1G)

Fortunately, it appears this limitation has been fixed as of v5.12 (torvalds/linux@0f02de4).

@a0u
Copy link
Member

a0u commented Sep 18, 2021

It looks like v5.12 and later bring only a partial fix. The VM init code was simplified to statically allocate only a single 2nd-level page table (PMD) for the provisional kernel mappings, effectively limiting the range to 1 GiB (i.e., 512 entries of 2 MiB megapages).

I don't think extremely large initramfs images will be well-supported going forward. To be fair, it is not a common use case on real systems.

@NathanTP
Copy link
Contributor Author

I have been talking with @davidbiancolin about bumping the kernel anyway, but there was apparently some problem. I think bumping to 5.14 (currently the latest stable) is the best solution here. I don't know if anyone has that big of an image but I can't imagine it would work well anywhere anyway. At that point I imagine you'd be better off writing a disk model for Spike than fixing Linux.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants