On 2020-06-26 16:22, Samuel Sieb wrote:
On 6/24/20 11:36 PM, fedora@xxxxxxxxxxxxxx wrote:
Jun 23 18:06:17 e7 kernel: usb 2-7: Disable of device-initiated U1 failed.
Jun 23 18:06:17 e7 kernel: usb 2-7: Disable of device-initiated U2 failed.
There is some issue with handling the SD card modes.
Testing on my other machine (already on f32) did not show the above messages.
However, being a 2009 vintage, makes the hware less sophisticated, and maybe the newer hware
is too smart for its own good?
Jun 23 18:06:23 e7 kernel: xhci_hcd 0000:00:14.0: xHCI host not responding to stop endpoint command.
Jun 23 18:06:23 e7 kernel: xhci_hcd 0000:00:14.0: xHCI host controller not responding, assume dead
Jun 23 18:06:23 e7 kernel: xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
Jun 23 18:06:23 e7 kernel: xhci_hcd 0000:00:14.0: HC died; cleaning up
Something happens with the reader which messes up the USB controller.
Jun 23 18:06:23 e7 kernel: usb 1-2: USB disconnect, device number 2
Jun 23 18:06:23 e7 kernel: usb 1-2.2: USB disconnect, device number 4
Jun 23 18:06:23 e7 kernel: usb 2-3: USB disconnect, device number 2
Jun 23 18:06:23 e7 kernel: usb 2-4: USB disconnect, device number 3
Jun 23 18:06:23 e7 kernel: usb 2-5: USB disconnect, device number 4
Jun 23 18:06:23 e7 kernel: usb 2-7: USB disconnect, device number 0
Jun 23 18:06:23 e7 kernel: usb 1-3: USB disconnect, device number 3
Jun 23 18:06:23 e7 kernel: usb 1-3.1: USB disconnect, device number 6
Jun 23 18:06:23 e7 kernel: usb 1-3.2: USB disconnect, device number 9
Jun 23 18:06:23 e7 kernel: usb 1-3.3: USB disconnect, device number 16
Jun 23 18:06:23 e7 kernel: usb 1-3.4: USB disconnect, device number 17
Jun 23 18:06:23 e7 kernel: usb 1-4: USB disconnect, device number 5
Jun 23 18:06:23 e7 kernel: usb 1-4.1: USB disconnect, device number 8
Jun 23 18:06:23 e7 kernel: usb 1-4.2: USB disconnect, device number 11
Jun 23 18:06:23 e7 kernel: usb 1-4.3: USB disconnect, device number 13
Jun 23 18:06:23 e7 kernel: usb 1-4.4: USB disconnect, device number 15
Jun 23 18:06:23 e7 kernel: usb 1-5: USB disconnect, device number 7
Jun 23 18:06:23 e7 kernel: usb 1-5.1: USB disconnect, device number 12
Jun 23 18:06:23 e7 kernel: usb 1-5.3: USB disconnect, device number 14
Jun 23 18:06:23 e7 kernel: usb 1-11: USB disconnect, device number 10
Then all your very many USB devices get disconnected.
Yes, there are many. A few DVB tuners, a BT dongle, a couple of TEMPer sensors, using three external 4-way hubs.
$ lsusb
Bus 002 Device 004: ID 05e3:0612 Genesys Logic, Inc. Hub
Bus 002 Device 003: ID 0bda:0411 Realtek Semiconductor Corp. 4-Port USB 3.0 Hub
Bus 002 Device 002: ID 05e3:0612 Genesys Logic, Inc. Hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 014: ID 0c45:7401 Microdia TEMPer Temperature Sensor
Bus 001 Device 012: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
Bus 001 Device 007: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
Bus 001 Device 015: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
Bus 001 Device 013: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
Bus 001 Device 011: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
Bus 001 Device 008: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
Bus 001 Device 005: ID 0bda:5411 Realtek Semiconductor Corp. 4-Port USB 2.0 Hub
Bus 001 Device 017: ID 1a86:7584 QinHeng Electronics CH340S
Bus 001 Device 016: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
Bus 001 Device 009: ID 0463:ffff MGE UPS Systems UPS
Bus 001 Device 006: ID 0c45:7401 Microdia TEMPer Temperature Sensor
Bus 001 Device 003: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
Bus 001 Device 021: ID 0c45:7403 Microdia Foot Switch
Bus 001 Device 020: ID 1a40:0101 Terminus Technology Inc. Hub
Bus 001 Device 010: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Jun 23 18:06:23 e7 kernel: usb 2-7: device not accepting address 5, error -22
Your reader appears to be trying to connect again, but not working.
Jun 23 18:07:35 e7 systemd[1]: Stopping MythTV backend service...
Jun 23 18:07:35 e7 mythbackend[2672]: 2020-06-23 18:07:35.817664 C signalhandling.cpp:302:handleSignal Received Terminated: Code 0, PID 1, UID 0, Value 0x00000000
Jun 23 18:07:35 e7 mythbackend[2672]: 2020-06-23 18:07:35.818098 N main_helpers.cpp:743:run_backend MythBackend exiting
Jun 23 18:07:35 e7 mythbackend[2672]: 2020-06-23 18:07:35.818620 I bonjourregister.cpp:26:~BonjourRegister Bonjour: De-registering service '_mythbackend._tcp.' on 'Mythbackend on e7.eyal.emu.id.au'
mythtv tries to shuts down cleanly.
Jun 23 18:07:40 e7 kernel: BUG: kernel NULL pointer dereference, address: 0000000000000200
Jun 23 18:07:40 e7 kernel: #PF: supervisor write access in kernel mode
Jun 23 18:07:40 e7 kernel: #PF: error_code(0x0002) - not-present page
Jun 23 18:07:40 e7 kernel: PGD 84e644067 P4D 84e644067 PUD 898110067 PMD 0
Jun 23 18:07:40 e7 kernel: Oops: 0002 [#1] SMP NOPTI
Jun 23 18:07:40 e7 kernel: CPU: 1 PID: 2672 Comm: mythbackend Not tainted 5.6.13-100.fc30.x86_64 #1
Jun 23 18:07:40 e7 kernel: Hardware name: Gigabyte Technology Co., Ltd. Z390 UD/Z390 UD, BIOS F8 05/24/2019
Jun 23 18:07:40 e7 kernel: RIP: 0010:dvb_frontend_release+0x3b/0x180 [dvb_core]
This is a kernel oops in the dvb driver. Something didn't get cleaned up properly when the device(s) went away.
I assume something else happened after the log that you had available which is not surprising since the kernel was already in a bad state.
Sure did, many processes had as fit, really a big mess.
It would have been useful to know what error messages you got when grub was trying to boot.
If this happened again I will try to capture the messages. Naturally these messages did not go to any log that I know of.
I suggest upgrading the system because there is likely a kernel fix for the initial trigger that caused the whole problem. And possibly a dvb fix as well to avoid the oops. I second the suggestion of testing with a live boot, but if you're going to upgrade anyway, might as well just do that.
Agreed, my sentiment as well.
Still, as this is repeatable, I wonder if running a debug kernel (kernel-debug) will reveal more?
--
Eyal at Home (fedora@xxxxxxxxxxxxxx)
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx
