Re: [PATCH 01/10] alpha: use libata instead of the legacy ide driver
Al Viro writes: > ... > > Do you have reports of libata variants of drivers actually tested on > those? PATA_CMD64X works fine on my 164LX for many years, last tested with 5.12-rc3. (with a caveat: in my setup with CF card DMA is broken, but it is broken with BLK_DEV_CMD64X as well).
Re: [PATCH] powerpc/32s: Use relocation offset when setting early hash table
Christophe Leroy writes:
> When calling early_hash_table(), the kernel hasn't been yet
> relocated to its linking address, so data must be addressed
> with relocation offset.
>
> Add relocation offset to write into Hash in early_hash_table().
>
> Reported-by: Erhard Furtner
> Reported-by: Andreas Schwab
> Fixes: 69a1593abdbc ("powerpc/32s: Setup the early hash table at all time.")
> Signed-off-by: Christophe Leroy
Tested-by: Serge Belyshev
Re: [PATCH] powerpc/32s: Setup the early hash table at all time.
>>> To be sure we are not in front of a long lasting bug, could you try >>> CONFIG_KASAN=y on v5.9 ? >> >> Indeed it started to fail somewhere between v5.6 and v5.7. >> >> v5.7 fails early with few messages on the console with reboot, v5.8 and >> later hang right at bootloader. >> >> I'm bisecting now. > > (side note: I tried FB_OF=y instead of DRM_RADEON + DRM_FBDEV_* to speed > up bisection and it turns out in that configuration KASAN never worked, > down to commit 305d600123046, hanging right after bootloader or even > with invalid access in the bootloader itself). My bisection ended up nowhere (at net-next merge with 2k commits), and given the above failure with unrelated configuration change, I conclude that KASAN=y was always broken on this box.
Re: [PATCH] powerpc/32s: Setup the early hash table at all time.
>> To be sure we are not in front of a long lasting bug, could you try >> CONFIG_KASAN=y on v5.9 ? > > Indeed it started to fail somewhere between v5.6 and v5.7. > > v5.7 fails early with few messages on the console with reboot, v5.8 and > later hang right at bootloader. > > I'm bisecting now. (side note: I tried FB_OF=y instead of DRM_RADEON + DRM_FBDEV_* to speed up bisection and it turns out in that configuration KASAN never worked, down to commit 305d600123046, hanging right after bootloader or even with invalid access in the bootloader itself).
Re: [PATCH] powerpc/32s: Setup the early hash table at all time.
Christophe Leroy writes: > To be sure we are not in front of a long lasting bug, could you try > CONFIG_KASAN=y on v5.9 ? Indeed it started to fail somewhere between v5.6 and v5.7. v5.7 fails early with few messages on the console with reboot, v5.8 and later hang right at bootloader. I'm bisecting now.
Re: [PATCH] powerpc/32s: Setup the early hash table at all time.
> Would you mind checking that with that patch reverted, you are able to > boot a kernel built with CONFIG_KASAN ? I can reproduce the same problem on a powerbook G4, and no, CONFIG_KASAN=y kernel with that patch reverted also does not boot with the same symptom: white screen at the bootloader right after "Booting Linux via __start() @ 0x014 ..."
Re: BUG: crash in __tlb_remove_page_size with STRICT_KERNEL_RWX on BOOK3S_32
Hi! > As pointed by Segher, those are not correct, bat 2 for instance should > be 0xc0c0-0xc0ff > > Could you try the below changes ? > > commit 5953416b8ef52107e8f04559a08a90aa5368cfcd > Author: Christophe Leroy > Date: Mon Apr 29 07:22:08 2019 + > > powerpc/32s: fix BATs setting with CONFIG_STRICT_KERNEL_RWX > The box did boot successfully, and survived disk read test, thanks! Here is the new debug information for the record: > /sys/kernel/debug/kernel_page_tables ---[ Start of kernel VM ]--- 0xe000-0xefff 0x2000 256Mrw present dirty accessed ---[ vmalloc() Area ]--- 0xf100-0xf1000fff 0x80041000 4Krw present guarded dirty accessed no cache 0xf1002000-0xf1003fff 0x80041000 8Krw present guarded dirty accessed no cache 0xf1005000-0xf1005fff 0x8006 4Krw present guarded dirty accessed no cache 0xf1007000-0xf1007fff 0x8005 4Krw present guarded dirty accessed no cache 0xf100a000-0xf100bfff 0xf8001000 8Krw present guarded dirty accessed no cache 0xf100d000-0xf100dfff 0x80018000 4Krw present guarded dirty accessed no cache 0xf101-0xf1011fff 0xa0006000 8Krw present guarded dirty accessed no cache 0xf101b000-0xf1025fff 0x3fc044Krw present dirty accessed 0xf1027000-0xf1027fff 0xb87ff000 4Krw present guarded dirty accessed no cache 0xf1029000-0xf1029fff 0xba7ff000 4Krw present guarded dirty accessed no cache 0xf102b000-0xf106afff 0x2f30 256Krw present guarded dirty accessed no cache 0xf106c000-0xf106 0x3fc0b00016Krw present dirty accessed 0xf1071000-0xf1071fff 0x8002 4Krw present guarded dirty accessed no cache 0xf1074000-0xf1077fff 0xf500400016Krw present guarded dirty accessed no cache 0xf107a000-0xf107bfff 0x80008000 8Krw present guarded dirty accessed no cache 0xf107d000-0xf107dfff 0xf500 4Krw present guarded dirty accessed no cache 0xf108-0xf118afff 0xb8008000 1068Krw present guarded dirty accessed no cache 0xf1195000-0xf1196fff 0x2f13e000 8Krw present dirty accessed 0xf1197000-0xf119cfff 0x2f3a24Krw present dirty accessed 0xf119d000-0xf119efff 0x2f13e000 8Krw present dirty accessed 0xf11a-0xf11a5fff 0x2f3a600024Krw present dirty accessed 0xf11a6000-0xf11a7fff 0x2f196000 8Krw present dirty accessed 0xf11a8000-0xf11a9fff 0x2f3a6000 8Krw present dirty accessed 0xf11ab000-0xf11abfff 0xa0004000 4Krw present guarded dirty accessed no cache 0xf11ad000-0xf11adfff 0xa000 4Krw present guarded dirty accessed no cache 0xf11af000-0xf11a 0xa0003000 4Krw present guarded dirty accessed no cache 0xf11b1000-0xf11b1fff 0xa0002000 4Krw present guarded dirty accessed no cache 0xf11b3000-0xf11b3fff 0xa0001000 4Krw present guarded dirty accessed no cache 0xf11b5000-0xf11b5fff 0x8001 4Krw present guarded dirty accessed no cache 0xf11b7000-0xf11b7fff 0x80008000 4Krw present guarded dirty accessed no cache 0xf11b9000-0xf11b9fff 0x80008000 4Krw present guarded dirty accessed no cache 0xf11bd000-0xf11bdfff 0x3fc8b000 4Krw present dirty accessed 0xf11c-0xf11c 0x880064Krw present guarded dirty accessed no cache 0xf120-0xf1259fff 0xba008000 360Krw present guarded dirty accessed no cache 0xf128-0xf147 0xf520 2Mrw present guarded dirty accessed no cache 0xf1551000-0xf1551fff 0x3fc17000 4Krw present dirty
Re: BUG: crash in __tlb_remove_page_size with STRICT_KERNEL_RWX on BOOK3S_32
Hi! > Could you please compile your kernel with CONFIG_PPC_PTDUMP, and > provide the content of: > > /sys/kernel/debug/kernel_page_tables ---[ Start of kernel VM ]--- 0xe100-0xefff 0x2100 240Mrw present dirty accessed ---[ vmalloc() Area ]--- 0xf100-0xf1000fff 0x80041000 4Krw present guarded dirty accessed no cache 0xf1002000-0xf1003fff 0x80041000 8Krw present guarded dirty accessed no cache 0xf1005000-0xf1005fff 0x8006 4Krw present guarded dirty accessed no cache 0xf1007000-0xf1007fff 0x8005 4Krw present guarded dirty accessed no cache 0xf100a000-0xf100bfff 0xf8001000 8Krw present guarded dirty accessed no cache 0xf100d000-0xf100dfff 0x80018000 4Krw present guarded dirty accessed no cache 0xf101-0xf1011fff 0xa0006000 8Krw present guarded dirty accessed no cache 0xf101b000-0xf1025fff 0x3fc044Krw present dirty accessed 0xf1027000-0xf1027fff 0xb87ff000 4Krw present guarded dirty accessed no cache 0xf1029000-0xf1029fff 0xba7ff000 4Krw present guarded dirty accessed no cache 0xf102b000-0xf106afff 0x2f30 256Krw present guarded dirty accessed no cache 0xf106c000-0xf106 0x3fc0b00016Krw present dirty accessed 0xf1071000-0xf1071fff 0x8002 4Krw present guarded dirty accessed no cache 0xf1074000-0xf1077fff 0xf500400016Krw present guarded dirty accessed no cache 0xf107a000-0xf107bfff 0x80008000 8Krw present guarded dirty accessed no cache 0xf107d000-0xf107dfff 0xf500 4Krw present guarded dirty accessed no cache 0xf108-0xf118afff 0xb8008000 1068Krw present guarded dirty accessed no cache 0xf1195000-0xf119cfff 0x2f3a32Krw present dirty accessed 0xf119d000-0xf119efff 0x2f3a 8Krw present dirty accessed 0xf11a-0xf11a5fff 0x2f3a800024Krw present dirty accessed 0xf11a6000-0xf11a7fff 0x2f3da000 8Krw present dirty accessed 0xf11a8000-0xf11a9fff 0x2f3a8000 8Krw present dirty accessed 0xf11ab000-0xf11abfff 0xa0004000 4Krw present guarded dirty accessed no cache 0xf11ad000-0xf11adfff 0xa000 4Krw present guarded dirty accessed no cache 0xf11af000-0xf11a 0xa0003000 4Krw present guarded dirty accessed no cache 0xf11b1000-0xf11b1fff 0xa0002000 4Krw present guarded dirty accessed no cache 0xf11b3000-0xf11b3fff 0xa0001000 4Krw present guarded dirty accessed no cache 0xf11b5000-0xf11b5fff 0x8001 4Krw present guarded dirty accessed no cache 0xf11b7000-0xf11b7fff 0x80008000 4Krw present guarded dirty accessed no cache 0xf11b9000-0xf11b9fff 0x80008000 4Krw present guarded dirty accessed no cache 0xf11c-0xf11c 0x880064Krw present guarded dirty accessed no cache 0xf11eb000-0xf11ebfff 0x3fc16000 4Krw present dirty accessed 0xf11ec000-0xf11ecfff 0x3fc15000 4Krw present dirty accessed 0xf11ed000-0xf11edfff 0x3fc14000 4Krw present dirty accessed 0xf120-0xf1259fff 0xba008000 360Krw present guarded dirty accessed no cache 0xf128-0xf147 0xf520 2Mrw present guarded dirty accessed no cache ---[ vmalloc() End ]--- ---[ Early I/O remap start ]--- 0xfde2b000-0xfde2cfff 0x80016000 8Krw present guarded dirty accessed no cache 0xfde2d000-0xfde2dfff 0x8000 4Krw present guarded dirty accessed no cache 0xfde2e000-0xfde2efff
BUG: crash in __tlb_remove_page_size with STRICT_KERNEL_RWX on BOOK3S_32
Hi! Commit 63b2bc61956 aka "powerpc/mm/32s: Use BATs for STRICT_KERNEL_RWX" caused my old powerbook to crash under I/O. After "dd if=/dev/hda of=/null" the crash happens in seconds. Reverting the commit helps, as well as disabling STRICT_KERNEL_RWX. Unfortunately, I was unable to capture the oops via the usb serial console, as it stuck right after the first "BUG: Unable to handle kernel data access at 0xe0c29000" message. Oops screenshot: http://aargh.no-ip.org/oops.jpg
