[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3exillpepa4jjxsjkp5vgn4347tsvt7q22m75tp3ncavkyzgl7@juvt3p4h53km>
Date: Wed, 15 Oct 2025 13:28:02 -0400
From: "Liam R. Howlett" <Liam.Howlett@...cle.com>
To: Guenter Roeck <linux@...ck-us.net>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Feng Chen <feng.chen@...ogic.com>,
Matthew Wilcox <willy@...radead.org>, Jeff Layton <jlayton@...nel.org>,
Michal Swiatkowski <michal.swiatkowski@...ux.intel.com>,
Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>,
Tao Ren <rentao.bupt@...il.com>,
Lukas Bulwahn <lukas.bulwahn@...hat.com>,
Alexei Starovoitov <ast@...nel.org>, Vlastimil Babka <vbabka@...e.cz>
Subject: Re: Linux 6.18-rc1
+ Cc Vlastimil, as you are indicating the slab merge.
* Guenter Roeck <linux@...ck-us.net> [251015 06:02]:
> On Mon, Oct 13, 2025 at 09:46:44PM -0700, Guenter Roeck wrote:
> > On Mon, Oct 13, 2025 at 10:08:26AM -0700, Guenter Roeck wrote:
> > > On Sun, Oct 12, 2025 at 02:04:32PM -0700, Linus Torvalds wrote:
> > > > Two weeks have passed, and 6.18-rc1 has been tagged and pushed out.
> > > >
> > > > Things look fairly normal: size-wise this is pretty much right in the
> > > > middle of the pack, and nothing particular stands out in the shortlog
> > > > of merges this merge window appended below. About half the diff is
> > > > drivers, with the res being all over: vfs and filesystems, arch
> > > > updates (although much of that is actually devicetree stuff, so it's
> > > > arguably more driver-related), tooling, rust support etc etc.
> > > >
> > > > This was one of the good merge windows where I didn't end up having to
> > > > bisect any particular problem on nay of the machines I was testing.
> > > > Let's hope that success mostly translates to the bigger picture too.
> > > >
> > >
> > > Test results don't look that good, unfortunately.:
> > >
> > ...
> > > Qemu test results:
> > > total: 609 pass: 581 fail: 28
> > > Failed tests:
> ...
> > > sheb:rts7751r2dplus_defconfig:initrd
> > > sheb:rts7751r2dplus_defconfig:ata:ext2
> > > sheb:rts7751r2dplus_defconfig:usb:ext2
> > > Unit test results:
> > > pass: 655208 fail: 0
> > >
> >
>
> Update on the sheb (SH4 big endian) failures below.
What is the qemu line you use and the memory configuration of that qemu,
or is this real hardware?
Are there sh4 configs that pass?
It's a bit odd it says "fail: 0" here, Is this message about something
else?
>
> Guenter
>
> ---
>
> sheb
> ----
>
> sheb:rts7751r2dplus_defconfig:initrd
> sheb:rts7751r2dplus_defconfig:ata:ext2
> sheb:rts7751r2dplus_defconfig:usb:ext2
>
> Bisect log:
>
> # bad: [ba9dac987319d4f3969691dcf366ef19c9ed8281] Merge tag 'libnvdimm-for-6.18' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm
> # good: [e5f0a698b34ed76002dc5cff3804a61c80233a7a] Linux 6.17
> git bisect start 'HEAD' 'v6.17'
> # good: [58809f614e0e3f4e12b489bddf680bfeb31c0a20] Merge tag 'drm-next-2025-10-01' of https://gitlab.freedesktop.org/drm/kernel
> git bisect good 58809f614e0e3f4e12b489bddf680bfeb31c0a20
> # bad: [8804d970fab45726b3c7cd7f240b31122aa94219] Merge tag 'mm-stable-2025-10-01-19-00' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
> git bisect bad 8804d970fab45726b3c7cd7f240b31122aa94219
> # good: [30c3055f9c0d84a67b8fd723bdec9b1b52b3c695] xsk: wrap generic metadata handling onto separate function
> git bisect good 30c3055f9c0d84a67b8fd723bdec9b1b52b3c695
> # good: [f79e772258df311c2cb21594ca0996318e720d28] Merge tag 'media/v6.18-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
> git bisect good f79e772258df311c2cb21594ca0996318e720d28
> # good: [f1455695d2d99894b65db233877acac9a0e120b9] Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net
> git bisect good f1455695d2d99894b65db233877acac9a0e120b9
> # good: [a16c46c2402026162111ed9fd1fc28d25223443e] dma-remap: drop nth_page() in dma_common_contiguous_remap()
> git bisect good a16c46c2402026162111ed9fd1fc28d25223443e
> # good: [a5883fa94295f1ef2473eadd84cc1e24dab9ae18] selftests/mm: gup_tests: option to GUP all pages in a single call
> git bisect good a5883fa94295f1ef2473eadd84cc1e24dab9ae18
> # good: [08498be43ee676d8a5eefb22278266322578a3e0] mm/ksm: get mm_slot by mm_slot_entry() when slot is !NULL
> git bisect good 08498be43ee676d8a5eefb22278266322578a3e0
> # good: [719a42e563bb087758500e43e67a57b27f303c4c] maple_tree: Convert forking to use the sheaf interface
> git bisect good 719a42e563bb087758500e43e67a57b27f303c4c
> # good: [b9120619246d733a27e5e93c29e86f2e0401cfc5] Merge series "SLUB percpu sheaves"
> git bisect good b9120619246d733a27e5e93c29e86f2e0401cfc5
> # bad: [24d9e8b3c9c8a6f72c8b4c196a703e144928d919] Merge tag 'slab-for-6.18' of git://git.kernel.org/pub/scm/linux/kernel/git/vbabka/slab
> git bisect bad 24d9e8b3c9c8a6f72c8b4c196a703e144928d919
> # good: [83382af9ddc3cb0ef43f67d049b461720ad785e6] slab: Make slub local_(try)lock more precise for LOCKDEP
> git bisect good 83382af9ddc3cb0ef43f67d049b461720ad785e6
> # good: [af92793e52c3a99b828ed4bdd277fd3e11c18d08] slab: Introduce kmalloc_nolock() and kfree_nolock().
> git bisect good af92793e52c3a99b828ed4bdd277fd3e11c18d08
> # good: [ca74b8cadaad4b179f77f1f4dc3d288be9a580f1] Merge series "slab: Re-entrant kmalloc_nolock()"
> git bisect good ca74b8cadaad4b179f77f1f4dc3d288be9a580f1
> # good: [07fdad3a93756b872da7b53647715c48d0f4a2d0] Merge tag 'net-next-6.18' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next
> git bisect good 07fdad3a93756b872da7b53647715c48d0f4a2d0
> # first bad commit: [24d9e8b3c9c8a6f72c8b4c196a703e144928d919] Merge tag 'slab-for-6.18' of git://git.kernel.org/pub/scm/linux/kernel/git/vbabka/slab
>
> I had to revert commit 719a42e563bb ("maple_tree: Convert forking to use
> the sheaf interface") and commit af92793e52c3 ("slab: Introduce
> kmalloc_nolock() and kfree_nolock()") in the 'slab-for-6.18' branch to fix
> the problem. The first patch can not be reverted in mainline since other
> patches depend on it.
Both 719a42e563bb and af92793e52c3 are listed as good in your bisect
above. Why are the two commits you name as the cause listed as 'good'?
What did you revert to get sh4 to work, and from which git branch?
What do you mean "can not be reverted in mainline"? And which is "the
first patch", I'm assuming the first one you listed (719a42e563bb)?
>
> There is no console output (earlycon does not work) and qemu exits almost
> immediately with those patches in place. I have no idea how to debug the
> problem further.
Never a fun situation :/
Thanks,
Liam
Powered by blists - more mailing lists