Bug#1054514: [PATCH 0/1] drm/qxl: fixes qxl_fence_wait

2024-03-07 Thread Alex Constantino
Hi, As initially reported by Timo in the QXL driver will crash given enough workload: https://lore.kernel.org/regressions/fb0fda6a-3750-4e1b-893f-97a3e402b...@leemhuis.info/ I initially came across this problem when migrating Debian VMs from Bullseye to Bookworm. This bug will somewhat randomly

Uploading linux (6.7.9-1)

2024-03-07 Thread Salvatore Bonaccorso
Hi I would like to upload linux version 6.7.9-1 to unstable soon if possible. There is the import of 6.7.8 and 6.7.9 from the 6.7.y stable series. Note that src:linux is not binNMU safe buildable and thus this is (for the time beeing) disabled since

Processed: Re: Bug#1065320: linux-image-6.1.0-18-amd64: 6.1.0-18 kernel enters ACPI Error loop during boot & requires power cycle

2024-03-07 Thread Debian Bug Tracking System
Processing control commands: > severity -1 serious Bug #1065320 [src:linux] linux-image-6.1.0-18-amd64: 6.1.0-18 kernel enters ACPI Error loop during boot & requires power cycle Severity set to 'serious' from 'critical' > tags -1 + upstream fixed-upstream Bug #1065320 [src:linux]

Bug#1065320: linux-image-6.1.0-18-amd64: 6.1.0-18 kernel enters ACPI Error loop during boot & requires power cycle

2024-03-07 Thread Salvatore Bonaccorso
Control: severity -1 serious Control: tags -1 + upstream fixed-upstream Control: forwarded -1 https://lore.kernel.org/regressions/zd2bsv8vsfjml...@archie.me/ https://bugzilla.kernel.org/show_bug.cgi?id=218531 Control: found -1 6.6.15-1 Control: found -1 6.7.4-1~exp1 Hi Lee, On Sat, Mar 02,

Bug#1064252: marked as done (linux-image-6.1.0-17-amd64: CONFIG_SYSTEM_TRUSTED_KEYS="y" is in the default config "y")

2024-03-07 Thread Debian Bug Tracking System
Your message dated Thu, 7 Mar 2024 22:02:05 +0100 with message-id and subject line Re: Bug#1064252: linux-image-6.1.0-17-amd64: CONFIG_SYSTEM_TRUSTED_KEYS="y" is in the default config "y" has caused the Debian Bug report #1064252, regarding linux-image-6.1.0-17-amd64:

Bug#1065611: Additional support for SolidRun HoneyComb

2024-03-07 Thread Diederik de Haas
Hi Josua, On Thursday, 18 January 2024 17:40:38 CET Josua Mayer wrote: > LX2160 SoC early silicon revisions have a pci-e generation 4 controller. > It requires a different driver from newer gen-3 silicon. > > This affects the SolidRun Honeycomb Workstation which > is otherwise fully supported in

Processed: found 1065585 in 6.6.3-1~exp1

2024-03-07 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org: > found 1065585 6.6.3-1~exp1 Bug #1065585 [src:linux] linux-headers-6.7.7-amd64: Depends: linux-compiler-gcc-13-x86 -> linux-image-6.7.7-amd64, gcc-13 => uninstallable on x32 Marked as found in versions linux/6.6.3-1~exp1. > thanks Stopping

Bug#1061116: linux-image-6.1.0-17-arm64: please enable support for lx2160a pcie gen4 controller on early silicon

2024-03-07 Thread Diederik de Haas
Control: clone -1 -2 Control: retitle -2 Additional support for SolidRun HoneyComb On Thursday, 18 January 2024 17:40:38 CET Josua Mayer wrote: > LX2160 SoC early silicon revisions have a pci-e generation 4 controller. > It requires a different driver from newer gen-3 silicon. > > This affects

Processed: Re: Bug#1061116: linux-image-6.1.0-17-arm64: please enable support for lx2160a pcie gen4 controller on early silicon

2024-03-07 Thread Debian Bug Tracking System
Processing control commands: > clone -1 -2 Bug #1061116 [src:linux] linux-image-6.1.0-17-arm64: please enable support for lx2160a pcie gen4 controller on early silicon Bug 1061116 cloned as bug 1065611 > retitle -2 Additional support for SolidRun HoneyComb Bug #1065611 [src:linux]

Bug#1064976:

2024-03-07 Thread colm
I am assuming that the original intent of adding linux-image-* as a dependency was to prevent the "Skipping BTF generation for %s due to unavailability of vmlinux" warning from being printed; is that a fair assumption? I am quite sure that this will not cause problems because of the decision in

Bug#1065392: Additional information : secure boot involved

2024-03-07 Thread pdormeau
Hello, I made additional tests this morning showing that the problem is related to the secure boot (even when the secure-boot-policy PCR binding is not used). - secure boot enabled, no PCR binding (--tpm2-pcrs="" passed to systemd-cryptenroll) : OK - secure boot enabled, PCR binding