patch link:
https://lore.kernel.org/r/20240508130558.1939304-2-sourabhjain%40linux.ibm.com
patch subject: [PATCH 1/2] powerpc/kexec_file: fix extra size calculation for
kexec FDT
config: powerpc-allyesconfig
(https://download.01.org/0day-ci/archive/20240509/202405091511.8sd2zyrn-...@intel.
On Wed, 2024-05-08 at 21:16 +0100, Simon Horman wrote:
> * As this patch seems to involve many non-trivial changes
> it seems to me that it would be best to break it up somehow.
> To allow proper review.
I would like to stress this latest point: it looks like the changes to
all the drivers are
patch link:
https://lore.kernel.org/r/20240508130558.1939304-2-sourabhjain%40linux.ibm.com
patch subject: [PATCH 1/2] powerpc/kexec_file: fix extra size calculation for
kexec FDT
config: powerpc64-randconfig-002-20240509
(https://download.01.org/0day-ci/archive/20240509/202405091617.irrntyre-...
Hi,
This is a relay work of Qingshun's v2 [1], but changed to focus on ANFE
processing as subject suggests and drops trace-event for now. I think it's
a bit heavy to do extra IOes to get PCIe registers only for trace purpose
and not see it a community request for now.
According to PCIe Base Speci
In some cases the detector of a Non-Fatal Error(NFE) is not the most
appropriate agent to determine the type of the error. For example,
when software performs a configuration read from a non-existent
device or Function, completer will send an ERR_NONFATAL Message.
On some platforms, ERR_NONFATAL re
When an Advisory Non-Fatal error(ANFE) triggers, both correctable error(CE)
status and ANFE related uncorrectable error(UE) status will be printed:
AER: Correctable error message received from :b7:02.0
PCIe Bus Error: severity=Correctable, type=Transaction Layer, (Receiver ID)
device [
When processing an ANFE, ideally both correctable error(CE) status and
uncorrectable error(UE) status should be cleared. However, there is no
way to fully identify the UE associated with ANFE. Even worse, Non-Fatal
Error(NFE) may set the same UE status bit as ANFE. Treating an ANFE as
NFE will brin
On Wed, May 8, 2024 at 4:14 PM Amadeusz Sławiński
wrote:
>
> On 5/8/2024 10:00 AM, Hans Verkuil wrote:
> > On 06/05/2024 10:49, Shengjiu Wang wrote:
> >> On Fri, May 3, 2024 at 4:42 PM Mauro Carvalho Chehab
> >> wrote:
> >>>
> >>> Em Fri, 3 May 2024 10:47:19 +0900
> >>> Mark Brown escreveu:
> >
On 5/9/2024 11:36 AM, Shengjiu Wang wrote:
On Wed, May 8, 2024 at 4:14 PM Amadeusz Sławiński
wrote:
On 5/8/2024 10:00 AM, Hans Verkuil wrote:
On 06/05/2024 10:49, Shengjiu Wang wrote:
On Fri, May 3, 2024 at 4:42 PM Mauro Carvalho Chehab wrote:
Em Fri, 3 May 2024 10:47:19 +0900
Mark Brown
On Thu, May 9, 2024 at 5:50 PM Amadeusz Sławiński
wrote:
>
> On 5/9/2024 11:36 AM, Shengjiu Wang wrote:
> > On Wed, May 8, 2024 at 4:14 PM Amadeusz Sławiński
> > wrote:
> >>
> >> On 5/8/2024 10:00 AM, Hans Verkuil wrote:
> >>> On 06/05/2024 10:49, Shengjiu Wang wrote:
> On Fri, May 3, 2024 a
On 5/9/2024 12:12 PM, Shengjiu Wang wrote:
On Thu, May 9, 2024 at 5:50 PM Amadeusz Sławiński
wrote:
On 5/9/2024 11:36 AM, Shengjiu Wang wrote:
On Wed, May 8, 2024 at 4:14 PM Amadeusz Sławiński
wrote:
On 5/8/2024 10:00 AM, Hans Verkuil wrote:
On 06/05/2024 10:49, Shengjiu Wang wrote:
On F
On Thu, May 9, 2024 at 6:28 PM Amadeusz Sławiński
wrote:
>
> On 5/9/2024 12:12 PM, Shengjiu Wang wrote:
> > On Thu, May 9, 2024 at 5:50 PM Amadeusz Sławiński
> > wrote:
> >>
> >> On 5/9/2024 11:36 AM, Shengjiu Wang wrote:
> >>> On Wed, May 8, 2024 at 4:14 PM Amadeusz Sławiński
> >>> wrote:
> >>>
On 09. 05. 24 12:44, Shengjiu Wang wrote:
mem2mem is just like the decoder in the compress pipeline. which is
one of the components in the pipeline.
I was thinking of loopback with endpoints using compress streams,
without physical endpoint, something like:
compress playback (to feed data from
While fadump is a more reliable alternative to kdump dump capturing
method, it doesn't support passing additional parameters. Having
such support is desirable for two major reasons:
1. It helps minimize the memory consumption of fadump dump capture
kernel by disabling features that consume
Currently, fadump on pseries assumes a single boot memory region even
though f/w supports more than one boot memory region. Add support for
more boot memory regions to make the implementation flexible for any
enhancements that introduce other region types. For this, rtas memory
structure for fadump
For fadump case, passing additional parameters to dump capture kernel
helps in minimizing the memory footprint for it and also provides the
flexibility to disable components/modules, like hugepages, that are
hindering the boot process of the special dump capture environment.
Set up a dedicated par
Append the additional parameters passed/set in the dedicated parameter
area (RTAS_FADUMP_PARAM_AREA) to bootargs in fadump capture kernel.
Signed-off-by: Hari Bathini
---
arch/powerpc/include/asm/fadump.h | 2 ++
arch/powerpc/kernel/fadump.c | 35 +++
arch/power
The fix of Powerpc hotplug driver (drivers/pci/hotplug/pnv_php.c)
addresses below two issues.
1. Kernel Crash during hot unplug of bridge/switch slot.
2. DPC-Support Enablement - Previously, when we do a hot-unplug
operation on a bridge slot, all the ports and devices behind the
bridge-ports woul
Description of the problem: The hotplug driver for powerpc
(pci/hotplug/pnv_php.c) gives kernel crash when we try to
hot-unplug/disable the PCIe switch/bridge from the PHB.
Root Cause of Crash: The crash is due to the reason that, though the msi
data structure has been released during disable/hot
There is an issue with the hotplug operation when it's done on the
bridge/switch slot. The bridge-port and devices behind the bridge, which
become offline by hot-unplug operation, don't get hot-plugged/enabled by
doing hot-plug operation on that slot. Only the first port of the bridge
gets enabled
In the xmon disassembly code there are several CPU feature checks to
determine what dialects should be passed to the disassembler. The
dialect controls which instructions the disassembler will recognise.
Unfortunately the checks are incorrect, because instead of passing a
single CPU feature they a
cpu_has_feature()/mmu_has_feature() are only able to check a single
feature at a time, but there is no enforcement of that.
In fact, as fixed in the previous commit, there was code that was
passing multiple values to cpu_has_feature().
So add a check that only a single feature is passed using pop
The CPU/MMU feature code has build-time checks that the feature value is
a builtin constant.
Back when the code was added clang wasn't able to compile the
checks, so an ifdef was added to avoid the checks for clang builds.
See b5fa0f7f88ed ("powerpc: Fix build failure with clang due to
BUILD_BUG_O
gcc
arc allnoconfig gcc
arc allyesconfig gcc
arc defconfig gcc
arc randconfig-001-20240509 gcc
arc randconfig-002-20240509
defconfig gcc
arc allmodconfig gcc
arc allnoconfig gcc
arc allyesconfig gcc
arc defconfig gcc
arc randconfig-001-20240509 gcc
arc randconfig-0
On Thu, May 09, 2024 at 10:12:48PM +1000, Michael Ellerman wrote:
> cpu_has_feature()/mmu_has_feature() are only able to check a single
> feature at a time, but there is no enforcement of that.
>
> In fact, as fixed in the previous commit, there was code that was
> passing multiple values to cpu_h
On Thu, May 09, 2024 at 10:57:37AM +0800, Shengjiu Wang wrote:
> Add compatible string "fsl,imx95-xcvr" for i.MX95 platform.
That's apparent from the diff. Why is it not compatible with existing
devices?
Cheers,
Conor.
>
> Signed-off-by: Shengjiu Wang
> ---
> Documentation/devicetree/bindings
On Thu, May 09, 2024 at 10:57:38AM +0800, Shengjiu Wang wrote:
> Add two PLL clock sources, they are the parent clocks of the root clock
> one is for 8kHz series rates, named as 'pll8k', another one is for
> 11kHz series rates, named as 'pll11k'. They are optional clocks,
> if there are such clocks
> On 7 May 2024, at 3:05 PM, Christophe Leroy
> wrote:
>
>
>
> Le 06/05/2024 à 14:19, Athira Rajeev a écrit :
>> Add support to capture and parse raw instruction in objdump.
>
> What's the purpose of using 'objdump' for reading raw instructions ?
> Can't they be read directly without invo
This patch expects to be applied on top of both of the following related
fixes:
- x86/fault: speed up uffd-unit-test by 10x: rate-limit "MCE: Killing" logs
https://lore.kernel.org/r/20240507022939.236896-1-jhubb...@nvidia.com
- [0/2] Minor fixups for hugetlb fault path
https://lore.kernel.org/
For real MCEs, various architectures print log messages when poisoned
memory is accessed (which results in a SIGBUS). These messages can be
important for users to understand the issue.
On the other hand, we have the userfaultfd UFFDIO_POISON operation,
which can "simulate" memory poisoning. That p
On Thu, May 9, 2024 at 10:27 AM Athira Rajeev
wrote:
>
>
>
> > On 7 May 2024, at 3:05 PM, Christophe Leroy
> > wrote:
> >
> >
> >
> > Le 06/05/2024 à 14:19, Athira Rajeev a écrit :
> >> Add support to capture and parse raw instruction in objdump.
> >
> > What's the purpose of using 'objdump' for
On Thu, May 09, 2024 at 01:39:07PM -0700, Axel Rasmussen wrote:
> For real MCEs, various architectures print log messages when poisoned
> memory is accessed (which results in a SIGBUS). These messages can be
> important for users to understand the issue.
>
> On the other hand, we have the userfaul
On 5/9/24 1:39 PM, Axel Rasmussen wrote:
This patch expects to be applied on top of both of the following related
fixes:
- x86/fault: speed up uffd-unit-test by 10x: rate-limit "MCE: Killing" logs
https://lore.kernel.org/r/20240507022939.236896-1-jhubb...@nvidia.com
This got mostly effectiv
On 5/9/24 1:39 PM, Axel Rasmussen wrote:
For real MCEs, various architectures print log messages when poisoned
memory is accessed (which results in a SIGBUS). These messages can be
important for users to understand the issue.
On the other hand, we have the userfaultfd UFFDIO_POISON operation,
wh
> > > On Tue, May 07, 2024 at 07:01:11PM +, Allen Pais wrote:
> > > > The only generic interface to execute asynchronously in the BH context
> > > > is
> > > > tasklet; however, it's marked deprecated and has some design flaws. To
> > > > replace tasklets, BH workqueue support was recently add
Paolo,
> On Wed, 2024-05-08 at 21:16 +0100, Simon Horman wrote:
> > * As this patch seems to involve many non-trivial changes
> > it seems to me that it would be best to break it up somehow.
> > To allow proper review.
>
> I would like to stress this latest point: it looks like the changes to
On Thu, May 9, 2024 at 2:30 PM John Hubbard wrote:
>
> On 5/9/24 1:39 PM, Axel Rasmussen wrote:
> > For real MCEs, various architectures print log messages when poisoned
> > memory is accessed (which results in a SIGBUS). These messages can be
> > important for users to understand the issue.
> >
>
On Thu, May 9, 2024 at 2:05 PM Peter Xu wrote:
>
> On Thu, May 09, 2024 at 01:39:07PM -0700, Axel Rasmussen wrote:
> > For real MCEs, various architectures print log messages when poisoned
> > memory is accessed (which results in a SIGBUS). These messages can be
> > important for users to understa
Hi Shengjiu,
kernel test robot noticed the following build errors:
[auto build test ERROR on broonie-sound/for-next]
[also build test ERROR on linus/master v6.9-rc7 next-20240509]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use
_GNU_SOURCE is provided by lib.mk, so it should be dropped to prevent
redefinition warnings.
Signed-off-by: Edward Liaw
---
tools/testing/selftests/powerpc/benchmarks/context_switch.c| 2 --
tools/testing/selftests/powerpc/benchmarks/exec_target.c | 2 --
tools/testing/selftests/powerp
ns;
---
base-commit: dd5a440a31fae6e459c0d627162825505361
change-id: 20240509-mac_hid-md-7df0c349753c
When CONFIG_ARCH_KEEP_MEMBLOCK not set, we expect to discard related
code and data. But it doesn't until CONFIG_MEMORY_HOTPLUG not set
neither.
This patch puts memblock's .text/.data into its own section, so that it
only depends on CONFIG_ARCH_KEEP_MEMBLOCK to discard related code and
data.
After
On Fri, May 10, 2024 at 1:14 AM Conor Dooley wrote:
>
> On Thu, May 09, 2024 at 10:57:38AM +0800, Shengjiu Wang wrote:
> > Add two PLL clock sources, they are the parent clocks of the root clock
> > one is for 8kHz series rates, named as 'pll8k', another one is for
> > 11kHz series rates, named as
On Fri, May 10, 2024 at 1:11 AM Conor Dooley wrote:
>
> On Thu, May 09, 2024 at 10:57:37AM +0800, Shengjiu Wang wrote:
> > Add compatible string "fsl,imx95-xcvr" for i.MX95 platform.
>
> That's apparent from the diff. Why is it not compatible with existing
> devices?
i.MX8MP: There is PHY and su
On Fri, May 10, 2024 at 10:27 AM Shengjiu Wang wrote:
>
> On Fri, May 10, 2024 at 1:14 AM Conor Dooley wrote:
> >
> > On Thu, May 09, 2024 at 10:57:38AM +0800, Shengjiu Wang wrote:
> > > Add two PLL clock sources, they are the parent clocks of the root clock
> > > one is for 8kHz series rates, na
Segher Boessenkool writes:
> On Thu, May 09, 2024 at 10:12:48PM +1000, Michael Ellerman wrote:
>> cpu_has_feature()/mmu_has_feature() are only able to check a single
>> feature at a time, but there is no enforcement of that.
>>
>> In fact, as fixed in the previous commit, there was code that was
47 matches
Mail list logo
