Le 02/08/2021 à 19:32, Stan Johnson a écrit :
On 8/2/21 8:41 AM, Christophe Leroy wrote:
Le 31/07/2021 à 20:24, Stan Johnson a écrit :
Hi Christophe,
On 7/31/21 9:58 AM, Christophe Leroy wrote:
Stan Johnson a écrit :
Hello,
The current Debian SID kernel will not boot on a PowerBook 3
On Wed, 14 Jul 2021 18:17:58 +0530, Hari Bathini wrote:
> As kprobe does not handle events happening in real mode, blacklist the
> functions that only get called in real mode or in kexec sequence with
> MMU turned off.
Applied to powerpc/next.
[1/1] powerpc/kexec: blacklist functions called in re
On Thu, 29 Jul 2021 20:01:03 +0200, Michal Suchanek wrote:
> commit 7c6986ade69e ("powerpc/stacktrace: Fix spurious "stale" traces in
> raise_backtrace_ipi()")
> introduces udelay() call without including the linux/delay.h header.
> This may happen to work on master but the header that declares th
On Mon, 19 Jul 2021 12:03:17 +0530, Gautham R. Shenoy wrote:
>
> Hi,
>
> This is the v5 of the patchset to fixup CEDE0 latency only from
> POWER10 onwards.
>
>
> [...]
Applied to powerpc/next.
[1/2] cpuidle/pseries: Fixup CEDE0 latency only for POWER10 onwards
https://git.kernel.org/pow
Ganesh Goudar writes:
> Add test for real address or control memory address access
> error handling, using NX-GZIP engine.
>
> The error is injected by accessing the control memory address
> using illegal instruction, on successful handling the process
> attempting to access control memory address
Currently it's tracked twice which driver is bound to a given pci
device. Now that all users of the pci specific one (struct
pci_dev::driver) are updated to use an access macro
(pci_driver_of_dev()), change the macro to use the information from the
driver core and remove the driver member from stru
Which driver a device is bound to is available twice: In struct
pci_dev::dev->driver and in struct pci_dev::driver. To get rid of the
duplication introduce a wrapper to access struct pci_dev's driver
member. Once all users are converted the wrapper can be changed to
calculate the driver using pci_d
Hello,
changes since v1
(https://lore.kernel.org/linux-pci/20210729203740.1377045-1-u.kleine-koe...@pengutronix.de):
- New patch to simplify drivers/pci/xen-pcifront.c, spotted and
suggested by Boris Ostrovsky
- Fix a possible NULL pointer dereference I introduced in xen-pcifront.c
- A few whi
This prepares removing the driver member of struct pci_dev which holds the
same information than struct pci_dev::dev->driver.
Signed-off-by: Uwe Kleine-König
---
arch/powerpc/include/asm/ppc-pci.h| 3 +-
arch/powerpc/kernel/eeh_driver.c | 12 ---
arch/x86/events/int
Michael Ellerman writes:
> On Mon, 19 Jul 2021 12:03:17 +0530, Gautham R. Shenoy wrote:
>>
>> Hi,
>>
>> This is the v5 of the patchset to fixup CEDE0 latency only from
>> POWER10 onwards.
>>
>>
>> [...]
>
> Applied to powerpc/next.
>
> [1/2] cpuidle/pseries: Fixup CEDE0 latency only for POWER1
kgdb makes use of its own cpulock (@dbg_master_lock, @kgdb_active)
during cpu roundup. This will conflict with the printk cpulock.
Therefore, a CPU must ensure that it is not holding the printk
cpulock when calling kgdb_cpu_enter(). If it is, it must allow its
printk context to complete first.
A n
The functions get_online_cpus() and put_online_cpus() have been
deprecated during the CPU hotplug rework. They map directly to
cpus_read_lock() and cpus_read_unlock().
Replace deprecated CPU-hotplug functions with the official version.
The behavior remains unchanged.
Cc: Michael Ellerman
Cc: Ben
On Tue, Aug 03, 2021 at 03:18:54PM +0206, John Ogness wrote:
> kgdb makes use of its own cpulock (@dbg_master_lock, @kgdb_active)
> during cpu roundup. This will conflict with the printk cpulock.
When the full vision is realized what will be the purpose of the printk
cpulock?
I'm asking largely b
With shared mapping, even though we are unmapping a large range, the kernel
will force a TLB flush with ptl lock held to avoid the race mentioned in
commit 1cf35d47712d ("mm: split 'tlb_flush_mmu()' into tlb flushing and memory
freeing parts")
This results in the kernel issuing a high number of TL
From: kernel test robot
for_each_node_by_type should have of_node_put() before return.
Generated by: scripts/coccinelle/iterators/for_each_child.cocci
CC: Sumera Priyadarsini
Reported-by: kernel test robot
Signed-off-by: kernel test robot
---
The code seems to have been this way since the b
When a DSI (Data Storage Interrupt) is taken while in NAP mode,
r11 doesn't survive the call to power_save_ppc32_restore().
So use r1 instead of r11 as they both contain the virtual stack
pointer at that point.
Reported-by: Finn Thain
Fixes: 4c0104a83fc3 ("powerpc/32: Dismantle EXC_XFER_STD/LITE
On 2021-08-03, Daniel Thompson wrote:
> On Tue, Aug 03, 2021 at 03:18:54PM +0206, John Ogness wrote:
>> kgdb makes use of its own cpulock (@dbg_master_lock, @kgdb_active)
>> during cpu roundup. This will conflict with the printk cpulock.
>
> When the full vision is realized what will be the purpos
Since 5.13 QE's ucc nodes can't get interrupts from devicetree:
ucc@2000 {
cell-index = <1>;
reg = <0x2000 0x200>;
interrupts = <32>;
interrupt-parent = <&qeic>;
};
Now fw_devlink expects driver to create and probe a
On Sat, Jul 31, 2021 at 03:00:20PM +0900, Masahiro Yamada wrote:
> arm, arm64, csky, mips, powerpc always select GENERIC_GETTIMEOFDAY,
> hence $(gettimeofday-y) never becomes empty.
>
> riscv conditionally selects GENERIC_GETTIMEOFDAY when MMU=y && 64BIT=y,
> but arch/riscv/kernel/vdso/vgettimeofd
https://bugzilla.kernel.org/show_bug.cgi?id=213961
Bug ID: 213961
Summary: Oops while loading radeon driver
Product: Platform Specific/Hardware
Version: 2.5
Kernel Version: 5.14-rc4
Hardware: PPC-32
OS: Linux
Laurent Dufour writes:
> V5:
> - Rework code structure
> - Reintroduce the capability to reuse other node's ids.
OK. While I preferred v4, where we would fail an add rather than allow
CPU IDs to appear to "travel" between nodes, this change is a net
improvement.
Reviewed-by: Nathan Lynch
ig
powerpc allnoconfig
x86_64 randconfig-a002-20210803
x86_64 randconfig-a004-20210803
x86_64 randconfig-a006-20210803
x86_64 randconfig-a003-20210803
x86_64 randconfig-a001-20210803
x86_64 randc
Laurent Dufour writes:
> V5:
> - Reword the commit's description to address Nathan's comments.
Thanks. Still don't like the global variable usage but:
Reviewed-by: Nathan Lynch
Le 03/08/2021 à 19:32, Nathan Lynch a écrit :
Laurent Dufour writes:
V5:
- Reword the commit's description to address Nathan's comments.
Thanks. Still don't like the global variable usage but:
Reviewed-by: Nathan Lynch
Thanks Nathan,
I don't like either the global variable usage but I
Le 03/08/2021 à 18:54, Nathan Lynch a écrit :
Laurent Dufour writes:
V5:
- Rework code structure
- Reintroduce the capability to reuse other node's ids.
OK. While I preferred v4, where we would fail an add rather than allow
CPU IDs to appear to "travel" between nodes, this change is a net
After commit 7cbd631d4dec ("cpuidle: pseries: Fixup CEDE0 latency only
for POWER10 onwards"), pseries_idle_probe() is no longer inlined when
compiling with clang, which causes a modpost warning:
WARNING: modpost: vmlinux.o(.text+0xc86a54): Section mismatch in
reference from the function pseries_id
On Tue, Aug 3, 2021 at 4:33 AM Maxim Kochetkov wrote:
>
> Since 5.13 QE's ucc nodes can't get interrupts from devicetree:
>
> ucc@2000 {
> cell-index = <1>;
> reg = <0x2000 0x200>;
> interrupts = <32>;
> interrupt-parent = <&q
On Tue, 3 Aug 2021, Stan Johnson wrote:
>
> I'm not sure of the issue you are referencing. If it's the Wallstreet
> issue, I believe we were waiting to hear back from you regarding the
> memory errors that crop up with CONFIG_VMAP_STACK=y and mem >464M.
> Finn, if that is not correct, please l
On Tue, 3 Aug 2021, Christophe Leroy wrote:
>
> Looks like the memory errors are linked to KUAP (Kernel Userspace Access
> Protection). Based on the places the problems happen, I don't think
> there are any invalid access, so there must be something wrong in the
> KUAP logic, probably linked
Nathan Chancellor writes:
> After commit 7cbd631d4dec ("cpuidle: pseries: Fixup CEDE0 latency only
> for POWER10 onwards"), pseries_idle_probe() is no longer inlined when
> compiling with clang, which causes a modpost warning:
>
> WARNING: modpost: vmlinux.o(.text+0xc86a54): Section mismatch in
>
This is the same as commit acdad8fb4a15 ("powerpc: Force inlining of
mmu_has_feature to fix build failure") but for radix_enabled(). The
config in the linked bugzilla causes the following build failure:
LD .tmp_vmlinux.kallsyms1
powerpc64-linux-ld: arch/powerpc/mm/pgtable.o: in function
`._
randconfig-c001-20210803
mips ip28_defconfig
armcerfcube_defconfig
armneponset_defconfig
arcnsimosci_defconfig
arm hackkit_defconfig
powerpc
On 8/3/21 4:08 AM, Christophe Leroy wrote:
>
>
> Le 02/08/2021 à 19:32, Stan Johnson a écrit :
>> On 8/2/21 8:41 AM, Christophe Leroy wrote:
>>>
>>> ...
>
> Can you try again without CONFIG_VMAP_STACK ?
>
> Thanks
> Christophe
> ...
With CONFIG_VMAP_STACK=y,
As well known, hvc backend can register its opertions to hvc backend.
the opertions contain put_chars(), get_chars() and so on.
Some hvc backend may do dma in its opertions. eg, put_chars() of
virtio-console. But in the code of hvc framework, it may pass DMA
incapable memory to put_chars() under a
hvc framework will never pass stack memory to the put_chars() function,
So the calling of kmemdup() is unnecessary, remove it.
This revert commit c4baad5029 ("virtio-console: avoid DMA from stack")
Signed-off-by: Xianting Tian
---
drivers/char/virtio_console.c | 12 ++--
1 file changed,
On Tue, 3 Aug 2021, Christophe Leroy wrote:
> When a DSI (Data Storage Interrupt) is taken while in NAP mode, r11
> doesn't survive the call to power_save_ppc32_restore().
>
> So use r1 instead of r11 as they both contain the virtual stack pointer
> at that point.
>
> Reported-by: Finn Thain
On Tue, 3 Aug 2021, Stan Johnson wrote:
> Attached you will find the following six files:
>
> 1) config-5.13-patched_VMAP.txt
> 2) config-5.13-patched_NO_VMAP.txt
> 3) pb3400c-console-5.13-patched_VMAP.txt (using config 1)
> 4) pb3400c-console-5.13-patched_NO_VMAP.txt (using config 2)
> 5) ws-c
Hi,
This is the next part of our printk-rework effort (points 3 and
4 of the LPC 2019 summary [0]).
Here the concept of "atomic consoles" is introduced through a
new (optional) write_atomic() callback for console drivers. This
callback must be implemented as an NMI-safe variant of the
write() ca
On Tue, Aug 03, 2021 at 03:18:51PM +0206, John Ogness wrote:
> Hi,
>
> This is the next part of our printk-rework effort (points 3 and
> 4 of the LPC 2019 summary [0]).
>
> Here the concept of "atomic consoles" is introduced through a
> new (optional) write_atomic() callback for console drivers.
On 8/3/21 6:01 AM, Uwe Kleine-König wrote:
> This prepares removing the driver member of struct pci_dev which holds the
> same information than struct pci_dev::dev->driver.
>
> Signed-off-by: Uwe Kleine-König
> ---
> arch/powerpc/include/asm/ppc-pci.h| 3 +-
> arch/powerpc/kernel/e
This is a tree wide replacement of the deprecated CPU hotplug functions
which are only wrappers around the actual functions.
Each patch is independent and can be picked up by the relevant maintainer.
Cc: Alexander Shishkin
Cc: Amit Kucheria
Cc: Andrew Morton
Cc: Andy Lutomirski
Cc: Arnaldo Ca
On Tue, Aug 03, 2021 at 12:01:48PM +0200, Uwe Kleine-König wrote:
> Which driver a device is bound to is available twice: In struct
> pci_dev::dev->driver and in struct pci_dev::driver. To get rid of the
> duplication introduce a wrapper to access struct pci_dev's driver
> member. Once all users ar
On Tue, Aug 03, 2021 at 12:01:49PM +0200, Uwe Kleine-König wrote:
> This prepares removing the driver member of struct pci_dev which holds the
> same information than struct pci_dev::dev->driver.
...
> + struct pci_driver *pdrv;
Missed blank line here and everywhere else. I don't remember if
On Tue, Aug 03, 2021 at 12:01:49PM +0200, Uwe Kleine-König wrote:
> This prepares removing the driver member of struct pci_dev which holds the
> same information than struct pci_dev::dev->driver.
>
> Signed-off-by: Uwe Kleine-König
> ---
> arch/powerpc/include/asm/ppc-pci.h| 3 +-
>
Hi Sebastien,
On 8/3/21 4:15 PM, Sebastian Andrzej Siewior wrote:
> This is a tree wide replacement of the deprecated CPU hotplug functions
> which are only wrappers around the actual functions.
>
> Each patch is independent and can be picked up by the relevant maintainer.
Ok; and I take it that
On 2021-08-03 17:30:40 [+0200], Hans de Goede wrote:
> Hi Sebastien,
Hi Hans,
> On 8/3/21 4:15 PM, Sebastian Andrzej Siewior wrote:
> > This is a tree wide replacement of the deprecated CPU hotplug functions
> > which are only wrappers around the actual functions.
> >
> > Each patch is independen
Excerpts from Aneesh Kumar K.V's message of August 4, 2021 12:37 am:
> With shared mapping, even though we are unmapping a large range, the kernel
> will force a TLB flush with ptl lock held to avoid the race mentioned in
> commit 1cf35d47712d ("mm: split 'tlb_flush_mmu()' into tlb flushing and
>
Gentle ping Michael ?
Le 25/06/2021 à 16:41, Christophe Leroy a écrit :
Hi Michael,
What happened to this series ? It has been flagged 'under review' in Patchwork since mid April but I
never saw it in next-test.
Thanks
Christophe
Le 12/04/2021 à 18:26, Christophe Leroy a écrit :
powerpc BU
In those hot functions that are called at every interrupt, any saved
cycle is worth it.
interrupt_exit_user_prepare() and interrupt_exit_kernel_prepare() are
called from three places:
- From entry_32.S
- From interrupt_64.S
- From interrupt_exit_user_restart() and interrupt_exit_kernel_restart()
Hi Randy,
Le 04/08/2021 à 04:40, Randy Dunlap a écrit :
On 7/31/21 11:22 AM, kernel test robot wrote:
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: c7d102232649226a6958a4942cf13cff4f7c
commit: fe3dc333d2ed50c9764d281869d87bae0d795ce5 powerpc/mmu:
Le 04/08/2021 à 03:37, Jordan Niethe a écrit :
This is the same as commit acdad8fb4a15 ("powerpc: Force inlining of
mmu_has_feature to fix build failure") but for radix_enabled(). The
config in the linked bugzilla causes the following build failure:
LD .tmp_vmlinux.kallsyms1
powerpc64-l
https://bugzilla.kernel.org/show_bug.cgi?id=213961
Christophe Leroy (christophe.le...@csgroup.eu) changed:
What|Removed |Added
CC||christoph
On 8/3/21 10:31 PM, Christophe Leroy wrote:
Hi Randy,
Le 04/08/2021 à 04:40, Randy Dunlap a écrit :
On 7/31/21 11:22 AM, kernel test robot wrote:
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: c7d102232649226a6958a4942cf13cff4f7c
commit: fe3dc333
Hi Radu,
Le 07/07/2021 à 07:55, Christophe Leroy a écrit :
32 bits BOOKE have special interrupts for debug and other
critical events.
Were you able to test this patch ?
Thanks
Christophe
When handling those interrupts, dedicated registers are saved
in the stack frame in addition to the st
Le 04/08/2021 à 06:04, Finn Thain a écrit :
On Tue, 3 Aug 2021, Christophe Leroy wrote:
When a DSI (Data Storage Interrupt) is taken while in NAP mode, r11
doesn't survive the call to power_save_ppc32_restore().
So use r1 instead of r11 as they both contain the virtual stack pointer
at that
i386 randconfig-c001-20210803
powerpc tqm8541_defconfig
nios2 3c120_defconfig
armpleb_defconfig
powerpc pseries_defconfig
armtrizeps4_defconfig
arm
Hi Nic,
I think I'll need your help on that one.
Le 04/08/2021 à 08:07, Christophe Leroy a écrit :
Le 04/08/2021 à 06:04, Finn Thain a écrit :
On Tue, 3 Aug 2021, Christophe Leroy wrote:
...
[ cut here ]
kernel BUG at arch/powerpc/kernel/interrupt.c:49!
Oops: Exce
Le 04/08/2021 à 02:34, Finn Thain a écrit :
On Tue, 3 Aug 2021, Christophe Leroy wrote:
Looks like the memory errors are linked to KUAP (Kernel Userspace Access
Protection). Based on the places the problems happen, I don't think
there are any invalid access, so there must be something wron
Excerpts from Nicholas Piggin's message of August 4, 2021 3:14 pm:
> Excerpts from Aneesh Kumar K.V's message of August 4, 2021 12:37 am:
>> With shared mapping, even though we are unmapping a large range, the kernel
>> will force a TLB flush with ptl lock held to avoid the race mentioned in
>> com
Nicholas Piggin writes:
> Excerpts from Aneesh Kumar K.V's message of August 4, 2021 12:37 am:
>> With shared mapping, even though we are unmapping a large range, the kernel
>> will force a TLB flush with ptl lock held to avoid the race mentioned in
>> commit 1cf35d47712d ("mm: split 'tlb_flush_mm
60 matches
Mail list logo
