drivers/interconnect/qcom/icc-rpmh.c | 8 ++++++++ 1 file changed, 8 insertions(+)
Recent addition of QoS configuration to the X1 variants resulted in
systems that spontaneously reset at boot time or under load.
Given that this is both very unpleasant and hard to debug, give the
affected user the option to survive such event with a module parameter.
Passing "icc_rpmh.enable_qos=0" to the kernel command-line will skip the
offending QoS setup.
Link: https://lore.kernel.org/all/apgeBNSiP01YfNcs@google.com
Link: https://lore.kernel.org/all/86ld9d4h4n.wl-maz@kernel.org
Signed-off-by: Marc Zyngier <maz@kernel.org>
Cc: Raviteja Laggyshetty <raviteja.laggyshetty@oss.qualcomm.com>
Cc: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Cc: Abel Vesa <abelvesa@kernel.org>
Cc: Bjorn Andersson <andersson@kernel.org>
Cc: Mostafa Saleh <smostafa@google.com>
---
drivers/interconnect/qcom/icc-rpmh.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/interconnect/qcom/icc-rpmh.c b/drivers/interconnect/qcom/icc-rpmh.c
index 3b445acefece7..3a4743c364dac 100644
--- a/drivers/interconnect/qcom/icc-rpmh.c
+++ b/drivers/interconnect/qcom/icc-rpmh.c
@@ -224,6 +224,9 @@ static int qcom_icc_rpmh_configure_qos(struct qcom_icc_provider *qp)
return ret;
}
+static bool enable_qos = true;
+module_param(enable_qos, bool, 0660);
+
int qcom_icc_rpmh_probe(struct platform_device *pdev)
{
const struct qcom_icc_desc *desc;
@@ -308,6 +311,11 @@ int qcom_icc_rpmh_probe(struct platform_device *pdev)
struct resource *res;
void __iomem *base;
+ if (!enable_qos) {
+ dev_info(dev, "Skipping QoS (command line)\n");
+ goto skip_qos_config;
+ }
+
/* Try parent's regmap first */
qp->regmap = dev_get_regmap(dev->parent, NULL);
if (!qp->regmap) {
--
2.47.3On 26-09-07 18:17:29, Marc Zyngier wrote: > Recent addition of QoS configuration to the X1 variants resulted in > systems that spontaneously reset at boot time or under load. > > Given that this is both very unpleasant and hard to debug, give the > affected user the option to survive such event with a module parameter. > > Passing "icc_rpmh.enable_qos=0" to the kernel command-line will skip the > offending QoS setup. > Lets not start doing this, please. Can we figure out which platform deosn't work and then maybe we can add a quirk in DT per platform?
On Mon, 07 Sep 2026 21:21:44 +0100, Abel Vesa <abel.vesa@oss.qualcomm.com> wrote: > > On 26-09-07 18:17:29, Marc Zyngier wrote: > > Recent addition of QoS configuration to the X1 variants resulted in > > systems that spontaneously reset at boot time or under load. > > > > Given that this is both very unpleasant and hard to debug, give the > > affected user the option to survive such event with a module parameter. > > > > Passing "icc_rpmh.enable_qos=0" to the kernel command-line will skip the > > offending QoS setup. > > > > Lets not start doing this, please. > > Can we figure out which platform deosn't work and then maybe we can > add a quirk in DT per platform? We have at least 3 machines that are dysfunctional since [1] was merged (mini-x, sp12 and devkit). Probably some more, but I'm not going to be the one doing a survey. What really should happen is [1] to be reversed until QC figures out a set of parameters that actually works, instead of making this platform even more unreliable than it already is. Just like [2] should have been reverted. Until then, we'll have to paper over this stuff. M. [1] https://lore.kernel.org/all/20260527-x1e80100_qos-v2-2-305c6539e6d2@oss.qualcomm.com [2] https://lore.kernel.org/all/20260203063244.1498699-1-xin.liu@oss.qualcomm.com -- Jazz isn't dead. It just smells funny.
On 26-09-07 22:15:09, Marc Zyngier wrote: > On Mon, 07 Sep 2026 21:21:44 +0100, > Abel Vesa <abel.vesa@oss.qualcomm.com> wrote: > > > > On 26-09-07 18:17:29, Marc Zyngier wrote: > > > Recent addition of QoS configuration to the X1 variants resulted in > > > systems that spontaneously reset at boot time or under load. > > > > > > Given that this is both very unpleasant and hard to debug, give the > > > affected user the option to survive such event with a module parameter. > > > > > > Passing "icc_rpmh.enable_qos=0" to the kernel command-line will skip the > > > offending QoS setup. > > > > > > > Lets not start doing this, please. > > > > Can we figure out which platform deosn't work and then maybe we can > > add a quirk in DT per platform? > > We have at least 3 machines that are dysfunctional since [1] was > merged (mini-x, sp12 and devkit). Probably some more, but I'm not > going to be the one doing a survey. > > What really should happen is [1] to be reversed until QC figures out a > set of parameters that actually works, instead of making this platform > even more unreliable than it already is. I'd rather have the patch reverted than adding a module parameter which users might not know about and distros will probably never addopt. > > Just like [2] should have been reverted. > > Until then, we'll have to paper over this stuff. But a module parameter complicates things rather than just papering over. I suggest we get both reverted if they break existing platforms.
On Tue, 08 Sep 2026 08:34:18 +0100, Abel Vesa <abel.vesa@oss.qualcomm.com> wrote: > > On 26-09-07 22:15:09, Marc Zyngier wrote: > > On Mon, 07 Sep 2026 21:21:44 +0100, > > Abel Vesa <abel.vesa@oss.qualcomm.com> wrote: > > > > > > On 26-09-07 18:17:29, Marc Zyngier wrote: > > > > Recent addition of QoS configuration to the X1 variants resulted in > > > > systems that spontaneously reset at boot time or under load. > > > > > > > > Given that this is both very unpleasant and hard to debug, give the > > > > affected user the option to survive such event with a module parameter. > > > > > > > > Passing "icc_rpmh.enable_qos=0" to the kernel command-line will skip the > > > > offending QoS setup. > > > > > > > > > > Lets not start doing this, please. > > > > > > Can we figure out which platform deosn't work and then maybe we can > > > add a quirk in DT per platform? > > > > We have at least 3 machines that are dysfunctional since [1] was > > merged (mini-x, sp12 and devkit). Probably some more, but I'm not > > going to be the one doing a survey. > > > > What really should happen is [1] to be reversed until QC figures out a > > set of parameters that actually works, instead of making this platform > > even more unreliable than it already is. > > I'd rather have the patch reverted than adding a module parameter which > users might not know about and distros will probably never addopt. > > > > > Just like [2] should have been reverted. > > > > Until then, we'll have to paper over this stuff. > > But a module parameter complicates things rather than just papering over. > > I suggest we get both reverted if they break existing platforms. We're in violent agreement. Thanks, M. -- Without deviation from the norm, progress is not possible.
On 9/8/26 10:42, Marc Zyngier wrote: > On Tue, 08 Sep 2026 08:34:18 +0100, > Abel Vesa <abel.vesa@oss.qualcomm.com> wrote: >> On 26-09-07 22:15:09, Marc Zyngier wrote: >>> On Mon, 07 Sep 2026 21:21:44 +0100, >>> Abel Vesa <abel.vesa@oss.qualcomm.com> wrote: >>>> On 26-09-07 18:17:29, Marc Zyngier wrote: >>>>> Recent addition of QoS configuration to the X1 variants resulted in >>>>> systems that spontaneously reset at boot time or under load. >>>>> >>>>> Given that this is both very unpleasant and hard to debug, give the >>>>> affected user the option to survive such event with a module parameter. >>>>> >>>>> Passing "icc_rpmh.enable_qos=0" to the kernel command-line will skip the >>>>> offending QoS setup. >>>> >>>> Lets not start doing this, please. >>>> >>>> Can we figure out which platform deosn't work and then maybe we can >>>> add a quirk in DT per platform? >>> >>> We have at least 3 machines that are dysfunctional since [1] was >>> merged (mini-x, sp12 and devkit). Probably some more, but I'm not >>> going to be the one doing a survey. >>> >>> What really should happen is [1] to be reversed until QC figures out a >>> set of parameters that actually works, instead of making this platform >>> even more unreliable than it already is. >> >> I'd rather have the patch reverted than adding a module parameter which >> users might not know about and distros will probably never addopt. >>> >>> Just like [2] should have been reverted. >>> >>> Until then, we'll have to paper over this stuff. >> >> But a module parameter complicates things rather than just papering over. >> >> I suggest we get both reverted if they break existing platforms. > > We're in violent agreement. Did anyone submit those reverts? Doesn't look like it from what I see. Do we maybe need to poke the subsystem maintainers? Side note for the record (noticed it just by chance): afaics one fix for [2] was submitted meanwhile: https://lore.kernel.org/all/20260914-x1-el2-unfuck-v1-1-00d8bc35a635@oldschoolsolutions.biz/ Ciao, Thorsten
On 26-09-15 14:12:30, Thorsten Leemhuis wrote: > On 9/8/26 10:42, Marc Zyngier wrote: > > On Tue, 08 Sep 2026 08:34:18 +0100, > > Abel Vesa <abel.vesa@oss.qualcomm.com> wrote: > >> On 26-09-07 22:15:09, Marc Zyngier wrote: > >>> On Mon, 07 Sep 2026 21:21:44 +0100, > >>> Abel Vesa <abel.vesa@oss.qualcomm.com> wrote: > >>>> On 26-09-07 18:17:29, Marc Zyngier wrote: > >>>>> Recent addition of QoS configuration to the X1 variants resulted in > >>>>> systems that spontaneously reset at boot time or under load. > >>>>> > >>>>> Given that this is both very unpleasant and hard to debug, give the > >>>>> affected user the option to survive such event with a module parameter. > >>>>> > >>>>> Passing "icc_rpmh.enable_qos=0" to the kernel command-line will skip the > >>>>> offending QoS setup. > >>>> > >>>> Lets not start doing this, please. > >>>> > >>>> Can we figure out which platform deosn't work and then maybe we can > >>>> add a quirk in DT per platform? > >>> > >>> We have at least 3 machines that are dysfunctional since [1] was > >>> merged (mini-x, sp12 and devkit). Probably some more, but I'm not > >>> going to be the one doing a survey. > >>> > >>> What really should happen is [1] to be reversed until QC figures out a > >>> set of parameters that actually works, instead of making this platform > >>> even more unreliable than it already is. > >> > >> I'd rather have the patch reverted than adding a module parameter which > >> users might not know about and distros will probably never addopt. > >>> > >>> Just like [2] should have been reverted. > >>> > >>> Until then, we'll have to paper over this stuff. > >> > >> But a module parameter complicates things rather than just papering over. > >> > >> I suggest we get both reverted if they break existing platforms. > > > > We're in violent agreement. > Did anyone submit those reverts? Doesn't look like it from what I see. > Do we maybe need to poke the subsystem maintainers? Sent the revert for the interconnect driver commit only. https://lore.kernel.org/all/20260915-icc-qcom-x1e80100-revert-qos-enabling-v1-1-cc4ba943bd9d@oss.qualcomm.com/
On Tue, 15 Sep 2026 13:12:30 +0100, Thorsten Leemhuis <regressions@leemhuis.info> wrote: > > On 9/8/26 10:42, Marc Zyngier wrote: > > On Tue, 08 Sep 2026 08:34:18 +0100, > > Abel Vesa <abel.vesa@oss.qualcomm.com> wrote: > >> On 26-09-07 22:15:09, Marc Zyngier wrote: > >>> On Mon, 07 Sep 2026 21:21:44 +0100, > >>> Abel Vesa <abel.vesa@oss.qualcomm.com> wrote: > >>>> On 26-09-07 18:17:29, Marc Zyngier wrote: > >>>>> Recent addition of QoS configuration to the X1 variants resulted in > >>>>> systems that spontaneously reset at boot time or under load. > >>>>> > >>>>> Given that this is both very unpleasant and hard to debug, give the > >>>>> affected user the option to survive such event with a module parameter. > >>>>> > >>>>> Passing "icc_rpmh.enable_qos=0" to the kernel command-line will skip the > >>>>> offending QoS setup. > >>>> > >>>> Lets not start doing this, please. > >>>> > >>>> Can we figure out which platform deosn't work and then maybe we can > >>>> add a quirk in DT per platform? > >>> > >>> We have at least 3 machines that are dysfunctional since [1] was > >>> merged (mini-x, sp12 and devkit). Probably some more, but I'm not > >>> going to be the one doing a survey. > >>> > >>> What really should happen is [1] to be reversed until QC figures out a > >>> set of parameters that actually works, instead of making this platform > >>> even more unreliable than it already is. > >> > >> I'd rather have the patch reverted than adding a module parameter which > >> users might not know about and distros will probably never addopt. > >>> > >>> Just like [2] should have been reverted. > >>> > >>> Until then, we'll have to paper over this stuff. > >> > >> But a module parameter complicates things rather than just papering over. > >> > >> I suggest we get both reverted if they break existing platforms. > > > > We're in violent agreement. > Did anyone submit those reverts? Doesn't look like it from what I see. > Do we maybe need to poke the subsystem maintainers? Done: https://lore.kernel.org/r/20260915123703.3228329-1-maz@kernel.org > Side note for the record (noticed it just by chance): afaics one fix for > [2] was submitted meanwhile: > > https://lore.kernel.org/all/20260914-x1-el2-unfuck-v1-1-00d8bc35a635@oldschoolsolutions.biz/ Ah, nice one. Hopefully this gets eventually merged. M. -- Without deviation from the norm, progress is not possible.
On 9/8/2026 1:04 PM, Abel Vesa wrote: > On 26-09-07 22:15:09, Marc Zyngier wrote: >> On Mon, 07 Sep 2026 21:21:44 +0100, >> Abel Vesa <abel.vesa@oss.qualcomm.com> wrote: >>> >>> On 26-09-07 18:17:29, Marc Zyngier wrote: >>>> Recent addition of QoS configuration to the X1 variants resulted in >>>> systems that spontaneously reset at boot time or under load. >>>> >>>> Given that this is both very unpleasant and hard to debug, give the >>>> affected user the option to survive such event with a module parameter. >>>> >>>> Passing "icc_rpmh.enable_qos=0" to the kernel command-line will skip the >>>> offending QoS setup. >>>> >>> >>> Lets not start doing this, please. >>> >>> Can we figure out which platform deosn't work and then maybe we can >>> add a quirk in DT per platform? >> >> We have at least 3 machines that are dysfunctional since [1] was >> merged (mini-x, sp12 and devkit). Probably some more, but I'm not >> going to be the one doing a survey. >> >> What really should happen is [1] to be reversed until QC figures out a >> set of parameters that actually works, instead of making this platform >> even more unreliable than it already is. > > I'd rather have the patch reverted than adding a module parameter which > users might not know about and distros will probably never addopt. > >> >> Just like [2] should have been reverted. >> >> Until then, we'll have to paper over this stuff. > > But a module parameter complicates things rather than just papering over. > > I suggest we get both reverted if they break existing platforms. I will share a patch to add interconnect support for Purwa. Purwa is similar to Hamoa, but there are few port additions and deletions with respect to PCIe, and trying to program QoS for them can result in crash. Thanks, Raviteja.
On Tue, 08 Sep 2026 09:29:44 +0100, Raviteja Laggyshetty <raviteja.laggyshetty@oss.qualcomm.com> wrote: > > > > On 9/8/2026 1:04 PM, Abel Vesa wrote: > > On 26-09-07 22:15:09, Marc Zyngier wrote: > >> On Mon, 07 Sep 2026 21:21:44 +0100, > >> Abel Vesa <abel.vesa@oss.qualcomm.com> wrote: > >>> > >>> On 26-09-07 18:17:29, Marc Zyngier wrote: > >>>> Recent addition of QoS configuration to the X1 variants resulted in > >>>> systems that spontaneously reset at boot time or under load. > >>>> > >>>> Given that this is both very unpleasant and hard to debug, give the > >>>> affected user the option to survive such event with a module parameter. > >>>> > >>>> Passing "icc_rpmh.enable_qos=0" to the kernel command-line will skip the > >>>> offending QoS setup. > >>>> > >>> > >>> Lets not start doing this, please. > >>> > >>> Can we figure out which platform deosn't work and then maybe we can > >>> add a quirk in DT per platform? > >> > >> We have at least 3 machines that are dysfunctional since [1] was > >> merged (mini-x, sp12 and devkit). Probably some more, but I'm not > >> going to be the one doing a survey. > >> > >> What really should happen is [1] to be reversed until QC figures out a > >> set of parameters that actually works, instead of making this platform > >> even more unreliable than it already is. > > > > I'd rather have the patch reverted than adding a module parameter which > > users might not know about and distros will probably never addopt. > > > >> > >> Just like [2] should have been reverted. > >> > >> Until then, we'll have to paper over this stuff. > > > > But a module parameter complicates things rather than just papering over. > > > > I suggest we get both reverted if they break existing platforms. > > I will share a patch to add interconnect support for Purwa. > Purwa is similar to Hamoa, but there are few port additions and deletions with > respect to PCIe, and trying to program QoS for them can result in crash. This is unfortunately not solely about Purwa, as repeatedly pointed out in this thread and the original one. Hamoa (at least the machine I use for a lot of my upstream work) has become completely unreliable since the QoS patch was merged, and randomly resets under IO load. Not applying the QoS configuration restores stability. My conclusion is that merging this stuff was premature and has evidently not seen enough testing and verification. M. -- Without deviation from the norm, progress is not possible.
© 2016 - 2026 Red Hat, Inc.