Bug#932157:
The merge request on Salsa was merged and is part of the debian/4.19.37-6 tag.
Bug#949825:
This seems to have been added in bc8cd7ed96ad [arm64] Enable BCMGENET which was part of the 5.5.2-1~exp1 release.
Bug#953017: closed by Ben Hutchings (Re: Bug#953017: Fixes in Upstream)
The stable kernel is still at v4.19.98 though. On Wed, Apr 15, 2020 at 8:36 AM Debian Bug Tracking System wrote: > > This is an automatic notification regarding your Bug report > which was filed against the src:linux package: > > #953017: linux-image-amd64: Regression from "mm/vmalloc: Sync unmappings in > __purge_vmap_area_lazy()" > > It has been closed by Ben Hutchings . > > Their explanation is attached below along with your original report. > If this explanation is unsatisfactory and you have not received a > better one in a separate message then please contact Ben Hutchings > by > replying to this email. > > > -- > 953017: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953017 > Debian Bug Tracking System > Contact ow...@bugs.debian.org with problems > > > > -- Forwarded message -- > From: Ben Hutchings > To: 953017-d...@bugs.debian.org > Cc: > Bcc: > Date: Wed, 15 Apr 2020 01:32:18 +0100 > Subject: Re: Bug#953017: Fixes in Upstream > Version: 5.5.13-1 > > On Thu, 2020-04-09 at 13:40 +0800, Chen-Yu Tsai wrote: > > The fix for this issue has been merged in v5.6-rc7 and is part of the > > v5.6 release. The commit in upstream is: > > > > 763802b53a42 x86/mm: split vmalloc_sync_all() > > > > This has also been backported to all current LTS kernels except 3.16 > > in the following releases: > > > > v4.4.218 > > v4.9.218 > > v4.14.175 > > v4.19.113 > > v5.4.28 > > ...and 5.5.12, so this is fixed in unstable. > > Ben. > > -- > Ben Hutchings > It is a miracle that curiosity survives formal education. > - Albert Einstein > > > > > > -- Forwarded message -- > From: Chen-Yu Tsai > To: Debian Bug Tracking System > Cc: > Bcc: > Date: Tue, 03 Mar 2020 17:51:31 +0800 > Subject: linux-image-amd64: Regression from "mm/vmalloc: Sync unmappings in > __purge_vmap_area_lazy()" > Package: linux-image-amd64 > Version: 5.4.13-1~bpo10+1 > Severity: important > Tags: upstream patch > > Dear Maintainer, > > A performance regression stemming from the patch "mm/vmalloc: Sync > unmappings in __purge_vmap_area_lazy()" in all mainline and current > stable kernels, except 3.16.y, was reported by multiple persons [1]. > The regression involves any activity that exercises vmalloc a lot, > such as creating threads with CONFIG_VMAP_STACK=y or tty allocation > (for example by SSH servers). > > A fix [2] for this was posted last October and was picked up in the > -mm tree last November [3]. However this fix did not make it into > v5.6-rc or any other release. It is still only in the -mm tree. > > AFAICT this regression only impacts x86 platforms, as it is the only > platform that has a custom vmalloc_sync_all() instead of the standard > no-op stub. > > As per my report to upstream, I currently have one production server > running with the offending patch reverted. I also have another with > the fix applied, and that seems to work well. > > Please consider adding the fix to Debian kernel images until upstream > kernels have it. > > [1] https://www.spinics.net/lists/stable/msg349763.html > [2] https://patchwork.kernel.org/patch/11181159/ > [3] https://www.spinics.net/lists/mm-commits/msg141749.html > > -- System Information: > Debian Release: 10.3 > APT prefers stable-updates > APT policy: (500, 'stable-updates'), (500, 'stable') > Architecture: amd64 (x86_64) > Foreign Architectures: armhf, i386, arm64 > > Kernel: Linux 5.2.0-0.bpo.2-amd64 (SMP w/8 CPU cores) > Locale: LANG=zh_TW.UTF-8, LC_CTYPE=zh_TW.UTF-8 (charmap=UTF-8), > LANGUAGE=zh_TW.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: sysvinit (via /sbin/init) > > Versions of packages linux-image-amd64 depends on: > ii linux-image-5.4.0-0.bpo.3-amd64 5.4.13-1~bpo10+1 > > linux-image-amd64 recommends no packages. > > linux-image-amd64 suggests no packages. > > -- no debconf information
Bug#953017: Fixes in Upstream
The fix for this issue has been merged in v5.6-rc7 and is part of the v5.6 release. The commit in upstream is: 763802b53a42 x86/mm: split vmalloc_sync_all() This has also been backported to all current LTS kernels except 3.16 in the following releases: v4.4.218 v4.9.218 v4.14.175 v4.19.113 v5.4.28
Bug#953017: linux-image-amd64: Regression from "mm/vmalloc: Sync unmappings in __purge_vmap_area_lazy()"
Package: linux-image-amd64 Version: 5.4.13-1~bpo10+1 Severity: important Tags: upstream patch Dear Maintainer, A performance regression stemming from the patch "mm/vmalloc: Sync unmappings in __purge_vmap_area_lazy()" in all mainline and current stable kernels, except 3.16.y, was reported by multiple persons [1]. The regression involves any activity that exercises vmalloc a lot, such as creating threads with CONFIG_VMAP_STACK=y or tty allocation (for example by SSH servers). A fix [2] for this was posted last October and was picked up in the -mm tree last November [3]. However this fix did not make it into v5.6-rc or any other release. It is still only in the -mm tree. AFAICT this regression only impacts x86 platforms, as it is the only platform that has a custom vmalloc_sync_all() instead of the standard no-op stub. As per my report to upstream, I currently have one production server running with the offending patch reverted. I also have another with the fix applied, and that seems to work well. Please consider adding the fix to Debian kernel images until upstream kernels have it. [1] https://www.spinics.net/lists/stable/msg349763.html [2] https://patchwork.kernel.org/patch/11181159/ [3] https://www.spinics.net/lists/mm-commits/msg141749.html -- System Information: Debian Release: 10.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: armhf, i386, arm64 Kernel: Linux 5.2.0-0.bpo.2-amd64 (SMP w/8 CPU cores) Locale: LANG=zh_TW.UTF-8, LC_CTYPE=zh_TW.UTF-8 (charmap=UTF-8), LANGUAGE=zh_TW.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages linux-image-amd64 depends on: ii linux-image-5.4.0-0.bpo.3-amd64 5.4.13-1~bpo10+1 linux-image-amd64 recommends no packages. linux-image-amd64 suggests no packages. -- no debconf information
Bug#793185: [linux-sunxi] Re: forwarding a bug: cpufreq missing in debian stable on a cuibeboard
On Sat, Jul 25, 2015 at 11:30 PM, Ian Campbell i...@debian.org wrote: On Sat, 2015-07-25 at 22:54 +0800, Chen-Yu Tsai wrote: On Sat, Jul 25, 2015 at 10:46 PM, Leonardo Canducci leonardo.candu...@gmail.com wrote: I got lost somewhere in that long thread but I saw cpufreq on cubie* works for someone [0]. It's just a matter of loading two modules. I tried myself on my jessie install (kernel from experimental) and can confirm that: leo@cubetto:~$ sudo modprobe axp20x-regulator leo@cubetto:~$ sudo modprobe cpufreq-dt leo@cubetto:~$ ls /sys/devices/system/cpu/cpu0/cpufreq/ affected_cpus related_cpus scaling_governor cpuinfo_cur_freqscaling_available_frequencies scaling_max_freq cpuinfo_max_freqscaling_available_governors scaling_min_freq cpuinfo_min_freqscaling_cur_freq scaling_setspeed cpuinfo_transition_latency scaling_driver stats How do I make this change persistent? Add both module names to /etc/modules. Is there any way to arrange for these modules to be loaded automatically without the user needing to configure it manually, like any other h/w driver? I'd expect at least the axp20x-regulator driver to get autoloaded when the relevant hardware is present. Not sure about the cpufreq-dt one, but should it not be loaded if the relevant nodes are present? cpufreq-dt is not a node in the DT. It is added in platform code. See arch/arm/mach-sunxi/sunxi.c. AFAIK all other users of cpufreq-dt use this method. Not sure how you can automatically detect this... Supposedly there would be an event to udev? ChenYu -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAGb2v67Ys2RLQSko=shluuo-2lpd+k+bexta2p48uns8oe-...@mail.gmail.com
Bug#793185: [linux-sunxi] Re: forwarding a bug: cpufreq missing in debian stable on a cuibeboard
On Sat, Jul 25, 2015 at 10:46 PM, Leonardo Canducci leonardo.candu...@gmail.com wrote: I got lost somewhere in that long thread but I saw cpufreq on cubie* works for someone [0]. It's just a matter of loading two modules. I tried myself on my jessie install (kernel from experimental) and can confirm that: leo@cubetto:~$ sudo modprobe axp20x-regulator leo@cubetto:~$ sudo modprobe cpufreq-dt leo@cubetto:~$ ls /sys/devices/system/cpu/cpu0/cpufreq/ affected_cpus related_cpus scaling_governor cpuinfo_cur_freqscaling_available_frequencies scaling_max_freq cpuinfo_max_freqscaling_available_governorsscaling_min_freq cpuinfo_min_freqscaling_cur_freq scaling_setspeed cpuinfo_transition_latency scaling_driver stats How do I make this change persistent? Add both module names to /etc/modules. ChenYu Thanks, Leonardo [0] http://forum.armbian.com/index.php/topic/108-no-cpufreq-support-in-cubietruck-debian-39-wheezy-405/?p=781 2015-07-24 15:23 GMT+02:00 Hans de Goede hdego...@redhat.com: Hi, On 24-07-15 15:16, Maxime Ripard wrote: On Fri, Jul 24, 2015 at 02:58:31PM +0200, Hans de Goede wrote: There is slightly more to it then those 5 lines, but yes we should enable voltage scaling on more boards. This mostly requires someone to simply just do the work. I've a workshop on dts this weekend at our localhacker space and the plan is for the people attending to get some handson experience by them doing this work (amongst other things) :) While I agree with you on the fact that more board needs to have the regulators enabled, I really don't think that making some newbies doing it without any schematics (and boards I guess?) They will only be writing patches for boards which I have, and the patches will be tested on the actual boards before submitting them upstream. I will be collecting and double checking all patches before sending them to you. I will let you know if they blow up any boards :) But I do not really expect that to happen. is a good thing when it comes to something that can permanently damage a board. I'd expect that such changes would be carefully done and tested before being submitted. And they will be, see above. Regards, Hans -- Leonardo Canducci -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cagb2v67mpxotyoshartn9w0aahg_bogorgpr2eip1tqwrq0...@mail.gmail.com
