Request to refresh: pci-utils, libpci and usb-utils

[maro]

As the world of new devices does not stand still it might be worth to give all the relevant extensions a refresh.

AFAIK the pci-utils version in the repository is v3.1.4 (from 2009-08-14) and a newer version (from 2010-01-31) is available. In any case an even more recent update of the PCI IDs (from 2011-05-25) appears to be available. Whilst I realize that an update script for the PCI IDs is part of the extension, it might still be worthwhile to include the most recent version in the extension as it often could be used for troubleshooting when a user is not yet online.

With the same logic it seems that 'usb-utils.tcz' might benefit from a refresh as well, as I could spot a newer version (from 2010-10-22). Likewise a more recent update of the USB IDs (from 2011-04-15) could also be found. OTOH the two sources listed in 'libusb.tcz.info' appear to be still the most recent releases.

Whilst collecting all those details I spotted that the development files had been split out of the 'libusb.tcz' extension. With this in mind one wonders whether a similar operation could be applied to 'libpci.tcz'.

[Juanito]

OK, let me have a look this weekend

[Juanito]

posted

[maro]

Thanks for the quick turn around. It's interesting to learn that the weekend happens in your part of the world on different days than here in NZ. 

Unfortunately a little issue seemed to have crept into the 'libpci.tcz' extension (i.e. the loss of the 'libpci.so.3' symbolic link):

Code: [Select]

tc@box:~$ lspci
lspci: error while loading shared libraries: libpci.so.3: cannot open shared object file: No such file or directory
tc@box:~$ ( cd /usr/local/lib ; sudo ln -s libpci.so.3.1.7 libpci.so.3 )
tc@box:~$ sudo /sbin/ldconfig 2>/dev/null
tc@box:~$ lspci
00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02)
00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II]
00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II]
00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)
00:02.0 VGA compatible controller: Cirrus Logic GD 5446
00:03.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet Controller (rev 03)
00:04.0 Multimedia audio controller: Intel Corporation 82801AA AC'97 Audio Controller (rev 01)
00:05.0 RAM memory: Red Hat, Inc Virtio memory balloon
tc@box:~$

And due to the missing 'libpci.so.3' symbolic link the 'libpci.so' symbolic link has "lost" it's target as well. Which is an interesting point in itself as the redirection of stderr (to '/dev/null') for the execution of '/sbin/ldconfig' in '/usr/bin/tce-load' hides the fact that a warning (i.e. ldconfig: skipping /usr/local/lib/libpci.so: No such file or directory) could have alerted the user to this. Therefore I wonder whether this error suppression is really such a good idea.

[Juanito]

I work in/deal with places where the weekend is Thu/Fri, Fri/Sat and Sat/Sun, which makes for some confusion, especially when time differences are added 

'Not sure what happened, but fixed version posted - thanks

[maro]

Another little problem seems to occur in the updated 'usb-utils.tcz' extension:

Code: [Select]

tc@box:~$ lsusb
lsusb: cannot open "/usr/local/share/usb.ids", No such file or directory
Bus 001 Device 001: ID 1d6b:0001
Bus 001 Device 002: ID 0627:0001
tc@box:~$

After a quick glance of the source code (i.e. 'lsusb.c') I could only assume that the compilation went without 'HAVE_LIBZ' enabled. Unfortunately when I did attempt to recreate this (via a "quick&dirty" build attempt using 'usbutils-0.91.tar.bz2') I "failed" insofar as I had "#define HAVE_LIBZ 1" in 'config.h' (after execution of ./configure --prefix=/usr/local). For my test I also had downloaded (and extracted) the latest 'usb.ids' (replacing the older file of the same name in the source directory). In my test the '/usr/local/share/usb.ids.gz' file was found and used, so the issue reported above could not be re-created.

Only then did I realize (after a lsusb -V) that the new extension was using '002' (instead of '0.91' which I had compiled). I had obviously not picked up on the progression of the version from 0.87, 0.90, 0.91 to 001, 002.

So another quick build test (this time with 'usbutils-002.tar.bz2') showed that the issue reported above is reproducible. Unfortunately I could not figure out from looking into the 'configure' script how to call it to prevent this from happening. The source code in 'lsusb.c' (and 'names.c') clearly expects the use of a 'HAVE_LIBZ' flag, and the 'configure' script of v0.91 seems to generate it provided the respective library is present. But the 'configure' script for v002 does not do the same (with the same library still present). And I could not quite work out between the use of 'HAVE_ZLIB' and 'USE_ZLIB' (and the absence of 'HAVE_LIBZ') in the script what the hell is going on here.

What I did instead is a bit of a fudge for building v002, but the result is at least as it should be. After ./configure --prefix=/usr/local I did
    echo '#define HAVE_LIBZ 1' >> config.h && sed -i '/LIBS = $/s#$#-lz #' Makefile
followed by the same steps as done for the test build of v0.91 (i.e. make && sudo make install && sudo rm -f /usr/local/share/usb.ids).

Afterwards the "new" 'lsusb' worked as expected:

Code: [Select]

tc@box:~$ hash -r
tc@box:~$ lsusb -V
lsusb (usbutils) 002
tc@box:~$ lsusb
Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 002: ID 0627:0001 Adomax Technology Co., Ltd
tc@box:~$


[Juanito]

..and what is even stranger is that I tested things with both pci-utils and usb-utils immediately after "make install" and they both worked...

[maro]

..and what is even stranger is that I tested things with both pci-utils and usb-utils immediately after "make install" and they both worked...

Hmmm, but IIRC 'make install' also copies 'usb.ids' to '/usr/local/share' so no complaints are to be expected if that is in place.

[Juanito]

corrected version uploaded - thanks for the detailed troubleshooting - and it's still not the weekend yet 

[maro]

Just for completeness: After discovery of this problem I raised it on the respective list (i.e. 'linux-usb@vger.kernel.org') and as it turned out there was a patch for the 'Makefile.am' already in the GIT. So after a quick test of that fix Greg KH has since released 'usbutils-003'.

As this was the only change from 'usbutils-002' I don't see any need for rebuilding the 'usb-utils.tcz' extension.