About ftrace+pstore+ramoops

Hi Anton / Joel (and all CCed), sorry for annoyance but I'm not being able to make pstore ftrace capture to work - I'm not sure if I might be missing something, or if there's a known limitation. So, first, my use case: I'd like to be able to collect *ftrace* trace buffer in a specific point in

Re: [PATCH v7 1/2] PCI/ERR: Call pci_bus_reset() before calling ->slot_reset() callback

Hi Kuppuswamy Sathyanarayanan (and all involved here), thanks for the patch! I'd like to ask what is the status of this patchset - I just "parachuted" in the issue, and by tracking the linux-pci ML, I found this V7 (and all previous versions since V2). Also, noticed that Jay's email might have

Re: [PATCH v3] sched/fair: fix unthrottle_cfs_rq for leaf_cfs_rq list

On 19/11/2020 05:36, Vincent Guittot wrote: > On Thu, 19 Nov 2020 at 01:36, Tao Zhou wrote: >> >> On Thu, Nov 19, 2020 at 07:50:15AM +0800, Tao Zhou wrote: >>> On Wed, Nov 18, 2020 at 07:56:38PM -0300, Guilherme G. Piccoli wrote: >>>> Hi Vincent (an

Re: [PATCH v3] sched/fair: fix unthrottle_cfs_rq for leaf_cfs_rq list

Hi Vincent (and all CCed), I'm sorry to ping about such "old" patch, but we experienced a similar condition to what this patch addresses; it's an older kernel (4.15.x) but when suggesting the users to move to an updated 5.4.x kernel, we noticed that this patch is not there, although similar ones

Re: [PATCH 1/3] x86/quirks: Scan all busses for early PCI quirks

First of all, thanks everybody for the great insights/discussion! This thread ended-up being a great learning for (at least) me. Given the big amount of replies and intermixed comments, I wouldn't be able to respond inline to all, so I'll try another approach below. >From Bjorn: "I think [0]

Re: [PATCH 1/3] x86/quirks: Scan all busses for early PCI quirks

On 23/10/2018 14:03, Bjorn Helgaas wrote: > On Mon, Oct 22, 2018 at 05:35:06PM -0300, Guilherme G. Piccoli wrote: >> On 18/10/2018 19:15, Bjorn Helgaas wrote: >>> On Thu, Oct 18, 2018 at 03:37:19PM -0300, Guilherme G. Piccoli wrote: >>> [...] >> I u

Re: [PATCH] Only allow to set crash_kexec_post_notifiers on boot time

On Tue, Sep 22, 2020 at 11:53 AM wrote: > > > On 9/22/20 6:58 AM, Philipp Rudo wrote: > > > > AFAIK pstore requires UEFI to work. So what's the point to enable it on > > non-UEFI > > systems? > > > I don't think UEFI is required, ERST can specify its own backend. And that, > in fact, can be

Re: [PATCH 4.19 35/47] x86/irq: Seperate unused system vectors from spurious entry again

Hi Greg / Thomas and all involved here. First, apologies for necro-bumping this thread, but I'm working a backport of this patch to kernel 4.15 (Ubuntu) and then I noticed we have it on stable, but only in 4.19+. Since the fixes tag presents an old commit (since ~3.19), I'm curious if we have a

Re: [PATCH 4.19 35/47] x86/irq: Seperate unused system vectors from spurious entry again

On 17/08/2020 13:49, Greg KH wrote: > [...] >> I'm sorry, I hoped the subject + thread would suffice heh > > There is no thread here :( > Wow, that's odd. I've sent with In-Reply-To, I'd expect it'd get threaded with the original message. Looking in lore archive [1], it seems my first message

Re: [PATCH 4.19 35/47] x86/irq: Seperate unused system vectors from spurious entry again

On 17/08/2020 13:21, Greg KH wrote: > On Mon, Aug 17, 2020 at 12:36:25PM -0300, Guilherme G. Piccoli wrote: >> Hi Greg / Thomas and all involved here. First, apologies for >> necro-bumping this thread, but I'm working a backport of this patch to >> kernel 4.15 (Ubuntu) and t

Re: [PATCH v2] x86/tsc: Allow quick PIT calibration despite interruptions

Hi Jan and all involved here, I'd like to know if there was any news on this patch - seems users are still facing this issue on AMD systems. Thanks in advance, Guilherme

Re: [PATCH] kernel/watchdog.c: convert {soft/hard}lockup boot parameters to sysctl aliases

On Thu, May 7, 2020 at 8:06 PM Andrew Morton wrote: > We have a lot of sysctls. What is the motivation for converting these > particular ones? No stronger motivation than a regular clean-up - I just liked the infrastructure provided by Vlastmil and thought in using it. I know we have plenty of

Re: [PATCH] mm, compaction: Indicate when compaction is manually triggered by sysctl

On Thu, May 7, 2020 at 8:04 PM Andrew Morton wrote: > > Could add it to vmstat? Hi Andrew, thanks for your suggestion! I thought the same, as a second potential solution for this..was planning to add as a comment below the "---" but forgot heheh I agree that would be great in vmstat, do you have

[PATCH] mm, compaction: Indicate when compaction is manually triggered by sysctl

. Signed-off-by: Guilherme G. Piccoli --- This patch was based on linux-next/akpm branch, at d0f3f6070c3a. Thanks in advance for reviews! Cheers, Guilherme mm/compaction.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/mm/compaction.c b/mm/compaction.c index

[PATCH] kernel/watchdog.c: convert {soft/hard}lockup boot parameters to sysctl aliases

converted hung_task_panic (see the patch series [0]) and put the alias table in alphabetical order. [0] lore.kernel.org/lkml/20200427180433.7029-1-vba...@suse.cz Signed-off-by: Guilherme G. Piccoli --- This patch is based on linux-next/akpm branch, at d0f3f6070c3a. Thanks in advance for reviews

Re: [PATCH] hugetlb: Add nohugepages parameter to prevent hugepages creation

On 10/15/19 11:05 AM, Michal Hocko wrote: On Tue 15-10-19 10:58:36, Guilherme G. Piccoli wrote: On 10/15/19 9:18 AM, Michal Hocko wrote: I do agree with Qian Cai here. Kdump kernel requires a very tailored environment considering it is running in a very restricted configuration. The hugetlb

Re: [PATCH] hugetlb: Add nohugepages parameter to prevent hugepages creation

On 10/15/19 9:18 AM, Michal Hocko wrote: I do agree with Qian Cai here. Kdump kernel requires a very tailored environment considering it is running in a very restricted configuration. The hugetlb pre-allocation sounds like a tooling problem and should be fixed at that layer. Hi Michal, thanks

[PATCH V2] hugetlb: Add nohugepages parameter to prevent hugepages creation

have kdump scripts removing the kernel command-line options to set hugepages, but it's not straightforward to prevent sysctl/sysfs configuration, given it happens in later boot or anytime when the system is running. Signed-off-by: Guilherme G. Piccoli --- .../admin-guide/kernel-parameters.txt

Re: [PATCH] hugetlb: Add nohugepages parameter to prevent hugepages creation

On 14/10/2019 15:25, Mike Kravetz wrote: > [...] > I don't know much about early_param(), so I will assume this works as you > describe. However, a quick grep shows hugepage options for ia64 also with > early_param. > Thanks a lot for the prompt and quite informative reply Mike. I've checked

[PATCH] hugetlb: Add nohugepages parameter to prevent hugepages creation

have kdump scripts removing the kernel command-line options to set hugepages, but it's not straightforward to prevent sysctl/sysfs configuration, given it happens in later boot or anytime when the system is running. Signed-off-by: Guilherme G. Piccoli --- About some decisions took in this patch

Re: [PATCH 1/3] fscache: Fix cookie collision

Hi David, was there any respin for this patch? I couldn't find it upstream. This message shows a lot in the xfstests against cifs. Thanks in advance, Guilherme

Re: [PATCHv6 0/7] tty: Hold write ldisc sem in tty_reopen()

On 07/12/2018 13:37, Dmitry Safonov wrote: > [...] > Yes, Greg kindly took the patches set into -next to increase coverage. > So far, there is no standing issues known to me. > > Ping me, if you have any, please. > > Thanks, > Dmitry > Thanks Dmitry, hopefully this time the series

Re: [PATCHv6 0/7] tty: Hold write ldisc sem in tty_reopen()

On 07/12/2018 13:37, Dmitry Safonov wrote: > [...] > Yes, Greg kindly took the patches set into -next to increase coverage. > So far, there is no standing issues known to me. > > Ping me, if you have any, please. > > Thanks, > Dmitry > Thanks Dmitry, hopefully this time the series

Re: [PATCHv6 0/7] tty: Hold write ldisc sem in tty_reopen()

Hi, thanks Dmitry for the re-spin - hopefully now the pa-risc issues are fixed. BTW, any news on the pa-risc testing? We're just waiting on this to get the patchset merged? Thanks in advance, Guilherme

Re: [PATCHv6 0/7] tty: Hold write ldisc sem in tty_reopen()

Hi, thanks Dmitry for the re-spin - hopefully now the pa-risc issues are fixed. BTW, any news on the pa-risc testing? We're just waiting on this to get the patchset merged? Thanks in advance, Guilherme

Re: [PATCHv5 3/7] tty: Hold tty_ldisc_lock() during tty_reopen()

On 01/10/2018 15:32, Guilherme G. Piccoli wrote: > Hi Dmitry, thanks for the patch. It's very promising, we have some > reports of this issue and I'm building a kernel with this patch in > order the reporter can test it. But based in the previous feedback, > this seems to be ver

Re: [PATCHv5 3/7] tty: Hold tty_ldisc_lock() during tty_reopen()

On 01/10/2018 15:32, Guilherme G. Piccoli wrote: > Hi Dmitry, thanks for the patch. It's very promising, we have some > reports of this issue and I'm building a kernel with this patch in > order the reporter can test it. But based in the previous feedback, > this seems to be ver

Re: [PATCH] MAINTAINERS: Change maintainer of genwqe

On 05/02/2018 11:13, Guilherme G. Piccoli wrote: > On 05/02/2018 11:10, Mauro S. M. Rodrigues wrote: >> Guilherme is no longer available to maintain the driver. I'll assume his >> position for now on. >> >> Signed-off-by: Mauro S. M. Rodrigues > > Thanks a lot

Re: [PATCH] MAINTAINERS: Change maintainer of genwqe

On 05/02/2018 11:13, Guilherme G. Piccoli wrote: > On 05/02/2018 11:10, Mauro S. M. Rodrigues wrote: >> Guilherme is no longer available to maintain the driver. I'll assume his >> position for now on. >> >> Signed-off-by: Mauro S. M. Rodrigues > > Thanks a lot

Re: [PATCH] MAINTAINERS: Change maintainer of genwqe

On 05/02/2018 11:10, Mauro S. M. Rodrigues wrote: > Guilherme is no longer available to maintain the driver. I'll assume his > position for now on. > > Signed-off-by: Mauro S. M. Rodrigues <maur...@linux.vnet.ibm.com> Thanks a lot Mauro! Acked-by: Guilherme G. Piccoli <g

Re: [PATCH] MAINTAINERS: Change maintainer of genwqe

On 05/02/2018 11:10, Mauro S. M. Rodrigues wrote: > Guilherme is no longer available to maintain the driver. I'll assume his > position for now on. > > Signed-off-by: Mauro S. M. Rodrigues Thanks a lot Mauro! Acked-by: Guilherme G. Piccoli > --- > MAINTAINERS | 2 +- &g

Re: jsm_tty: Deletion of a null pointer check in two functions?

On 12/16/2017 04:27 AM, SF Markus Elfring wrote: >> Thanks for the fix. > > Thanks for your positive feedback. > > >> I was on vacation - but now seeing all the analysis made here, > > I assume that special communication settings could trigger > corresponding consequences for the discussed

Re: jsm_tty: Deletion of a null pointer check in two functions?

On 12/16/2017 04:27 AM, SF Markus Elfring wrote: >> Thanks for the fix. > > Thanks for your positive feedback. > > >> I was on vacation - but now seeing all the analysis made here, > > I assume that special communication settings could trigger > corresponding consequences for the discussed

[PATCH 1/3] genwqe: Remove unused variable and rename function

This is a clean-up patch, no functional changes intended. It removes an unused variable from do_execute_ddcb() and also renames the function free_user_pages(), prepending "genwqe" prefix in order to clarify the code. Signed-off-by: Guilherme G. Piccoli <gpicc...@linux.vnet.ibm.com&

[PATCH 2/3] genwqe: Make defines uppercase

This is a clean-up patch, no functional changes intended. It makes all defines uppercase, following a "tradition" that helps to make code clearer. Signed-off-by: Guilherme G. Piccoli <gpicc...@linux.vnet.ibm.com> --- drivers/misc/genwqe/card_base.c| 16 dri

[PATCH 1/3] genwqe: Remove unused variable and rename function

This is a clean-up patch, no functional changes intended. It removes an unused variable from do_execute_ddcb() and also renames the function free_user_pages(), prepending "genwqe" prefix in order to clarify the code. Signed-off-by: Guilherme G. Piccoli --- drivers/misc/genwqe/card_de

[PATCH 2/3] genwqe: Make defines uppercase

This is a clean-up patch, no functional changes intended. It makes all defines uppercase, following a "tradition" that helps to make code clearer. Signed-off-by: Guilherme G. Piccoli --- drivers/misc/genwqe/card_base.c| 16 drivers/misc/genwqe/card_base

[PATCH 3/3] genwqe: Remove unused parameter in some functions

This is a clean-up patch, no functional changes intended. It removes the unused parameter of type "struct ddcb_requ*" from the functions genwqe_user_vmap() and genwqe_user_vunmap(). Signed-off-by: Guilherme G. Piccoli <gpicc...@linux.vnet.ibm.com> --- drivers/misc/genwqe/c

[PATCH 0/3] Some small clean-ups in genwqe

This patchset is composed by 3 small clean-ups to genwqe driver. It aims to improve code clarity, by removing unused stuff and make the code follow some conventions. It was built and tested against v4.15-rc3, and aims merge in v4.16 if possible. Thanks in advance! Guilherme G. Piccoli (3

[PATCH 3/3] genwqe: Remove unused parameter in some functions

This is a clean-up patch, no functional changes intended. It removes the unused parameter of type "struct ddcb_requ*" from the functions genwqe_user_vmap() and genwqe_user_vunmap(). Signed-off-by: Guilherme G. Piccoli --- drivers/misc/genwqe/card_base.h | 6 ++ drivers/m

[PATCH 0/3] Some small clean-ups in genwqe

This patchset is composed by 3 small clean-ups to genwqe driver. It aims to improve code clarity, by removing unused stuff and make the code follow some conventions. It was built and tested against v4.15-rc3, and aims merge in v4.16 if possible. Thanks in advance! Guilherme G. Piccoli (3

Re: [PATCH 11/45] drivers: misc: remove duplicate includes

e clean-up! Acked-by: Guilherme G. Piccoli <gpicc...@linux.vnet.ibm.com> > --- > drivers/misc/genwqe/card_base.c | 1 - > drivers/misc/genwqe/card_ddcb.c | 1 - > drivers/misc/genwqe/card_utils.c | 2 -- > 3 files changed, 4 deletions(-) > > diff --git a/drivers/misc/genwqe/

Re: [PATCH 11/45] drivers: misc: remove duplicate includes

On 12/06/2017 02:54 PM, Pravin Shedge wrote: > These duplicate includes have been found with scripts/checkincludes.pl but > they have been removed manually to avoid removing false positives. > > Signed-off-by: Pravin Shedge Thanks for the clean-up! Acked-by: Guilherm

Re: jsm_tty: Fix a possible null pointer dereference in two functions

On 11/29/2017 04:19 PM, SF Markus Elfring wrote: >>> It's pretty unlikely, but it is an actual defect. >> >> No it is not, those variables will never be set to NULL, >> so this can never be triggered. Walk up the call chain. > > If the involved software developers are convinced about the

Re: jsm_tty: Fix a possible null pointer dereference in two functions

On 11/29/2017 04:19 PM, SF Markus Elfring wrote: >>> It's pretty unlikely, but it is an actual defect. >> >> No it is not, those variables will never be set to NULL, >> so this can never be triggered. Walk up the call chain. > > If the involved software developers are convinced about the

Re: [PATCH] tty: serial: jsm: remove redundant pointer ts

ing: Value stored to 'ts' > is never read > > Signed-off-by: Colin Ian King <colin.k...@canonical.com> Thanks Colin! Acked-by: Guilherme G. Piccoli <gpicc...@linux.vnet.ibm.com> > --- > drivers/tty/serial/jsm/jsm_tty.c | 2 -- > 1 file changed, 2 deletions(-) &

Re: [PATCH] tty: serial: jsm: remove redundant pointer ts

ever read > > Signed-off-by: Colin Ian King Thanks Colin! Acked-by: Guilherme G. Piccoli > --- > drivers/tty/serial/jsm/jsm_tty.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/drivers/tty/serial/jsm/jsm_tty.c > b/drivers/tty/serial/jsm/jsm_tt

Re: [PATCH 0/5] TTY/JSM coding style fixes

Gimcuan! For the entire series: Acked-by: Guilherme G. Piccoli <gpicc...@linux.vnet.ibm.com>

Re: [PATCH 0/5] TTY/JSM coding style fixes

Gimcuan! For the entire series: Acked-by: Guilherme G. Piccoli

Re: [PATCH] powerpc/powernv: Enable reset_devices parameter to issue a PHB reset

V2 just sent to linuxppc-dev[0] list, with some simplifications. This one is then officially dropped! Thanks, Guilherme [0] http://patchwork.ozlabs.org/patch/830320

Re: [PATCH] powerpc/powernv: Enable reset_devices parameter to issue a PHB reset

V2 just sent to linuxppc-dev[0] list, with some simplifications. This one is then officially dropped! Thanks, Guilherme [0] http://patchwork.ozlabs.org/patch/830320

Re: [PATCH] genwqe: Take R/W permissions into account when dealing with memory pages

On 10/21/2017 05:51 AM, Greg KH wrote: > Is this a regression? It seems like it's just a "fix something that has > always been broken but no one has noticed yet" type of thing, right? > Yes, this a fix for something that always has been broken, not a regression! Thanks, Guilherme > thanks,

Re: [PATCH] genwqe: Take R/W permissions into account when dealing with memory pages

On 10/21/2017 05:51 AM, Greg KH wrote: > Is this a regression? It seems like it's just a "fix something that has > always been broken but no one has noticed yet" type of thing, right? > Yes, this a fix for something that always has been broken, not a regression! Thanks, Guilherme > thanks,

[PATCH] genwqe: Take R/W permissions into account when dealing with memory pages

of read-only-pages). Signed-off-by: Frank Haverkamp <ha...@linux.vnet.ibm.com> Signed-off-by: Guilherme G. Piccoli <gpicc...@linux.vnet.ibm.com> --- Arnd/Greg, we found this bug recently, although not critical, it's really a boring issue affecting driver functionality. If it's poss

[PATCH] genwqe: Take R/W permissions into account when dealing with memory pages

of read-only-pages). Signed-off-by: Frank Haverkamp Signed-off-by: Guilherme G. Piccoli --- Arnd/Greg, we found this bug recently, although not critical, it's really a boring issue affecting driver functionality. If it's possible to take this patch still on v4.14, we'd be really thankful! But we

Re: [PATCH] powerpc/powernv: Enable reset_devices parameter to issue a PHB reset

On 10/14/2017 06:13 AM, Benjamin Herrenschmidt wrote: > No, he's saying this is useful for the developers when debugging the > kernel driver (or for asking users to "test" something as part of > debugging a driver problem). > > It's common to have various command line options affecting PCIe >

Re: [PATCH] powerpc/powernv: Enable reset_devices parameter to issue a PHB reset

On 10/14/2017 06:13 AM, Benjamin Herrenschmidt wrote: > No, he's saying this is useful for the developers when debugging the > kernel driver (or for asking users to "test" something as part of > debugging a driver problem). > > It's common to have various command line options affecting PCIe >

Re: [PATCH] powerpc/powernv: Enable reset_devices parameter to issue a PHB reset

On 10/13/2017 05:37 AM, Michael Ellerman wrote: > > I really dislike this. > > You're basically saying the kernel can't work out how to get a device > working, so let's leave it up to the user. Oh, it was never my intention to say such blasphemy :) It meant to be just a debug option to help the

Re: [PATCH] powerpc/powernv: Enable reset_devices parameter to issue a PHB reset

On 10/13/2017 05:37 AM, Michael Ellerman wrote: > > I really dislike this. > > You're basically saying the kernel can't work out how to get a device > working, so let's leave it up to the user. Oh, it was never my intention to say such blasphemy :) It meant to be just a debug option to help the

[PATCH] powerpc/powernv: Enable reset_devices parameter to issue a PHB reset

of it. This is a PowerPC-only change. Signed-off-by: Guilherme G. Piccoli <gpicc...@linux.vnet.ibm.com> --- This patch was built/tested against powerpc/next branch. We recently had a situation in which i40e driver couldn't start, even after a full power cycle, due to a bug in its FW triggered by a DCB con

[PATCH] powerpc/powernv: Enable reset_devices parameter to issue a PHB reset

of it. This is a PowerPC-only change. Signed-off-by: Guilherme G. Piccoli --- This patch was built/tested against powerpc/next branch. We recently had a situation in which i40e driver couldn't start, even after a full power cycle, due to a bug in its FW triggered by a DCB condition in switch (thanks Mauro

Re: [PATCH v2] Documentation: rewrite confusing statement about memory barriers

On 09/21/2017 04:50 PM, Paul E. McKenney wrote: > On Thu, Sep 21, 2017 at 04:29:01PM -0300, Guilherme G. Piccoli wrote: >> In this specific portion of the write memory barriers description, >> the documentation mentions sequential order of stores, which is >> confusing sinc

Re: [PATCH v2] Documentation: rewrite confusing statement about memory barriers

On 09/21/2017 04:50 PM, Paul E. McKenney wrote: > On Thu, Sep 21, 2017 at 04:29:01PM -0300, Guilherme G. Piccoli wrote: >> In this specific portion of the write memory barriers description, >> the documentation mentions sequential order of stores, which is >> confusing sinc

[PATCH v2] Documentation: rewrite confusing statement about memory barriers

aul...@linux.vnet.ibm.com> Signed-off-by: Guilherme G. Piccoli <gpicc...@linux.vnet.ibm.com> --- v2: added Paul in CC. Documentation/memory-barriers.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barrie

[PATCH v2] Documentation: rewrite confusing statement about memory barriers

-by: Guilherme G. Piccoli --- v2: added Paul in CC. Documentation/memory-barriers.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt index b759a60624fd..a4bbbd1b63a0 100644 --- a/Documentation/memory

[PATCH] Documentation: rewrite confusing statement about memory barriers

In this specific portion of the write memory barriers description, the documentation mentions sequential order of stores, which is confusing since sequential ordering is not guaranteed. This patch tries to improve the doc in order to avoid any mis-understanding. Signed-off-by: Guilherme G

[PATCH] Documentation: rewrite confusing statement about memory barriers

In this specific portion of the write memory barriers description, the documentation mentions sequential order of stores, which is confusing since sequential ordering is not guaranteed. This patch tries to improve the doc in order to avoid any mis-understanding. Signed-off-by: Guilherme G

Re: [PATCH 1/3] PCI: ensure the PCI device is locked over ->reset_notify calls

On 06/12/2017 08:14 PM, Bjorn Helgaas wrote: > On Wed, Jun 07, 2017 at 08:29:36PM +0200, Christoph Hellwig wrote: >> On Tue, Jun 06, 2017 at 04:14:43PM -0500, Bjorn Helgaas wrote: >>> So I guess the method here is >>> dev->driver->err_handler->reset_notify(), and the PCI core should be >>> holding

Re: [PATCH 1/3] PCI: ensure the PCI device is locked over ->reset_notify calls

On 06/12/2017 08:14 PM, Bjorn Helgaas wrote: > On Wed, Jun 07, 2017 at 08:29:36PM +0200, Christoph Hellwig wrote: >> On Tue, Jun 06, 2017 at 04:14:43PM -0500, Bjorn Helgaas wrote: >>> So I guess the method here is >>> dev->driver->err_handler->reset_notify(), and the PCI core should be >>> holding

[PATCH] MAINTAINERS: Change maintainer of genwqe driver

Gabriel won't maintain this driver anymore. So, I'll maintain it with Frank. Thanks Gabriel for all your work on genwqe. Signed-off-by: Guilherme G. Piccoli <gpicc...@linux.vnet.ibm.com> --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAI

[PATCH] MAINTAINERS: Change maintainer of genwqe driver

Gabriel won't maintain this driver anymore. So, I'll maintain it with Frank. Thanks Gabriel for all your work on genwqe. Signed-off-by: Guilherme G. Piccoli --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index f7d568b8f133

Re: [PATCH] powerpc/xmon: Fix an unexpected xmon onoff state change

On 02/17/2017 07:30 AM, Pan Xinhui wrote: > > > 在 2017/2/17 14:05, Michael Ellerman 写道: >> Pan Xinhui writes: >>> diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c >>> index 9c0e17c..f6e5c3d 100644 >>> --- a/arch/powerpc/xmon/xmon.c >>> +++

Re: [PATCH] powerpc/xmon: Fix an unexpected xmon onoff state change

On 02/17/2017 07:30 AM, Pan Xinhui wrote: > > > 在 2017/2/17 14:05, Michael Ellerman 写道: >> Pan Xinhui writes: >>> diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c >>> index 9c0e17c..f6e5c3d 100644 >>> --- a/arch/powerpc/xmon/xmon.c >>> +++ b/arch/powerpc/xmon/xmon.c >>> @@ -76,6

Re: [PATCH] powerpc/xmon: Fix an unexpected xmon onoff state change

On 16/02/2017 03:09, Michael Ellerman wrote: > Pan Xinhui writes: > >> Once xmon is triggered by sysrq-x, it is enabled always afterwards even >> if it is disabled during boot. This will cause a system reset interrut >> fail to dump. So keep xmon in its original

Re: [PATCH] powerpc/xmon: Fix an unexpected xmon onoff state change

On 16/02/2017 03:09, Michael Ellerman wrote: > Pan Xinhui writes: > >> Once xmon is triggered by sysrq-x, it is enabled always afterwards even >> if it is disabled during boot. This will cause a system reset interrut >> fail to dump. So keep xmon in its original state after exit. >> >>

Re: [PATCH] powerpc/xmon: Fix an unexpected xmon onoff state change

Xinhui <xinhui@linux.vnet.ibm.com> Patch is fine - minor typo: interrut => interrupt Feel free to add my: Tested-by: Guilherme G. Piccoli <gpicc...@linux.vnet.ibm.com> Thanks, Guilherme > --- > arch/powerpc/xmon/xmon.c | 5 - > 1 file changed, 4 insertions(+), 1 deletion

Re: [PATCH] powerpc/xmon: Fix an unexpected xmon onoff state change

Patch is fine - minor typo: interrut => interrupt Feel free to add my: Tested-by: Guilherme G. Piccoli Thanks, Guilherme > --- > arch/powerpc/xmon/xmon.c | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmo

Re: [PATCH] scsi: do not requeue requests unaligned with device sector size

tors total, 3072 bytes done. > [...] sd 0:0:0:0: [sda] tag#0 checking 3072 bytes for alignment > (sector size 4096, remainder 3072, resid 1024) > [...] sd 0:0:0:0: [sda] tag#0 sd_done: completed 4096 of 4096 bytes > [...] sd 0:0:0:0: [sda] tag#0 8 sectors tota

Re: [PATCH] scsi: do not requeue requests unaligned with device sector size

tors total, 3072 bytes done. > [...] sd 0:0:0:0: [sda] tag#0 checking 3072 bytes for alignment > (sector size 4096, remainder 3072, resid 1024) > [...] sd 0:0:0:0: [sda] tag#0 sd_done: completed 4096 of 4096 bytes > [...] sd 0:0:0:0: [sda] tag#0 8 sectors tot

Re: [PATCH] genirq/affinity: fix node generation from cpumask

On 12/15/2016 07:36 AM, Thomas Gleixner wrote: > On Thu, 15 Dec 2016, Gavin Shan wrote: >>> static int get_nodes_in_cpumask(const struct cpumask *mask, nodemask_t >>> *nodemsk) >>> { >>> - int n, nodes; >>> + int n, nodes = 0; >>> >>> /* Calculate the number of nodes in the supplied

Re: [PATCH] genirq/affinity: fix node generation from cpumask

On 12/15/2016 07:36 AM, Thomas Gleixner wrote: > On Thu, 15 Dec 2016, Gavin Shan wrote: >>> static int get_nodes_in_cpumask(const struct cpumask *mask, nodemask_t >>> *nodemsk) >>> { >>> - int n, nodes; >>> + int n, nodes = 0; >>> >>> /* Calculate the number of nodes in the supplied

[tip:irq/urgent] genirq/affinity: Fix node generation from cpumask

Commit-ID: c0af52437254fda8b0cdbaae5a9b6d9327f1fcd5 Gitweb: http://git.kernel.org/tip/c0af52437254fda8b0cdbaae5a9b6d9327f1fcd5 Author: Guilherme G. Piccoli <gpicc...@linux.vnet.ibm.com> AuthorDate: Wed, 14 Dec 2016 16:01:12 -0200 Committer: Thomas Gleixner <t...@linutronix.de>

[tip:irq/urgent] genirq/affinity: Fix node generation from cpumask

Commit-ID: c0af52437254fda8b0cdbaae5a9b6d9327f1fcd5 Gitweb: http://git.kernel.org/tip/c0af52437254fda8b0cdbaae5a9b6d9327f1fcd5 Author: Guilherme G. Piccoli AuthorDate: Wed, 14 Dec 2016 16:01:12 -0200 Committer: Thomas Gleixner CommitDate: Thu, 15 Dec 2016 12:32:35 +0100 genirq

[PATCH] genirq/affinity: fix node generation from cpumask

ve _more_ nodes than vectors. Fixes: 34c3d9819fda ("genirq/affinity: Provide smarter irq spreading infrastructure") Reported-by: Gabriel Krisman Bertazi <gabr...@krisman.be> Signed-off-by: Guilherme G. Piccoli <gpicc...@linux.vnet.ibm.com> Cc: sta...@vger.kernel.org # v4

[PATCH] genirq/affinity: fix node generation from cpumask

ve _more_ nodes than vectors. Fixes: 34c3d9819fda ("genirq/affinity: Provide smarter irq spreading infrastructure") Reported-by: Gabriel Krisman Bertazi Signed-off-by: Guilherme G. Piccoli Cc: sta...@vger.kernel.org # v4.9+ Cc: Christoph Hellwig Cc: linuxppc-...@lists.ozlabs.org

Re: [PATCH 06/13] irq: add a helper spread an affinity mask for MSI/MSI-X vectors

Thanks for the responses Bart and Christoph. On 06/15/2016 07:10 AM, Christoph Hellwig wrote: On Tue, Jun 14, 2016 at 06:54:22PM -0300, Guilherme G. Piccoli wrote: On 06/14/2016 04:58 PM, Christoph Hellwig wrote: This is lifted from the blk-mq code and adopted to use the affinity mask

Re: [PATCH 06/13] irq: add a helper spread an affinity mask for MSI/MSI-X vectors

Thanks for the responses Bart and Christoph. On 06/15/2016 07:10 AM, Christoph Hellwig wrote: On Tue, Jun 14, 2016 at 06:54:22PM -0300, Guilherme G. Piccoli wrote: On 06/14/2016 04:58 PM, Christoph Hellwig wrote: This is lifted from the blk-mq code and adopted to use the affinity mask

Re: [PATCH 06/13] irq: add a helper spread an affinity mask for MSI/MSI-X vectors

On 06/14/2016 04:58 PM, Christoph Hellwig wrote: This is lifted from the blk-mq code and adopted to use the affinity mask concept just intruced in the irq handling code. Very nice patch Christoph, thanks. There's a little typo above, on "intruced". Signed-off-by: Christoph Hellwig

Re: [PATCH 06/13] irq: add a helper spread an affinity mask for MSI/MSI-X vectors

On 06/14/2016 04:58 PM, Christoph Hellwig wrote: This is lifted from the blk-mq code and adopted to use the affinity mask concept just intruced in the irq handling code. Very nice patch Christoph, thanks. There's a little typo above, on "intruced". Signed-off-by: Christoph Hellwig ---

Re: [PATCH] Use MICRO UINT_MAX instead of actual value

On 04/30/2016 07:13 AM, Minfei Huang wrote: Ping. Any comment is appreciate. Hi Minfei, I guess a good idea would be to resend the patch with the typo fixed, as a v2 patch. What do you think? Cheers, Guilherme Thanks Minfei On 04/25/16 at 11:13P, Minfei Huang wrote: It's more

Re: [PATCH] Use MICRO UINT_MAX instead of actual value

On 04/30/2016 07:13 AM, Minfei Huang wrote: Ping. Any comment is appreciate. Hi Minfei, I guess a good idea would be to resend the patch with the typo fixed, as a v2 patch. What do you think? Cheers, Guilherme Thanks Minfei On 04/25/16 at 11:13P, Minfei Huang wrote: It's more