Processed: severity of 1053856 is important
Processing commands for cont...@bugs.debian.org: > severity 1053856 important Bug #1053856 [firmware-amd-graphics] firmware-amd-graphics: Inconsistent firmware snapshot for Zen4/Phoenix1 GPUs Severity set to 'important' from 'grave' > thanks Stopping processing here. Please contact me if you need assistance. -- 1053856: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053856 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Re: CONFIG_PREEMPT_DYNAMIC=y?
Hi, On 2023-10-08 06:20, Johannes Schauer Marin Rodrigues wrote: > I'm wondering whether it'd make sense for the Debian kernel to be built with > CONFIG_PREEMPT_DYNAMIC=y. On amd64 we already have PREEMPT_DYNAMIC=y, so I thought of running some benchmarks on my Ryzen system to evaluate the performance overhead it introduces. To my surprise, I found that in Debian you get a 20% (!) performance improvement on kernel-heavy workloads simply by setting PREEMPT_DYNAMIC to 'n'. I brought up the topic on LKML [1], and it turns out that what is really eating performance for us is DEBUG_PREEMPT=y. There is a performance penalty in PREEMPT_DYNAMIC=y as well, but it's much smaller, around 3 or 4%. The Kconfig help entry for DEBUG_PREEMPT also clearly mentions the performance overhead: This option has potential to introduce high runtime overhead, depending on workload as it triggers debugging routines for each this_cpu operation. It should only be used for debugging purposes. Regardless of what we are going to decide about PREEMPT_DYNAMIC, we surely have to disable DEBUG_PREEMPT. I opened [2] for that. [1] https://lore.kernel.org/lkml/ZTJFA_Ac6nWawIHb@ariel/ [2] https://salsa.debian.org/kernel-team/linux/-/merge_requests/874
Bug#1040901: Upcoming changes to Debian Linux kernel packages
[ Removing some lists ] On Sat, Oct 07, 2023 at 04:53:33PM +0200, Bastian Blank wrote: > > ## Image packages contains more version info > > > > Example: linux-image-6.5.3-cloud-arm64 > > > It will not longer be possible to reliably derive the package name from > > kernel release (see above), as both values are not really related > > anymore. > What should work: We define a new control field. It contains both the > kernel name and a version prefix. Or would it be easier to re-use normal dependency resolving, like: Kernel-Provides: linux (>> 6.6.1~), linux (<< 6.6.1.) This would allow full flexibility and re-uses existing code to check such definitions. Regards, Bastian -- Women professionals do tend to over-compensate. -- Dr. Elizabeth Dehaver, "Where No Man Has Gone Before", stardate 1312.9.
Bug#1053347: still not working on linux-image-6.5.0-2-amd64
Hi, just upgraded to linux-image-6.5.0-2-amd64 but same symptoms. Last working kernel was linux-image-6.4.0-4-amd64 thanks -- Ivan Sergio Borgonovo https://www.webthatworks.it https://www.borgonovo.net
