Description of problem: Todays rpm update to hwdata-0.325-1.fc29 disabled the USB devices on : Manufacturer: ASUSTeK COMPUTER INC. Product Name: PRIME A320M-K bios: Vendor: American Megatrends Inc. Version: 4027 Release Date: 11/04/2018 CPU : AMD Ryzen 5 1500X Quad-Core Processor after downgrading and installing version 324, system is back to normal. A sideffect was, that nemo + nautilus showed: /efi /boot /home / as Devices in the devices list, instead of "nothing" or the usb drives connected. So plugging a usb memory stick to the pc, resulted in "nothing" . it was not listed as a device. Version-Release number of selected component (if applicable): 0.325-1 Add-Info: 00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) Root Complex 00:00.2 IOMMU: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) I/O Memory Management Unit 00:01.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-1fh) PCIe Dummy Host Bridge 00:01.3 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) PCIe GPP Bridge 00:02.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-1fh) PCIe Dummy Host Bridge 00:03.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-1fh) PCIe Dummy Host Bridge 00:03.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) PCIe GPP Bridge 00:04.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-1fh) PCIe Dummy Host Bridge 00:07.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-1fh) PCIe Dummy Host Bridge 00:07.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) Internal PCIe GPP Bridge 0 to Bus B 00:08.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-1fh) PCIe Dummy Host Bridge 00:08.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) Internal PCIe GPP Bridge 0 to Bus B 00:14.0 SMBus: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller (rev 59) 00:14.3 ISA bridge: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge (rev 51) 00:18.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) Data Fabric: Device 18h; Function 0 00:18.1 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) Data Fabric: Device 18h; Function 1 00:18.2 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) Data Fabric: Device 18h; Function 2 00:18.3 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) Data Fabric: Device 18h; Function 3 00:18.4 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) Data Fabric: Device 18h; Function 4 00:18.5 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) Data Fabric: Device 18h; Function 5 00:18.6 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) Data Fabric: Device 18h; Function 6 00:18.7 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) Data Fabric: Device 18h; Function 7 01:00.0 USB controller: Advanced Micro Devices, Inc. [AMD] Device 43bc (rev 02) 01:00.1 SATA controller: Advanced Micro Devices, Inc. [AMD] Device 43b8 (rev 02) 01:00.2 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 43b3 (rev 02) 02:04.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] 300 Series Chipset PCIe Port (rev 02) 02:05.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] 300 Series Chipset PCIe Port (rev 02) 02:06.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] 300 Series Chipset PCIe Port (rev 02) 02:07.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] 300 Series Chipset PCIe Port (rev 02) 05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15) 07:00.0 VGA compatible controller: NVIDIA Corporation GP107 [GeForce GTX 1050] (rev a1) 07:00.1 Audio device: NVIDIA Corporation GP107GL High Definition Audio Controller (rev a1) 08:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Zeppelin/Raven/Raven2 PCIe Dummy Function 08:00.2 Encryption controller: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) Platform Security Processor 08:00.3 USB controller: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) USB 3.0 Host Controller 09:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Zeppelin/Renoir PCIe Dummy Function 09:00.2 SATA controller: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode] (rev 51) 09:00.3 Audio device: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) HD Audio Controller After a reboot at 14:00 .. there is this log entry : Jul 16 14:29:00 linux.fritz.box kernel: usb 1-7: New USB device found, idVendor=0000, idProduct=ef12, bcdDevice= 1.00 Jul 16 14:29:00 linux.fritz.box kernel: usb 1-7: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Jul 16 14:29:00 linux.fritz.box kernel: usb 1-7: Product: Flash Jul 16 14:29:00 linux.fritz.box kernel: usb 1-7: Manufacturer: USB 2.0 Jul 16 14:29:00 linux.fritz.box kernel: usb 1-7: SerialNumber: C8F268A2AD95CBD0 Jul 16 14:29:00 linux.fritz.box kernel: usb-storage 1-7:1.0: USB Mass Storage device detected Jul 16 14:29:00 linux.fritz.box kernel: scsi host10: usb-storage 1-7:1.0 Jul 16 14:29:00 linux.fritz.box mtp-probe[4692]: checking bus 1, device 4: "/sys/devices/pci0000:00/0000:00:01.3/0000:01:00.0/usb1/1-7" Jul 16 14:29:00 linux.fritz.box mtp-probe[4692]: bus: 1, device: 4 was not an MTP device Jul 16 14:29:00 linux.fritz.box mtp-probe[4695]: checking bus 1, device 4: "/sys/devices/pci0000:00/0000:00:01.3/0000:01:00.0/usb1/1-7" Jul 16 14:29:00 linux.fritz.box mtp-probe[4695]: bus: 1, device: 4 was not an MTP device Jul 16 14:29:01 linux.fritz.box kernel: scsi 10:0:0:0: Direct-Access USB 2.0 Flash 1.21 PQ: 0 ANSI: 2 Jul 16 14:29:01 linux.fritz.box kernel: sd 10:0:0:0: Attached scsi generic sg6 type 0 Jul 16 14:29:01 linux.fritz.box kernel: sd 10:0:0:0: [sdf] 4159488 512-byte logical blocks: (2.13 GB/1.98 GiB) Jul 16 14:29:01 linux.fritz.box kernel: sd 10:0:0:0: [sdf] Write Protect is off Jul 16 14:29:01 linux.fritz.box kernel: sd 10:0:0:0: [sdf] Mode Sense: 0b 00 00 08 Jul 16 14:29:01 linux.fritz.box kernel: sd 10:0:0:0: [sdf] No Caching mode page found Jul 16 14:29:01 linux.fritz.box kernel: sd 10:0:0:0: [sdf] Assuming drive cache: write through Jul 16 14:29:01 linux.fritz.box kernel: sdf: Jul 16 14:29:01 linux.fritz.box kernel: sd 10:0:0:0: [sdf] Attached SCSI removable disk But it did not show up.
This seems very weird... hwdata package is basically just collection of text files with device names. Additionally, there was no single change in usb.ids between hwdata-0.324 and hwdata-0.325. I'm using hwdata-0.325-1.fc29.noarch on F29 right now and I see nothing unusual. Are you absolutely sure that it's caused by hwdata package? Did you update only that single package? Have you tried to install it back and do you see the same issue again?
Yes it does look weird, but as i wrote, a dnf downgrade to base and an update to 324 fixed the issue, which was permanent between reboots. The upgrade to 325 happend at 10:00 in the morning, 2 reboots later ( 12:54 and 14:00 ) the problem still persisted until the downgrade-update of only hwdata. Nemo, Nautilus and therefor the desktop too, showed the odd devicelist. There were some other updaters installed on the same time, nss i.e. and some other stuff,that has nothing to do with hardware,usb or anything near it. I would accept, that the package was installed with errors and that the down/update just fixed it, but there is no script to be executed on install, just some textfiles and id lists inside that package. So, what could go wrong here? Sidenote: the mainboard seems to be relativly new, as i.e. flashrom does not recognize the bios chip . May it possible that the mb (or it's compounds) is not in the new id list?
Created attachment 1591723 [details] Desktop with /efi /boot/ / /home under hwdata-325
Created attachment 1591724 [details] Desktop with normal view under hwdata-324
Created attachment 1591725 [details] View of Nautilus AS ROOT with hwdata-325
Update: we reinstalled hwdata 325 , rebooted and the error was there again. downgrading, updating to 324 , reboot, error was gone. It's caused by that package, so something else must have changed too. Further testing with 325 showed, that the USB drive does get mounted FOR ROOT, as you can see in the Nautilus screenshot, instead for the active desktop user. that makes the messup complete :)
just forgot: Dismounting USB drive: [ 489.478639] usb 1-7: USB disconnect, device number 4 Mounting (hwdata 325 ) of USB drive: [ 511.537012] usb 1-7: new high-speed USB device number 5 using xhci_hcd [ 511.748427] usb 1-7: New USB device found, idVendor=0000, idProduct=ef12, bcdDevice= 1.00 [ 511.748430] usb 1-7: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 511.748432] usb 1-7: Product: Flash [ 511.748434] usb 1-7: Manufacturer: USB 2.0 [ 511.748436] usb 1-7: SerialNumber: C8F268A2AD95CBD0 [ 511.755428] usb-storage 1-7:1.0: USB Mass Storage device detected [ 511.755568] scsi host10: usb-storage 1-7:1.0 [ 512.780929] scsi 10:0:0:0: Direct-Access USB 2.0 Flash 1.21 PQ: 0 ANSI: 2 [ 512.781448] sd 10:0:0:0: Attached scsi generic sg6 type 0 [ 512.781567] sd 10:0:0:0: [sdf] 4159488 512-byte logical blocks: (2.13 GB/1.98 GiB) [ 512.781752] sd 10:0:0:0: [sdf] Write Protect is off [ 512.781755] sd 10:0:0:0: [sdf] Mode Sense: 0b 00 00 08 [ 512.781927] sd 10:0:0:0: [sdf] No Caching mode page found [ 512.781929] sd 10:0:0:0: [sdf] Assuming drive cache: write through [ 512.783605] sdf: [ 512.785577] sd 10:0:0:0: [sdf] Attached SCSI removable disk
Thanks for the investigation! Let's compare old and new version of the package. I see nothing wrong in ownership, permissions etc: $ rpm -q hwdata -hwdata-0.324-1.fc29.noarch +hwdata-0.325-1.fc29.noarch $ rpm -qlv hwdata --rw-r--r-- 1 root root 884 Jun 3 10:46 /usr/lib/modprobe.d/dist-blacklist.conf -drwxr-xr-x 2 root root 0 Jun 3 10:46 /usr/share/doc/hwdata --rw-r--r-- 1 root root 18092 Jun 3 09:46 /usr/share/doc/hwdata/COPYING --rw-r--r-- 1 root root 175 Jun 3 09:46 /usr/share/doc/hwdata/LICENSE -drwxr-xr-x 2 root root 0 Jun 3 10:46 /usr/share/hwdata --rw-r--r-- 1 root root 1778725 Jun 3 10:46 /usr/share/hwdata/iab.txt --rw-r--r-- 1 root root 3983342 Jun 3 10:46 /usr/share/hwdata/oui.txt --rw-r--r-- 1 root root 1173661 Jun 3 10:46 /usr/share/hwdata/pci.ids --rw-r--r-- 1 root root 55049 Jun 3 10:46 /usr/share/hwdata/pnp.ids --rw-r--r-- 1 root root 610768 Jun 3 10:46 /usr/share/hwdata/usb.ids +-rw-r--r-- 1 root root 884 Jun 27 12:33 /usr/lib/modprobe.d/dist-blacklist.conf +drwxr-xr-x 2 root root 0 Jun 27 12:33 /usr/share/doc/hwdata +-rw-r--r-- 1 root root 18092 Jun 27 10:39 /usr/share/doc/hwdata/COPYING +-rw-r--r-- 1 root root 175 Jun 27 10:39 /usr/share/doc/hwdata/LICENSE +drwxr-xr-x 2 root root 0 Jun 27 12:33 /usr/share/hwdata +-rw-r--r-- 1 root root 1778725 Jun 27 12:33 /usr/share/hwdata/iab.txt +-rw-r--r-- 1 root root 4001315 Jun 27 12:33 /usr/share/hwdata/oui.txt +-rw-r--r-- 1 root root 1178553 Jun 27 12:33 /usr/share/hwdata/pci.ids +-rw-r--r-- 1 root root 55049 Jun 27 12:33 /usr/share/hwdata/pnp.ids +-rw-r--r-- 1 root root 610768 Jun 27 12:33 /usr/share/hwdata/usb.ids Only two files were changed (ignoring the change in timestamp): $ rpmdiff -i T ./hwdata-0.324-1.fc29.noarch.rpm ./hwdata-0.325-1.fc29.noarch.rpm S.5........ /usr/share/hwdata/oui.txt S.5........ /usr/share/hwdata/pci.ids Looking into pci.ids changes... no id was discarded, five ids were renamed. The rest are newly added ids. Diff attached. Does any of the changed/added id seem suspicious? Then we have changes in oui.txt. Many of them. To be honest, I have no idea whether this can cause such a problem. If you're willing to, I would suggest to install -324 version and then manually replace pci.ids and oui.txt one by one by files from -325 version to find which of them causes the issue. I can also build a scratch package for you with currently released databases to check whether it's going to work. Right now I can see there are updates in iab.txt, oui.txt and few in pci.ids.
Created attachment 1591740 [details] diff between pci.ids file in hwdata-324 and hwdata-325
i think i can manage it without a package.. It will take some time..
(In reply to customercare from comment #10) > i think i can manage it without a package.. > It will take some time.. No problem. In my opinion it's fine to use old version as a workaround and you can try -326 later in August whether it works as expected.
First test: old pci.ids and the NEW "4001315 27. Jun 12:33 oui.txt" Result: FAILED Next test: old pci.ids, old oui.txt Result: *OK*
Created attachment 1591741 [details] verbose LSPCI to check it out.
Update: We updated the ASUS Bios to the latest version 5004 from 18.6.2019 . Things got worse, as now hw 324 also shows the incorrect drives and does not mount the USB drive/stick anymore. Shall i escalate this to ASUS ?
(In reply to customercare from comment #14) > Update: > > We updated the ASUS Bios to the latest version 5004 from 18.6.2019 . > > Things got worse, as now hw 324 also shows the incorrect drives and does not > mount the USB drive/stick anymore. > > Shall i escalate this to ASUS ? Yes please, thank you.
Update: After the bios update, the system showed the wrong drives. Yesterday, for the entire day, it showed the wrong drives. Today: Without ANY updates installed, the falsely shown drives are gone. USB working again. My Conclusion: some system init routine seems to have a RACE going on. What do we need to supply to make this visible? Journal log of two different boots maybe?
This is beyond my knowledge. I suggest we change component of the bug to... kernel, probably?
different kernels show the same symptoms 5.1.15 -> 5.1.18 tested.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There are a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 29 kernel bugs. Fedora 29 has now been rebased to 5.2.9-100.fc29. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 30, and are still experiencing this issue, please change the version to Fedora 30. If you experience different issues, please open a new bug report for those.
Update: The ASUS mainboards firmware got updated to "5702" , but the described problem is not fixed. It happens not quite as often as with the old firmware, but it's still present.
This message is a reminder that Fedora 29 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '29'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 29 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 29 changed to end-of-life (EOL) status on 2019-11-26. Fedora 29 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.