>
> On Thu, Nov 24, 2022 at 01:08:57AM +0000, Dominic Jones wrote:
> > > On Fri, Oct 28, 2022 at 02:51:43PM +0000, Dominic Jones wrote:
> > > > Updating the machine's kernel from v5.19.x to v6.0.x causes the machine to not
> > > > successfully boot. The machine boots successfully (and exhibits stable operation)
> > > > with version v5.19.17 and multiple earlier releases in the 5.19 line. Multiple releases
> > > > from the 6.0 line (including 6.0.0, 6.0.3, and 6.0.5), with no other changes to the
> > > > software environment, do not boot. Instead, the machine hangs after loading services
> > > > but before presenting a display manager; the machine instead shows repetitive hard
> > > > drive activity at this point and then no apparent activity.
> > > >
> > > > ''uname'' output for the machine successfully running v5.19.17 is:
> > > >
> > > > Linux [MACHINE_NAME] 5.19.17 #1 SMP PREEMPT_DYNAMIC Mon Oct 24 13:32:29 2022 i686 Intel(R) Atom(TM) CPU N270 @ 1.60GHz GenuineIntel GNU/Linux
> > > >
> > > > The machine is an OCZ Neutrino netbook, running a custom OS build largely similar to
> > > > LFS development. The kernel update uses ''make olddefconfig''.
> > >
> > > Can you use 'git bisect' to find the offending change that causes this
> > > to happen?
> >
> > Bisection is complete. Here's what it returned.
> >
> > ---
> >
> > 3a194f3f8ad01bce00bd7174aaba1563bcc827eb is the first bad commit
> > commit 3a194f3f8ad01bce00bd7174aaba1563bcc827eb
> > Author: Naoya Horiguchi <naoya.horiguchi@xxxxxxx>
> > Date: Thu Jul 14 13:24:14 2022 +0900
> >
> > mm/hugetlb: make pud_huge() and follow_huge_pud() aware of non-present pud entry
> >
> > follow_pud_mask() does not support non-present pud entry now. As long as
> > I tested on x86_64 server, follow_pud_mask() still simply returns
> > no_page_table() for non-present_pud_entry() due to pud_bad(), so no severe
> > user-visible effect should happen. But generally we should call
> > follow_huge_pud() for non-present pud entry for 1GB hugetlb page.
> >
> > Update pud_huge() and follow_huge_pud() to handle non-present pud entries.
> > The changes are similar to previous works for pud entries commit
> > e66f17ff7177 ("mm/hugetlb: take page table lock in follow_huge_pmd()") and
> > commit cbef8478bee5 ("mm/hugetlb: pmd_huge() returns true for non-present
> > hugepage").
> >
> > Link: https://lkml.kernel.org/r/20220714042420.1847125-3-naoya.horiguchi@xxxxxxxxx
> > Signed-off-by: Naoya Horiguchi <naoya.horiguchi@xxxxxxx>
> > Reviewed-by: Miaohe Lin <linmiaohe@xxxxxxxxxx>
> > Reviewed-by: Mike Kravetz <mike.kravetz@xxxxxxxxxx>
> > Cc: David Hildenbrand <david@xxxxxxxxxx>
> > Cc: kernel test robot <lkp@xxxxxxxxx>
> > Cc: Liu Shixin <liushixin2@xxxxxxxxxx>
> > Cc: Muchun Song <songmuchun@xxxxxxxxxxxxx>
> > Cc: Oscar Salvador <osalvador@xxxxxxx>
> > Cc: Yang Shi <shy828301@xxxxxxxxx>
> > Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
> >
> > arch/x86/mm/hugetlbpage.c | 8 +++++++-
> > mm/hugetlb.c | 32 ++++++++++++++++++++++++++++++--
> > 2 files changed, 37 insertions(+), 3 deletions(-)
> >
I got two replies here, so I'm responding to both for visibility.
>From Greg K H:
> Great! Please work with those developers to figure out why this is
> causing a problem for your system.
>From Thorsten L:
> Many thx for this. A fix for that particular commit for recently
> committed to 6.0.y:
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-6.0.y&id=bccc10be65e365ba8a3215cb702e6f57177eea07
>
> That thus bears the question: does your problem still happen with the
> latest 6.0.y version?
Version 6.0.9 appears to fix the issue, with no regression as of 6.0.10.
(The issue appeared in 6.0.7. I didn't test 6.0.8 since 6.0.9 had already
appeared by the time bisection was complete.)
Thanks!
Dominic Jones
jonesd@xxxxxxxxxxxx
