You are not logged in.
I just upgraded from 5.7.2 to 5.7.3 on Toshiba laptop and then LXQT, Fluxbox and Openbox all hang on invocation of any window after desktop appears. Is 5.7.3 supposed to deprecate support for old radeon? What other diagnostic info should I post? Couldn't find any errors in DMESG or `journalctl -ef`:
Hardware:
product: Satellite Pro P300
vendor: TOSHIBA
version: PSPCDA-00L00D
serial: Y8084915W
width: 64 bits
capabilities:
SMBIOS version 2.5,
DMI version 2.5,
Symmetric Multi-Processing,
32-bit processes
configuration:
administrator_password: disabled
boot: normal
chassis: notebook
frontpanel_password: unknown
keyboard_password: unknown
power-on_password: disabled
uuid: 2077568A-3292-E411-8FD1-00238B3C6A46
Video on 'radeon' driver (works in kernel 5.7.2):
VGA compatible controller
/0/100/1/0
product: RV635/M86 [Mobility Radeon HD 3650] [1002:9591]
vendor: Advanced Micro Devices, Inc. [AMD/ATI] [1002]
bus info: pci@0000:01:00.0
version: 00
width: 64 bits
clock: 33MHz
capabilities:
Power Management,
PCI Express,
Message Signalled Interrupts,
vga_controller,
bus mastering,
PCI capabilities listing,
extension ROM
configuration:
driver: radeon
latency: 0
resources:
irq: 33
memory: d0000000-dfffffff
memory: cfef0000-cfefffff
ioport: 2000(size=256)
memory: c0000-dffff
Downgrading to Kernel 5.7.2 instantly fixed the problem.
Last edited by splurben (2020-06-19 11:37:26)
Offline
I had the same kinda trouble when I upgraded to 5.7.3 yesterday, and I'm running newer AMD hardware (Ryzen 5 4500U). Upgrading to 5.7.4 (in testing) solved it for me. WiFi wasn't working as well with the current kernel, but I upgraded instead of downgrading, so there might be some 5.7.3 shenanigans -- I didn't investigate much as it's my work laptop and I needed to solve it as quickly as possible. Give it a spin and let us know.
Offline
Thank you, Onyros, I'll wait for 5.7.4 and see how things go. Cheers!
I had the same kinda trouble when I upgraded to 5.7.3 yesterday, and I'm running newer AMD hardware (Ryzen 5 4500U). Upgrading to 5.7.4 (in testing) solved it for me. WiFi wasn't working as well with the current kernel, but I upgraded instead of downgrading, so there might be some 5.7.3 shenanigans -- I didn't investigate much as it's my work laptop and I needed to solve it as quickly as possible. Give it a spin and let us know.
Offline
I had the same kinda trouble when I upgraded to 5.7.3 yesterday, and I'm running newer AMD hardware (Ryzen 5 4500U). Upgrading to 5.7.4 (in testing) solved it for me. WiFi wasn't working as well with the current kernel, but I upgraded instead of downgrading, so there might be some 5.7.3 shenanigans -- I didn't investigate much as it's my work laptop and I needed to solve it as quickly as possible. Give it a spin and let us know.
Same thing on my new ideapad ( Ryzen 5 4500U) sddm doesn't start. Tested with 5.7.3 and lts 5.4.47. Downgraded back to 5.7.2 for quick fix.
Offline
I can confirm that 5.7.3 breaks at least SDDM. Graphical output is freezed but tty terminal works and when I switch back SDDM output gets updated. Downgrading to 5.7.2 fixes the issue.
Btw, I have RX5700 GPU
Offline
If you want to test the new kernel without enabling testing altogether, to see whether it'll break things moving forward or not, you can just download the testing kernel and linux-headers from the Arch Archive -- https://archive.archlinux.org/packages/l/linux/ -- and then upgrade the packages manually with a pacman -U. I hope it was a fleeting kernel problem that slipped by, as I'm not seeing any problems with 5.7.4.
Offline
Regression
https://bugzilla.kernel.org/show_bug.cgi?id=208221
didn't find it's way to Archlinux stable kernel.
I have Ryzen 7 4000 Series
Last edited by eth0:1 (2020-06-19 12:59:43)
Offline
No problems here on 5.7.3 ,
The date command and clock also stay consistent and correct, but i'm using ntp for timekeeping .
Do those having the issue use systemd-timesyncd ?
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
(A works at time B) && (time C > time B ) ≠ (A works at time C)
Offline
Thank you, good suggestion. I will do.
If you want to test the new kernel without enabling testing altogether, to see whether it'll break things moving forward or not, you can just download the testing kernel and linux-headers from the Arch Archive -- https://archive.archlinux.org/packages/l/linux/ -- and then upgrade the packages manually with a pacman -U. I hope it was a fleeting kernel problem that slipped by, as I'm not seeing any problems with 5.7.4.
Offline
If you want to test the new kernel without enabling testing altogether, to see whether it'll break things moving forward or not, you can just download the testing kernel and linux-headers from the Arch Archive -- https://archive.archlinux.org/packages/l/linux/ -- and then upgrade the packages manually with a pacman -U. I hope it was a fleeting kernel problem that slipped by, as I'm not seeing any problems with 5.7.4.
This can lead to broken system, if "testing" kernel depends on new version of its dependencies (like kmod or initramfs or coreutils) which is also in "testing". i.e. if kernel does not work with old version of its dependencies (which is in core) then it will lead to unbootable system.
So if you use anything from "testing" then you must enable "testing" repo as well.
Offline
It can, but it's extremely rare for that to happen. The kernel is one of the safer things to cherry pick. Just make sure you grab any out of tree modules as well.
It isn't in testing anymore, anyway.
Last edited by Scimmia (2020-06-19 15:11:33)
Offline
5.7.4 now in stable repo and solve the issue. Thank for the quick fix.
Offline
This fixed everything up. I'll wait for 5.7.4 and report back here if it works with old radeon hardware.
Thank you, good suggestion. I will do.
Onyros wrote:If you want to test the new kernel without enabling testing altogether, to see whether it'll break things moving forward or not, you can just download the testing kernel and linux-headers from the Arch Archive -- https://archive.archlinux.org/packages/l/linux/ -- and then upgrade the packages manually with a pacman -U. I hope it was a fleeting kernel problem that slipped by, as I'm not seeing any problems with 5.7.4.
Offline
I recommend that you install the LTS kernel, not because you have old hardware, but because Arch Linux generally uses the latest release of the linux kernel and sometimes it can be broken. You can set up the boot loader to allow the selection from several kernels. As for 5.7.3, it was an upstream bug, or I would say a collection of those, clearly showing the weaknesses of the QA process of the kernel team. For me it was not booting at all and I had no other kernel installed for Arch, so I had to use chroot to install the LTS kernel.
Offline