rhel-8.3
x86_64randconfig-a013
x86_64randconfig-a011
s390 allyesconfig
arc randconfig-r043-20220928
x86_64randconfig-a015
x86_64 allyesconfig
Arnaldo Carvalho de Melo writes:
> Em Wed, Sep 21, 2022 at 08:22:54PM +0530, Athira Rajeev escreveu:
>> commit b55878c90ab9 ("perf test: Add test for branch stack sampling")
>> added test for branch stack sampling. There is a sanity check in the
>> beginning to skip the test if the hardware
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
next
branch HEAD: 6bd7ff497b4af13ea3d53781ffca7dc744dbb4da powerpc/udbg: Remove
extern function prototypes
elapsed time: 853m
configs tested: 58
configs skipped: 2
The following configs have been built
Make sure the ultravisor code at least gets some build testing by
enabling it in powernv_defconfig.
Signed-off-by: Michael Ellerman
---
arch/powerpc/configs/powernv_defconfig | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/powerpc/configs/powernv_defconfig
Alistair Popple writes:
> Michael Ellerman writes:
>> Alistair Popple writes:
>>> When the CPU tries to access a device private page the migrate_to_ram()
>>> callback associated with the pgmap for the page is called. However no
>>> reference is taken on the faulting page. Therefore a concurrent
Hi All,
I have found the issue. I cross compiled this kernel with GCC 11.2.0 on Ubuntu
22.04.1.
I cross compiled the same kernel with GCC 9.4.0 again. This time on Ubuntu
20.04.5.
KVM with the VirtIO GPU works with the GCC 9.4.0 compiled kernel.
— Christian
I wrote:
Hello,
Xorg doesn't
Just for info:
The values have been fine again since the RC7 of kernel 6.0.
— Christian
> On 7. Sep 2022, at 06:25, Christian Zigotzky wrote:
>
> Hi All,
>
> I use the Nemo board with a PASemi PA6T CPU and some values of lscpu are
> wrong since the RC1 of kernel 6.0.
>
>
From: Li Chen
We already have struct range, so just use it.
Signed-off-by: Li Chen
Acked-by: Baoquan He
Signed-off-by: Baoquan He
Cc: linuxppc-dev
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
---
Baoquan:
- Rebased to the latest linus's master branch, fix the
arch/powerpc/kernel/systbl_chk.sh has not been referenced since commit
ab66dcc76d6a ("powerpc: generate uapi header and system call table
files"). Remove it.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/kernel/systbl_chk.sh | 30 --
1 file changed, 30 deletions(-)
This is the register layout of the litesd peripheral for the fusesoc
based Microwatt SoC.
Signed-off-by: Joel Stanley
---
arch/powerpc/boot/dts/microwatt.dts | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/powerpc/boot/dts/microwatt.dts
Generally the hypervisor decides to allocate a window on different
VAS instances. But if the user space wishes to allocate on the
current VAS instance where the process is executing, the kernel has
to pass associativity domain IDs to allocate VAS window HCALL. To
determine the associativity
On Wed, Sep 28, 2022 at 10:51 AM Nicholas Piggin wrote:
>
> On Wed Sep 28, 2022 at 11:48 AM AEST, Zhouyi Zhou wrote:
> > Thank Nick for reviewing my patch
> >
> > On Tue, Sep 27, 2022 at 12:25 PM Nicholas Piggin wrote:
> > >
> > > On Tue Sep 27, 2022 at 11:48 AM AEST, Zhouyi Zhou wrote:
> > > >
Michael Ellerman writes:
> Alistair Popple writes:
>> When the CPU tries to access a device private page the migrate_to_ram()
>> callback associated with the pgmap for the page is called. However no
>> reference is taken on the faulting page. Therefore a concurrent
>> migration of the device
Quoting Sean Anderson (2022-09-20 13:23:51)
> This adds ids for the Lynx 10g SerDes's internal PLLs. These may be used
> with assigned-clock* to specify a particular frequency to use. For
> example, to set the second PLL (at offset 0x20)'s frequency, use
> LYNX10G_PLLa(1). These are for use only
Alistair Popple writes:
> When the CPU tries to access a device private page the migrate_to_ram()
> callback associated with the pgmap for the page is called. However no
> reference is taken on the faulting page. Therefore a concurrent
> migration of the device private page can free the page and
On Wed, Jul 27, 2022 at 09:32:51AM +0800, Kai-Heng Feng wrote:
> PCIe service that shares IRQ with PME may cause spurious wakeup on
> system suspend.
>
> PCIe Base Spec 5.0, section 5.2 "Link State Power Management" states
> that TLP and DLLP transmission is disabled for a Link in L2/L3 Ready
>
Re comments about infinite retry: gotcha, makes sense to me.
On Tue, 2022-09-27 at 09:45 +1000, Alistair Popple wrote:
> John Hubbard writes:
>
> > On 9/26/22 14:35, Lyude Paul wrote:
> > > > + for (i = 0; i < npages; i++) {
> > > > + if (src_pfns[i] & MIGRATE_PFN_MIGRATE) {
On Wed, Jul 27, 2022 at 09:32:52AM +0800, Kai-Heng Feng wrote:
> PCIe service that shares IRQ with PME may cause spurious wakeup on
> system suspend.
>
> Since AER is conditionally disabled in previous patch, also apply the
> same condition to disable DPC which depends on AER to work.
>
> PCIe
On Tue, 2022-09-27 at 11:39 +1000, Alistair Popple wrote:
> Felix Kuehling writes:
>
> > On 2022-09-26 17:35, Lyude Paul wrote:
> > > On Mon, 2022-09-26 at 16:03 +1000, Alistair Popple wrote:
> > > > When the module is unloaded or a GPU is unbound from the module it is
> > > > possible for
On Wed, Sep 28, 2022 at 12:13:53PM -0700, Josh Poimboeuf wrote:
> On Wed, Sep 28, 2022 at 08:44:27AM -0700, Nathan Chancellor wrote:
> > This crash appears to just be a symptom of objtool erroring throughout
> > the entire build, which means things like the jump label hacks do not
> > get applied.
Michael Ellerman writes:
> @@ -588,6 +590,15 @@ static __init int add_pcspkr(void)
> device_initcall(add_pcspkr);
> #endif /* CONFIG_PCSPKR_PLATFORM */
>
> +static char ppc_hw_desc_buf[128] __initdata;
> +
> +struct seq_buf ppc_hw_desc __initdata = {
> + .buffer = ppc_hw_desc_buf,
>
Michael Ellerman writes:
> Add firmware version details to the dump stack arch description, which
> is printed in case of an oops.
>
> Currently /hypervisor only exists on KVM, so if we don't find that
> look for something that suggests we're on phyp and if so that's
> probably a good guess. The
On Wed, Sep 28, 2022 at 08:44:27AM -0700, Nathan Chancellor wrote:
> This crash appears to just be a symptom of objtool erroring throughout
> the entire build, which means things like the jump label hacks do not
> get applied. I see a flood of
>
> error: objtool: --mnop requires --mcount
>
>
Andrew Donnellan writes:
> On Mon, 2022-09-26 at 08:16 -0500, Nathan Lynch wrote:
>> The error injection facility on pseries VMs allows corruption of
>> arbitrary guest memory, potentially enabling a sufficiently
>> privileged
>> user to disable lockdown or perform other modifications of the
>>
On 9/28/22 7:06 PM, Serge Semin wrote:
On Wed, Sep 28, 2022 at 06:59:37PM +0800, Zhuo Chen wrote:
Hello.
Here comes patch v3, which contains some fixes and optimizations of
aer api usage. The v1 and v2 can be found on the mailing list.
v3:
- Modifications to comments proposed by
On 13/09/2022 12:57, Athira Rajeev wrote:
> perf stat includes option to specify aggr_mode to display
> per-socket, per-core, per-die, per-node counter details.
> Also there is option -A ( AGGR_NONE, -no-aggr ), where the
> counter values are displayed for each cpu along with "CPU"
> value in
Hi all,
On Wed, Sep 28, 2022 at 08:48:53AM +0800, kernel test robot wrote:
> Greeting,
>
> FYI, we noticed the following commit (built with clang-14):
>
> commit: ca5e2b42c0d4438ba93623579b6860b98f3598f3 ("[PATCH v3 11/16] objtool:
> Add --mnop as an option to --mcount")
> url:
>
> On 16-Sep-2022, at 5:01 PM, Disha Goel wrote:
>
> This Message Is From an External Sender
> This message came from outside your organization.
>
>
> On 9/13/22 5:27 PM, Athira Rajeev wrote:
>> perf stat includes option to specify aggr_mode to display
>> per-socket, per-core, per-die,
Em Wed, Sep 21, 2022 at 08:22:54PM +0530, Athira Rajeev escreveu:
> commit b55878c90ab9 ("perf test: Add test for branch stack sampling")
> added test for branch stack sampling. There is a sanity check in the
> beginning to skip the test if the hardware doesn't support branch stack
> sampling.
>
> On 21-Sep-2022, at 8:22 PM, Athira Rajeev wrote:
>
> commit b55878c90ab9 ("perf test: Add test for branch stack sampling")
> added test for branch stack sampling. There is a sanity check in the
> beginning to skip the test if the hardware doesn't support branch stack
> sampling.
>
>
Em Wed, Sep 28, 2022 at 10:22:18AM +0530, Athira Rajeev escreveu:
> The testcase “vmlinux-kallsyms.c” fails in powerpc.
>
> vmlinux symtab matches kallsyms: FAILED!
Thanks, applied.
- Arnaldo
> This test look at the symbols in the vmlinux DSO
> and check if we find all of them in the
On Mon, 2022-09-26 at 08:16 -0500, Nathan Lynch wrote:
> The error injection facility on pseries VMs allows corruption of
> arbitrary guest memory, potentially enabling a sufficiently
> privileged
> user to disable lockdown or perform other modifications of the
> running
> kernel via the rtas
Add firmware version details to the dump stack arch description, which
is printed in case of an oops.
Currently /hypervisor only exists on KVM, so if we don't find that
look for something that suggests we're on phyp and if so that's
probably a good guess. The actual content of the
Add the PVR and CPU name to the dump stack arch description, which is
printed in case of an oops.
eg: Hardware name: ... POWER8E (raw) pvr:0x4b0201
Signed-off-by: Michael Ellerman
---
arch/powerpc/kernel/prom.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/powerpc/kernel/prom.c
Add OPAL version details to the dump stack arch description, which is
printed in case of an oops.
eg: Hardware name: ... opal:v6.2
Signed-off-by: Michael Ellerman
---
arch/powerpc/platforms/powernv/setup.c | 26 ++
1 file changed, 26 insertions(+)
diff --git
As soon as we know the name of the machine description we're using,
add it to the dump stack arch description, which is printed in case of
an oops.
eg: Hardware name: ... machine:pSeries
Signed-off-by: Michael Ellerman
---
arch/powerpc/include/asm/setup.h | 2 ++
Add the model of the machine we're on to the dump stack arch
description, which is printed in case of an oops.
eg: Hardware name: model:'IBM,8247-22L'
Signed-off-by: Michael Ellerman
---
arch/powerpc/kernel/prom.c | 19 +++
1 file changed, 19 insertions(+)
diff --git
If we detect a logical PVR add that to the dump stack arch
description, which is printed in case of an oops.
eg: Hardware name: ... lpvr:0xf04
Signed-off-by: Michael Ellerman
---
arch/powerpc/kernel/prom.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
No toolchain we support should be generating stabs debug information
anymore. Drop the sections entirely from our linker scripts.
We removed all the manual stabs annotations in commit
12318163737c ("powerpc/32: Remove remaining .stabs annotations").
Signed-off-by: Michael Ellerman
---
The bulk of this was moved/reworded in:
57f266497d81 ("powerpc: Use gas sections for arranging exception vectors")
And now appears around line 700 in arch/powerpc/kernel/exceptions-64s.S.
Signed-off-by: Michael Ellerman
---
arch/powerpc/kernel/exceptions-64s.S | 10 --
1 file
This used to be about the 0x4300 handler, but that was moved in commit
da2bc4644c75 ("powerpc/64s: Add new exception vector macros").
Note that "STAB" here refers to "Segment Table" not the debug format.
Signed-off-by: Michael Ellerman
---
arch/powerpc/kernel/exceptions-64s.S | 6 --
1
On Wed, Sep 28, 2022, at 2:15 PM, Michael Ellerman wrote:
> But I think it makes more sense to do the same as mmap2() and pass the
> 4K offset through, and pass shift = PAGE_SHIFT - 12. I also borrowed the
> "off_4k" name from arm64. End result:
>
> #ifdef CONFIG_COMPAT
>
Rohan McLure writes:
> Syscall handlers should not be invoked internally by their symbol names,
> as these symbols defined by the architecture-defined SYSCALL_DEFINE
> macro. Move the compatibility syscall definition for mmap2 to
> syscalls.c, so that all mmap implementations can share a helper
Rohan McLure writes:
> Remove explicit clearing of the high order-word of user parameters when
> handling compatibility syscalls in system_call_exception. The
> COMPAT_SYSCALL_DEFINEx macros handle this clearing through an
> explicit cast to the signature type of the target handler.
Lyude Paul writes:
> On Mon, 2022-09-26 at 16:03 +1000, Alistair Popple wrote:
>> nouveau_dmem_fault_copy_one() is used during handling of CPU faults via
>> the migrate_to_ram() callback and is used to copy data from GPU to CPU
>> memory. It is currently specific to fault handling, however a
Hi
Am 28.09.22 um 13:12 schrieb Michal Suchánek:
Hello,
On Wed, Sep 28, 2022 at 12:50:10PM +0200, Thomas Zimmermann wrote:
All DRM formats assume little-endian byte order. On big-endian systems,
it is likely that the scanout buffer is in big endian as well. Update
the format accordingly and
Hello,
On Wed, Sep 28, 2022 at 12:50:10PM +0200, Thomas Zimmermann wrote:
> All DRM formats assume little-endian byte order. On big-endian systems,
> it is likely that the scanout buffer is in big endian as well. Update
> the format accordingly and add endianess conversion to the format-helper
>
On Wed, Sep 28, 2022 at 06:59:37PM +0800, Zhuo Chen wrote:
> Hello.
>
> Here comes patch v3, which contains some fixes and optimizations of
> aer api usage. The v1 and v2 can be found on the mailing list.
>
> v3:
> - Modifications to comments proposed by Sathyanarayanan.
> Remove
>
On Wed, Sep 28, 2022 at 06:59:40PM +0800, Zhuo Chen wrote:
> There is no need to clear error status during init code, so remove it.
Why do you think there isn't? Justify in more details.
-Sergey
>
> Signed-off-by: Zhuo Chen
> ---
> drivers/ntb/hw/idt/ntb_hw_idt.c | 2 --
> 1 file changed, 2
Statements clearing status in aer_enable_rootport() is functionally
equivalent with pcie_clear_device_status() and pci_aer_clear_status().
So replace them, which has no functional changes.
After commit 20e15e673b05 ("PCI/AER: Add pci_aer_raw_clear_status()
to unconditionally clear Error Status"),
When state is pci_channel_io_frozen in pcie_do_recovery(), the
severity is fatal and fatal error status should be cleared.
So add pci_aer_clear_fatal_status().
Signed-off-by: Zhuo Chen
---
drivers/pci/pcie/err.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git
Use pcie_aer_is_native() in place of "host->native_aer ||
pcie_ports_native" to judge whether OS owns AER in aer_root_reset().
Replace "dev->aer_cap && (pcie_ports_native || host->native_aer)" in
get_port_device_capability() with pcie_aer_is_native(), which has no
functional changes.
pcie_clear_device_status() doesn't check for pcie_aer_is_native()
internally, but after commit 068c29a248b6 ("PCI/ERR: Clear PCIe Device
Status errors only if OS owns AER") and commit aa344bc8b727 ("PCI/ERR:
Clear AER status only when we control AER"), both callers check before
calling it. So move
On Tue, Sep 27, 2022 at 11:35:18PM +0800, Zhuo Chen wrote:
> Status bits for ERR_NONFATAL errors only are cleared in
> pci_aer_clear_nonfatal_status(), but we want clear uncorrectable
> error status in idt_init_pci(), so we change to use
> pci_aer_clear_uncorrect_error_status().
Have the
Since pci_aer_clear_nonfatal_status() is used only internally, move
its declaration to the PCI internal header file. Also, no one cares
about return value of pci_aer_clear_nonfatal_status(), so make it void.
Signed-off-by: Zhuo Chen
---
drivers/pci/pci.h | 2 ++
drivers/pci/pcie/aer.c | 7
lpfc_aer_cleanup_state() requires clearing both fatal and non-fatal
uncorrectable error status. But using pci_aer_clear_nonfatal_status()
will only clear non-fatal error status. To clear both fatal and
non-fatal error status, use pci_aer_clear_uncorrect_error_status().
Signed-off-by: Zhuo Chen
There is no need to clear error status during init code, so remove it.
Signed-off-by: Zhuo Chen
---
drivers/ntb/hw/idt/ntb_hw_idt.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/ntb/hw/idt/ntb_hw_idt.c b/drivers/ntb/hw/idt/ntb_hw_idt.c
index 0ed6f809ff2e..fed03217289d 100644
---
pci_aer_clear_uncorrect_error_status() clears both fatal and non-fatal
errors. So use it in place of pci_aer_clear_nonfatal_status()
and pci_aer_clear_fatal_status().
Signed-off-by: Zhuo Chen
---
drivers/pci/pcie/dpc.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git
In lpfc_aer_cleanup_state(), uncorrectable error status needs to be
cleared, which can be done by calling pci_aer_clear_nonfatal_status()
and pci_aer_clear_fatal_status(). Meanwhile they can be combined in
one function (the same in dpc_process_error). So add
pci_aer_clear_uncorrect_error_status()
Hello.
Here comes patch v3, which contains some fixes and optimizations of
aer api usage. The v1 and v2 can be found on the mailing list.
v3:
- Modifications to comments proposed by Sathyanarayanan. Remove
pci_aer_clear_nonfatal_status() call in NTB and improve commit log.
v2:
-
Le 28/09/2022 à 03:30, Benjamin Gray a écrit :
> On Tue, 2022-09-27 at 06:40 +, Christophe Leroy wrote:
>>> + /* Flush on the EA that may be executed in case of a non-
>>> coherent icache */
>>> + icbi(prog_addr);
>>
>> prog_addr is a misleading name ? Is that the address at
All DRM formats assume little-endian byte order. On big-endian systems,
it is likely that the scanout buffer is in big endian as well. Update
the format accordingly and add endianess conversion to the format-helper
library. Also opt-in to allocated buffers in host format by default.
Suggested-by:
Support the CRTC's color-management property and implement each model's
palette support.
The OF hardware has different methods of setting the palette. The
respective code has been taken from fbdev's offb and refactored into
per-model device functions. The device functions integrate this
Add a dedicated CRTC state to ofdrm to later store information for
palette updates.
v3:
* rework CRTC state helpers (Javier)
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/gpu/drm/tiny/ofdrm.c | 59 ++--
1 file
Add a per-model device-function structure in preparation of adding
color-management support. Detection of the individual models has been
taken from fbdev's offb.
v3:
* define constants for PCI ids (Javier)
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
PowerPC's Open Firmware offers a simple display buffer for graphics
output. Add ofdrm, a DRM driver for the device. As with the existing
simpledrm driver, the graphics hardware is pre-initialized by the
firmware. The driver only provides blitting, no actual DRM modesetting
is possible.
Patch 1
Open Firmware provides basic display output via the 'display' node.
DT platform code already provides a device that represents the node's
framebuffer. Add a DRM driver for the device. The display mode and
color format is pre-initialized by the system's firmware. Runtime
modesetting via DRM is not
On Mon, 2022-09-26 at 08:16 -0500, Nathan Lynch wrote:
> The /proc/powerpc/ofdt interface allows the root user to freely alter
> the in-kernel device tree, enabling arbitrary physical address writes
> via drivers that could bind to malicious device nodes, thus making it
> possible to disable
On 9/28/22 3:31 AM, Sathyanarayanan Kuppuswamy wrote:
Hi,
On 9/27/22 8:35 AM, Zhuo Chen wrote:
Sometimes we need to clear aer uncorrectable error status, so we add
Adding n actual use case will help.
pci_aer_clear_uncorrect_error_status() to PCI core.
If possible, try to avoid "we"
At the time being, with 16k pages __set_pte_at() writes table entries
in reverse order:
294: 91 49 00 0c stw r10,12(r9)
298: 91 49 00 08 stw r10,8(r9)
29c: 91 49 00 04 stw r10,4(r9)
2a0: 91 49 00 00 stw r10,0(r9)
Allthough there should be no impact at
While looking at code generated for code patching, I saw that
pte_clear generated:
2d8: 38 a0 00 00 li r5,0
2dc: 38 e0 10 00 li r7,4096
2e0: 39 00 20 00 li r8,8192
2e4: 39 40 30 00 li r10,12288
2e8: 90 a9 00 00 stw r5,0(r9)
2ec: 90 e9
71 matches
Mail list logo
