Created attachment 1122354 [details] output of strace -r -f lspci Description of problem: lspci chokes on open("/sys/bus/pci/devices/0000:01:00.0/label in kernels 4.3+, not on kernels 4.2.x and earlier Version-Release number of selected component (if applicable): pciutils-3.3.1-2.fc23.x86_64 How reproducible: enter command lspci or enter "sudo -i", which hangs on lspci Steps to Reproduce: 1. 2. 3. Actual results: lspci finishes but takes about 9 seconds Expected results: lspci should finish within one second Additional info: see bug https://bugzilla.redhat.com/show_bug.cgi?id=1302998 strace -r -f lspci output (attached) shows 3625 8.728309 open("/sys/bus/pci/devices/0000:01:00.0/label", O_RDONLY) = -1 ENOENT (No such file or directory) On kernel 4.2.8 max time observed is 0.7 seconds. This run on a Lenovo W540, SSD, 32GB ram
Created attachment 1123214 [details] strace of "lspci -vvxxx" Same behaviour witnessed on F22: $ time lspci ... real 0m8.735s user 0m0.006s sys 0m0.728s $ uname -a Linux obsidian 4.3.4-200.fc22.x86_64 #1 SMP Mon Jan 25 13:37:15 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux Again a W540. Attached is the result: $ strace -r -f lspci -vvxxx in line with the request in the man page for those options when submitting bugs for lspci.
(In reply to Rich Jarvis from comment #1) > Created attachment 1123214 [details] > strace of "lspci -vvxxx" > > Same behaviour witnessed on F22: > > $ time lspci > > ... > > real 0m8.735s > user 0m0.006s > sys 0m0.728s > > > $ uname -a > Linux obsidian 4.3.4-200.fc22.x86_64 #1 SMP Mon Jan 25 13:37:15 UTC 2016 > x86_64 x86_64 x86_64 GNU/Linux > > > Again a W540. Attached is the result: > > $ strace -r -f lspci -vvxxx > > in line with the request in the man page for those options when submitting > bugs for lspci. Not much movement here. What is your bios level of the W540? BIOS Information Vendor: LENOVO Version: GNET71WW (2.19 ) Release Date: 02/05/2015
Since no reaction on this bug I had another look at /var/log/messages while doing lspci - I see Nouveau is causing the delays: Mar 14 08:05:20 marchost kernel: nouveau 0000:01:00.0: DRM: resuming kernel object tree... Mar 14 08:05:21 marchost kernel: nouveau 0000:01:00.0: devinit: 0x64da[0]: script needs connector type Mar 14 08:05:23 marchost kernel: nouveau 0000:01:00.0: DRM: resuming client object trees... Mar 14 08:05:27 marchost kernel: nouveau 0000:01:00.0: DRM: resuming display... Mar 14 08:05:27 marchost kernel: nouveau 0000:01:00.0: DRM: resuming console... Mar 14 08:05:32 marchost kernel: ACPI Warning: \_SB_.PCI0.PEG_.VID_._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150930/nsarguments-95) Mar 14 08:05:32 marchost kernel: ACPI Warning: \_SB_.PCI0.PEG_.VID_._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150930/nsarguments-95) Mar 14 08:05:32 marchost kernel: nouveau 0000:01:00.0: DRM: suspending console... Mar 14 08:05:32 marchost kernel: nouveau 0000:01:00.0: DRM: suspending display... Mar 14 08:05:32 marchost kernel: nouveau 0000:01:00.0: DRM: evicting buffers... Mar 14 08:05:32 marchost kernel: nouveau 0000:01:00.0: DRM: waiting for kernel channels to go idle... Mar 14 08:05:32 marchost kernel: nouveau 0000:01:00.0: DRM: suspending client object trees... Mar 14 08:05:36 marchost kernel: nouveau 0000:01:00.0: DRM: suspending kernel object tree... The string "nouveau 0000:01:00.0:" matches strace : 8.728309 open("/sys/bus/pci/devices/0000:01:00.0/label", O_RDONLY) = -1 ENOENT (No such file or directory) Don't know if changing the component of this bug to Nouveau is the way to do it, but since noone responded to this bug for over a month I guess I give it a try. Marc
*** This bug has been marked as a duplicate of bug 1302847 ***