[CCing Mario, who asked for the two suspected commits to be backported]
On 05.05.24 03:12, Micha Albert wrote:
>
> I have an AMD Radeon 6600 XT GPU in a cheap Thunderbolt eGPU board.
> In 6.8.7, this works as expected, and my Plymouth screen (including the
> LUKS password prompt) shows on my 2 monitors connected to the GPU as
> well as my main laptop screen. Upon entering the password, I'm put into
> userspace as expected. However, upon upgrading to 6.8.8, I will be
> greeted with the regular password prompt, but after entering my password
> and waiting for it to be accepted, my eGPU will reset and not function.
> I can tell that it resets since I can hear the click of my ATX power
> supply turning off and on again, and the status LED of the eGPU board
> goes from green to blue and back to green, all in less than a second.
>
> I talked to a friend, and we found out that the kernel parameter
> thunderbolt.host_reset=false fixes the issue. He also thinks that
> commits cc4c94 (59a54c upstream) and 11371c (ec8162 upstream) look
> suspicious. I've attached the output of dmesg when the error was
> occurring, since I'm still able to use my laptop normally when this
> happens, just not with my eGPU and its connected displays.
Thx for the report. Could you please test if 6.9-rc6 (or a later
snapshot; or -rc7, which should be out in about ~18 hours) is affected
as well? That would be really important to know.
It would also be great if you could try reverting the two patches you
mentioned and see if they are really what's causing this. There iirc are
two more; maybe you might need to revert some or all of them in the
order they were applied.
Ciao, Thorsten
P.s.: To be sure the issue doesn't fall through the cracks unnoticed,
I'm adding it to regzbot, the Linux kernel regression tracking bot:
#regzbot ^introduced v6.8.7..v6.8.8
#regzbot title thunderbolt: eGPU disconnected during boot
This is a note to let you know that I've just added the patch titled
iio: temperature: mcp9600: Fix temperature reading for negative
to my char-misc git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
in the char-misc-next branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will also be merged in the next major kernel release
during the merge window.
If you have any questions about this process, please let me know.
From 827dca3129708a8465bde90c86c2e3c38e62dd4f Mon Sep 17 00:00:00 2001
From: Dimitri Fedrau <dima.fedrau(a)gmail.com>
Date: Wed, 24 Apr 2024 20:59:10 +0200
Subject: iio: temperature: mcp9600: Fix temperature reading for negative
values
Temperature is stored as 16bit value in two's complement format. Current
implementation ignores the sign bit. Make it aware of the sign bit by
using sign_extend32.
Fixes: 3f6b9598b6df ("iio: temperature: Add MCP9600 thermocouple EMF converter")
Signed-off-by: Dimitri Fedrau <dima.fedrau(a)gmail.com>
Reviewed-by: Marcelo Schmitt <marcelo.schmitt1(a)gmail.com>
Tested-by: Andrew Hepp <andrew.hepp(a)ahepp.dev>
Link: https://lore.kernel.org/r/20240424185913.1177127-1-dima.fedrau@gmail.com
Cc: <Stable(a)vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com>
---
drivers/iio/temperature/mcp9600.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/iio/temperature/mcp9600.c b/drivers/iio/temperature/mcp9600.c
index 46845804292b..7a3eef5d5e75 100644
--- a/drivers/iio/temperature/mcp9600.c
+++ b/drivers/iio/temperature/mcp9600.c
@@ -52,7 +52,8 @@ static int mcp9600_read(struct mcp9600_data *data,
if (ret < 0)
return ret;
- *val = ret;
+
+ *val = sign_extend32(ret, 15);
return 0;
}
--
2.45.0
This is a note to let you know that I've just added the patch titled
iio: adc: axi-adc: make sure AXI clock is enabled
to my char-misc git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
in the char-misc-next branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will also be merged in the next major kernel release
during the merge window.
If you have any questions about this process, please let me know.
From 80721776c5af6f6dce7d84ba8df063957aa425a2 Mon Sep 17 00:00:00 2001
From: Nuno Sa <nuno.sa(a)analog.com>
Date: Fri, 26 Apr 2024 17:42:13 +0200
Subject: iio: adc: axi-adc: make sure AXI clock is enabled
We can only access the IP core registers if the bus clock is enabled. As
such we need to get and enable it and not rely on anyone else to do it.
Note this clock is a very fundamental one that is typically enabled
pretty early during boot. Independently of that, we should really rely on
it to be enabled.
Fixes: ef04070692a2 ("iio: adc: adi-axi-adc: add support for AXI ADC IP core")
Signed-off-by: Nuno Sa <nuno.sa(a)analog.com>
Link: https://lore.kernel.org/r/20240426-ad9467-new-features-v2-4-6361fc3ba1cc@an…
Cc: <Stable(a)vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com>
---
drivers/iio/adc/adi-axi-adc.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/iio/adc/adi-axi-adc.c b/drivers/iio/adc/adi-axi-adc.c
index 9444b0c5a93c..f54830658da8 100644
--- a/drivers/iio/adc/adi-axi-adc.c
+++ b/drivers/iio/adc/adi-axi-adc.c
@@ -161,6 +161,7 @@ static int adi_axi_adc_probe(struct platform_device *pdev)
struct adi_axi_adc_state *st;
void __iomem *base;
unsigned int ver;
+ struct clk *clk;
int ret;
st = devm_kzalloc(&pdev->dev, sizeof(*st), GFP_KERNEL);
@@ -181,6 +182,10 @@ static int adi_axi_adc_probe(struct platform_device *pdev)
if (!expected_ver)
return -ENODEV;
+ clk = devm_clk_get_enabled(&pdev->dev, NULL);
+ if (IS_ERR(clk))
+ return PTR_ERR(clk);
+
/*
* Force disable the core. Up to the frontend to enable us. And we can
* still read/write registers...
--
2.45.0
[ Upstream commit ebf2e8860eea66e2c4764316b80c6a5ee5f336ee]
[ Upstream commit f8dd95b29d7ef08c19ec9720564acf72243ddcf6]
In the first patch,
ebf2e8860eea ("tcp_bpf: Inline do_tcp_sendpages as it's now a wrapper around tcp_sendmsg")
This block of code is added to tcp_bpf_push(). The
tcp_bpf_push is the code used by BPF to submit messages into the TCP
stack.
if (flags & MSG_SENDPAGE_NOTLAST)
msghdr.msg_flags | MSG_MORE;
In the second patch,
f8dd95b29d7e ("tcp_bpf, smc, tls, espintcp, siw: Reduce MSG_SENDPAGE_NOTLAST usage")
this logic was further changed to,
if (flags & MSG_SENDPAGE_NOTLAST)
msghdr.msg_flags |= MSG_MORE
This was done as part of an improvement to use the sendmsg() callbacks
and remove the sendpage usage inside the various sub systems.
However, these two patches together fixed a bug. The issue is without
MSG_MORE set we will break a msg up into many smaller sends. In some
case a lot because the operation loops over the scatter gather list.
Without the MSG_MORE set (the current 6.1 case) we see stalls in data
send/recv and sometimes applications failing to receive data. This
generally is the result of an application that gives up after calling
recv() or similar too many times. We introduce this because of how
we incorrectly change the TCP send pattern.
Now that we have both 6.5 and 6.1 stable kernels deployed we've
observed a series of issues related to this in real deployments. In 6.5
kernels all the HTTP and other compliance tests pass and we are not
observing any other issues. On 6.1 various compliance tests fail
(nginx for example), but more importantly in these clusters without
the flag set we observe stalled applications and increased retries in
other applications. Openssl users where we have annotations to monitor
retries and failures observed a significant increase in retries for
example.
For the backport we isolated the fix to the two lines in the above
patches that fixed the code. With this patch we deployed the workloads
again and error rates and stalls went away and 6.1 stable kernels
perform similar to 6.5 stable kernels. Similarly the compliance tests
also passed.
Cc: <stable(a)vger.kernel.org> # 6.1.x
Fixes: 604326b41a6fb ("tcp_bpf, smc, tls, espintcp, siw: Reduce MSG_SENDPAGE_NOTLAST usage")
Signed-off-by: John Fastabend <john.fastabend(a)gmail.com>
---
net/ipv4/tcp_bpf.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/ipv4/tcp_bpf.c b/net/ipv4/tcp_bpf.c
index f8037d142bb7..20d94f67fde2 100644
--- a/net/ipv4/tcp_bpf.c
+++ b/net/ipv4/tcp_bpf.c
@@ -105,6 +105,9 @@ static int tcp_bpf_push(struct sock *sk, struct sk_msg *msg, u32 apply_bytes,
tcp_rate_check_app_limited(sk);
retry:
+ if (size < sge->length && msg->sg.start != msg->sg.end)
+ flags |= MSG_SENDPAGE_NOTLAST;
+
has_tx_ulp = tls_sw_has_ctx_tx(sk);
if (has_tx_ulp) {
flags |= MSG_SENDPAGE_NOPOLICY;
--
2.33.0
If there is no bus number available for the downstream bus of the
hot-plugged bridge, pci_hp_add_bridge() will fail. The driver proceeds
regardless, and the kernel crashes.
Abort if pci_hp_add_bridge() fails.
Fixes: 0eb3bcfd088e ("[PATCH] pciehp: allow bridged card hotplug")
Signed-off-by: Nam Cao <namcao(a)linutronix.de>
Cc: Rajesh Shah <rajesh.shah(a)intel.com>
Cc: <stable(a)vger.kernel.org>
---
drivers/pci/hotplug/pciehp_pci.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/hotplug/pciehp_pci.c b/drivers/pci/hotplug/pciehp_pci.c
index ad12515a4a12..faf4fcf2fbdf 100644
--- a/drivers/pci/hotplug/pciehp_pci.c
+++ b/drivers/pci/hotplug/pciehp_pci.c
@@ -58,8 +58,13 @@ int pciehp_configure_device(struct controller *ctrl)
goto out;
}
- for_each_pci_bridge(dev, parent)
- pci_hp_add_bridge(dev);
+ for_each_pci_bridge(dev, parent) {
+ if (pci_hp_add_bridge(dev)) {
+ pci_stop_and_remove_bus_device(dev);
+ ret = -EINVAL;
+ goto out;
+ }
+ }
pci_assign_unassigned_bridge_resources(bridge);
pcie_bus_configure_settings(parent);
--
2.39.2
This is a note to let you know that I've just added the patch titled
iio: temperature: mcp9600: Fix temperature reading for negative
to my char-misc git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
in the char-misc-testing branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will be merged to the char-misc-next branch sometime soon,
after it passes testing, and the merge window is open.
If you have any questions about this process, please let me know.
From 827dca3129708a8465bde90c86c2e3c38e62dd4f Mon Sep 17 00:00:00 2001
From: Dimitri Fedrau <dima.fedrau(a)gmail.com>
Date: Wed, 24 Apr 2024 20:59:10 +0200
Subject: iio: temperature: mcp9600: Fix temperature reading for negative
values
Temperature is stored as 16bit value in two's complement format. Current
implementation ignores the sign bit. Make it aware of the sign bit by
using sign_extend32.
Fixes: 3f6b9598b6df ("iio: temperature: Add MCP9600 thermocouple EMF converter")
Signed-off-by: Dimitri Fedrau <dima.fedrau(a)gmail.com>
Reviewed-by: Marcelo Schmitt <marcelo.schmitt1(a)gmail.com>
Tested-by: Andrew Hepp <andrew.hepp(a)ahepp.dev>
Link: https://lore.kernel.org/r/20240424185913.1177127-1-dima.fedrau@gmail.com
Cc: <Stable(a)vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com>
---
drivers/iio/temperature/mcp9600.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/iio/temperature/mcp9600.c b/drivers/iio/temperature/mcp9600.c
index 46845804292b..7a3eef5d5e75 100644
--- a/drivers/iio/temperature/mcp9600.c
+++ b/drivers/iio/temperature/mcp9600.c
@@ -52,7 +52,8 @@ static int mcp9600_read(struct mcp9600_data *data,
if (ret < 0)
return ret;
- *val = ret;
+
+ *val = sign_extend32(ret, 15);
return 0;
}
--
2.45.0
This is a note to let you know that I've just added the patch titled
iio: adc: axi-adc: make sure AXI clock is enabled
to my char-misc git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
in the char-misc-testing branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will be merged to the char-misc-next branch sometime soon,
after it passes testing, and the merge window is open.
If you have any questions about this process, please let me know.
From 80721776c5af6f6dce7d84ba8df063957aa425a2 Mon Sep 17 00:00:00 2001
From: Nuno Sa <nuno.sa(a)analog.com>
Date: Fri, 26 Apr 2024 17:42:13 +0200
Subject: iio: adc: axi-adc: make sure AXI clock is enabled
We can only access the IP core registers if the bus clock is enabled. As
such we need to get and enable it and not rely on anyone else to do it.
Note this clock is a very fundamental one that is typically enabled
pretty early during boot. Independently of that, we should really rely on
it to be enabled.
Fixes: ef04070692a2 ("iio: adc: adi-axi-adc: add support for AXI ADC IP core")
Signed-off-by: Nuno Sa <nuno.sa(a)analog.com>
Link: https://lore.kernel.org/r/20240426-ad9467-new-features-v2-4-6361fc3ba1cc@an…
Cc: <Stable(a)vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com>
---
drivers/iio/adc/adi-axi-adc.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/iio/adc/adi-axi-adc.c b/drivers/iio/adc/adi-axi-adc.c
index 9444b0c5a93c..f54830658da8 100644
--- a/drivers/iio/adc/adi-axi-adc.c
+++ b/drivers/iio/adc/adi-axi-adc.c
@@ -161,6 +161,7 @@ static int adi_axi_adc_probe(struct platform_device *pdev)
struct adi_axi_adc_state *st;
void __iomem *base;
unsigned int ver;
+ struct clk *clk;
int ret;
st = devm_kzalloc(&pdev->dev, sizeof(*st), GFP_KERNEL);
@@ -181,6 +182,10 @@ static int adi_axi_adc_probe(struct platform_device *pdev)
if (!expected_ver)
return -ENODEV;
+ clk = devm_clk_get_enabled(&pdev->dev, NULL);
+ if (IS_ERR(clk))
+ return PTR_ERR(clk);
+
/*
* Force disable the core. Up to the frontend to enable us. And we can
* still read/write registers...
--
2.45.0