Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1203179 > unrolled thread

Bug#1075770: linux-image-6.9.7-amd64: adlp_tc_phy_connect [i915] fills logs with drm_WARN_ON(tc->mode == TC_PORT_LEGACY) call traces

Started by"Francesco Poli (wintermute)" <invernomuto@paranoici.org>
First post2024-07-04 19:40 +0200
Last post2024-07-29 12:40 +0200
Articles 9 — 6 participants

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#1075770: linux-image-6.9.7-amd64: adlp_tc_phy_connect [i915] fills logs with drm_WARN_ON(tc->mode == TC_PORT_LEGACY) call traces "Francesco Poli (wintermute)" <invernomuto@paranoici.org> - 2024-07-04 19:40 +0200
    Bug#1075770: linux-image-6.9.7-amd64: adlp_tc_phy_connect [i915] fills logs with drm_WARN_ON(tc->mode == TC_PORT_LEGACY) call traces Salvatore Bonaccorso <carnil@debian.org> - 2024-07-13 15:10 +0200
      Bug#1075770: linux-image-6.9.7-amd64: adlp_tc_phy_connect [i915] fills logs with drm_WARN_ON(tc->mode == TC_PORT_LEGACY) call traces Francesco Poli <invernomuto@paranoici.org> - 2024-07-13 19:20 +0200
        Bug#1075770: linux-image-6.9.7-amd64: adlp_tc_phy_connect [i915] fills logs with drm_WARN_ON(tc->mode == TC_PORT_LEGACY) call traces Salvatore Bonaccorso <carnil@debian.org> - 2024-07-13 21:00 +0200
          Bug#1075770: linux-image-6.9.7-amd64: adlp_tc_phy_connect [i915] fills logs with drm_WARN_ON(tc->mode == TC_PORT_LEGACY) call traces Francesco Poli <invernomuto@paranoici.org> - 2024-07-15 20:30 +0200
    Bug#1075770: [bug report] adlp_tc_phy_connect [i915] floods logs with drm_WARN_ON(tc->mode == TC_PORT_LEGACY) call traces Jani Nikula <jani.nikula@linux.intel.com> - 2024-07-24 18:20 +0200
    Bug#1075770: [bug report] adlp_tc_phy_connect [i915] floods logs with drm_WARN_ON(tc->mode == TC_PORT_LEGACY) call traces Imre Deak <imre.deak@intel.com> - 2024-07-24 20:40 +0200
      Bug#1075770: [bug report] adlp_tc_phy_connect [i915] floods logs with drm_WARN_ON(tc->mode == TC_PORT_LEGACY) call traces Francesco Poli <invernomuto@paranoici.org> - 2024-07-26 00:10 +0200
        Bug#1075770: [bug report] adlp_tc_phy_connect [i915] floods logs with drm_WARN_ON(tc->mode == TC_PORT_LEGACY) call traces Jani Nikula <jani.nikula@intel.com> - 2024-07-29 12:40 +0200

#1203179 — Bug#1075770: linux-image-6.9.7-amd64: adlp_tc_phy_connect [i915] fills logs with drm_WARN_ON(tc->mode == TC_PORT_LEGACY) call traces

From"Francesco Poli (wintermute)" <invernomuto@paranoici.org>
Date2024-07-04 19:40 +0200
SubjectBug#1075770: linux-image-6.9.7-amd64: adlp_tc_phy_connect [i915] fills logs with drm_WARN_ON(tc->mode == TC_PORT_LEGACY) call traces
Message-ID<IWyB3-7Fyi-3@gated-at.bofh.it>

[Multipart message — attachments visible in raw view] — view raw

Package: src:linux
Version: 6.9.7-1
Severity: normal
X-Debbugs-Cc: invernomuto@paranoici.org

Hello,
on a laptop where I installed Debian testing some 6 months ago,
I noticed that the logs are continuously filled with call traces
like the attached snippet (taken from /var/log/kern.log ).

It seems to me that it also used to happen with previous versions
of the Linux kernel, but I am under the impression that, with linux/6.9.7-1,
it got worse.

I see 12 of these call traces just after boot, before even starting X
(with 'startx').
More of these call traces are sent to the logs after starting X, or
after invoking 'xrandr', or after locking the X session (with
XScreenSaver), ...

They seem to correspond to no actual issue, as far as I can tell,
but they are filling the logs with a significant flow of text...
which is worrying by itself.

What's wrong?
How can I stop this log-filling flood?


-- Package-specific info:
** Version:
Linux version 6.9.7-amd64 (debian-kernel@lists.debian.org) (x86_64-linux-gnu-gcc-13 (Debian 13.3.0-1) 13.3.0, GNU ld (GNU Binutils for Debian) 2.42.50.20240625) #1 SMP PREEMPT_DYNAMIC Debian 6.9.7-1 (2024-06-27)

** Command line:
BOOT_IMAGE=/vmlinuz-6.9.7-amd64 root=/dev/mapper/ol-root ro quiet

