Randy Dunlap writes:
> When CONFIG_SMP is not set, CONFIG_BROKEN_ON_SMP is set, and
> CONFIG_PCI is not set, there can be a kconfig warning:
>
> WARNING: unmet direct dependencies detected for PPC_INDIRECT_PCI
> Depends on [n]: PCI [=n]
> Selected by [y]:
> - MPC10X_BRIDGE [=y]
>
> To fix
Bagas Sanjaya writes:
> Hi,
>
> I notice a regression report on bugzilla ([1]). As many developers
> don't keep an eye on it, I decide to forward it by email.
Bugs filed against powerpc do get Cc'ed to linuxppc-dev, so we do see
them. Though that doesn't always mean we have time to fix them :)
Hi,
On Thu, May 11, 2023 at 03:02:55PM +0100, Matthew Wilcox wrote:
> On Wed, May 10, 2023 at 09:35:44PM -0700, Hugh Dickins wrote:
> > On Wed, 10 May 2023, Matthew Wilcox wrote:
> >
> > I don't really understand why you're going down a remove-CONFIG_HIGHPTE
> > route: I thought you were
Hello Michael,
System test hit the crash. I believe, it was PHYP that resulted in it
due to number of TCEs passed in to be >512.
I was wondering about the Fixes tag as well. But, this interface, in
it's current form, is there from the day the file was created. So, in
this case, should I
Uwe Kleine-König writes:
> On Thu, Apr 13, 2023 at 08:16:42AM +0200, Uwe Kleine-König wrote:
>> While mpc5200b.dtsi contains a device that this driver can bind to, the
>> only purpose of a bound device is to be used by the four exported functions
>> mpc52xx_lpbfifo_submit(),
Gaurav Batra writes:
> As of now, in tce_freemulti_pSeriesLP(), there is no limit on how many TCEs
> are passed to H_STUFF_TCE hcall. PAPR is enforcing this to be limited to
> 512 TCEs.
Did you actually hit a bug here, or just noticed via code inspection?
Can you provide a Fixes: tag ?
cheers
Rohan McLure writes:
> Prior to this patch, data races are detectable by KCSAN of the following
> forms:
>
> [1] Asynchronous calls to mmiowb_set_pending() from an interrupt context
> or otherwise outside of a critical section
> [2] Interrupted critical sections, where the interrupt will
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
fixes-test
branch HEAD: 66b2ca086210732954a7790d63d35542936fc664 powerpc/64s/radix: Fix
soft dirty tracking
elapsed time: 730m
configs tested: 38
configs skipped: 156
The following configs have been built
PCIe services that share an IRQ with PME, such as AER or DPC, may cause a
spurious wakeup on system suspend. Since DPC depends on AER to work, disable
DPC interrupt notification during the system suspend process as AER interrupt
notification is already disabled by previous patch.
As Per PCIe Base
PCIe services that share an IRQ with PME, such as AER or DPC, may cause a
spurious wakeup on system suspend. To prevent this, disable the AER interrupt
notification during the system suspend process.
As Per PCIe Base Spec 5.0, section 5.2, titled "Link State Power Management",
TLP and DLLP
There are many places that enable and disable AER interrupt, so move
them into helpers.
Reviewed-by: Mika Westerberg
Reviewed-by: Kuppuswamy Sathyanarayanan
Reviewed-by: Jonathan Cameron
Signed-off-by: Kai-Heng Feng
---
v6:
- No change.
v5:
- Fix misspelling.
v4:
- No change.
v3:
-
On Fri, May 12, 2023 at 6:08 AM Sathyanarayanan Kuppuswamy
wrote:
>
>
>
> On 5/11/23 6:36 AM, Kai-Heng Feng wrote:
> > PCIe service that shares IRQ with PME may cause spurious wakeup on
> > system suspend.
> >
> > This is very similar to previous attempts to suspend AER and DPC [1],
> > but this
On Thu, 11 May 2023, Matthew Wilcox wrote:
>
> I was thinking that removing CONFIG_HIGHPTE might simplify the page
> fault handling path a little, but now I've looked at it some more, and
> I'm not sure there's any simplification to be had. It should probably
> use kmap_local instead of
On 5/11/23 6:36 AM, Kai-Heng Feng wrote:
> PCIe service that shares IRQ with PME may cause spurious wakeup on
> system suspend.
>
> This is very similar to previous attempts to suspend AER and DPC [1],
> but this time disabling AER IRQ is to prevent immediate PME wakeup when
> AER shares the
On Wed, May 10, 2023 at 8:23 PM Michael Ellerman wrote:
>
> Nhat Pham writes:
> > cachestat is previously only wired in for x86 (and architectures using
> > the generic unistd.h table):
> >
> > https://lore.kernel.org/lkml/20230503013608.2431726-1-npha...@gmail.com/
> >
> > This patch wires
On Wed, May 10, 2023 at 8:21 PM Michael Ellerman wrote:
>
> Nhat Pham writes:
> > Test cachestat on a newly created file, /dev/ files, and /proc/ files.
> > Also test on a shmem file (which can also be tested with huge pages
> > since tmpfs supports huge pages).
> >
> > Signed-off-by: Nhat Pham
On Mai 09 2023, Alexandre Ghiti wrote:
> On 5/9/23 21:07, Andreas Schwab wrote:
>> That does not work with UEFI booting:
>>
>> Loading Linux 6.4.0-rc1-1.g668187d-default ...
>> Loading initial ramdisk ...
>> Unhandled exception: Instruction access fault
>> EPC: 80016d56 RA:
On Thu 2023-05-04 15:13:42, Douglas Anderson wrote:
> In preparation for the buddy hardlockup detector, which wants the same
> petting logic as the current perf hardlockup detector, move the code
> to watchdog.c. While doing this, rename the global variable to match
> others nearby. The
Hi Christian,
On Thu, May 11, 2023 at 5:10 PM Christian Göttsche
wrote:
> Add the four syscalls setxattrat(), getxattrat(), listxattrat() and
> removexattrat(). Those can be used to operate on extended attributes,
> especially security related ones, either relative to a pinned directory
> or on
On Thu 2023-05-04 15:13:41, Douglas Anderson wrote:
> In preparation for the buddy hardlockup detector where the CPU
> checking for lockup might not be the currently running CPU, add a
> "cpu" parameter to watchdog_hardlockup_check().
>
> --- a/kernel/watchdog.c
> +++ b/kernel/watchdog.c
> @@
On Wed, May 10, 2023 at 09:35:44PM -0700, Hugh Dickins wrote:
> On Wed, 10 May 2023, Matthew Wilcox wrote:
> > On Tue, May 09, 2023 at 09:39:13PM -0700, Hugh Dickins wrote:
> > > Two: pte_offset_map() will need to do an rcu_read_lock(), with the
> > > corresponding rcu_read_unlock() in
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 logic to disable DPC which depends on AER to work.
It's okay to disable DPC because PCIe Base Spec 5.0, section 5.2 "Link
State Power
PCIe service that shares IRQ with PME may cause spurious wakeup on
system suspend.
This is very similar to previous attempts to suspend AER and DPC [1],
but this time disabling AER IRQ is to prevent immediate PME wakeup when
AER shares the same IRQ line with PME.
It's okay to disable AER because
There are many places that enable and disable AER interrupt, so move
them into helpers.
Reviewed-by: Mika Westerberg
Reviewed-by: Kuppuswamy Sathyanarayanan
Reviewed-by: Jonathan Cameron
Signed-off-by: Kai-Heng Feng
---
v5
- Fix misspelling.
v4:
- No change.
v3:
- Correct subject.
v2:
On Tue, Apr 25, 2023 at 7:47 AM Sathyanarayanan Kuppuswamy
wrote:
>
>
>
> On 4/23/23 10:52 PM, 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
On Sat, May 6, 2023 at 3:22 AM Bjorn Helgaas wrote:
>
> On Mon, Apr 24, 2023 at 01:52:48PM +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
On Fri, May 5, 2023 at 11:37 PM Jonathan Cameron
wrote:
>
> On Mon, 24 Apr 2023 13:52:47 +0800
> Kai-Heng Feng wrote:
>
> > There are many places that enable and disable AER interrput, so move
>
> interrupt
Thanks, will correct that in next revision.
Kai-Heng
>
> > them into helpers.
>
>
On Fri 2023-05-05 09:38:14, Doug Anderson wrote:
> Hi,
>
> On Thu, May 4, 2023 at 8:02 PM Nicholas Piggin wrote:
> >
> > On Fri May 5, 2023 at 8:13 AM AEST, Douglas Anderson wrote:
> > > These are tiny style changes:
> > > - Add a blank line before a "return".
> > > - Renames two globals to use
Dan Horák writes:
> Hi all,
>
> we have been struggling with an issue in the bdwgc project (garbage
> collector) on P9 systems for a while [1]. There were some test failing
> on P9, but not on P8 or other platforms (x86, s390x, aarch64). Recently
> the upstream developer has found out there is
On Fri 2023-05-05 09:37:50, Doug Anderson wrote:
> Hi,
>
> On Thu, May 4, 2023 at 7:58 PM Nicholas Piggin wrote:
> >
> > On Fri May 5, 2023 at 8:13 AM AEST, Douglas Anderson wrote:
> > > The perf hardlockup detector works by looking at interrupt counts and
> > > seeing if they change from run to
It was reported that soft dirty tracking doesn't work when using the
Radix MMU.
The tracking is supposed to work by clearing the soft dirty bit for a
mapping and then write protecting the PTE. If/when the page is written
to, a page fault occurs and the soft dirty bit is added back via
On Thu 2023-05-04 15:13:38, Douglas Anderson wrote:
> The code currently in "watchdog_hld.c" is for detecting hardlockups
> using perf, as evidenced by the line in the Makefile that only
> compiles this file if CONFIG_HARDLOCKUP_DETECTOR_PERF is
> defined. Rename the file to prepare for the buddy
On Thu, May 11, 2023 at 12:05 AM Arnd Bergmann wrote:
>
> On Wed, May 10, 2023, at 21:58, Nhat Pham wrote:
> > cachestat is previously only wired in for x86 (and architectures using
> > the generic unistd.h table):
> >
> > https://lore.kernel.org/lkml/20230503013608.2431726-1-npha...@gmail.com/
>
On Fri 2023-05-05 09:37:35, Doug Anderson wrote:
> Hi,
>
> On Thu, May 4, 2023 at 7:51 PM Nicholas Piggin wrote:
> >
> > On Fri May 5, 2023 at 8:13 AM AEST, Douglas Anderson wrote:
> > > In preparation for the buddy hardlockup detector, rename
> > > touch_nmi_watchdog() to
On Thu, Apr 13, 2023 at 6:06 PM Sean Anderson wrote:
>
> This is a generic binding for simple MMIO GPIO controllers. Although we
> have a single driver for these controllers, they were previously spread
> over several files. Consolidate them. The register descriptions are
> adapted from the
On Thu, May 11, 2023 at 12:01 AM Geert Uytterhoeven
wrote:
>
> Hi Nat,
>
> On Wed, May 10, 2023 at 9:58 PM Nhat Pham wrote:
> > cachestat is previously only wired in for x86 (and architectures using
> > the generic unistd.h table):
> >
> >
https://bugzilla.kernel.org/show_bug.cgi?id=217427
--- Comment #3 from darkbasic (darkba...@linuxsystems.it) ---
Gitlab issue: https://gitlab.freedesktop.org/drm/amd/-/issues/2553
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the
On Fri 2023-05-05 12:43:49, Nicholas Piggin wrote:
> On Fri May 5, 2023 at 8:13 AM AEST, Douglas Anderson wrote:
> > The real watchdog_update_hrtimer_threshold() is defined in
> > watchdog_hardlockup_perf.c. That file is included if
>
> In kernel/watchdog_hld.c.
With this fixed path:
Hi,
I notice a regression report on bugzilla ([1]). As many developers
don't keep an eye on it, I decide to forward it by email.
Quoting from it:
> darkbasic 2023-05-10 13:36:37 UTC
>
> I'm using Gentoo Linux on a Raptor CS Talos 2 ppc64le, GPU is an AMD RX 570.
> So far the past dozen of
Hi all,
we have been struggling with an issue in the bdwgc project (garbage
collector) on P9 systems for a while [1]. There were some test failing
on P9, but not on P8 or other platforms (x86, s390x, aarch64). Recently
the upstream developer has found out there is likely a problem in the
kernel
On Wed, May 10, 2023 at 12:58:06PM -0700, Nhat Pham wrote:
> cachestat is previously only wired in for x86 (and architectures using
> the generic unistd.h table):
>
> https://lore.kernel.org/lkml/20230503013608.2431726-1-npha...@gmail.com/
>
> This patch wires cachestat in for all the other
On Wed, May 10, 2023 at 08:16:34PM -0700, Hugh Dickins wrote:
> Thanks for looking so quickly, Peter: I didn't Cc you on this particular
> series, but shall certainly be doing so on the ones that follow, because
> a few of those patches go into interesting pmdp_get_lockless() territory.
I'm in
On Wed, May 10, 2023, at 21:58, Nhat Pham wrote:
> cachestat is previously only wired in for x86 (and architectures using
> the generic unistd.h table):
>
> https://lore.kernel.org/lkml/20230503013608.2431726-1-npha...@gmail.com/
>
> This patch wires cachestat in for all the other architectures.
>
Hi Nat,
On Wed, May 10, 2023 at 9:58 PM Nhat Pham wrote:
> cachestat is previously only wired in for x86 (and architectures using
> the generic unistd.h table):
>
> https://lore.kernel.org/lkml/20230503013608.2431726-1-npha...@gmail.com/
>
> This patch wires cachestat in for all the other
Hi Hugh,
On Thu, May 11, 2023 at 4:58 AM Hugh Dickins wrote:
> On Wed, 10 May 2023, Geert Uytterhoeven wrote:
> > On Wed, May 10, 2023 at 6:48 AM Hugh Dickins wrote:
> > > In rare transient cases, not yet made possible, pte_offset_map() and
> > > pte_offset_map_lock() may not find a page table:
45 matches
Mail list logo
