Bug 1730328 - hwdata update to 0.325-1 disabled USB and has other implications
Summary: hwdata update to 0.325-1 disabled USB and has other implications
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 29
Hardware: x86_64
OS: Linux
unspecified
urgent
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-07-16 13:14 UTC by customercare
Modified: 2019-11-27 23:15 UTC (History)
22 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-11-27 23:15:37 UTC


Attachments (Terms of Use)
Desktop with /efi /boot/ / /home under hwdata-325 (50.76 KB, image/jpeg)
2019-07-18 08:28 UTC, customercare
no flags Details
Desktop with normal view under hwdata-324 (49.83 KB, image/jpeg)
2019-07-18 08:28 UTC, customercare
no flags Details
View of Nautilus AS ROOT with hwdata-325 (423.26 KB, image/png)
2019-07-18 08:29 UTC, customercare
no flags Details
diff between pci.ids file in hwdata-324 and hwdata-325 (17.33 KB, patch)
2019-07-18 10:47 UTC, Vitezslav Crhonek
no flags Details | Diff
verbose LSPCI to check it out. (27.16 KB, text/plain)
2019-07-18 11:10 UTC, customercare
no flags Details

Description customercare 2019-07-16 13:14:10 UTC
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.

Comment 1 Vitezslav Crhonek 2019-07-17 13:29:48 UTC
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?

Comment 2 customercare 2019-07-17 14:18:10 UTC
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?

Comment 3 customercare 2019-07-18 08:28:34 UTC
Created attachment 1591723 [details]
Desktop with /efi /boot/ / /home   under hwdata-325

Comment 4 customercare 2019-07-18 08:28:59 UTC
Created attachment 1591724 [details]
Desktop with normal view under hwdata-324

Comment 5 customercare 2019-07-18 08:29:30 UTC
Created attachment 1591725 [details]
View of Nautilus AS ROOT with hwdata-325

Comment 6 customercare 2019-07-18 08:32:44 UTC
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 :)

Comment 7 customercare 2019-07-18 08:33:44 UTC
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

Comment 8 Vitezslav Crhonek 2019-07-18 10:45:43 UTC
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.

Comment 9 Vitezslav Crhonek 2019-07-18 10:47:06 UTC
Created attachment 1591740 [details]
diff between pci.ids file in hwdata-324 and hwdata-325

Comment 10 customercare 2019-07-18 10:51:51 UTC
i think i can manage it without a package..
It will take some time..

Comment 11 Vitezslav Crhonek 2019-07-18 11:08:37 UTC
(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.

Comment 12 customercare 2019-07-18 11:09:37 UTC
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*

Comment 13 customercare 2019-07-18 11:10:55 UTC
Created attachment 1591741 [details]
verbose LSPCI to check it out.

Comment 14 customercare 2019-07-21 21:15:08 UTC
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 ?

Comment 15 Vitezslav Crhonek 2019-07-23 07:54:19 UTC
(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.

Comment 16 customercare 2019-07-23 09:22:30 UTC
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?

Comment 17 Vitezslav Crhonek 2019-07-23 09:43:21 UTC
This is beyond my knowledge. I suggest we change component of the bug to... kernel, probably?

Comment 18 customercare 2019-07-25 09:52:11 UTC
different kernels show the same symptoms

5.1.15 -> 5.1.18 tested.

Comment 19 Justin M. Forbes 2019-08-20 17:39:18 UTC
*********** 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.

Comment 20 customercare 2019-08-20 17:51:05 UTC
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.

Comment 21 Ben Cotton 2019-10-31 18:56:11 UTC
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.

Comment 22 Ben Cotton 2019-11-27 23:15:37 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.