Bug#900087: xserver-xorg-video-amdgpu: AMD RX 550 often locks up
On 2019-08-29 11:29+0200 Moritz Mühlenhoff wrote: I'm seeing the same [instabilities] with RX 570 (which according to Wikipedia should be the same architecture as your RX 550) and the stable Buster release, both with the standard 4.19 kernel and the 5.2 kernel from buster-backports. The short story is after a BIOS upgrade my box has been stable for 27 days and counting. For the longer story read on I am now of the opinion that this whole mess is due to incompatibilities between real AMD Motherboard and graphics chip sets *as sold with initial BIOS* to unsuspecting Linux users in the last couple of years and the AMD documentation of those chip sets (which Linux kernel developers must rely on). So the net result of these initially buggy BIOS's is general Linux-AMD instability. (Do a google search for the terms (without quotes) "amd linux instability" and you will find many sorry tales.) Up to a month ago, I had solved virtually all the night-time almost completely idle lockups by using the kernel parameters idle=nomwait rcu_nocbs=0-15 (where the 15 corresponds to one less than the 16 hardware threads I have on my Ryzen 7 1700 system). But the rcu_nocbs parameter requires a special kernel build with a different configuration (CONFIG_RCU_NOCB_CPU=y) than what Debian supplies. With that custom kernel (4.18.10-custom) the idle lockups dropped to just one for a large number of months, but the active (as opposed to idle) instability issues still caused lockups with up times between them that ranged from 0.5 days to 24 days with an average up time of a week or so. Soon after I reported this box instability to kernel developers I got the advice from them to try a BIOS update. But I put that off for more than a year because such upgrades are considered to be a last resort. The reason for that is they can turn your motherboard into a brick with low but still non zero probability due to a number of different causes (such as AMD/Motherboard vendor screw ups with the BIOS upgrade, internet download errors with the BIOS, power outages during the BIOS upgrade, etc.) Also, there was huge churn in the BIOS upgrades with ASUS (my motherboard vendor) putting out 10 (!) of them since the BIOS I received when I bought the box. So I decided to wait until that churn had settled down, i.e., ASUS had gotten asymptotically closer to the definitive BIOS for my box. And meanwhile the above average up time of ~1 week was livable. The upshot was that 27 days ago I finally arranged for some professionals to do the BIOS upgrade. That made the AMD CBS Power Supply Idle Control option available for the first time, and I set that control from "auto" to "Typical Current Idle" (which apparently is an alternative to setting the custom kernel parameter rcu_nocbs=0-15 for dealing with idle instability issues). The net result of this update is the current up time (still with the same 4.18.10-custom kernel and kernel parameters) is 27 days and counting which is a new record. So I am beginning to hope that this BIOS upgrade has solved the active lockup issues not covered by rcu_nocbs=0-15, and might even (with Power Supply Idle Control set to "Typical Current Idle") solve the idle lockup issues if I drop rcu_nocbs=0-15. Therefore, if the current up time experiment with kernel 4.18.10 custom is able to continue for another month or so, my plan is to try a similar experiment with stock Debian kernel (i.e. without the custom kernel parameter rcu_nocbs=0-15), and if I get, say ~60 days up time with that kernel, I will likely conclude this problem has been completely solved, and I will close this bug report. Meanwhile, I hope if you decide as a last resort to try updating your own BIOS (after careful consideration of the known risks), that will completely solve this issue for you. Alan __ Alan W. Irwin Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __
Bug#938856: xserver-xorg-video-qxl: Python2 removal in sid/bullseye
Package: src:xserver-xorg-video-qxl Version: 0.1.5-2 Severity: normal Tags: sid bullseye User: debian-pyt...@lists.debian.org Usertags: py2removal Python2 becomes end-of-live upstream, and Debian aims to remove Python2 from the distribution, as discussed in https://lists.debian.org/debian-python/2019/07/msg00080.html Your package either build-depends, depends on Python2, or uses Python2 in the autopkg tests. Please stop using Python2, and fix this issue by one of the following actions. - Convert your Package to Python3. This is the preferred option. In case you are providing a Python module foo, please consider dropping the python-foo package, and only build a python3-foo package. Please don't drop Python2 modules, which still have reverse dependencies, just document them. This is the preferred option. - If the package is dead upstream, cannot be converted or maintained in Debian, it should be removed from the distribution. If the package still has reverse dependencies, raise the severity to "serious" and document the reverse dependencies with the BTS affects command. If the package has no reverse dependencies, confirm that the package can be removed, reassign this issue to ftp.debian.org, make sure that the bug priority is set to normal and retitle the issue to "RM: PKG -- removal triggered by the Python2 removal". - If the package has still many users (popcon >= 300), or is needed to build another package which cannot be removed, document that by adding the "py2keep" user tag (not replacing the py2remove tag), using the debian-pyt...@lists.debian.org user. Also any dependencies on an unversioned python package (python, python-dev) must not be used, same with the python shebang. These have to be replaced by python2/python2.7 dependencies and shebang. This is the least preferred option. If the conversion or removal needs action on another package first, please document the blocking by using the BTS affects command, like affects + src:xserver-xorg-video-qxl If there is no py2removal bug for that reverse-dependency, please file a bug on this package (similar to this bug report). If there are questions, please refer to the wiki page for the removal: https://wiki.debian.org/Python/2Removal, or ask for help on IRC #debian-python, or the debian-pyt...@lists.debian.org mailing list.
Bug#938839: xcb-proto: Python2 removal in sid/bullseye
Package: src:xcb-proto Version: 1.13-1 Severity: normal Tags: sid bullseye User: debian-pyt...@lists.debian.org Usertags: py2removal Python2 becomes end-of-live upstream, and Debian aims to remove Python2 from the distribution, as discussed in https://lists.debian.org/debian-python/2019/07/msg00080.html Your package either build-depends, depends on Python2, or uses Python2 in the autopkg tests. Please stop using Python2, and fix this issue by one of the following actions. - Convert your Package to Python3. This is the preferred option. In case you are providing a Python module foo, please consider dropping the python-foo package, and only build a python3-foo package. Please don't drop Python2 modules, which still have reverse dependencies, just document them. This is the preferred option. - If the package is dead upstream, cannot be converted or maintained in Debian, it should be removed from the distribution. If the package still has reverse dependencies, raise the severity to "serious" and document the reverse dependencies with the BTS affects command. If the package has no reverse dependencies, confirm that the package can be removed, reassign this issue to ftp.debian.org, make sure that the bug priority is set to normal and retitle the issue to "RM: PKG -- removal triggered by the Python2 removal". - If the package has still many users (popcon >= 300), or is needed to build another package which cannot be removed, document that by adding the "py2keep" user tag (not replacing the py2remove tag), using the debian-pyt...@lists.debian.org user. Also any dependencies on an unversioned python package (python, python-dev) must not be used, same with the python shebang. These have to be replaced by python2/python2.7 dependencies and shebang. This is the least preferred option. If the conversion or removal needs action on another package first, please document the blocking by using the BTS affects command, like affects + src:xcb-proto If there is no py2removal bug for that reverse-dependency, please file a bug on this package (similar to this bug report). If there are questions, please refer to the wiki page for the removal: https://wiki.debian.org/Python/2Removal, or ask for help on IRC #debian-python, or the debian-pyt...@lists.debian.org mailing list.
Bug#936940: libxcb: Python2 removal in sid/bullseye
Package: src:libxcb Version: 1.13.1-2 Severity: normal Tags: sid bullseye User: debian-pyt...@lists.debian.org Usertags: py2removal Python2 becomes end-of-live upstream, and Debian aims to remove Python2 from the distribution, as discussed in https://lists.debian.org/debian-python/2019/07/msg00080.html Your package either build-depends, depends on Python2, or uses Python2 in the autopkg tests. Please stop using Python2, and fix this issue by one of the following actions. - Convert your Package to Python3. This is the preferred option. In case you are providing a Python module foo, please consider dropping the python-foo package, and only build a python3-foo package. Please don't drop Python2 modules, which still have reverse dependencies, just document them. This is the preferred option. - If the package is dead upstream, cannot be converted or maintained in Debian, it should be removed from the distribution. If the package still has reverse dependencies, raise the severity to "serious" and document the reverse dependencies with the BTS affects command. If the package has no reverse dependencies, confirm that the package can be removed, reassign this issue to ftp.debian.org, make sure that the bug priority is set to normal and retitle the issue to "RM: PKG -- removal triggered by the Python2 removal". - If the package has still many users (popcon >= 300), or is needed to build another package which cannot be removed, document that by adding the "py2keep" user tag (not replacing the py2remove tag), using the debian-pyt...@lists.debian.org user. Also any dependencies on an unversioned python package (python, python-dev) must not be used, same with the python shebang. These have to be replaced by python2/python2.7 dependencies and shebang. This is the least preferred option. If the conversion or removal needs action on another package first, please document the blocking by using the BTS affects command, like affects + src:libxcb If there is no py2removal bug for that reverse-dependency, please file a bug on this package (similar to this bug report). If there are questions, please refer to the wiki page for the removal: https://wiki.debian.org/Python/2Removal, or ask for help on IRC #debian-python, or the debian-pyt...@lists.debian.org mailing list.
Bug#936868: libglvnd: Python2 removal in sid/bullseye
Package: src:libglvnd Version: 1.1.0-1 Severity: normal Tags: sid bullseye User: debian-pyt...@lists.debian.org Usertags: py2removal Python2 becomes end-of-live upstream, and Debian aims to remove Python2 from the distribution, as discussed in https://lists.debian.org/debian-python/2019/07/msg00080.html Your package either build-depends, depends on Python2, or uses Python2 in the autopkg tests. Please stop using Python2, and fix this issue by one of the following actions. - Convert your Package to Python3. This is the preferred option. In case you are providing a Python module foo, please consider dropping the python-foo package, and only build a python3-foo package. Please don't drop Python2 modules, which still have reverse dependencies, just document them. This is the preferred option. - If the package is dead upstream, cannot be converted or maintained in Debian, it should be removed from the distribution. If the package still has reverse dependencies, raise the severity to "serious" and document the reverse dependencies with the BTS affects command. If the package has no reverse dependencies, confirm that the package can be removed, reassign this issue to ftp.debian.org, make sure that the bug priority is set to normal and retitle the issue to "RM: PKG -- removal triggered by the Python2 removal". - If the package has still many users (popcon >= 300), or is needed to build another package which cannot be removed, document that by adding the "py2keep" user tag (not replacing the py2remove tag), using the debian-pyt...@lists.debian.org user. Also any dependencies on an unversioned python package (python, python-dev) must not be used, same with the python shebang. These have to be replaced by python2/python2.7 dependencies and shebang. This is the least preferred option. If the conversion or removal needs action on another package first, please document the blocking by using the BTS affects command, like affects + src:libglvnd If there is no py2removal bug for that reverse-dependency, please file a bug on this package (similar to this bug report). If there are questions, please refer to the wiki page for the removal: https://wiki.debian.org/Python/2Removal, or ask for help on IRC #debian-python, or the debian-pyt...@lists.debian.org mailing list.
Bug#936126: apitrace: Python2 removal in sid/bullseye
Package: src:apitrace Version: 7.1+git20170623.d38a69d6+repack-3 Severity: normal Tags: sid bullseye User: debian-pyt...@lists.debian.org Usertags: py2removal Python2 becomes end-of-live upstream, and Debian aims to remove Python2 from the distribution, as discussed in https://lists.debian.org/debian-python/2019/07/msg00080.html Your package either build-depends, depends on Python2, or uses Python2 in the autopkg tests. Please stop using Python2, and fix this issue by one of the following actions. - Convert your Package to Python3. This is the preferred option. In case you are providing a Python module foo, please consider dropping the python-foo package, and only build a python3-foo package. Please don't drop Python2 modules, which still have reverse dependencies, just document them. This is the preferred option. - If the package is dead upstream, cannot be converted or maintained in Debian, it should be removed from the distribution. If the package still has reverse dependencies, raise the severity to "serious" and document the reverse dependencies with the BTS affects command. If the package has no reverse dependencies, confirm that the package can be removed, reassign this issue to ftp.debian.org, make sure that the bug priority is set to normal and retitle the issue to "RM: PKG -- removal triggered by the Python2 removal". - If the package has still many users (popcon >= 300), or is needed to build another package which cannot be removed, document that by adding the "py2keep" user tag (not replacing the py2remove tag), using the debian-pyt...@lists.debian.org user. Also any dependencies on an unversioned python package (python, python-dev) must not be used, same with the python shebang. These have to be replaced by python2/python2.7 dependencies and shebang. This is the least preferred option. If the conversion or removal needs action on another package first, please document the blocking by using the BTS affects command, like affects + src:apitrace If there is no py2removal bug for that reverse-dependency, please file a bug on this package (similar to this bug report). If there are questions, please refer to the wiki page for the removal: https://wiki.debian.org/Python/2Removal, or ask for help on IRC #debian-python, or the debian-pyt...@lists.debian.org mailing list.
