[*really* added kexec maintainers this time.] Full thread starts here: https://lore.kernel.org/all/3a1b9909-45ac-4f97-ad68-d16ef1ce99db@xxxxxxxxxxxxxxx/ On Wed, Mar 13, 2024 at 12:12:31AM +0530, Pavin Joseph wrote: > On 3/12/24 20:43, Steve Wahl wrote: > > But I don't want to introduce a new command line parameter if the > > actual problem can be understood and fixed. The question is how much > > time do I have to persue a direct fix before some other action needs > > to be taken? > > Perhaps the kexec maintainers [0] can be made aware of this and you could > coordinate with them on a potential fix? > > Currently maintained by > P: Simon Horman > M: horms@xxxxxxxxxxxx > L: kexec@xxxxxxxxxxxxxxxxxxx Probably a good idea to add kexec people to the list, so I've added them to this email. Everyone, my recent patch to the kernel that changed identity mapping: 7143c5f4cf2073193 x86/mm/ident_map: Use gbpages only where full GB page should be mapped. ... has broken kexec on a few machines. The symptom is they do a full BIOS reboot instead of a kexec of the new kernel. Seems to be limited to AMD processors, but it's not all AMD processors, probably just some characteristic that they happen to share. The same machines that are broken by my patch, are also broken in previous kernels if you add "nogbpages" to the kernel command line (which makes the identity map bigger, "nogbpages" doing for all parts of the identity map what my patch does only for some parts of it). I'm still hoping to find a machine I can reproduce this on to try and debug it myself. If any of you have any assistance or advice to offer, it would be most welcome! > I hope the root cause can be fixed instead of patching it over with a flag > to suppress the problem, but I don't know how regressions are handled here. That would be my preference as well. Thanks, --> Steve Wahl -- Steve Wahl, Hewlett Packard Enterprise