** Tainted: W (512)
 * kernel issued warning

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
sys_vendor: Notebook
product_name: NLxxPUx
product_version: Not Applicable
chassis_vendor: No Enclosure
chassis_version: N/A
bios_vendor: INSYDE Corp.
bios_version: 1.07.09
board_vendor: Notebook
board_name: NLxxPUx
board_version: Not Applicable

** Loaded modules:
8021q
garp
stp
mrp
llc
iptable_nat
nf_nat
nf_conntrack
cmac
nf_defrag_ipv6
nf_defrag_ipv4
algif_hash
libcrc32c
algif_skcipher
iptable_mangle
af_alg
snd_hda_codec_hdmi
iptable_filter
bnep
binfmt_misc
nls_ascii
nls_cp437
vfat
snd_sof_pci_intel_tgl
fat
snd_sof_intel_hda_common
soundwire_intel
snd_sof_intel_hda_mlink
soundwire_cadence
snd_sof_intel_hda
snd_sof_pci
snd_sof_xtensa_dsp
snd_sof
snd_sof_utils
snd_soc_hdac_hda
snd_soc_acpi_intel_match
soundwire_generic_allocation
snd_soc_acpi
soundwire_bus
snd_soc_avs
snd_soc_hda_codec
snd_hda_ext_core
btusb
i915
btrtl
snd_soc_core
btintel
btbcm
btmtk
snd_compress
iwlmvm
intel_uncore_frequency
intel_uncore_frequency_common
snd_pcm_dmaengine
bluetooth
x86_pkg_temp_thermal
snd_hda_intel
mac80211
intel_powerclamp
snd_intel_dspcfg
uvcvideo
coretemp
snd_intel_sdw_acpi
snd_usb_audio
processor_thermal_device_pci
videobuf2_vmalloc
kvm_intel
snd_hda_codec
processor_thermal_device
drm_buddy
snd_usbmidi_lib
uvc
processor_thermal_wt_hint
libarc4
sha3_generic
drm_display_helper
snd_hda_core
snd_rawmidi
videobuf2_memops
processor_thermal_rfim
kvm
jitterentropy_rng
snd_hwdep
snd_seq_device
cec
videobuf2_v4l2
iwlwifi
intel_rapl_msr
processor_thermal_rapl
snd_pcm
drbg
rc_core
iTCO_wdt
videodev
intel_rapl_common
rapl
mei_pxp
mei_hdcp
processor_thermal_wt_req
ttm
intel_pmc_bxt
ansi_cprng
snd_timer
cfg80211
jc42
intel_cstate
processor_thermal_power_floor
intel_pmc_core
videobuf2_common
iTCO_vendor_support
drm_kms_helper
mei_me
snd
ecdh_generic
int3403_thermal
processor_thermal_mbox
int3400_thermal
intel_uncore
pmt_telemetry
pcspkr
watchdog
mc
ee1004
i2c_algo_bit
ecc
mei
rfkill
soundcore
intel_vsec
igen6_edac
int340x_thermal_zone
joydev
evdev
acpi_thermal_rel
pmt_class
intel_hid
acpi_pad
sparse_keymap
ac
button
hid_multitouch
serio_raw
efi_pstore
configfs
nfnetlink
efivarfs
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
crc32c_generic
dm_crypt
dm_mod
nvme
nvme_core
usbhid
t10_pi
crc32_pclmul
crc32c_intel
crc64_rocksoft_generic
crc64_rocksoft
hid_generic
ahci
ghash_clmulni_intel
crc_t10dif
sha512_ssse3
xhci_pci
libahci
r8169
crct10dif_generic
i2c_hid_acpi
rtsx_pci_sdmmc
sha512_generic
xhci_hcd
libata
realtek
crct10dif_pclmul
i2c_hid
intel_lpss_pci
mmc_core
sha256_ssse3
mdio_devres
crc64
scsi_mod
i2c_i801
usbcore
intel_lpss
drm
psmouse
sha1_ssse3
libphy
video
rtsx_pci
crct10dif_common
i2c_smbus
scsi_common
idma64
usb_common
battery
hid
wmi
aesni_intel
crypto_simd
cryptd

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Alder Lake-U15 Host and DRAM Controller [8086:4601] (rev 04)
	Subsystem: CLEVO/KAPOK Computer Device [1558:4150]
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR- <PERR- INTx-
	Latency: 0
	IOMMU group: 1
	Capabilities: <access denied>
	Kernel driver in use: igen6_edac
	Kernel modules: igen6_edac

00:02.0 VGA compatible controller [0300]: Intel Corporation Alder Lake-UP3 GT2 [UHD Graphics] [8086:4628] (rev 0c) (prog-if 00 [VGA controller])
	Subsystem: CLEVO/KAPOK Computer Device [1558:4150]
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 159
	IOMMU group: 0
	Region 0: Memory at 6000000000 (64-bit, non-prefetchable) [size=16M]
	Region 2: Memory at 4000000000 (64-bit, prefetchable) [size=256M]
	Region 4: I/O ports at 4000 [size=64]
	Expansion ROM at 000c0000 [virtual] [disabled] [size=128K]
	Capabilities: <access denied>
	Kernel driver in use: i915
	Kernel modules: i915

