Bug#1028451: 2nd DisplayPort doesn't get video
Hi Didier, On Sat, Jan 21, 2023 at 05:43:03PM +0100, Didier 'OdyX' Raboud wrote: > Control: tags -1 +patch > > Le vendredi, 20 janvier 2023, 21.38:42 h CET Salvatore Bonaccorso a écrit : > > There is the patchset currently asked for inclusion at > > https://lore.kernel.org/stable/20230119235200.441386-1-harry.wentl...@amd.co > > m/T/#m3b5b3616eac750cfd7c9bd00ac1cf95006a6aeec which is for addressing this > > issue. > > Indeed. I can confirm this fixes my issue with the attached patch on top of > 6.1.7-1, which is all 4 patches from : > https://gitlab.freedesktop.org/hwentland/linux/-/commits/mst_regression_6.1 > aka: > https://gitlab.freedesktop.org/hwentland/linux/-/compare/ > 21e996306a6afaae88295858de0ffb8955173a15...1521e9dcb431f31c15a0256cb619b09cca3efc4e? > from_project_id=12209=false > > I hope this can either get to 6.1 stable, or be backported / carried over by > Debian! Happy to MR this if it makes sense! perfect thanks for testing! You could add an explicit Tested-by on the patch sumission thread. I expect the patches to be reviewed and acked soon, then they should tickle in in 6.1.y. Will pick those up with our packaging workflow. Regards, Salvatore
Bug#1028451: 2nd DisplayPort doesn't get video
Control: tags -1 +patch
Le vendredi, 20 janvier 2023, 21.38:42 h CET Salvatore Bonaccorso a écrit :
> There is the patchset currently asked for inclusion at
> https://lore.kernel.org/stable/20230119235200.441386-1-harry.wentl...@amd.co
> m/T/#m3b5b3616eac750cfd7c9bd00ac1cf95006a6aeec which is for addressing this
> issue.
Indeed. I can confirm this fixes my issue with the attached patch on top of
6.1.7-1, which is all 4 patches from :
https://gitlab.freedesktop.org/hwentland/linux/-/commits/mst_regression_6.1
aka:
https://gitlab.freedesktop.org/hwentland/linux/-/compare/
21e996306a6afaae88295858de0ffb8955173a15...1521e9dcb431f31c15a0256cb619b09cca3efc4e?
from_project_id=12209=false
I hope this can either get to 6.1 stable, or be backported / carried over by
Debian! Happy to MR this if it makes sense!
Best,
OdyXdiff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index dacad8b85963..fbc89129e7de 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -9399,6 +9399,8 @@ static int amdgpu_dm_atomic_check(struct drm_device *dev,
struct drm_connector_state *old_con_state, *new_con_state;
struct drm_crtc *crtc;
struct drm_crtc_state *old_crtc_state, *new_crtc_state;
+ struct drm_dp_mst_topology_mgr *mgr;
+ struct drm_dp_mst_topology_state *mst_state;
struct drm_plane *plane;
struct drm_plane_state *old_plane_state, *new_plane_state;
enum dc_status status;
@@ -9654,6 +9656,28 @@ static int amdgpu_dm_atomic_check(struct drm_device *dev,
lock_and_validation_needed = true;
}
+#if defined(CONFIG_DRM_AMD_DC_DCN)
+ /* set the slot info for each mst_state based on the link encoding format */
+ for_each_new_mst_mgr_in_state(state, mgr, mst_state, i) {
+ struct amdgpu_dm_connector *aconnector;
+ struct drm_connector *connector;
+ struct drm_connector_list_iter iter;
+ u8 link_coding_cap;
+
+ drm_connector_list_iter_begin(dev, );
+ drm_for_each_connector_iter(connector, ) {
+ if (connector->index == mst_state->mgr->conn_base_id) {
+aconnector = to_amdgpu_dm_connector(connector);
+link_coding_cap = dc_link_dp_mst_decide_link_encoding_format(aconnector->dc_link);
+drm_dp_mst_update_slots(mst_state, link_coding_cap);
+
+break;
+ }
+ }
+ drm_connector_list_iter_end();
+ }
+#endif
+
/**
* Streams and planes are reset when there are changes that affect
* bandwidth. Anything that affects bandwidth needs to go through
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
index f72c013d3a5b..16623f73ddbe 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
@@ -120,23 +120,50 @@ enum dc_edid_status dm_helpers_parse_edid_caps(
}
static void
-fill_dc_mst_payload_table_from_drm(struct drm_dp_mst_topology_state *mst_state,
- struct amdgpu_dm_connector *aconnector,
+fill_dc_mst_payload_table_from_drm(struct dc_link *link,
+ bool enable,
+ struct drm_dp_mst_atomic_payload *target_payload,
struct dc_dp_mst_stream_allocation_table *table)
{
struct dc_dp_mst_stream_allocation_table new_table = { 0 };
struct dc_dp_mst_stream_allocation *sa;
- struct drm_dp_mst_atomic_payload *payload;
+ struct link_mst_stream_allocation_table copy_of_link_table =
+ link->mst_stream_alloc_table;
+
+ int i;
+ int current_hw_table_stream_cnt = copy_of_link_table.stream_count;
+ struct link_mst_stream_allocation *dc_alloc;
+
+ /* TODO: refactor to set link->mst_stream_alloc_table directly if possible.*/
+ if (enable) {
+ dc_alloc =
+ _of_link_table.stream_allocations[current_hw_table_stream_cnt];
+ dc_alloc->vcp_id = target_payload->vcpi;
+ dc_alloc->slot_count = target_payload->time_slots;
+ } else {
+ for (i = 0; i < copy_of_link_table.stream_count; i++) {
+ dc_alloc =
+ _of_link_table.stream_allocations[i];
+
+ if (dc_alloc->vcp_id == target_payload->vcpi) {
+dc_alloc->vcp_id = 0;
+dc_alloc->slot_count = 0;
+break;
+ }
+ }
+ ASSERT(i != copy_of_link_table.stream_count);
+ }
/* Fill payload info*/
- list_for_each_entry(payload, _state->payloads, next) {
- if (payload->delete)
- continue;
-
- sa = _table.stream_allocations[new_table.stream_count];
- sa->slot_count = payload->time_slots;
- sa->vcp_id = payload->vcpi;
- new_table.stream_count++;
+ for (i = 0; i < MAX_CONTROLLER_NUM; i++) {
+ dc_alloc =
+ _of_link_table.stream_allocations[i];
+ if (dc_alloc->vcp_id > 0 && dc_alloc->slot_count > 0) {
+ sa = _table.stream_allocations[new_table.stream_count];
+ sa->slot_count = dc_alloc->slot_count;
+ sa->vcp_id = dc_alloc->vcp_id;
+ new_table.stream_count++;
+ }
}
/* Overwrite the old table */
@@ -185,7 +212,7 @@ bool dm_helpers_dp_mst_write_payload_allocation_table(
* AUX message. The sequence is slot 1-63 allocated
Bug#1028451: 2nd DisplayPort doesn't get video
There is the patchset currently asked for inclusion at https://lore.kernel.org/stable/20230119235200.441386-1-harry.wentl...@amd.com/T/#m3b5b3616eac750cfd7c9bd00ac1cf95006a6aeec which is for addressing this issue. Regards, Salvatore
Bug#1028451: 2nd DisplayPort doesn't get video
Package: src:linux Version: 6.1.4-1 Followup-For: Bug #1028451 X-Debbugs-Cc: v.abr...@mittwald.de Dear Maintainer, I've the same issue on my ThinkPad X14 with amdgpu. I've two externel display that work fine with kernel version 6.0.12-1. After upgrading to version 6.1.4-1, the two external displays remain black. I can see both external displays in Gnome-Control-Center but I can't use them. Thank you for your graceful work Regards Viktor Abrams -- Package-specific info: ** Version: Linux version 6.1.0-1-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 12.2.0-13) 12.2.0, GNU ld (GNU Binutils for Debian) 2.39.90.20221231) #1 SMP PREEMPT_DYNAMIC Debian 6.1.4-1 (2023-01-07) ** Command line: BOOT_IMAGE=/vmlinuz-6.1.0-1-amd64 root=/dev/mapper/default-root ro quiet ** Tainted: W (512) * kernel issued warning ** Kernel log: [ 939.012765] [Hardware Error]: CPU:0 (19:44:1) MC17_STATUS[Over|CE|MiscV|AddrV|-|-|SyndV|CECC|-|-|-]: 0xdc20400c011b [ 939.012772] [Hardware Error]: Error Addr: 0xfdeb1640 [ 939.012774] [Hardware Error]: IPID: 0x009600250f00, Syndrome: 0x01ff0a240701 [ 939.012776] [Hardware Error]: Unified Memory Controller Ext. Error Code: 12 [ 939.012778] [Hardware Error]: cache level: L3/GEN, tx: GEN, mem-tx: RD [ 939.012782] [Hardware Error]: Corrected error, no action required. [ 939.012783] [Hardware Error]: CPU:0 (19:44:1) MC18_STATUS[Over|CE|MiscV|AddrV|-|-|SyndV|CECC|-|-|-]: 0xdc20400c011b [ 939.012790] [Hardware Error]: Error Addr: 0xfdeb16c0 [ 939.012792] [Hardware Error]: IPID: 0x009600350f00, Syndrome: 0x01ff0a240701 [ 939.012795] [Hardware Error]: Unified Memory Controller Ext. Error Code: 12 [ 939.012796] [Hardware Error]: cache level: L3/GEN, tx: GEN, mem-tx: RD [ 970.456007] audit: type=1400 audit(1674225510.834:203): apparmor="DENIED" operation="open" profile="/usr/sbin/cups-browsed" name="/proc/sys/net/ipv6/conf/all/disable_ipv6" pid=3344 comm="cups-browsed" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 [ 970.457820] audit: type=1400 audit(1674225510.838:204): apparmor="DENIED" operation="open" profile="/usr/sbin/cups-browsed" name="/proc/sys/net/ipv6/conf/all/disable_ipv6" pid=3344 comm="cups-browsed" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 [ 970.458957] audit: type=1400 audit(1674225510.838:205): apparmor="DENIED" operation="open" profile="/usr/sbin/cups-browsed" name="/proc/sys/net/ipv6/conf/all/disable_ipv6" pid=3344 comm="cups-browsed" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 [ 970.460339] audit: type=1400 audit(1674225510.838:206): apparmor="DENIED" operation="open" profile="/usr/sbin/cups-browsed" name="/proc/sys/net/ipv6/conf/all/disable_ipv6" pid=3344 comm="cups-browsed" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 [ 973.632352] audit: type=1400 audit(1674225514.010:207): apparmor="DENIED" operation="open" profile="/usr/sbin/cups-browsed" name="/proc/sys/net/ipv6/conf/all/disable_ipv6" pid=3344 comm="cups-browsed" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 [ 973.633587] audit: type=1400 audit(1674225514.014:208): apparmor="DENIED" operation="open" profile="/usr/sbin/cups-browsed" name="/proc/sys/net/ipv6/conf/all/disable_ipv6" pid=3344 comm="cups-browsed" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 [ 973.634851] audit: type=1400 audit(1674225514.014:209): apparmor="DENIED" operation="open" profile="/usr/sbin/cups-browsed" name="/proc/sys/net/ipv6/conf/all/disable_ipv6" pid=3344 comm="cups-browsed" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 [ 973.635882] audit: type=1400 audit(1674225514.014:210): apparmor="DENIED" operation="open" profile="/usr/sbin/cups-browsed" name="/proc/sys/net/ipv6/conf/all/disable_ipv6" pid=3344 comm="cups-browsed" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 [ 1250.308622] mce_notify_irq: 2 callbacks suppressed [ 1250.308630] mce: [Hardware Error]: Machine check events logged [ 1250.308636] [Hardware Error]: Corrected error, no action required. [ 1250.308641] [Hardware Error]: CPU:0 (19:44:1) MC15_STATUS[Over|CE|MiscV|AddrV|-|-|SyndV|CECC|-|-|-]: 0xdc20400c011b [ 1250.308655] [Hardware Error]: Error Addr: 0xefcfe240 [ 1250.308657] [Hardware Error]: IPID: 0x009600050f00, Syndrome: 0x01ff0a240701 [ 1250.308662] [Hardware Error]: Unified Memory Controller Ext. Error Code: 12 [ 1250.308665] [Hardware Error]: cache level: L3/GEN, tx: GEN, mem-tx: RD [ 1250.308672] mce: [Hardware Error]: Machine check events logged [ 1250.308673] [Hardware Error]: Corrected error, no action required. [ 1250.308675] [Hardware Error]: CPU:0 (19:44:1) MC16_STATUS[Over|CE|MiscV|AddrV|-|-|SyndV|CECC|-|-|-]: 0xdc20400c011b [ 1250.308686] [Hardware Error]: Error Addr: 0xfaa80040 [ 1250.308688] [Hardware Error]: IPID: 0x009600150f00, Syndrome: 0x01ff0a240701 [ 1250.308691] [Hardware Error]: Unified Memory Controller Ext. Error Code: 12 [ 1250.308693] [Hardware Error]: cache level: L3/GEN,
Bug#1028451: 2nd DisplayPort doesn't get video
Hi, On 17-01-2023 07:14, Salvatore Bonaccorso wrote: I will bite the bullet (taking full responsibility for it if necessary, don't blame the other kernel team members) and ask here now the release team: Can we let linux 6.1.4-1 despite the RC bug reported, migrate to testing, so we can move on to 6.1.y? I have added the hints. linux should migrate in the 22:00 UTC britney run. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1028451: 2nd DisplayPort doesn't get video
Hello Salvatore, 17 janvier 2023 07:14 "Salvatore Bonaccorso" a écrit: > I will bite the bullet (taking full responsibility for it if > necessary, don't blame the other kernel team members) and ask here now > the release team: Can we let linux 6.1.4-1 despite the RC bug > reported, migrate to testing, so we can move on to 6.1.y? Let's keep > the bug as RC severity. I'm currently working on uploading as well > 6.1.6 or 6.1.7 (depending on the timing) further after that to > unstable. Unfortuantely there is still not a solution to address > #1028451 but will contain other important fixes (including security > ones). > > Thank you for considering it, > > Odyx, I feel sorry, this will knowingly impact your and others! No problem; such is the life on the unstable/testing edge. I'll keep a 6.0.0-6 kernel around, and will keep testing the most recent kernels; as well as report back if these help. Best, OdyX
Bug#1028451: 2nd DisplayPort doesn't get video
Package: src:linux Version: 6.1.4-1 Followup-For: Bug #1028451 X-Debbugs-Cc: vent...@debian.org Dear Maintainer, I can confirm this bug on my Lenovo T14s with integrated AMD graphics. I have two monitors connected via docking station. One Display Port the other one via HDMI, since 6.1 only one of them shows active already after starting the boot process. Via Gnome's system settings, I can see that both monitors are there, I can however only ever activate one of them (if that makes sense). That is maybe the new bit of information from the original bugreport as that not only the 2nd DP is affected but the HDMI as well. On <= 6.0 this was never an issue. Please note that I'm currently running 6.0 in order to use both monitors. Cheers, Bastian -- Package-specific info: ** Kernel log: boot messages should be attached ** Model information sys_vendor: LENOVO product_name: 20UHS0G000 product_version: ThinkPad T14s Gen 1 chassis_vendor: LENOVO chassis_version: None bios_vendor: LENOVO bios_version: R1CET73W(1.42 ) board_vendor: LENOVO board_name: 20UHS0G000 board_version: SDK0J40697 WIN ** PCI devices: 00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Renoir/Cezanne Root Complex [1022:1630] Subsystem: Lenovo Renoir/Cezanne Root Complex [17aa:5082] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- 00:01.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Renoir PCIe Dummy Host Bridge [1022:1632] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport 00:02.2 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Renoir/Cezanne PCIe GPP Bridge [1022:1634] (prog-if 00 [Normal decode]) Subsystem: Lenovo Renoir/Cezanne PCIe GPP Bridge [17aa:5082] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport 00:02.3 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Renoir/Cezanne PCIe GPP Bridge [1022:1634] (prog-if 00 [Normal decode]) Subsystem: Lenovo Renoir/Cezanne PCIe GPP Bridge [17aa:5082] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport 00:02.4 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Renoir/Cezanne PCIe GPP Bridge [1022:1634] (prog-if 00 [Normal decode]) Subsystem: Lenovo Renoir/Cezanne PCIe GPP Bridge [17aa:5082] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport 00:02.7 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Renoir/Cezanne PCIe GPP Bridge [1022:1634] (prog-if 00 [Normal decode]) Subsystem: Lenovo Renoir/Cezanne PCIe GPP Bridge [17aa:5082] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport 00:08.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Renoir PCIe Dummy Host Bridge [1022:1632] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport 00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller [1022:790b] (rev 51) Subsystem: Lenovo FCH SMBus Controller [17aa:5082] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort-
Bug#1028451: 2nd DisplayPort doesn't get video
Hi, Thanks all who have contributed to the descussion! Much appreciated. On Mon, Jan 16, 2023 at 03:08:22PM -0700, Sam Hartman wrote: > > "Moritz" == Moritz Mühlenhoff writes: > Moritz> Not moving to 6.1.x (which is most likely the next Linux > Moritz> kernel LTS) is by far a worse regression since it applies to > Moritz> every single Debian system. > > Moritz> As a community distro without paid, full time kernel > Moritz> maintainers we can't just randomly stick to an older kernel > Moritz> tree and decide to assess/backport hundreds of patches sent > Moritz> to stable@ every week. > > I think we're all agreed on that point. > What we can do is delay the release if we have a serious enough bug that > is not fixed yet. > I think what people are saying on this bug is that this issue is serious > enough it should be considered as a release blocker---something that > could actually delay the release. I do agree, this is defintively an issue we would not would want to have in a stable release, so the assessment of marking it RC is defintively right. While 6.0.y is now EOL, and 6.1 was aimed to be the LTS release, and the reason we would like to pick that for bookworm, there was not yet an official announce for it, in part because of reported regressions, cf. https://lore.kernel.org/all/y53bputyk+3dj...@kroah.com/ and https://lore.kernel.org/all/20230114084719.ga6...@1wt.eu/ for some context. > From where I sit, thinking about what I've deployed in the last five > years, I agree with that analysis: this *might* be serious enough to > delay the release until there is a fix. > Given that we can't stick on 6.0, I think we should try to get this > into testing as soon as possible so we can see how big of an impact it > is in practice. > I don't like to see testing broken, but I like to see stable broken in > serious ways even less. > And so I'd recommend we see how badly this is going to hurt us. I will bite the bullet (taking full responsibility for it if necessary, don't blame the other kernel team members) and ask here now the release team: Can we let linux 6.1.4-1 despite the RC bug reported, migrate to testing, so we can move on to 6.1.y? Let's keep the bug as RC severity. I'm currently working on uploading as well 6.1.6 or 6.1.7 (depending on the timing) further after that to unstable. Unfortuantely there is still not a solution to address #1028451 but will contain other important fixes (including security ones). Thank you for considering it, Odyx, I feel sorry, this will knowingly impact your and others! Regards, Salvatore
Bug#1028451: 2nd DisplayPort doesn't get video
> "Moritz" == Moritz Mühlenhoff writes: Moritz> Not moving to 6.1.x (which is most likely the next Linux Moritz> kernel LTS) is by far a worse regression since it applies to Moritz> every single Debian system. Moritz> As a community distro without paid, full time kernel Moritz> maintainers we can't just randomly stick to an older kernel Moritz> tree and decide to assess/backport hundreds of patches sent Moritz> to stable@ every week. I think we're all agreed on that point. What we can do is delay the release if we have a serious enough bug that is not fixed yet. I think what people are saying on this bug is that this issue is serious enough it should be considered as a release blocker---something that could actually delay the release. From where I sit, thinking about what I've deployed in the last five years, I agree with that analysis: this *might* be serious enough to delay the release until there is a fix. Given that we can't stick on 6.0, I think we should try to get this into testing as soon as possible so we can see how big of an impact it is in practice. I don't like to see testing broken, but I like to see stable broken in serious ways even less. And so I'd recommend we see how badly this is going to hurt us. signature.asc Description: PGP signature
Bug#1028451: 2nd DisplayPort doesn't get video
Am Mon, Jan 16, 2023 at 12:46:37PM + schrieb Didier 'OdyX' Raboud: > > I understand that would be annoying for you, but I don't think that it would > > affect the majority of our users. > > Hrm. More and more laptops come with usb-c only, and dongles/docks become more > and more common. > > It's clearly a serious regression, as such setups "just worked" with 6.0. Not moving to 6.1.x (which is most likely the next Linux kernel LTS) is by far a worse regression since it applies to every single Debian system. As a community distro without paid, full time kernel maintainers we can't just randomly stick to an older kernel tree and decide to assess/backport hundreds of patches sent to stable@ every week. Cheers, Moritz
Bug#1028451: 2nd DisplayPort doesn't get video
Hello there, I finally managed to test https://github.com/archlinux/linux/commit/7c4fed4d2afd27d7acb8835f8e79f49c99c03cdf.patch (which is a revert of 4d07b0bc403403438d9cf88450506240c5faf92f) … on top of 6.1.4-1. I can confirm (without looking into any code-related details), that the two of my DisplayPort-connected screens light up and work correctly. (The "first" external screen is connected with a DisplayPort-DVI converter; that one always worked; the "second" is connected directly via DisplayPort, which didn't work on unpatched 6.1.4) 14 janvier 2023 17:52 "Diederik de Haas" a écrit: > On Saturday, 14 January 2023 16:30:05 CET Salvatore Bonaccorso wrote: >> On Thu, Jan 12, 2023 at 02:51:05PM +0100, Diederik de Haas wrote: >> On Thursday, 12 January 2023 12:03:24 CET Sjoerd Simons wrote: >>> Fwiw there is a general regression with AMDGPU MST on linux 6.1; tracked >>> >>> upstream here: >>> https://gitlab.freedesktop.org/drm/amd/-/issues/2171 >> >> Thanks! About an hour ago the suggested fix was to revert commit >> 4d07b0bc403403438d9cf88450506240c5faf92f part of v6.1-rc1 >> >> https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html# >> s4.2.2 describes a procedure to build a kernel with the proposed patch >> (attached). >> >> OdyX: Can you try to see whether that resolves the issue? >> >> Should we keep 6.1.y based kernel out of testing until this is clear? >> As we aim though to have 6.1.y into bookworm I would see it as more >> preferable to get 6.1.4 in for testing, we will need to followup as >> well soonish with another interation for e.g. for fixing >> CVE-2023-0266. > > As CVE-2023-0266 is fixed in 6.1.6, I'd suggest to upload that now, which I > believe is ready to be uploaded already. > That should keep 6.1.y out of testing for a few more days. > >> Now if it turns out that this is the same issue as the referenced >> upstream, reverting I think we only should really revert the commit if >> that's queued up for 6.1. There is currently some furhter discussion >> on >> https://lore.kernel.org/stable/dcf0612f-7d40-d607-e9aa-94599594e...@amd.com >> /T/#m38bdafb9c6c64b167ec94ac1bd131f1d2db66e40 >> >> Given the size of the revert, there is as well a chance to re-break >> other parts. So preferring to closely follow upstream here, whatever >> the decision will be. > > Agreed. > > I asked 'OdyX' to test the revert to make sure it would indeed fix *this* > issue, IOW what I consider standard bug triaging. > > But even Daniel Vetter has SERIOUS 'issues' with the revert, next to the other > people who weren't happy about it. So *I* wouldn't suggest applying it to > Debian (although I don't think my opinion should have much weight). > > As for letting this bug _continue_ to prevent a migration, ie keep the RC > status, I'm against it and for downgrading it to 'important'. > You could opt to add a NEWS item to warn people about this potential issue. > > But the original report is about the *2nd* DisplayPort being 'broken'. > > On zaterdag 14 januari 2023 17:04:52 CET you wrote: > >> Basically this issue breaks all usage of Displayport MST on amdgpu systems. >> Which roughly translates to breaking external monitors for everyone using >> an USB-C docks with multiple display outputs (which is pretty common these >> days) on AMD laptops. As well as those like myself who daisy-chain display >> port monitors with an amdgpu using graphics card. > > I understand that would be annoying for you, but I don't think that it would > affect the majority of our users. Hrm. More and more laptops come with usb-c only, and dongles/docks become more and more common. It's clearly a serious regression, as such setups "just worked" with 6.0. Best, OdyX
Bug#1028451: 2nd DisplayPort doesn't get video
On Saturday, 14 January 2023 16:30:05 CET Salvatore Bonaccorso wrote: > On Thu, Jan 12, 2023 at 02:51:05PM +0100, Diederik de Haas wrote: > > On Thursday, 12 January 2023 12:03:24 CET Sjoerd Simons wrote: > > > Fwiw there is a general regression with AMDGPU MST on linux 6.1; tracked > > > > > > upstream here: > > > https://gitlab.freedesktop.org/drm/amd/-/issues/2171 > > > > Thanks! About an hour ago the suggested fix was to revert commit > > 4d07b0bc403403438d9cf88450506240c5faf92f part of v6.1-rc1 > > > > https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html# > > s4.2.2 describes a procedure to build a kernel with the proposed patch > > (attached). > > > > OdyX: Can you try to see whether that resolves the issue? > > Should we keep 6.1.y based kernel out of testing until this is clear? > As we aim though to have 6.1.y into bookworm I would see it as more > preferable to get 6.1.4 in for testing, we will need to followup as > well soonish with another interation for e.g. for fixing > CVE-2023-0266. As CVE-2023-0266 is fixed in 6.1.6, I'd suggest to upload that now, which I believe is ready to be uploaded already. That should keep 6.1.y out of testing for a few more days. > Now if it turns out that this is the same issue as the referenced > upstream, reverting I think we only should really revert the commit if > that's queued up for 6.1. There is currently some furhter discussion > on > https://lore.kernel.org/stable/dcf0612f-7d40-d607-e9aa-94599594e...@amd.com > /T/#m38bdafb9c6c64b167ec94ac1bd131f1d2db66e40 > > Given the size of the revert, there is as well a chance to re-break > other parts. So preferring to closely follow upstream here, whatever > the decision will be. Agreed. I asked 'OdyX' to test the revert to make sure it would indeed fix *this* issue, IOW what I consider standard bug triaging. But even Daniel Vetter has SERIOUS 'issues' with the revert, next to the other people who weren't happy about it. So *I* wouldn't suggest applying it to Debian (although I don't think my opinion should have much weight). As for letting this bug _continue_ to prevent a migration, ie keep the RC status, I'm against it and for downgrading it to 'important'. You could opt to add a NEWS item to warn people about this potential issue. But the original report is about the *2nd* DisplayPort being 'broken'. On zaterdag 14 januari 2023 17:04:52 CET you wrote: > Basically this issue breaks all usage of Displayport MST on amdgpu systems. > Which roughly translates to breaking external monitors for everyone using > an USB-C docks with multiple display outputs (which is pretty common these > days) on AMD laptops. As well as those like myself who daisy-chain display > port monitors with an amdgpu using graphics card. I understand that would be annoying for you, but I don't think that it would affect the majority of our users. On 2023-01-13 10:25 Daniel Vetter wrote (in that thread): > Like yes it's a regression, but apparently not a blantantly obvious one The revert may cause much wider issues which upstream may or may not care (much) about. And it would be a divergence from upstream. Getting wider testing of the 6.1 kernel is something I find much more important. There could be other issues lurking which would not get exposure and therefor wouldn't get fixed until this bug would be fixed. Uploading 6.1.6 now would give (us/)upstream a couple of more days to figure out a potential *better* way to deal with it. One which should be acceptable for the upstream Stable Kernel maintainers. But I wouldn't let this bug cause further delays to Testing. Testing is meant to test things for the next Stable release and things can and will break from time to time. If people can't deal with that, they should not be running Testing. My 0.02 signature.asc Description: This is a digitally signed message part.
Bug#1028451: 2nd DisplayPort doesn't get video
Hey, On Sat, 2023-01-14 at 16:30 +0100, Salvatore Bonaccorso wrote: > Hi, > > On Thu, Jan 12, 2023 at 02:51:05PM +0100, Diederik de Haas wrote: > > On Thursday, 12 January 2023 12:03:24 CET Sjoerd Simons wrote: > > > Fwiw there is a general regression with AMDGPU MST on linux 6.1; tracked > > > upstream here: > > > https://gitlab.freedesktop.org/drm/amd/-/issues/2171 > > > > Thanks! About an hour ago the suggested fix was to revert commit > > 4d07b0bc403403438d9cf88450506240c5faf92f part of v6.1-rc1 > > > > https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s4.2.2 > > describes a procedure to build a kernel with the proposed patch (attached). > > > > OdyX: Can you try to see whether that resolves the issue? > > Should we keep 6.1.y based kernel out of testing until this is clear? Basically this issue breaks all usage of Displayport MST on amdgpu systems. Which roughly translates to breaking external monitors for everyone using an USB-C docks with multiple display outputs (which is pretty common these days) on AMD laptops. As well as those like myself who daisy-chain display port monitors with an amdgpu using graphics card. So I would expect this impacts a lot of people :/ Which is also why there is loads of activity and duplicates on the fd.o bug now that 6.1 is trickling into distributions. > As we aim though to have 6.1.y into bookworm I would see it as more > preferable to get 6.1.4 in for testing, we will need to followup as > well soonish with another interation for e.g. for fixing > CVE-2023-0266. > > Now if it turns out that this is the same issue as the referenced > upstream, reverting I think we only should really revert the commit if > that's queued up for 6.1. There is currently some furhter discussion > on > https://lore.kernel.org/stable/dcf0612f-7d40-d607-e9aa-94599594e...@amd.com/T/#m38bdafb9c6c64b167ec94ac1bd131f1d2db66e4 > Given the size of the revert, there is as well a chance to re-break > other parts. So preferring to closely follow upstream here, whatever > the decision will be. For what it's worth; The revert as currently suggested also reverts big chunks for Intel and nvidia based GPUs, which unsurprisingly the maintainers of those aren't too thrilled about. And really i'd be amazed if it doesn't cause regressions for those systems... Unless the AMD folks pull a small/targetted fix out their hats, this is likely going to take weeks if not months before it's resolved in a way that's acceptable for 6.1.y :/ -- Sjoerd Simons
Bug#1028451: 2nd DisplayPort doesn't get video
Hi, On Thu, Jan 12, 2023 at 02:51:05PM +0100, Diederik de Haas wrote: > On Thursday, 12 January 2023 12:03:24 CET Sjoerd Simons wrote: > > Fwiw there is a general regression with AMDGPU MST on linux 6.1; tracked > > upstream here: > > https://gitlab.freedesktop.org/drm/amd/-/issues/2171 > > Thanks! About an hour ago the suggested fix was to revert commit > 4d07b0bc403403438d9cf88450506240c5faf92f part of v6.1-rc1 > > https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s4.2.2 > describes a procedure to build a kernel with the proposed patch (attached). > > OdyX: Can you try to see whether that resolves the issue? Should we keep 6.1.y based kernel out of testing until this is clear? As we aim though to have 6.1.y into bookworm I would see it as more preferable to get 6.1.4 in for testing, we will need to followup as well soonish with another interation for e.g. for fixing CVE-2023-0266. Now if it turns out that this is the same issue as the referenced upstream, reverting I think we only should really revert the commit if that's queued up for 6.1. There is currently some furhter discussion on https://lore.kernel.org/stable/dcf0612f-7d40-d607-e9aa-94599594e...@amd.com/T/#m38bdafb9c6c64b167ec94ac1bd131f1d2db66e40 Given the size of the revert, there is as well a chance to re-break other parts. So preferring to closely follow upstream here, whatever the decision will be. Regards, Salvatore
Bug#1028451: 2nd DisplayPort doesn't get video
On Thursday, 12 January 2023 12:03:24 CET Sjoerd Simons wrote:
> Fwiw there is a general regression with AMDGPU MST on linux 6.1; tracked
> upstream here:
> https://gitlab.freedesktop.org/drm/amd/-/issues/2171
Thanks! About an hour ago the suggested fix was to revert commit
4d07b0bc403403438d9cf88450506240c5faf92f part of v6.1-rc1
https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s4.2.2
describes a procedure to build a kernel with the proposed patch (attached).
OdyX: Can you try to see whether that resolves the issue?diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 77277d90b6e2..674f5dc1102b 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6548,7 +6548,6 @@ static int dm_encoder_helper_atomic_check(struct drm_encoder *encoder,
const struct drm_display_mode *adjusted_mode = _state->adjusted_mode;
struct drm_dp_mst_topology_mgr *mst_mgr;
struct drm_dp_mst_port *mst_port;
- struct drm_dp_mst_topology_state *mst_state;
enum dc_color_depth color_depth;
int clock, bpp = 0;
bool is_y420 = false;
@@ -6562,13 +6561,6 @@ static int dm_encoder_helper_atomic_check(struct drm_encoder *encoder,
if (!crtc_state->connectors_changed && !crtc_state->mode_changed)
return 0;
- mst_state = drm_atomic_get_mst_topology_state(state, mst_mgr);
- if (IS_ERR(mst_state))
- return PTR_ERR(mst_state);
-
- if (!mst_state->pbn_div)
- mst_state->pbn_div = dm_mst_get_pbn_divider(aconnector->mst_port->dc_link);
-
if (!state->duplicated) {
int max_bpc = conn_state->max_requested_bpc;
is_y420 = drm_mode_is_420_also(>display_info, adjusted_mode) &&
@@ -6580,10 +6572,11 @@ static int dm_encoder_helper_atomic_check(struct drm_encoder *encoder,
clock = adjusted_mode->clock;
dm_new_connector_state->pbn = drm_dp_calc_pbn_mode(clock, bpp, false);
}
-
- dm_new_connector_state->vcpi_slots =
- drm_dp_atomic_find_time_slots(state, mst_mgr, mst_port,
- dm_new_connector_state->pbn);
+ dm_new_connector_state->vcpi_slots = drm_dp_atomic_find_time_slots(state,
+ mst_mgr,
+ mst_port,
+ dm_new_connector_state->pbn,
+ dm_mst_get_pbn_divider(aconnector->dc_link));
if (dm_new_connector_state->vcpi_slots < 0) {
DRM_DEBUG_ATOMIC("failed finding vcpi slots: %d\n", (int)dm_new_connector_state->vcpi_slots);
return dm_new_connector_state->vcpi_slots;
@@ -6654,14 +6647,17 @@ static int dm_update_mst_vcpi_slots_for_dsc(struct drm_atomic_state *state,
dm_conn_state->vcpi_slots = slot_num;
ret = drm_dp_mst_atomic_enable_dsc(state, aconnector->port,
- dm_conn_state->pbn, false);
+ dm_conn_state->pbn, 0, false);
if (ret < 0)
return ret;
continue;
}
- vcpi = drm_dp_mst_atomic_enable_dsc(state, aconnector->port, pbn, true);
+ vcpi = drm_dp_mst_atomic_enable_dsc(state,
+ aconnector->port,
+ pbn, pbn_div,
+ true);
if (vcpi < 0)
return vcpi;
@@ -9497,6 +9493,8 @@ static int amdgpu_dm_atomic_check(struct drm_device *dev,
struct dm_crtc_state *dm_old_crtc_state, *dm_new_crtc_state;
#if defined(CONFIG_DRM_AMD_DC_DCN)
struct dsc_mst_fairness_vars vars[MAX_PIPES];
+ struct drm_dp_mst_topology_state *mst_state;
+ struct drm_dp_mst_topology_mgr *mgr;
#endif
trace_amdgpu_dm_atomic_check_begin(state);
@@ -9744,6 +9742,33 @@ static int amdgpu_dm_atomic_check(struct drm_device *dev,
lock_and_validation_needed = true;
}
+#if defined(CONFIG_DRM_AMD_DC_DCN)
+ /* set the slot info for each mst_state based on the link encoding format */
+ for_each_new_mst_mgr_in_state(state, mgr, mst_state, i) {
+ struct amdgpu_dm_connector *aconnector;
+ struct drm_connector *connector;
+ struct drm_connector_list_iter iter;
+ u8 link_coding_cap;
+
+ if (!mgr->mst_state )
+ continue;
+
+ drm_connector_list_iter_begin(dev, );
+ drm_for_each_connector_iter(connector, ) {
+ int id = connector->index;
+
+ if (id == mst_state->mgr->conn_base_id) {
+aconnector = to_amdgpu_dm_connector(connector);
+link_coding_cap = dc_link_dp_mst_decide_link_encoding_format(aconnector->dc_link);
+drm_dp_mst_update_slots(mst_state, link_coding_cap);
+
+break;
+ }
+ }
+ drm_connector_list_iter_end();
+
+ }
+#endif
/**
* Streams and planes are reset when there are changes that affect
* bandwidth. Anything that affects bandwidth needs to go through
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
index 6994c9a1ed85..ac5a8cad0695 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
@@ -27,7 +27,6 @@
#include
#include
-#include
#include
#include
#include
@@ -120,27 +119,40 @@ enum dc_edid_status dm_helpers_parse_edid_caps(
}
static void
Bug#1028451: 2nd DisplayPort doesn't get video
Source: linux Followup-For: Bug #1028451 Fwiw there is a general regression with AMDGPU MST on linux 6.1; tracked upstream here: https://gitlab.freedesktop.org/drm/amd/-/issues/2171 As the original report was about a second displayport on a docking station I would guess it's the same issue. For reference i'm hit by the same issue due to using MST for daisy-chaining monitors. -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'oldstable-proposed-updates'), (500, 'oldstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: armhf, arm64 Kernel: Linux 6.0.0-6-amd64 (SMP w/32 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1028451: 2nd DisplayPort doesn't get video
Hello there, It's really time-consuming to download, reboot, wait cryptsetup prompt, fail, reboot, wait cryptsetup prompt, type long passphrase, log in account, dpkg -i, reboot, rinse repeat. Anyway, I can confirm that on my Lenovo X13 AMD; * 6.1~rc3+1~exp1 doesn't boot until the cryptsetup prompt * 6.1~rc5+1~exp1 doesn't boot until the cryptsetup prompt * 6.1~rc6+1~exp1 doesn't boot until the cryptsetup prompt * 6.1~rc7+1~exp1 boots until the cryptsetup prompt, but the culprit screen doesn't get anything So it seems the issue was already there in 6.1~rc7+1~exp1, but I can't rewind further. Hope that helps! OdyX 11 janvier 2023 10:04 "Diederik de Haas" a écrit: > On Wednesday, 11 January 2023 08:33:29 CET Didier 'OdyX' Raboud wrote: > >> Package: src:linux >> Version: 6.1.4-1 >> Severity: serious >> >> Since booting 6.1.0-1, the 2nd DisplayPort output from my Lenovo Docking >> Station doesn't get any output. > > Can you try the previous versions of the 6.1.x series which you can get via > snapshot.debian.org? I recommend to start with the first 6.1-rcX version. > > A `git bisect` is the best way to figure out what caused it, but the above > procedure is the quickest way to narrow down the search space.
Bug#1028451: 2nd DisplayPort doesn't get video
On Wednesday, 11 January 2023 08:33:29 CET Didier 'OdyX' Raboud wrote: > Package: src:linux > Version: 6.1.4-1 > Severity: serious > > Since booting 6.1.0-1, the 2nd DisplayPort output from my Lenovo Docking > Station doesn't get any output. Can you try the previous versions of the 6.1.x series which you can get via snapshot.debian.org? I recommend to start with the first 6.1-rcX version. A `git bisect` is the best way to figure out what caused it, but the above procedure is the quickest way to narrow down the search space. signature.asc Description: This is a digitally signed message part.
Bug#1028451: 2nd DisplayPort doesn't get video
Package: src:linux Version: 6.1.4-1 Severity: serious Hello there, Since booting 6.1.0-1, the 2nd DisplayPort output from my Lenovo Docking Station doesn't get any output. It is _seen_ as connected by the screen, but apparently gets no video signal (or just blank). This is clearly a regression from 6.0.0-6 where this was working. I'm quite confident this is a kernel-level change (and not X11 or Plasma) as this already appears clearly at cryptsetup password prompt (which usually goes to all outputs, but not on 6.1.0-1 which only displays it on the laptop screen and the 1st connected DisplayPort. Happy to help solve this. Best, OdyX -- Package-specific info: ** Version: Linux version 6.1.0-1-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 12.2.0-13) 12.2.0, GNU ld (GNU Binutils for Debian) 2.39.90.20221231) #1 SMP PREEMPT_DYNAMIC Debian 6.1.4-1 (2023-01-07) ** Command line: BOOT_IMAGE=/vmlinuz-6.1.0-1-amd64 root=/dev/mapper/turnagra--vg-root ro quiet splash cgroup_enable=memory apparmor=1 security=apparmor ** Tainted: W (512) * kernel issued warning ** Kernel log: [ 15.343546] input: HD-Audio Generic Headphone as /devices/pci:00/:00:08.1/:05:00.6/sound/card4/input38 [ 15.443246] usbcore: registered new interface driver btusb [ 15.481320] bluetooth hci0: firmware: direct-loading firmware mediatek/BT_RAM_CODE_MT7961_1_2_hdr.bin [ 15.493335] intel_rapl_common: Found RAPL domain package [ 15.493340] intel_rapl_common: Found RAPL domain core [ 15.499969] mt7921e :03:00.0: enabling device ( -> 0002) [ 15.518411] mt7921e :03:00.0: ASIC revision: 79610010 [ 15.602835] mt7921e :03:00.0: firmware: direct-loading firmware mediatek/WIFI_MT7961_patch_mcu_1_2_hdr.bin [ 15.602842] mt7921e :03:00.0: HW/SW Version: 0x8a108a10, Build Time: 20221109110918a [ 15.603213] Bluetooth: hci0: Device setup in 121459 usecs [ 15.603217] Bluetooth: hci0: HCI Enhanced Setup Synchronous Connection command is advertised, but not supported. [ 15.614235] mt7921e :03:00.0: firmware: direct-loading firmware mediatek/WIFI_RAM_CODE_MT7961_1.bin [ 15.614240] mt7921e :03:00.0: WM Firmware Version: 01, Build Time: 20221109111005 [ 15.654966] mt7921e :03:00.0: firmware: direct-loading firmware mediatek/WIFI_RAM_CODE_MT7961_1.bin [ 15.676225] EXT4-fs (nvme0n1p2): mounting ext2 file system using the ext4 subsystem [ 15.677063] EXT4-fs (nvme0n1p2): mounted filesystem without journal. Quota mode: none. [ 15.679393] EXT4-fs (dm-4): mounted filesystem with ordered data mode. Quota mode: none. [ 15.679984] EXT4-fs (dm-2): mounted filesystem with ordered data mode. Quota mode: none. [ 15.689038] systemd-journald[673]: Received client request to flush runtime journal. [ 15.692904] systemd-journald[673]: File /var/log/journal/554675a9a7254eeea535d3d6aa31a8a6/system.journal corrupted or uncleanly shut down, renaming and replacing. [ 15.849074] audit: type=1400 audit(1673421894.663:4): apparmor="STATUS" operation="profile_load" profile="unconfined" name="libreoffice-senddoc" pid=980 comm="apparmor_parser" [ 15.849408] audit: type=1400 audit(1673421894.663:5): apparmor="STATUS" operation="profile_load" profile="unconfined" name="lsb_release" pid=966 comm="apparmor_parser" [ 15.849475] audit: type=1400 audit(1673421894.663:6): apparmor="STATUS" operation="profile_load" profile="unconfined" name="libreoffice-oosplash" pid=979 comm="apparmor_parser" [ 15.849517] audit: type=1400 audit(1673421894.663:7): apparmor="STATUS" operation="profile_load" profile="unconfined" name="torbrowser_tor" pid=974 comm="apparmor_parser" [ 15.849866] audit: type=1400 audit(1673421894.663:8): apparmor="STATUS" operation="profile_load" profile="unconfined" name="nvidia_modprobe" pid=969 comm="apparmor_parser" [ 15.849871] audit: type=1400 audit(1673421894.663:9): apparmor="STATUS" operation="profile_load" profile="unconfined" name="nvidia_modprobe//kmod" pid=969 comm="apparmor_parser" [ 15.849949] audit: type=1400 audit(1673421894.663:10): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/bin/man" pid=977 comm="apparmor_parser" [ 15.849954] audit: type=1400 audit(1673421894.663:11): apparmor="STATUS" operation="profile_load" profile="unconfined" name="man_filter" pid=977 comm="apparmor_parser" [ 15.849957] audit: type=1400 audit(1673421894.663:12): apparmor="STATUS" operation="profile_load" profile="unconfined" name="man_groff" pid=977 comm="apparmor_parser" [ 15.851055] audit: type=1400 audit(1673421894.667:13): apparmor="STATUS" operation="profile_load" profile="unconfined" name="system_tor" pid=972 comm="apparmor_parser" [ 16.466830] mt7921e :03:00.0 wlp3s0: renamed from wlan0 [ 16.789424] Bluetooth: BNEP (Ethernet Emulation) ver 1.3 [ 16.789428] Bluetooth: BNEP filters: protocol multicast [ 16.789433] Bluetooth: BNEP socket layer initialized [ 16.790811] Bluetooth: MGMT ver 1.22
