Re: [Bug][Git-Bisect][6.11.0-next-20240917]BUG: Unable to handle kernel data access on read at 0xc00c020000013d88

Hi, On (24/09/22 22:23), Venkat Rao Bagalkote wrote: > Greetings!!! > > I am observing Kernel OOPs on PowerPC system, while running LTP Test case. > > [11472.962838] BUG: Unable to handle kernel data access on read at > 0xc00c02013d88 > [11472.962846] Faulting instruction address: 0xc000

Re: [Bug][Git-Bisect][6.11.0-next-20240917]BUG: Unable to handle kernel data access on read at 0xc00c020000013d88

Hello, Below is the TC, I was running. https://github.com/avocado-framework-tests/avocado-misc-tests/blob/master/generic/ltp.py Regards, Venkat. On 23/09/24 7:45 am, Sergey Senozhatsky wrote: Hi, On (24/09/22 22:23), Venkat Rao Bagalkote wrote: Greetings!!! I am observing Kernel OOPs on

Re: [RFC PATCH] powerpc/tlb: enable arch want batched unmap tlb flush

Luming Yu writes: > On Sun, Sep 22, 2024 at 04:39:53PM +0530, Ritesh Harjani wrote: >> Luming Yu writes: >> >> > From: Yu Luming >> > >> > ppc always do its own tracking for batch tlb. By trivially enabling >> > the ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH in ppc, ppc arch can re-use >> > common code

Re: [RFC PATCH] powerpc/tlb: enable arch want batched unmap tlb flush

On Sun, Sep 22, 2024 at 04:39:53PM +0530, Ritesh Harjani wrote: > Luming Yu writes: > > > From: Yu Luming > > > > ppc always do its own tracking for batch tlb. By trivially enabling > > the ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH in ppc, ppc arch can re-use > > common code in rmap and reduce overhead

Re: [PATCH v3] crypto: Removing CRYPTO_AES_GCM_P10.

Thanks Herbert. -Danny On 9/21/24 4:31 AM, Herbert Xu wrote: On Thu, Sep 19, 2024 at 07:36:37AM -0400, Danny Tsen wrote: Data mismatch found when testing ipsec tunnel with AES/GCM crypto. Disabling CRYPTO_AES_GCM_P10 in Kconfig for this feature. Fixes: fd0e9b3e2ee6 ("crypto: p10-aes-gcm - An

[Bug][Git-Bisect][6.11.0-next-20240917]BUG: Unable to handle kernel data access on read at 0xc00c020000013d88

Greetings!!! I am observing Kernel OOPs on PowerPC system, while running LTP Test case. Below is the Traces: [11472.962838] BUG: Unable to handle kernel data access on read at 0xc00c02013d88 [11472.962846] Faulting instruction address: 0xc055e2c0 [11472.962851] Oops: Kernel acces

[RFC / PoC v1 1/1] powerpc: Add support for batched unmap TLB flush

=== NOT FOR MERGE YET === This adds the support for ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH. More details are added to the cover letter. --- arch/powerpc/Kconfig | 1 + arch/powerpc/include/asm/book3s/64/tlbflush.h | 5 +++ arch/powerpc/include/asm/tlbbatch.h | 14

[RFC / PoC v1 0/1] powerpc: Add support for batched unmap TLB flush

Hello All, This is a quick PoC to add ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH support to powerpc for book3s64. The ISA in 6.10 of "Translation Table Update Synchronization Requirements" says that the architecture allows for optimizing the translation cache invalidation by doing it in bulk later after th

Re: [PATCH 06/12] huge_memory: Allow mappings of PUD sized pages

Alistair Popple wrote: > Currently DAX folio/page reference counts are managed differently to > normal pages. To allow these to be managed the same as normal pages > introduce dax_insert_pfn_pud. This will map the entire PUD-sized folio > and take references as it would for a normally mapped page.

Re: [PATCH 05/12] mm/memory: Add dax_insert_pfn

[ add s390 folks to comment on CONFIG_FS_DAX_LIMITED ] Alistair Popple wrote: > Currently to map a DAX page the DAX driver calls vmf_insert_pfn. This > creates a special devmap PTE entry for the pfn but does not take a > reference on the underlying struct page for the mapping. This is > because DA

Re: [PATCH 04/12] mm: Allow compound zone device pages

Alistair Popple wrote: > Zone device pages are used to represent various type of device memory > managed by device drivers. Currently compound zone device pages are > not supported. This is because MEMORY_DEVICE_FS_DAX pages are the only > user of higher order zone device pages and have their own p

Re: [PATCH 03/12] fs/dax: Refactor wait for dax idle page

Alistair Popple wrote: > A FS DAX page is considered idle when its refcount drops to one. This > is currently open-coded in all file systems supporting FS DAX. Move > the idle detection to a common function to make future changes easier. > > Signed-off-by: Alistair Popple > Reviewed-by: Jan Kara

Re: [PATCH 02/12] pci/p2pdma: Don't initialise page refcount to one

Alistair Popple wrote: > The reference counts for ZONE_DEVICE private pages should be > initialised by the driver when the page is actually allocated by the > driver allocator, not when they are first created. This is currently > the case for MEMORY_DEVICE_PRIVATE and MEMORY_DEVICE_COHERENT pages >

Re: [PATCH 01/12] mm/gup.c: Remove redundant check for PCI P2PDMA page

Alistair Popple wrote: > PCI P2PDMA pages are not mapped with pXX_devmap PTEs therefore the > check in __gup_device_huge() is redundant. Remove it > > Signed-off-by: Alistair Popple > Reviewed-by: Jason Gunthorpe > Acked-by: David Hildenbrand > --- > mm/gup.c | 5 - > 1 file changed, 5 del

Re: [RFC PATCH] powerpc/tlb: enable arch want batched unmap tlb flush

Luming Yu writes: > From: Yu Luming > > ppc always do its own tracking for batch tlb. By trivially enabling > the ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH in ppc, ppc arch can re-use > common code in rmap and reduce overhead and do optimization it could not > have without a tlb flushing context at low

[PPC] Kernel doesn't boot after DRM updates (drm-next-2024-09-19)

On 22 September 2024 at 08:48 am, Christian Zigotzky wrote: On 21 September 2024 at 06:15 am, Christian Zigotzky wrote: Hi All, The lastest Git kernel doesn't boot anymore after the latest DRM updates (drm-next-2024-09-19). [1] I tested it with an AMD Radeon HD 6970 (Cayman XT) and with an A