00:04.0 Signal processing controller [1180]: Intel Corporation Alder Lake Innovation Platform Framework Processor Participant [8086:461d] (rev 04)
	Subsystem: CLEVO/KAPOK Computer Device [1558:4150]
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 16
	IOMMU group: 2
	Region 0: Memory at 6001100000 (64-bit, non-prefetchable) [size=128K]
	Capabilities: <access denied>
	Kernel driver in use: proc_thermal_pci
	Kernel modules: processor_thermal_device_pci

00:06.0 PCI bridge [0604]: Intel Corporation 12th Gen Core Processor PCI Express x4 Controller #0 [8086:464d] (rev 04) (prog-if 00 [Normal decode])
	Subsystem: CLEVO/KAPOK Computer Device [1558:4150]
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin D routed to IRQ 122
	IOMMU group: 3
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
	I/O behind bridge: [disabled] [16-bit]
	Memory behind bridge: 80900000-809fffff [size=1M] [32-bit]
	Prefetchable memory behind bridge: [disabled] [64-bit]
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
	BridgeCtl: Parity- SERR+ NoISA- VGA- VGA16- MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: <access denied>
	Kernel driver in use: pcieport

00:08.0 System peripheral [0880]: Intel Corporation 12th Gen Core Processor Gaussian & Neural Accelerator [8086:464f] (rev 04)
	Subsystem: CLEVO/KAPOK Computer Device [1558:4150]
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 255
	IOMMU group: 4
	Region 0: Memory at 6001139000 (64-bit, non-prefetchable) [size=4K]
	Capabilities: <access denied>

00:0a.0 Signal processing controller [1180]: Intel Corporation Platform Monitoring Technology [8086:467d] (rev 01)
	Subsystem: CLEVO/KAPOK Computer Device [1558:4150]
	Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	IOMMU group: 5
	Region 0: Memory at 6001120000 (64-bit, non-prefetchable) [size=32K]
	Capabilities: <access denied>
	Kernel driver in use: intel_vsec
	Kernel modules: intel_vsec

00:14.0 USB controller [0c03]: Intel Corporation Alder Lake PCH USB 3.2 xHCI Host Controller [8086:51ed] (rev 01) (prog-if 30 [XHCI])
	Subsystem: CLEVO/KAPOK Computer Device [1558:4150]
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 125
	IOMMU group: 6
	Region 0: Memory at 80a00000 (64-bit, non-prefetchable) [size=64K]
	Capabilities: <access denied>
	Kernel driver in use: xhci_hcd
	Kernel modules: xhci_pci

00:14.2 RAM memory [0500]: Intel Corporation Alder Lake PCH Shared SRAM [8086:51ef] (rev 01)
	Subsystem: CLEVO/KAPOK Computer Device [1558:4150]
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	IOMMU group: 6
	Region 0: Memory at 6001130000 (64-bit, non-prefetchable) [size=16K]
	Region 2: Memory at 6001138000 (64-bit, non-prefetchable) [size=4K]
	Capabilities: <access denied>

00:14.3 Network controller [0280]: Intel Corporation Alder Lake-P PCH CNVi WiFi [8086:51f0] (rev 01)
	Subsystem: Intel Corporation Dual Band Wi-Fi 6(802.11ax) AX201 160MHz 2x2 [Harrison Peak] [8086:0074]
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 16
	IOMMU group: 7
	Region 0: Memory at 600112c000 (64-bit, non-prefetchable) [size=16K]
	Capabilities: <access denied>
	Kernel driver in use: iwlwifi
	Kernel modules: iwlwifi

00:15.0 Serial bus controller [0c80]: Intel Corporation Alder Lake PCH Serial IO I2C Controller #0 [8086:51e8] (rev 01)
	Subsystem: CLEVO/KAPOK Computer Device [1558:4150]
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 27
	IOMMU group: 8
	Region 0: Memory at 4017000000 (64-bit, non-prefetchable) [size=4K]
	Capabilities: <access denied>
	Kernel driver in use: intel-lpss
	Kernel modules: intel_lpss_pci

00:15.1 Serial bus controller [0c80]: Intel Corporation Alder Lake PCH Serial IO I2C Controller #1 [8086:51e9] (rev 01)
	Subsystem: CLEVO/KAPOK Computer Device [1558:4150]
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin B routed to IRQ 40
	IOMMU group: 8
	Region 0: Memory at 4017001000 (64-bit, non-prefetchable) [size=4K]
	Capabilities: <access denied>
	Kernel driver in use: intel-lpss
	Kernel modules: intel_lpss_pci

