Bug 608568

the strange thing is that, I checked the dmesg/messages/lsmod/modinfo in sysreport, none of these shows anything about the "xigz" driver. maybe the INFO test worked well as it should be, and there're some other reasons for the system not reporting the usage of this 3rd party driver ?

(In reply to comment #1)
> the strange thing is that, I checked the dmesg/messages/lsmod/modinfo in
> sysreport, none of these shows anything about the "xigz" driver. maybe the INFO
> test worked well as it should be, and there're some other reasons for the
> system not reporting the usage of this 3rd party driver ?    

As I know the xorg drivers are userspace drivers only. so to list them, we check the xserver only. Xorg.(N).log files are best to check what all modular capabilities were loaded. 

The reason why all tests worked fine I believe is because there is no use case to test against this, no checksum list or whitelist to check against so far. 

However apart from the less popular driver name, the detail of  "compiled for $version" informational of xorg log were useful to catch this xigz issue.

(In reply to comment #2)
> As I know the xorg drivers are userspace drivers only. so to list them, we
> check the xserver only. Xorg.(N).log files are best to check what all modular
> capabilities were loaded. 
> 
> The reason why all tests worked fine I believe is because there is no use case
> to test against this, no checksum list or whitelist to check against so far. 
> 
> However apart from the less popular driver name, the detail of  "compiled for
> $version" informational of xorg log were useful to catch this xigz issue.    

In reply to my own comment, this was one of case where a least popular xorg driver was used, tomorrow say there could be another xorg driver, even a replacement of rhel shipped driver from upstream or another distro etc. in extremely ignorant cases.

Could one of the easy work around be that we run "rpm -V" against used driver file ? for a different issue I am thinking we can do the same for files in HAL and UDEV config dirs.

I think this is still do-able and would be good 1.5 content.  We can do this by checking the startx log for the "Loading {path}" lines.  This is all of the X modules that are loaded.  This will also pickup extension and some other items that are not exclusively the display driver; but that should be ok as it should only add a few seconds and it's just as invalid if the libglx isn't the one we're shipping as if the vesa driver has been replaced.

For Example on my box:

Loading /usr/lib64/xorg/modules/extensions/libglx.so
Loading /usr/lib64/xorg/modules/extensions/librecord.so
Loading /usr/lib64/xorg/modules/extensions/libdri.so
Loading /usr/lib64/xorg/modules/extensions/libdri2.so
Loading /usr/lib64/xorg/modules/drivers/vesa_drv.so
Loading /usr/lib64/xorg/modules/drivers/fbdev_drv.so
Loading /usr/lib64/xorg/modules/libfbdevhw.so
Loading /usr/lib64/xorg/modules/drivers/fbdev_drv.so
Loading /usr/lib64/xorg/modules/libfbdevhw.so
Loading /usr/lib64/xorg/modules/libfb.so
Loading /usr/lib64/xorg/modules/libshadow.so
Loading /usr/lib64/xorg/modules/input/evdev_drv.so

...we can check all of these paths with an "rpm -Vf {file}" and verify the build host is redhat.com with an "rpm -qf {file} --queryformat '%{BUILDHOST}'.

Created attachment 573476 [details]
Patch to check all of the loaded X modules

This checks the X log, finds the Loading with path lines, then rpm -V the file and verifies the providing rpm vendor and buildhost similar to the info testing of kernel modules.

There is no srcversion to check so we have to assume in memory and ondisk are the same; which is safer here given there are typically not initrd's that go away during startx which would alter the load time and run time paths.

The patch in attachment 573476 [details] doesn't crash on this box, but I don't have any non-redhat video modules loaded either.  This case will require testing.

    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
An enhancement has been made in v7 1.5 that test suite is now able to detect all Xorg drivers and warn user for non-Red Hat drivers.

    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1 +1 @@
-An enhancement has been made in v7 1.5 that test suite is now able to detect all Xorg drivers and warn user for non-Red Hat drivers.+A new feature has been made in v7 1.5 that test suite is now able to detect all Xorg drivers and warn user for non-Red Hat drivers.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2012-0711.html