Also Affect Ryzen 7 PRO with Radeon Graphics.

Hey, do you have use multiple monitors? I have similar crashes on boot with AMD Ryzen 9 5950X. When unplugging my 2nd monitor it boots fine 100% of the time.

No. It is laptop with it's own display. No more monitors connected.

Hi Azamat,

Can you try latest mainline to see if this regression disappears?

(In reply to Bagas Sanjaya from comment #4)
> Hi Azamat,
> 
> Can you try latest mainline to see if this regression disappears?

Please check https://bugzilla.kernel.org/show_bug.cgi?id=216340 first. There are found bisect that affects my case. If you think that after that things belongs to it changed, I can try latest mainline without page_poison=0.

> # git bisect good
> f289041ed4cf9a3f6e8a32068fef9ffb2acc5662 is the first bad commit
> commit f289041ed4cf9a3f6e8a32068fef9ffb2acc5662
> Author: Vlastimil Babka <vbabka@suse.cz>
> Date:   Mon Dec 14 19:13:45 2020 -0800
> 
>     mm, page_poison: remove CONFIG_PAGE_POISONING_ZERO
>      
>     CONFIG_PAGE_POISONING_ZERO uses the zero pattern instead of 0xAA.  It was
>     introduced by commit 1414c7f4f7d7 ("mm/page_poisoning.c: allow for zero
>     poisoning"), noting that using zeroes retains the benefit of sanitizing
>     content of freed pages, with the benefit of not having to zero them again
>     on alloc, and the downside of making some forms of corruption (stray
>     writes of NULLs) harder to detect than with the 0xAA pattern.  Together
>     with CONFIG_PAGE_POISONING_NO_SANITY it made possible to sanitize the
>     contents on free without checking it back on alloc.
>     
>     These days we have the init_on_free() option to achieve sanitization with
>     zeroes and to save clearing on alloc (and without checking on alloc).
>     Arguably if someone does choose to check the poison for corruption on
>     alloc, the savings of not clearing the page are secondary, and it makes
>     sense to always use the 0xAA poison pattern.  Thus, remove the
>     CONFIG_PAGE_POISONING_ZERO option for being redundant.
>     
>     Link: https://lkml.kernel.org/r/20201113104033.22907-6-vbabka@suse.cz
>     Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
>     Acked-by: David Hildenbrand <david@redhat.com>
>     Cc: Mike Rapoport <rppt@linux.ibm.com>
>     Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>     Cc: Alexander Potapenko <glider@google.com>
>     Cc: Kees Cook <keescook@chromium.org>
>     Cc: Laura Abbott <labbott@kernel.org>
>     Cc: Mateusz Nosek <mateusznosek0@gmail.com>
>     Cc: Michal Hocko <mhocko@kernel.org>
>     Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>     Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
> 
>  include/linux/poison.h       |  4 ----
>  mm/Kconfig.debug             | 12 ------------
>  mm/page_alloc.c              |  8 +-------
>  tools/include/linux/poison.h |  6 +-----
>  4 files changed, 2 insertions(+), 28 deletions(-)

[reply] [−] Comment 23

At current time I use kernel with page_poison=0 without any issues.

(In reply to Azamat S. Kalimoulline from comment #5)
> (In reply to Bagas Sanjaya from comment #4)
> > Hi Azamat,
> > 
> > Can you try latest mainline to see if this regression disappears?
> 
> Please check https://bugzilla.kernel.org/show_bug.cgi?id=216340 first. There
> are found bisect that affects my case. If you think that after that things
> belongs to it changed, I can try latest mainline without page_poison=0.
> 

OK, thanks!