00:16.0 Communication controller [0780]: Intel Corporation Alder Lake PCH HECI Controller [8086:51e0] (rev 01)
	Subsystem: CLEVO/KAPOK Computer Device [1558:4150]
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 144
	IOMMU group: 9
	Region 0: Memory at 6001135000 (64-bit, non-prefetchable) [size=4K]
	Capabilities: <access denied>
	Kernel driver in use: mei_me
	Kernel modules: mei_me

00:17.0 SATA controller [0106]: Intel Corporation Alder Lake-P SATA AHCI Controller [8086:51d3] (rev 01) (prog-if 01 [AHCI 1.0])
	Subsystem: CLEVO/KAPOK Computer Device [1558:4150]
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 134
	IOMMU group: 10
	Region 0: Memory at 80a20000 (32-bit, non-prefetchable) [size=8K]
	Region 1: Memory at 80a24000 (32-bit, non-prefetchable) [size=256]
	Region 2: I/O ports at 4080 [size=8]
	Region 3: I/O ports at 4088 [size=4]
	Region 4: I/O ports at 4060 [size=32]
	Region 5: Memory at 80a23000 (32-bit, non-prefetchable) [size=2K]
	Capabilities: <access denied>
	Kernel driver in use: ahci
	Kernel modules: ahci

00:1d.0 PCI bridge [0604]: Intel Corporation Alder Lake PCI Express Root Port #9 [8086:51b0] (rev 01) (prog-if 00 [Normal decode])
	Subsystem: CLEVO/KAPOK Computer Device [1558:4150]
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 123
	IOMMU group: 11
	Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
	I/O behind bridge: 3000-3fff [size=4K] [16-bit]
	Memory behind bridge: 80800000-808fffff [size=1M] [32-bit]
	Prefetchable memory behind bridge: [disabled] [64-bit]
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
	BridgeCtl: Parity- SERR+ NoISA- VGA- VGA16- MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: <access denied>
	Kernel driver in use: pcieport

00:1f.0 ISA bridge [0601]: Intel Corporation Alder Lake PCH eSPI Controller [8086:5182] (rev 01)
	Subsystem: CLEVO/KAPOK Computer Device [1558:4150]
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	IOMMU group: 12

00:1f.3 Audio device [0403]: Intel Corporation Alder Lake PCH-P High Definition Audio Controller [8086:51c8] (rev 01)
	Subsystem: CLEVO/KAPOK Computer Device [1558:4150]
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 32, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 160
	IOMMU group: 12
	Region 0: Memory at 6001128000 (64-bit, non-prefetchable) [size=16K]
	Region 4: Memory at 6001000000 (64-bit, non-prefetchable) [size=1M]
	Capabilities: <access denied>
	Kernel driver in use: snd_hda_intel
	Kernel modules: snd_hda_intel, snd_soc_avs, snd_sof_pci_intel_tgl

00:1f.4 SMBus [0c05]: Intel Corporation Alder Lake PCH-P SMBus Host Controller [8086:51a3] (rev 01)
	Subsystem: CLEVO/KAPOK Computer Device [1558:4150]
	Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Interrupt: pin A routed to IRQ 16
	IOMMU group: 12
	Region 0: Memory at 6001134000 (64-bit, non-prefetchable) [size=256]
	Region 4: I/O ports at efa0 [size=32]
	Kernel driver in use: i801_smbus
	Kernel modules: i2c_i801

00:1f.5 Serial bus controller [0c80]: Intel Corporation Alder Lake-P PCH SPI Controller [8086:51a4] (rev 01)
	Subsystem: CLEVO/KAPOK Computer Device [1558:4150]
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	IOMMU group: 12
	Region 0: Memory at 80a10000 (32-bit, non-prefetchable) [size=4K]

01:00.0 Non-Volatile memory controller [0108]: Kingston Technology Company, Inc. NV2 NVMe SSD SM2267XT (DRAM-less) [2646:5017] (rev 03) (prog-if 02 [NVM Express])
	Subsystem: Kingston Technology Company, Inc. NV2 NVMe SSD SM2267XT (DRAM-less) [2646:5017]
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 16
	IOMMU group: 13
	Region 0: Memory at 80900000 (64-bit, non-prefetchable) [size=16K]
	Capabilities: <access denied>
	Kernel driver in use: nvme
	Kernel modules: nvme

02:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTL8411B PCI Express Card Reader [10ec:5287] (rev 01)
	Subsystem: CLEVO/KAPOK Computer Device [1558:4150]
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin B routed to IRQ 124
	IOMMU group: 14
	Region 0: Memory at 80805000 (32-bit, non-prefetchable) [size=4K]
	Expansion ROM at 80810000 [disabled] [size=64K]
	Capabilities: <access denied>
	Kernel driver in use: rtsx_pci
	Kernel modules: rtsx_pci

02:00.1 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 12)
	Subsystem: CLEVO/KAPOK Computer Device [1558:4150]
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 16
	IOMMU group: 14
	Region 0: I/O ports at 3000 [size=256]
	Region 2: Memory at 80804000 (64-bit, non-prefetchable) [size=4K]
	Region 4: Memory at 80800000 (64-bit, non-prefetchable) [size=16K]
	Capabilities: <access denied>
	Kernel driver in use: r8169
	Kernel modules: r8169


