February 2022 - openSUSE Users - openSUSE Mailing Lists

[oS-en] [Solved] USB trouble af
by Carlos E. R. 05 Feb '22

05 Feb '22

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The issue is solved, but as it may help other people searching for issues, I post it. Actually, I solved it after writing the post, when I had a new idea to try ;-) Actual solution at the bottom. So the text below is as written before I solved the problem, so it is in the present tense. Convert mentally to "past", there are too many things to manually edit ;-) I have trouble today with USB. I noticed the keyboard not responding at times, too, but I don't think it is the keyboard at fault, because I disconnected it and the messages in the log did not stop: <0.3> 2022-02-04T16:02:10.505904+01:00 Telcontar kernel - - - [13512.013430] usb 3-2: device descriptor read/64, error -110 <0.3> 2022-02-04T16:02:26.429904+01:00 Telcontar kernel - - - [13527.937480] usb 3-2: device descriptor read/64, error -110 <0.6> 2022-02-04T16:02:26.737899+01:00 Telcontar kernel - - - [13528.245446] usb 3-2: new low-speed USB device number 69 using xhci_hcd <0.3> 2022-02-04T16:02:42.550312+01:00 Telcontar kernel - - - [13544.061549] usb 3-2: device descriptor read/64, error -110 <0.3> 2022-02-04T16:02:58.218032+01:00 Telcontar kernel - - - [13559.725587] usb 3-2: device descriptor read/64, error -110 <0.6> 2022-02-04T16:02:58.325919+01:00 Telcontar kernel - - - [13559.833895] usb usb3-port2: attempt power cycle <0.3> 2022-02-04T16:02:58.405913+01:00 Telcontar kernel - - - [13559.913695] debugfs: Directory '03' with parent 'devices' already present! <0.6> 2022-02-04T16:02:58.809916+01:00 Telcontar kernel - - - [13560.317578] usb 3-2: new low-speed USB device number 70 using xhci_hcd <0.4> 2022-02-04T16:03:08.435534+01:00 Telcontar kernel - - - [13569.946944] usb 3-2: Device not responding to setup address. <0.3> 2022-02-04T16:03:08.437901+01:00 Telcontar kernel - - - [13569.947312] debugfs: Directory '04' with parent 'devices' already present! <0.4> 2022-02-04T16:03:18.271274+01:00 Telcontar kernel - - - [13579.782227] usb 3-2: Device not responding to setup address. <0.3> 2022-02-04T16:03:18.481921+01:00 Telcontar kernel - - - [13579.989623] usb 3-2: device not accepting address 70, error -71 <0.3> 2022-02-04T16:03:18.481935+01:00 Telcontar kernel - - - [13579.990023] debugfs: Directory '06' with parent 'devices' already present! <0.6> 2022-02-04T16:03:18.678068+01:00 Telcontar kernel - - - [13580.185623] usb 3-2: new low-speed USB device number 71 using xhci_hcd <0.4> 2022-02-04T16:03:28.302733+01:00 Telcontar kernel - - - [13589.814221] usb 3-2: Device not responding to setup address. <0.3> 2022-02-04T16:03:28.305898+01:00 Telcontar kernel - - - [13589.814625] debugfs: Directory '07' with parent 'devices' already present! <0.4> 2022-02-04T16:03:38.141900+01:00 Telcontar kernel - - - [13599.650482] usb 3-2: Device not responding to setup address. <0.3> 2022-02-04T16:03:38.353902+01:00 Telcontar kernel - - - [13599.861695] usb 3-2: device not accepting address 71, error -71 <0.3> 2022-02-04T16:03:38.353914+01:00 Telcontar kernel - - - [13599.861989] usb usb3-port2: unable to enumerate USB device Telcontar:~ # lsusb Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 005 Device 005: ID 05e3:0608 Genesys Logic, Inc. Hub <-- UPS? Bus 005 Device 002: ID 046d:c404 Logitech, Inc. TrackMan Wheel Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 005: ID 04d9:2020 Holtek Semiconductor, Inc. USB Keyboard Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Telcontar:~ # Telcontar:~ # uname -a Linux Telcontar 5.3.18-150300.59.43-default #1 SMP Sun Jan 23 19:27:23 UTC 2022 (c76af22) x86_64 x86_64 x86_64 GNU/Linux Telcontar:~ # The only things connected to the USB now are the keyboard, the mouse, and an UPS. Looking at previous log entries I see: Telcontar:~ # zgrep "usb 3-2:" /var/log/messages-20220203.xz <0.6> 2022-01-27T11:36:21.240553+01:00 Telcontar kernel - - - [30257.429520] usb 3-2: reset low-speed USB device number 3 using xhci_hcd <0.6> 2022-01-27T18:19:25.226068+01:00 Telcontar kernel - - - [39132.001180] usb 3-2: reset low-speed USB device number 3 using xhci_hcd <0.6> 2022-01-28T11:43:40.193992+01:00 Telcontar kernel - - - [65096.224584] usb 3-2: reset low-speed USB device number 3 using xhci_hcd <0.6> 2022-01-28T23:19:36.212612+01:00 Telcontar kernel - - - [82710.907141] usb 3-2: reset low-speed USB device number 3 using xhci_hcd <0.6> 2022-01-29T00:27:38.989871+01:00 Telcontar kernel - - - [ 6.552012] usb 3-2: new low-speed USB device number 2 using xhci_hcd <0.6> 2022-01-29T00:27:38.989925+01:00 Telcontar kernel - - - [ 7.598700] usb 3-2: New USB device found, idVendor=0463, idProduct=ffff, bcdDevice= 0.01 <0.6> 2022-01-29T00:27:38.989925+01:00 Telcontar kernel - - - [ 7.603853] usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=4 <0.6> 2022-01-29T00:27:38.989925+01:00 Telcontar kernel - - - [ 7.608948] usb 3-2: Product: ELLIPSE <0.6> 2022-01-29T00:27:38.989930+01:00 Telcontar kernel - - - [ 7.614002] usb 3-2: Manufacturer: EATON <0.6> 2022-01-29T00:27:38.989930+01:00 Telcontar kernel - - - [ 7.618987] usb 3-2: SerialNumber: 000000000 <0.6> 2022-01-29T12:53:44.212043+01:00 Telcontar kernel - - - [14276.521334] usb 3-2: reset low-speed USB device number 2 using xhci_hcd <0.6> 2022-01-29T19:53:50.190505+01:00 Telcontar kernel - - - [24902.096326] usb 3-2: reset low-speed USB device number 2 using xhci_hcd <0.6> 2022-01-30T13:02:30.443420+01:00 Telcontar kernel - - - [ 6.492010] usb 3-2: new low-speed USB device number 2 using xhci_hcd <0.6> 2022-01-30T13:02:30.443458+01:00 Telcontar kernel - - - [ 7.535702] usb 3-2: New USB device found, idVendor=0463, idProduct=ffff, bcdDevice= 0.01 <0.6> 2022-01-30T13:02:30.443493+01:00 Telcontar kernel - - - [ 7.540599] usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=4 <0.6> 2022-01-30T13:02:30.443495+01:00 Telcontar kernel - - - [ 7.545485] usb 3-2: Product: ELLIPSE <0.6> 2022-01-30T13:02:30.443496+01:00 Telcontar kernel - - - [ 7.550328] usb 3-2: Manufacturer: EATON <0.6> 2022-01-30T13:02:30.443497+01:00 Telcontar kernel - - - [ 7.555128] usb 3-2: SerialNumber: 000000000 <0.6> 2022-01-30T20:13:37.216073+01:00 Telcontar kernel - - - [14716.037398] usb 3-2: reset low-speed USB device number 2 using xhci_hcd <0.6> 2022-01-31T11:17:15.195212+01:00 Telcontar kernel - - - [40118.790690] usb 3-2: reset low-speed USB device number 2 using xhci_hcd <0.6> 2022-01-31T18:56:33.207103+01:00 Telcontar kernel - - - [55638.682915] usb 3-2: reset low-speed USB device number 2 using xhci_hcd <0.6> 2022-02-01T08:05:36.186233+01:00 Telcontar kernel - - - [85187.438786] usb 3-2: reset low-speed USB device number 2 using xhci_hcd <0.6> 2022-02-01T17:56:27.206231+01:00 Telcontar kernel - - - [102700.937967] usb 3-2: reset low-speed USB device number 2 using xhci_hcd <0.6> 2022-02-02T08:58:42.228372+01:00 Telcontar kernel - - - [136057.971264] usb 3-2: reset low-speed USB device number 2 using xhci_hcd <0.6> 2022-02-02T19:00:50.221197+01:00 Telcontar kernel - - - [152279.349753] usb 3-2: reset low-speed USB device number 2 using xhci_hcd Telcontar:~ # - --- Solution It was when pasting the test just above I noticed that usb 3-2 was "EATON", thus the UPS. I did not know before which was the culprit. So suspicions were a kernel update just before this happened, or broken hardware at the computer USB port because I had accidentally powered off the UPS while the computer was active. But then, being less dramatic, just the UPS chipset hanging. So I halted the computer, powered off the UPS at is buttton, then powered off the mains before the UPS. And on the next power up, the problem was gone :-) So the problem was that, chipset hung up at the UPS. - -- Cheers Carlos E. R. (from 15.3 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCYf5/Hxwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVo5cAnRNRcug7TIwEtUmCyf7c pUJDM/1+AKCN5ayWA8vRdxxnnD5BYtgO9IJCBw== =7tte -----END PGP SIGNATURE-----

1 0

VMWare Workstation Pro kernel module error
by Simon Connah 04 Feb '22

04 Feb '22

Hi, Sorry to send two messages to the mailing list in the past hour but I'm not sure what I am doing wrong. The full error log can be found here: https://gist.github.com/simonconnah/626bcc3ba426990757f900f3a59ad5cf Does anyone have any experience with this sort of issue? Thank you. Simon.

2 3

OpenSUSE Tumbleweed init.d directory?
by Simon Connah 04 Feb '22

04 Feb '22

Hi, I'm trying to install VMWare Workstation Pro 16.2.1 on a new install of Tumbleweed with all updates installed and when I run the installer it asks me this question: System service scripts directory (commonly /etc/init.d).: But I'm not sure what to put in there. Does anyone know by any chance? Thank you. Simon.

2 2

[oS-en] Leap 15.3: can't mount /home
by Carlos E. R. 03 Feb '22

03 Feb '22

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Unknown filesystem 'reiserfs' :-/ - -- Cheers Carlos E. R. (from 15.2 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCYcvG+hwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVeQcAn1pPUk98DaNg71a+xWkt aO8+J/NUAJ9+K6U01YofXopVhWGaPh6VIt2Ygw== =nhEU -----END PGP SIGNATURE-----

6 29

[oS-en] Reiserfs ongoing problem
by Carlos E. R. 02 Feb '22

02 Feb '22

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I have a problem with my one remaining reiserfs partition on rotating rust. The problem I initially detected was that telling the machine to hibernate sometimes appeared to stall, and I had to force a power off (via physical power switch) to recover. In fact, I found out later, the kernel was simply syncing one partition, and this operation would take half an hour, which it is absurd. Later I found out that it was only one partition affected, and this partition was (is) reiserfs. Then I guessed that the slow operation was syncing the metadata (the time stamps) of the news (nntp) spool. Traditionally a news server touches (and use) the access timestamp each time a post is read, affecting one file per read. With the default mount options used nowdays this modification stays in RAM for long, many hours. So, the cronjob that scans the news spool now also calls sync on that filesystem, and when hibernating I call sync in advance. This improved things, but not completely. Thus I finally resorted to moving the news spool only to another reiserfs partition created on an SSD disk, which usually syncs in seconds, instead of half an hour. So I thought, problem solved. But later on I noticed that the sync operation prior to hibernating on the old reiserfs partition still takes long, but only on some days - even if nothing writes there now. This is astonishing. Look, last Monday: Telcontar:~ # hibernate 2021-12-13 04:26:18+01:00 Checking news to send 2021-12-13 04:26:22+01:00 Syncing rm: cannot remove '/var/lib/news/bin/cronscriptparafetchnews.enabled': No such file or directory 2021-12-13 06:06:09+01:00 synced. Now screensaver xscreensaver-command: no screensaver is running on display :0.0 touch /var/lib/news/bin/cronscriptparafetchnews.enabled Telcontar:~ # An hour and a half to sync a not used partition! (I know it is only one partition because I monitor it with gkrellm) Hibernation script: date --rfc-3339=seconds echo Checking news to send /var/lib/news/bin/cronscriptparaenviarnewspendientes date --rfc-3339=seconds echo Syncing rm /var/lib/news/bin/cronscriptparafetchnews.enabled strace -o /tmp/hibernate.strace sync date --rfc-3339=seconds echo "synced. Now screensaver" xscreensaver-command -lock sleep 3 #sudo chvt 10 #sleep 1 sudo /usr/local/sbin/beep sleep 1 #systemctl hibernate sudo /usr/bin/systemctl hibernate The structure of the mount is this: Telcontar:~ # mount | grep sdc9 /dev/sdc9 on /data/Lareiserfs type reiserfs (rw,relatime,lazytime,user_xattr,acl) /dev/sdc9 on /usr/src type reiserfs (rw,relatime,lazytime,user_xattr,acl) /dev/sdc9 on /home/cer/terrasync type reiserfs (rw,relatime,lazytime,user_xattr,acl) /dev/sdc9 on /data/homedvl type reiserfs (rw,relatime,lazytime,user_xattr,acl) /dev/sdc9 on /usr/share/flightgear type reiserfs (rw,relatime,lazytime,user_xattr,acl) Telcontar:~ # The first one is the actual mount, the rest are bind mounts - fstab: LABEL=c_data_reiser /data/Lareiserfs reiserfs acl,user_xattr,barrier=flush,lazytime 1 3 /data/Lareiserfs/gamedata/flightgear /usr/share/flightgear none bind 0 0 /data/Lareiserfs/gamedata/terrasync /home/cer/terrasync none bind 0 0 /data/Lareiserfs/data_homedvl /data/homedvl none bind 0 0 /data/Lareiserfs/usr_src /usr/src none bind 0 0 Now I have added entries to my hibernate script to sync each reiserfs bind mount separately, find out which one it is, if any. - -- Cheers Carlos E. R. (from 15.2 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCYbiC3Bwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVNQ0An0UB/PrQobQOFtt1bA5b ll35Ej7FAJ9E6b3Mh88V1OcIbudlN0SwdavIhw== =hvzD -----END PGP SIGNATURE-----

5 11

15.3, updates a few moments ago, what are those update-test-.... updates? similar to early alpha/beta stages?
by cagsm 02 Feb '22

02 Feb '22

List, some simple 15.3 just applied some update-test-..... named updates. What gives? I am not on alpha or beta level repos or anything? bug? testing on whole userbase? 2022-02-01 20:17:34|install|update-test-affects-package-manager|5.1-33.2|x86_64||repo-sle-update|b30701eb358b95cabf7a724565bab263629b1dccdec9b50cb2113a0e34b9f6de| 2022-02-01 20:17:34|install|update-test-interactive|5.1-33.2|x86_64||repo-sle-update|f2211a27237a471cf6f558c22e63119d6e3a30af1d065be3697e53714d105ff3| 2022-02-01 20:17:34|install|update-test-optional|5.1-33.2|x86_64||repo-sle-update|b40ea677c146f8494f954531b5eac29bd88912386069039fbf7c397bdad7a41d| 2022-02-01 20:17:35|install|update-test-reboot-needed|5.1-33.2|x86_64||repo-sle-update|09f0465f6e500c6467f1c0e0865a268c0259386198a18c833b5f4049126212c2| 2022-02-01 20:17:35|install|update-test-security|5.1-33.2|x86_64||repo-sle-update|85b096976235af18d085a52cbfa1d31c40336e6120c396b3feafb264c09ef1ce| 2022-02-01 20:17:35|install|update-test-trivial|5.1-33.2|x86_64||repo-sle-update|e219dd6c3a92ccb691bafe7cfbd338d61160dc33e1470fe266e8f2dc57be4b60| ty

5 12

Leap 15.3 latest kernel update gibts bootup freeze on amd gpu based - nomodeset needed to work again
by cagsm 01 Feb '22

01 Feb '22

Hello list dwellers, some simplistic leap 15.3 system, just applied tonights kernel update fix currently installed packages, dunno why after reboot surplus kernels dont get cleaned up btw. used to be in the past? anyhow: rpm -aq | grep kernel | sort kernel-default-5.3.18-150300.59.43.1.x86_64 kernel-default-5.3.18-59.40.1.x86_64 kernel-default-extra-5.3.18-150300.59.43.1.x86_64 kernel-default-extra-5.3.18-59.40.1.x86_64 kernel-default-optional-5.3.18-150300.59.43.1.x86_64 kernel-default-optional-5.3.18-59.40.1.x86_64 kernel-firmware-all-20210208-2.4.noarch kernel-firmware-amdgpu-20210208-2.4.noarch kernel-firmware-ath10k-20210208-2.4.noarch kernel-firmware-ath11k-20210208-2.4.noarch kernel-firmware-atheros-20210208-2.4.noarch kernel-firmware-bluetooth-20210208-2.4.noarch kernel-firmware-bnx2-20210208-2.4.noarch kernel-firmware-brcm-20210208-2.4.noarch kernel-firmware-chelsio-20210208-2.4.noarch kernel-firmware-dpaa2-20210208-2.4.noarch kernel-firmware-i915-20210208-2.4.noarch kernel-firmware-intel-20210208-2.4.noarch kernel-firmware-iwlwifi-20210208-2.4.noarch kernel-firmware-liquidio-20210208-2.4.noarch kernel-firmware-marvell-20210208-2.4.noarch kernel-firmware-media-20210208-2.4.noarch kernel-firmware-mediatek-20210208-2.4.noarch kernel-firmware-mellanox-20210208-2.4.noarch kernel-firmware-mwifiex-20210208-2.4.noarch kernel-firmware-network-20210208-2.4.noarch kernel-firmware-nfp-20210208-2.4.noarch kernel-firmware-nvidia-20210208-2.4.noarch kernel-firmware-platform-20210208-2.4.noarch kernel-firmware-prestera-20210208-2.4.noarch kernel-firmware-qlogic-20210208-2.4.noarch kernel-firmware-radeon-20210208-2.4.noarch kernel-firmware-realtek-20210208-2.4.noarch kernel-firmware-serial-20210208-2.4.noarch kernel-firmware-sound-20210208-2.4.noarch kernel-firmware-ti-20210208-2.4.noarch kernel-firmware-ueagle-20210208-2.4.noarch kernel-firmware-usb-network-20210208-2.4.noarch purge-kernels-service-0-8.3.1.noarch right now only via nomodeset as additional grub2 parameter in that command line there able to boot into this system. otherwise after grub2 screen and selection or timeout into boot, whole screen gets back, becomes powersaved (monitor says no signal, powersaves itself thereafter) no ctrl alt del no numlock LED no nothing. no hdd events/LED whole system needs to use the reset button to come back up again into BIOS/POST and grub2 screen again and continuing there only with additional nomodeset parameter. some elderly amd / amd gpu/chipset based system. worked neatly until a few minutes ago before the kernel update :( Linux linux 5.3.18-150300.59.43-default #1 SMP Sun Jan 23 19:27:23 UTC 2022 (c76af22) x86_64 x86_64 x86_64 GNU/Linux 01:05.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RS880 [Radeon HD 4200] (prog-if 00 [VGA controller]) Subsystem: ASUSTeK Computer Inc. M4A785TD Motherboard Flags: bus master, fast devsel, latency 0, IRQ 10, NUMA node 0 Memory at f0000000 (32-bit, prefetchable) [size=128M] I/O ports at c000 [size=256] Memory at fe9f0000 (32-bit, non-prefetchable) [size=64K] Memory at fe800000 (32-bit, non-prefetchable) [size=1M] [virtual] Expansion ROM at 000c0000 [disabled] [size=128K] Capabilities: [50] Power Management version 3 Capabilities: [a0] MSI: Enable- Count=1/1 Maskable- 64bit+ Kernel modules: radeon 01:05.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] RS880 HDMI Audio [Radeon HD 4200 Series] Subsystem: ASUSTeK Computer Inc. M4A785TD Motherboard Flags: bus master, fast devsel, latency 0, IRQ 19, NUMA node 0 Memory at fe9e8000 (32-bit, non-prefetchable) [size=16K] Capabilities: [50] Power Management version 3 Capabilities: [a0] MSI: Enable- Count=1/1 Maskable- 64bit+ Kernel driver in use: snd_hda_intel Kernel modules: snd_hda_intel what now? kernel rpm changelog showd quite a lot of amd/drm fixage and stuff. anyone able to fix this quickly? thanks. TIA

7 10