https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211746
Maxim Sobolev changed:
What|Removed |Added
See Also||https://bugs.freebsd.org/bu
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211746
Dexuan Cui changed:
What|Removed |Added
Status|New |Closed
Resolution|---
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211746
--- Comment #34 from commit-h...@freebsd.org ---
A commit references this bug:
Author: dexuan
Date: Thu Mar 30 12:51:44 UTC 2017
New revision: 316273
URL: https://svnweb.freebsd.org/changeset/base/316273
Log:
MFC: 314547, 314770, 314828,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211746
--- Comment #33 from commit-h...@freebsd.org ---
A commit references this bug:
Author: dexuan
Date: Thu Mar 30 12:41:21 UTC 2017
New revision: 316272
URL: https://svnweb.freebsd.org/changeset/base/316272
Log:
MFC: 314547, 314770, 314828,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211746
--- Comment #32 from commit-h...@freebsd.org ---
A commit references this bug:
Author: dexuan
Date: Thu Mar 30 12:41:21 UTC 2017
New revision: 316272
URL: https://svnweb.freebsd.org/changeset/base/316272
Log:
MFC: 314547, 314770, 314828,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211746
--- Comment #31 from commit-h...@freebsd.org ---
A commit references this bug:
Author: dexuan
Date: Thu Mar 30 12:41:21 UTC 2017
New revision: 316272
URL: https://svnweb.freebsd.org/changeset/base/316272
Log:
MFC: 314547, 314770, 314828,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211746
--- Comment #30 from Marcel Moolenaar ---
(In reply to Dexuan Cui from comment #27)
Thanks for collecting the memory maps and resolving any issues!
--
You are receiving this mail because:
You are the assignee for the bug.
___
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211746
--- Comment #29 from commit-h...@freebsd.org ---
A commit references this bug:
Author: dexuan
Date: Tue Mar 14 08:12:14 UTC 2017
New revision: 315235
URL: https://svnweb.freebsd.org/changeset/base/315235
Log:
loader.efi: use stricter che
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211746
--- Comment #28 from Dexuan Cui ---
(In reply to Dexuan Cui from comment #27)
> We can notice there is a 4MB BootServicesCode range at [12MB, 16MB) ...
loader.efi just writes into this range by force -- this is unsafe anyway!
To fix this
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211746
--- Comment #27 from Dexuan Cui ---
Created attachment 180660
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=180660&action=edit
The unusual EFI memory map on Roberto's physical host
--
You are receiving this mail because:
You a
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211746
--- Comment #26 from Dexuan Cui ---
(In reply to Dexuan Cui from comment #25)
FYI:
Let me attach 1 more sample of unusual EFI memory map from Roberto's physical
host.
We can notice there is an unusual 4MB range of BootServicesCode at [12
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211746
--- Comment #25 from Dexuan Cui ---
Created attachment 180585
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=180585&action=edit
EFI mem map from Supermicro A1SRM-2758F host
--
You are receiving this mail because:
You are the as
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211746
--- Comment #24 from Dexuan Cui ---
(In reply to Dexuan Cui from comment #23)
FYI:
Let me attach another sample of unusual EFI memory map from Alex's Supermicro
A1SRM-2758F host.
We can notice the 2MB range's type is BootServicesData ins
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211746
--- Comment #23 from Dexuan Cui ---
Created attachment 180552
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=180552&action=edit
uefi-mem-map-on-native.png
--
You are receiving this mail because:
You are the assignee for the bug
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211746
--- Comment #22 from Dexuan Cui ---
(In reply to commit-hook from comment #21)
Some people reported the fix was breaking their hosts.
Chris H is the first person to dump the EFI memory map to me: on the host there
is a 1MB LoaderData memo
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211746
--- Comment #21 from commit-h...@freebsd.org ---
A commit references this bug:
Author: dexuan
Date: Thu Mar 2 07:25:50 UTC 2017
New revision: 314547
URL: https://svnweb.freebsd.org/changeset/base/314547
Log:
loader.efi: reduce the size
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211746
--- Comment #20 from Dexuan Cui ---
(In reply to Dexuan Cui from comment #19)
I posted https://reviews.freebsd.org/D9686 for this bug.
--
You are receiving this mail because:
You are the assignee for the bug.
_
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211746
--- Comment #19 from Dexuan Cui ---
(In reply to Dexuan Cui from comment #18)
It looks this is indeed a complex issue and a lots of work is required to have
a thorough fix.
For now, I'm planning to make a patch to verify the assumption th
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211746
--- Comment #18 from Dexuan Cui ---
(In reply to Marcel Moolenaar from comment #17)
Thanks very much for sharing the insights, Marcel!
BTW, last year, people already reported an issue with mfs-based images +
EFI_STAGING_SIZE=1024MB:
https:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211746
--- Comment #17 from Marcel Moolenaar ---
I think the complexity of having the kernel at any other physical address is
what has us do the staging/copying. It was a quick-n-dirty mechanism that
avoided a lot of work and complexity -- which i
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211746
--- Comment #16 from Dexuan Cui ---
(In reply to Marcel Moolenaar from comment #15)
Probably. IMO this means we can't freely change the 2MB kernphys.
--
You are receiving this mail because:
You are the assignee for the bug.
__
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211746
--- Comment #15 from Marcel Moolenaar ---
Maybe because of sys/boot/common/load_elf.c, line 329?
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-virtualizat
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211746
--- Comment #14 from Dexuan Cui ---
BTW, anyone knows how to change the kernel base address (physical address)?
Currently it should be 2MB, and I tried to change it to 128MB like this:
--- a/sys/conf/ldscript.amd64
+++ b/sys/conf/ldscript
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211746
--- Comment #13 from Dexuan Cui ---
Created attachment 180002
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=180002&action=edit
new mem map before/after the AllocatePages with staging below 1G
--
You are receiving this mail bec
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211746
--- Comment #12 from Dexuan Cui ---
(In reply to Marcel Moolenaar from comment #10)
Hi Mercel,
You're correct about the second bug -- we don't hit the second bug just because
we are lucky: when accessing 0xf37cb000, we actually access 0x337
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211746
Dexuan Cui changed:
What|Removed |Added
CC||k...@freebsd.org
--- Comment #11 from
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211746
--- Comment #10 from Marcel Moolenaar ---
I just realized that efi_copy_finish() is called via trampoline(). I presume
that this means that it runs with the temporary mapping that was created in
elf64_exec(). We only map the 1GB of physical
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211746
--- Comment #9 from Dexuan Cui ---
(In reply to Marcel Moolenaar from comment #6)
Differences between the maps are:
1) In the first red rectangle, we can see 48MB memory (0x3000 pages) is
allocated from ConvventionalMemory to LoaderData a
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211746
--- Comment #8 from Dexuan Cui ---
Created attachment 179977
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=179977&action=edit
memory map before vs. after allocating 48MB memory
--
You are receiving this mail because:
You are t
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211746
--- Comment #7 from Dexuan Cui ---
(In reply to Marcel Moolenaar from comment #6)
I'll be attaching the memory map before and after
efi_copy_init() -> BS->AllocatePages (..., 48MB, ...)
BTW, in my test, STAGE_PAGES <= 45MB is OK, and >=46
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211746
--- Comment #6 from Marcel Moolenaar ---
Check in the EFI memory map whether there's runtime-persistent memory at
0x20 + 45MB (or abouts). Runtime persistent memory are memory allocations
of type runtime, firmware, (e.g. ACPI non-reclai
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211746
--- Comment #5 from Dexuan Cui ---
(In reply to Dexuan Cui from comment #4)
> last = (uint64_t *)staging + (1024*1024*45);
I meant
last = (uint64_t *) (staging + (1024*1024*45));
(I missed a pair of parentheses)
--
You are receiving th
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211746
--- Comment #4 from Dexuan Cui ---
(In reply to Marcel Moolenaar from comment #3)
Hi Marcel,
Thank you for the quick help!
Yes, I checked all the AllocatePages() calls and they all succeeded, i.e.
returning 0.
I found the crash happened
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211746
--- Comment #3 from Marcel Moolenaar ---
It looks like AllocatePages() succeeded. Is that correct?
If yes, then it's possible that there's a Hyper-V bug.
Try to obtain the memory map before the call to AllocatePages and then again
after
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211746
--- Comment #2 from Dexuan Cui ---
By bisecting, I found the first "bad" commit for this bug is:
https://github.com/freebsd/freebsd/commit/6471c2fc7c1fced2b5d2073b1629aa76588c61e2
(it changed EFI_STAGING_SIZE from 32MB to 48MB).
It looks
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211746
Mark Linimon changed:
What|Removed |Added
Assignee|freebsd-b...@freebsd.org|freebsd-virtualization@Free
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211746
Dexuan Cui changed:
What|Removed |Added
CC||delp...@freebsd.org,
37 matches
Mail list logo