** USB devices:
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 04f3:0235 Elan Microelectronics Corp. Optical Mouse
Bus 001 Device 003: ID 04f3:0c63 Elan Microelectronics Corp. ELAN:Fingerprint
Bus 001 Device 004: ID 0d8c:025b C-Media Electronics, Inc. USB Advanced Audio Device
Bus 001 Device 005: ID 5986:214c Bison Electronics Inc. BisonCam,NB Pro
Bus 001 Device 006: ID 8087:0026 Intel Corp. AX201 Bluetooth
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub


-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (800, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.9.7-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=C, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages linux-image-6.9.7-amd64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.142
ii  kmod                                    32+20240611-1
ii  linux-base                              4.10.1

Versions of packages linux-image-6.9.7-amd64 recommends:
ii  apparmor  3.1.7-1

Versions of packages linux-image-6.9.7-amd64 suggests:
pn  debian-kernel-handbook  <none>
ii  firmware-linux-free     20240610-1
ii  grub-efi-amd64          2.12-2
pn  linux-doc-6.9           <none>

Versions of packages linux-image-6.9.7-amd64 is related to:
pn  firmware-amd-graphics     <none>
pn  firmware-atheros          <none>
pn  firmware-bnx2             <none>
pn  firmware-bnx2x            <none>
pn  firmware-brcm80211        <none>
pn  firmware-cavium           <none>
pn  firmware-intel-sound      <none>
pn  firmware-intelwimax       <none>
pn  firmware-ipw2x00          <none>
pn  firmware-ivtv             <none>
ii  firmware-iwlwifi          20230625-2
pn  firmware-libertas         <none>
pn  firmware-linux-nonfree    <none>
ii  firmware-misc-nonfree     20230625-2
pn  firmware-myricom          <none>
pn  firmware-netxen           <none>
pn  firmware-qlogic           <none>
ii  firmware-realtek          20230625-2
pn  firmware-samsung          <none>
pn  firmware-siano            <none>
pn  firmware-ti-connectivity  <none>
pn  xen-hypervisor            <none>

-- no debconf information

[toc] | [next] | [standalone]

#1204157

FromSalvatore Bonaccorso <carnil@debian.org>
Date2024-07-13 15:10 +0200
Message-ID<IZKFI-1OqG-17@gated-at.bofh.it>
In reply to#1203179
Hi Francesco,

On Thu, Jul 04, 2024 at 07:36:21PM +0200, Francesco Poli (wintermute) wrote:
> Package: src:linux
> Version: 6.9.7-1
> Severity: normal
> X-Debbugs-Cc: invernomuto@paranoici.org
> 
> Hello,
> on a laptop where I installed Debian testing some 6 months ago,
> I noticed that the logs are continuously filled with call traces
> like the attached snippet (taken from /var/log/kern.log ).
> 
> It seems to me that it also used to happen with previous versions
> of the Linux kernel, but I am under the impression that, with linux/6.9.7-1,
> it got worse.
> 
> I see 12 of these call traces just after boot, before even starting X
> (with 'startx').
> More of these call traces are sent to the logs after starting X, or
> after invoking 'xrandr', or after locking the X session (with
> XScreenSaver), ...
> 
> They seem to correspond to no actual issue, as far as I can tell,
> but they are filling the logs with a significant flow of text...
> which is worrying by itself.
> 
> What's wrong?
> How can I stop this log-filling flood?

We discussed your case in the last kernel-team meeting and came to the
conclusion that if possible you report your issue upstream and keep us
here in the loop about progressm. I was not clear though if you need
some guidance to do so.

The get the correct contact addresses for reporting the issue you can
use the get_maintainers.pl script in the upstream source. I would
suggest to approach the following people:

$ ./scripts/get_maintainer.pl drivers/gpu/drm/i915/display/intel_tc.c
Jani Nikula <jani.nikula@linux.intel.com> (supporter:INTEL DRM DISPLAY FOR XE AND I915 DRIVERS)
Rodrigo Vivi <rodrigo.vivi@intel.com> (supporter:INTEL DRM DISPLAY FOR XE AND I915 DRIVERS)
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> (supporter:INTEL DRM I915 DRIVER (Meteor Lake, DG2 and old...)
Tvrtko Ursulin <tursulin@ursulin.net> (supporter:INTEL DRM I915 DRIVER (Meteor Lake, DG2 and old...)
David Airlie <airlied@gmail.com> (maintainer:DRM DRIVERS)
Daniel Vetter <daniel@ffwll.ch> (maintainer:DRM DRIVERS)
intel-gfx@lists.freedesktop.org (open list:INTEL DRM DISPLAY FOR XE AND I915 DRIVERS)
intel-xe@lists.freedesktop.org (open list:INTEL DRM DISPLAY FOR XE AND I915 DRIVERS)
dri-devel@lists.freedesktop.org (open list:DRM DRIVERS)
linux-kernel@vger.kernel.org (open list)

Regards,
Salvatore

[toc] | [prev] | [next] | [standalone]

#1204186

FromFrancesco Poli <invernomuto@paranoici.org>
Date2024-07-13 19:20 +0200
Message-ID<IZOzD-1QTH-7@gated-at.bofh.it>
In reply to#1204157

[Multipart message — attachments visible in raw view] — view raw

On Sat, 13 Jul 2024 15:04:49 +0200 Salvatore Bonaccorso wrote:

[...]
> We discussed your case in the last kernel-team meeting and came to the
> conclusion that if possible you report your issue upstream and keep us
> here in the loop about progressm. I was not clear though if you need
> some guidance to do so.
[...]

Wouldn't it be so much easier, if you just forward my bug report
upstream?


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
..................................................... Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE

[toc] | [prev] | [next] | [standalone]

#1204194

FromSalvatore Bonaccorso <carnil@debian.org>
Date2024-07-13 21:00 +0200
Message-ID<IZQ8p-1RZ1-1@gated-at.bofh.it>
In reply to#1204186
Hi,

On Sat, Jul 13, 2024 at 07:10:08PM +0200, Francesco Poli wrote:
> On Sat, 13 Jul 2024 15:04:49 +0200 Salvatore Bonaccorso wrote:
> 
> [...]
> > We discussed your case in the last kernel-team meeting and came to the
> > conclusion that if possible you report your issue upstream and keep us
> > here in the loop about progressm. I was not clear though if you need
> > some guidance to do so.
> [...]
> 
> Wouldn't it be so much easier, if you just forward my bug report
> upstream?

You are directly affected and we cannot reproduce the issue on our
own, so we gave you guidance on where exactly to report it. If you
directly report it you get the direct interaction with upstream, as
you might be the only one providing additional feedback on question.

But sure if you do not want to report it, I can forward to the
maintainers with similar effect, just let me know if you prefer to not
write on your own to upstream.

Regards,
Salvatore

[toc] | [prev] | [next] | [standalone]

#1204426

FromFrancesco Poli <invernomuto@paranoici.org>
Date2024-07-15 20:30 +0200
Message-ID<J0yCt-2mhC-7@gated-at.bofh.it>
In reply to#1204194

[Multipart message — attachments visible in raw view] — view raw

On Sat, 13 Jul 2024 20:56:08 +0200 Salvatore Bonaccorso wrote:

[...]
> On Sat, Jul 13, 2024 at 07:10:08PM +0200, Francesco Poli wrote:
[...]
> > Wouldn't it be so much easier, if you just forward my bug report
> > upstream?
> 
> You are directly affected and we cannot reproduce the issue on our
> own, so we gave you guidance on where exactly to report it. If you
> directly report it you get the direct interaction with upstream, as
> you might be the only one providing additional feedback on question.
> 
> But sure if you do not want to report it, I can forward to the
> maintainers with similar effect, just let me know if you prefer to not
> write on your own to upstream.

OK, I'll try, but, depending on which feedback I am asked to provide,
I could need some help from you.


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
..................................................... Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE

[toc] | [prev] | [next] | [standalone]

#1205418 — Bug#1075770: [bug report] adlp_tc_phy_connect [i915] floods logs with drm_WARN_ON(tc->mode == TC_PORT_LEGACY) call traces

FromJani Nikula <jani.nikula@linux.intel.com>
Date2024-07-24 18:20 +0200
SubjectBug#1075770: [bug report] adlp_tc_phy_connect [i915] floods logs with drm_WARN_ON(tc->mode == TC_PORT_LEGACY) call traces
Message-ID<J3MSB-230-1@gated-at.bofh.it>
In reply to#1203179
On Mon, 15 Jul 2024, Francesco Poli <invernomuto@paranoici.org> wrote:
> Hi all,
> on a laptop where I installed Debian testing some 6 months ago,
> I noticed that the logs are continuously flooded with call traces
> like the attached snippet (taken from /var/log/kern.log ).
>
> It seems to me that it also used to happen with previous versions
> of the Linux kernel, but I am under the impression that, with Linux
> kernel 6.9.7, it got worse. I have recently upgraded to Linux kernel
> version 6.9.8 (provided by the distro, Debian testing, as I said), but
> the bug is still reproducible:
>
>   $ uname -srvmo
>   Linux 6.9.8-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.9.8-1 (2024-07-07) x86_64 GNU/Linux
>
> I see at least 12 of these call traces just after boot, before even
> starting X (with 'startx').
> More of these call traces are sent to the logs after starting X, or
> after invoking 'xrandr', or after locking the X session (with
> XScreenSaver), ...
> I always see these call traces (I mean the bug is always reproducible:
> each time I boot, each time I call xrandr, ...).
>
> They seem to correspond to no actual issue, as far as I can tell,
> but they are flooding the logs with a significant flow of text...
> which is worrying by itself.
>
>
> What's wrong?
> How can I stop this log-filling flood?
> Should I black-list some module, for instance?
>
>
> The outputs of
>
>   # lspci -vnn -d :*:0300
>
> and of
>
>   # dmidecode
>
> are attached.
> Also, I booted with kernel parameters
> 'drm.debug=0xe log_buf_len=4M ignore_loglevel' and
> logged in as root right after the boot.
> The output of
>
>   # dmesg
>
> is attached.
>
> Some additional information may be found on the [Debian bug] report I had previously filed.
>
> [Debian bug]: <https://bugs.debian.org/1075770>
>
>
> N.B.:
> Please Cc me and the Debian bug address <1075770@bugs.debian.org>
> on replies, so that the interested parties (including me!) are kept
> in the loop.
> Thanks a lot for your time and for any help you may provide!

Please file i915 bugs at fdo gitlab as described at [1].

BR,
Jani.

[1] https://drm.pages.freedesktop.org/intel-docs/how-to-file-i915-bugs.html


-- 
Jani Nikula, Intel

[toc] | [prev] | [next] | [standalone]

#1205429 — Bug#1075770: [bug report] adlp_tc_phy_connect [i915] floods logs with drm_WARN_ON(tc->mode == TC_PORT_LEGACY) call traces

FromImre Deak <imre.deak@intel.com>
Date2024-07-24 20:40 +0200
SubjectBug#1075770: [bug report] adlp_tc_phy_connect [i915] floods logs with drm_WARN_ON(tc->mode == TC_PORT_LEGACY) call traces
Message-ID<J3P45-3kC-9@gated-at.bofh.it>
In reply to#1203179
On Mon, Jul 15, 2024 at 08:35:43PM +0200, Francesco Poli wrote:
> Hi all,
> on a laptop where I installed Debian testing some 6 months ago,
> I noticed that the logs are continuously flooded with call traces
> like the attached snippet (taken from /var/log/kern.log ).
> 
> It seems to me that it also used to happen with previous versions
> of the Linux kernel, but I am under the impression that, with Linux
> kernel 6.9.7, it got worse. I have recently upgraded to Linux kernel
> version 6.9.8 (provided by the distro, Debian testing, as I said), but
> the bug is still reproducible:
> 
>   $ uname -srvmo
>   Linux 6.9.8-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.9.8-1 (2024-07-07) x86_64 GNU/Linux
> 
> I see at least 12 of these call traces just after boot, before even
> starting X (with 'startx').
> More of these call traces are sent to the logs after starting X, or
> after invoking 'xrandr', or after locking the X session (with
> XScreenSaver), ...
> I always see these call traces (I mean the bug is always reproducible:
> each time I boot, each time I call xrandr, ...).
> 
> They seem to correspond to no actual issue, as far as I can tell,
> but they are flooding the logs with a significant flow of text...
> which is worrying by itself.
> 
> 
> What's wrong?
> How can I stop this log-filling flood?
> Should I black-list some module, for instance?
> 
> 
> The outputs of
> 
>   # lspci -vnn -d :*:0300
> 
> and of
> 
>   # dmidecode
> 
> are attached.
> Also, I booted with kernel parameters
> 'drm.debug=0xe log_buf_len=4M ignore_loglevel' and
> logged in as root right after the boot.
> The output of
> 
>   # dmesg
> 
> is attached.

Thanks for the logs. The VBT claims that the laptop has 1 USB-C
and 3 legacy DP connectors (the latter 3 being a bit odd on a laptop,
even if not impossible). The DMI in BIOS says:

DMI: Notebook NLxxPUx/NLxxPUx, BIOS 1.07.09 11/17/2023

for which I can't find the particular system to check the actual
configuration. Could you point to the laptop vendor/model's page or
describe what are the connectors on it?

Could you check if there is a BIOS upgrade available? Please follow up
on the gitlab issue as Jani suggested.

> Some additional information may be found on the [Debian bug] report I had previously filed.
> 
> [Debian bug]: <https://bugs.debian.org/1075770>
> 
> 
> N.B.:
> Please Cc me and the Debian bug address <1075770@bugs.debian.org>
> on replies, so that the interested parties (including me!) are kept
> in the loop.
> Thanks a lot for your time and for any help you may provide!
> 
> 
> -- 
>  http://www.inventati.org/frx/
>  There's not a second to spare! To the laboratory!
> ..................................................... Francesco Poli .
>  GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE

[toc] | [prev] | [next] | [standalone]

#1205613 — Bug#1075770: [bug report] adlp_tc_phy_connect [i915] floods logs with drm_WARN_ON(tc->mode == TC_PORT_LEGACY) call traces

FromFrancesco Poli <invernomuto@paranoici.org>
Date2024-07-26 00:10 +0200
SubjectBug#1075770: [bug report] adlp_tc_phy_connect [i915] floods logs with drm_WARN_ON(tc->mode == TC_PORT_LEGACY) call traces
Message-ID<J4eOR-krh-3@gated-at.bofh.it>
In reply to#1205429

[Multipart message — attachments visible in raw view] — view raw

On Wed, 24 Jul 2024 21:30:00 +0300 Imre Deak wrote:

[...]
> Thanks for the logs.

Thanks to you for looking into them!
By the way, I have just upgraded the Linux kernel, but the
issue stays the same:

  $ uname -srvmo
  Linux 6.9.10-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.9.10-1 (2024-07-19) x86_64 GNU/Linux

> The VBT claims that the laptop has 1 USB-C

which I think it has (and dmidecode seems to see it)...

> and 3 legacy DP connectors (the latter 3 being a bit odd on a laptop,
> even if not impossible).

Do you mean that I should see 3 external DisplayPort connectors?
I really cannot spot them.
I cannot see any set of three identical connectors on the "outer
surface" of the laptop case, actually.

However, the graphics software stack sees them, as confirmed by
the output of 'xrandr' (attached).

Could they be internal (unused) connectors?

Or maybe they are not really present in the hardware, and the Linux
kernel wrongly thinks they are there, because of some bug...?
Could this happen?!?

> The DMI in BIOS says:
> 
> DMI: Notebook NLxxPUx/NLxxPUx, BIOS 1.07.09 11/17/2023
> 
> for which I can't find the particular system to check the actual
> configuration. Could you point to the laptop vendor/model's page or
> describe what are the connectors on it?

The label on the bottom of the laptop case says:

  MODEL: NL41PU

and

  PRODUCT CODE: NL41PU2

According to the same label, the brand should be [Clevo].

[Clevo]: <https://clevo-computer.com/en/>

I bought the laptop from an Italian shop which, among other things,
assembles customized laptops, that can be configured through
a web [configurator] (unfortunately, it seems that the website
is in Italian only...).

[configurator]: <https://syspack.com/configuratoreNotebook.php>

The notebook that I selected (along with other components) is
identified as "Work14 i5-1235U DDR4 M.2 14" FullHD"
The provided description (translated into English by me) is attached.

I think the Clevo NL41PU laptop is the same as the one
described [here].

[here]: <https://laptopwithlinux.com/product/clevo-nl41/>

> 
> Could you check if there is a BIOS upgrade available?

Following from the Clevo [support] site, I think I found
the relevant download server [folder], but it seems to me that
there is no upgrade later than "1.07.09 11/17/2023"...
Actually, I cannot even see that version, which is awkward.
Maybe I am misunderstanding something...   :-(
Or maybe not: I have also asked the shop about possible BIOS upgrades,
and they replied to me that there are no BIOS upgrades yet for that
model, as far as they can tell.

[support]: <https://clevo-computer.com/en/support-drivers>
[folder]: <https://my.hidrive.com/share/yze8mg-wf8#$/BIOS%20and%20EC%20Firmware/CLEVO/N_Series/NLxxx/NLxxPxx/NL4xPUx>

> Please follow up
> on the gitlab issue as Jani suggested.

I had reported the bug to the Debian BTS (Bug Tracking System), where
I was told to report the bug upstream, by contacting developers/mailing
lists.
Now on this mailing list, I am being told to report the issue on
gitlab.freedesktop.org (which requires to register an account, in order
to report issues)... Having to jump through all these hoops is beginning
to be a little time consuming...   :-(


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
..................................................... Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE

[toc] | [prev] | [next] | [standalone]

#1206158 — Bug#1075770: [bug report] adlp_tc_phy_connect [i915] floods logs with drm_WARN_ON(tc->mode == TC_PORT_LEGACY) call traces

FromJani Nikula <jani.nikula@intel.com>
Date2024-07-29 12:40 +0200
SubjectBug#1075770: [bug report] adlp_tc_phy_connect [i915] floods logs with drm_WARN_ON(tc->mode == TC_PORT_LEGACY) call traces
Message-ID<J5vXj-1ep9-9@gated-at.bofh.it>
In reply to#1205613
On Thu, 25 Jul 2024, Francesco Poli <invernomuto@paranoici.org> wrote:
> I had reported the bug to the Debian BTS (Bug Tracking System), where
> I was told to report the bug upstream, by contacting developers/mailing
> lists.
> Now on this mailing list, I am being told to report the issue on
> gitlab.freedesktop.org (which requires to register an account, in order
> to report issues)... Having to jump through all these hoops is beginning
> to be a little time consuming...   :-(

There are a number of reasons why email and mailing lists are really bad
for reporting bugs, from our perspective, which is why we've asked
people to report bugs to freedesktop.org bug trackers for about a decade
now.

If the right person doesn't have time to resolve the issue right away,
it'll likely be forgotten on the mailing list. Attachments aren't
welcome on mailing lists, let alone big logs. It's easier to label and
reference issues on a bug tracker. It's easier (yes, for us) to manage
the issues, and the people working on them, on a bug tracker. And so on.

BR,
Jani.


-- 
Jani Nikula, Intel

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web