Hi, all!
We’ve encountered a kernel crash when running rmmod i2c-pasemi-platform on a
Mac Mini M1 (T8103) running Asahi Arch Linux.
The bug was first found on the Linux v6.6, which is built manually with the
Asahi given config to run our services.
At that time, the i2c-pasemi-platform was i2c
> From: Fabio M. De Francesco
> [...]
> Subject: [PATCH 1/4 v3] ACPI: extlog: Trace CPER Non-standard Section Body
>
> ghes_do_proc() has a catch-all for unknown or unhandled CPER formats (UEFI
> v2.10 Appendix N 2.3), extlog_print() does not. This gap was noticed by a RAS
> test that injected CX
On 28.05.25 19:18, Donet Tom wrote:
During node device initialization, `memory blocks` are registered under
each NUMA node. The `memory blocks` to be registered are identified using
the node’s start and end PFNs, which are obtained from the node's pg_data
However, not all PFNs within this range
On 04.06.25 05:07, Andrew Morton wrote:
On Wed, 28 May 2025 12:18:00 -0500 Donet Tom wrote:
During node device initialization, `memory blocks` are registered under
each NUMA node. The `memory blocks` to be registered are identified using
the node’s start and end PFNs, which are obtained from t
From: Laurentiu Tudor
[ Upstream commit 23d060136841c58c2f9ee8c08ad945d1879ead4b ]
In case the MC firmware runs in debug mode with extensive prints pushed
to the console, the current timeout of 500ms is not enough.
Increase the timeout value so that we don't have any chance of wrongly
assuming t
From: Laurentiu Tudor
[ Upstream commit 23d060136841c58c2f9ee8c08ad945d1879ead4b ]
In case the MC firmware runs in debug mode with extensive prints pushed
to the console, the current timeout of 500ms is not enough.
Increase the timeout value so that we don't have any chance of wrongly
assuming t
From: Laurentiu Tudor
[ Upstream commit 23d060136841c58c2f9ee8c08ad945d1879ead4b ]
In case the MC firmware runs in debug mode with extensive prints pushed
to the console, the current timeout of 500ms is not enough.
Increase the timeout value so that we don't have any chance of wrongly
assuming t
From: Laurentiu Tudor
[ Upstream commit 23d060136841c58c2f9ee8c08ad945d1879ead4b ]
In case the MC firmware runs in debug mode with extensive prints pushed
to the console, the current timeout of 500ms is not enough.
Increase the timeout value so that we don't have any chance of wrongly
assuming t
From: Laurentiu Tudor
[ Upstream commit 23d060136841c58c2f9ee8c08ad945d1879ead4b ]
In case the MC firmware runs in debug mode with extensive prints pushed
to the console, the current timeout of 500ms is not enough.
Increase the timeout value so that we don't have any chance of wrongly
assuming t
From: Laurentiu Tudor
[ Upstream commit 23d060136841c58c2f9ee8c08ad945d1879ead4b ]
In case the MC firmware runs in debug mode with extensive prints pushed
to the console, the current timeout of 500ms is not enough.
Increase the timeout value so that we don't have any chance of wrongly
assuming t
From: Laurentiu Tudor
[ Upstream commit 23d060136841c58c2f9ee8c08ad945d1879ead4b ]
In case the MC firmware runs in debug mode with extensive prints pushed
to the console, the current timeout of 500ms is not enough.
Increase the timeout value so that we don't have any chance of wrongly
assuming t
From: Laurentiu Tudor
[ Upstream commit 23d060136841c58c2f9ee8c08ad945d1879ead4b ]
In case the MC firmware runs in debug mode with extensive prints pushed
to the console, the current timeout of 500ms is not enough.
Increase the timeout value so that we don't have any chance of wrongly
assuming t
On 6/4/25 3:15 PM, David Hildenbrand wrote:
On 04.06.25 05:07, Andrew Morton wrote:
On Wed, 28 May 2025 12:18:00 -0500 Donet Tom
wrote:
During node device initialization, `memory blocks` are registered under
each NUMA node. The `memory blocks` to be registered are identified
using
the nod
On 6/4/25 3:08 PM, David Hildenbrand wrote:
On 28.05.25 19:18, Donet Tom wrote:
During node device initialization, `memory blocks` are registered under
each NUMA node. The `memory blocks` to be registered are identified
using
the node’s start and end PFNs, which are obtained from the node's
On 04.06.25 15:17, Donet Tom wrote:
On 6/4/25 3:15 PM, David Hildenbrand wrote:
On 04.06.25 05:07, Andrew Morton wrote:
On Wed, 28 May 2025 12:18:00 -0500 Donet Tom
wrote:
During node device initialization, `memory blocks` are registered under
each NUMA node. The `memory blocks` to be regis
Thank you David
I’ll make the change and send the next revision.
Feel free to only send a fixup on top of this patch.
--
Cheers,
David / dhildenb
On 6/4/25 8:37 AM, Andrew Morton wrote:
On Wed, 28 May 2025 12:18:00 -0500 Donet Tom wrote:
During node device initialization, `memory blocks` are registered under
each NUMA node. The `memory blocks` to be registered are identified using
the node’s start and end PFNs, which are obtained from
On 6/4/25 7:00 PM, David Hildenbrand wrote:
On 04.06.25 15:17, Donet Tom wrote:
On 6/4/25 3:15 PM, David Hildenbrand wrote:
On 04.06.25 05:07, Andrew Morton wrote:
On Wed, 28 May 2025 12:18:00 -0500 Donet Tom
wrote:
During node device initialization, `memory blocks` are registered
under
On Thu, May 29, 2025 at 10:39:58PM +0530, Srish Srinivasan wrote:
>
> On 5/23/25 11:49 AM, Michal Suchánek wrote:
> > Hello,
> >
> > On Wed, May 21, 2025 at 04:27:58PM +0530, Srish Srinivasan wrote:
> > > The PLPKS enabled PowerVM LPAR sysfs exposes all of the secure boot
> > > secvars irrespecti
Alistair Popple wrote:
> The PFN_MAP flag is no longer used for anything, so remove it. The
> PFN_SG_CHAIN and PFN_SG_LAST flags never appear to have been used so
> also remove them.
>
> Signed-off-by: Alistair Popple
> Reviewed-by: Christoph Hellwig
Looks good and I see PFN_DEV goes later in t
> From: Fabio M. De Francesco
> [...]
> Subject: [PATCH 3/4 v3] ACPI: extlog: Trace CPER PCI Express Error Section
>
> I/O Machine Check Architecture events may signal failing PCIe components or
> links. The AER event contains details on what was happening on the wire
> when the error was signale
Alistair Popple wrote:
> Currently dax is the only user of pmd and pud mapped ZONE_DEVICE
> pages. Therefore page walkers that want to exclude DAX pages can check
> pmd_devmap or pud_devmap. However soon dax will no longer set PFN_DEV,
> meaning dax pages are mapped as normal pages.
>
> Ensure pag
Alistair Popple wrote:
[..]
> Alistair Popple (12):
> mm: Remove PFN_MAP, PFN_SG_CHAIN and PFN_SG_LAST
> mm: Convert pXd_devmap checks to vma_is_dax
> mm/pagewalk: Skip dax pages in pagewalk
> mm: Convert vmf_insert_mixed() from using pte_devmap to pte_special
> mm: Remove remaining uses
Alistair Popple wrote:
> DAX no longer requires device PTEs as it always has a ZONE_DEVICE page
> associated with the PTE that can be reference counted normally. Other users
> of pte_devmap are drivers that set PFN_DEV when calling vmf_insert_mixed()
> which ensures vm_normal_page() returns NULL fo
Alistair Popple wrote:
> PFN_DEV was used by callers of dax_direct_access() to figure out if the
> returned PFN is associated with a page using pfn_t_has_page() or
> not. However all DAX PFNs now require an assoicated ZONE_DEVICE page so can
> assume a page exists.
>
> Other users of PFN_DEV were
Alistair Popple wrote:
> GUP uses pXX_devmap() calls to see if it needs to a get a reference on
> the associated pgmap data structure to ensure the pages won't go
> away. However it's a driver responsibility to ensure that if pages are
> mapped (ie. discoverable by GUP) that they are not offlined o
Alistair Popple wrote:
> DAX was the only thing that created pmd_devmap and pud_devmap entries
> however it no longer does as DAX pages are now refcounted normally and
> pXd_trans_huge() returns true for those. Therefore checking both pXd_devmap
> and pXd_trans_huge() is redundant and the former ca
Alistair Popple wrote:
> Previously dax pages were skipped by the pagewalk code as pud_special() or
> vm_normal_page{_pmd}() would be false for DAX pages. Now that dax pages are
> refcounted normally that is no longer the case, so add explicit checks to
> skip them.
>
> Signed-off-by: Alistair Pop
28 matches
Mail list logo
