On Thu, 2021-12-16 at 17:47 +, Christophe Leroy wrote:
Tested-by: Maxime Bizon
Now running fine with every CONFIG_DEBUG_xxx enabled, thanks!
--
Maxime
On Tuesday 07 Dec 2021 à 07:11:40 (+0100), Christophe Leroy wrote:
Hello Christophe,
With all your recent patches, I was able to boot a kernel with every
CONFIG_DEBUG enabled.
After modprobing an empty module (probe just return 0), I get this new
one:
[ 15.351649] BUG: spinlock recursion on
On Friday 10 Dec 2021 à 08:09:42 (+), Christophe Leroy wrote:
Tested-by: Maxime Bizon
--
Maxime
On Tue, 2021-12-07 at 06:10 +, Christophe Leroy wrote:
Hello,
With the patch applied and
CONFIG_DEBUG_PAGEALLOC=y
CONFIG_DEBUG_PAGEALLOC_ENABLE_DEFAULT=y
CONFIG_DEBUG_VM=y
I get tons of this during boot:
[0.00] Dentry cache hash table entries: 262144 (order: 8, 1048576
bytes, li
On Mon, 2021-12-06 at 14:12 +, Christophe Leroy wrote:
Tested-by: Maxime Bizon
--
Maxime
On Tue, 2021-12-07 at 05:54 +, Christophe Leroy wrote:
>
> Did you check with my latest patch (v2) ?
>
yes I did, works perfectly, I just sent the Tested-By
--
Maxime
On Mon, 2021-12-06 at 11:11 +, Christophe Leroy wrote:
>
> Reported-by: Maxime Bizon
Tested-by: Maxime Bizon
maybe stable ? I had this on 5.15
Thanks !
--
Maxime
On Mon, 2021-12-06 at 14:22 +, Christophe Leroy wrote:
> Fixed both in v2.
Works fine, many thanks
--
Maxime
On Mon, 2021-12-06 at 09:07 +, Christophe Leroy wrote:
Hello,
> Looks like you can win something if you take the patch I just sent
> and replace the memblock_phys_alloc(k_size, k_size) by
> memblock_phys_alloc_range(k_size, k_size, 0, MEMBLOCK_ALLOC_ANYWHERE)
I tried your patch without y
On Mon, 2021-12-06 at 07:03 +, Christophe Leroy wrote:
> Is it worth it ? I have the feeling that's more a corner case.
probably not since it's not an easy fix
I'm running on the edge wrt BAT usage on my 2GB board, it's not that
common I guess.
--
Maxime
On Sunday 05 Dec 2021 à 18:11:59 (+), Christophe Leroy wrote:
> > Is BAT5 needed here ?
>
> Sure it is, because that's were kernel expects lowmem to be mapped.
> Allthough the kernel will unlikely access the 128M reserved for KASAN
> directly, the other 128M are still needed.
>
Yes tha
Hello,
With CONFIG_DEBUG_VM=y, early_iounmap() triggers this:
VM_WARN_ON(pte_hw_valid(*ptep) && !pte_protnone(*ptep));
[0.292811] WARNING: CPU: 0 PID: 1 at arch/powerpc/mm/pgtable.c:194
set_pte_at+0x8c/0x21c
[0.301053] CPU: 0 PID: 1 Comm: swapper Tainted: GW 5.
On Saturday 04 Dec 2021 à 17:42:44 (+), Christophe Leroy wrote:
> I guess all the guard is in the comment ...
>
> /*
> * Set up one of the I/D BAT (block address translation) register pairs.
> * The parameters are not checked; in particular size must be a power
> * of 2 between 128k
On Saturday 04 Dec 2021 à 10:01:07 (+), Christophe Leroy wrote:
> In fact BAT4 is wrong. Both virtual and physical address of a 64M BAT
> must be 64M aligned. I think the display is wrong as well (You took it
oh so hardware does simple bitmask after all
I got fooled by the lack of guard i
On Fri, 2021-12-03 at 12:49 +, Christophe Leroy wrote:
Hello,
> I need to think a bit more about it to find the cleanest solution
> that works for all platforms.
Maybe related, when enabling KASAN on that same platform, it oopses early.
I have picked the patch "powerpc/32s: Fix shift-out-
15 matches
Mail list logo
