SUMMARY: patch kit/driver conflict

From: Peyton Bland <bland_at_umich.edu>
Date: Fri, 11 May 2001 14:11:04 -0400

Hi,

------------- the original question -----------------

We are running Tru64 V5.1 on a DS-20E. This system contains a PowerStorm
350 graphics board, so I installed the latest driver 3x05x20A during the
initial setup of this machine. Not long after, I installed patch kit
T64V51AS0003-20010413 (downloaded from the Compaq web site -- checksums
were OK), electing to install all 76 patches. After an uneventful install
and kernel rebuild, I rebooted the machine. It hung part way through the
boot sequence with a pattern of alternating blue and white stripes. To
make a long story short, with the help of serial terminal connected to COM1
and Compaq tech support on the phone, all is well now. The fix was to
uninstall the PS software, boot from genvmunix, and re-install the PS
software (many details omitted).

The conclusion seems to be that before installing the patch kit, I needed
to uninstall the PS stuff and re-install it after the patch. The tech at
Compaq said that this was an odd problem and that having to un-install the
PS software was unexpected.

Any comments? Does it make sense to have to un-install certain software
before applying a patch kit? If so, is there any way to know what should
be un-installed? By the way, the patch kit did include a patch for a new
graphics adapter, but I don't recall seeing what model it was.

------------------- the answer ----------------------

My thanks go to Tom Blinn for the definitive and educational answer...

"Dr. Thomas.Blinn_at_Compaq.com" <tpb_at_doctor.zk3.dec.com>

There is a LONG HISTORY of the group that produced the 3D graphics option
support (Open3D) deciding they should just replace standard kernel modules
with their own modules. Other software kits MIGHT do this, but most do
not. To see if a kit MIGHT be at risk of doing this, you can cd into the
/usr/.smdb. directory and look for the kit's inventory files (which will
have a three letter prefix that is unique to the product, some letters,
and a 3 digit number, followed by .inv). If there is a lock file (.lk),
the kit subset is installed, but it's easier to first figure out if the
inventory makes the kit risky. Use grep to look in the inventory file
for the pattern "\.mod " where the white space is a tab character. If
you find any .mod files, look also at the .scp file and see if there is
any logic to move aside a file in /sys/BINARY (or /usr/sys/BINARY) and
then either replace it with a copy of the file from the kit or a symlink
to the file from the kit. Any layered product kit that does this is at
risk of being broken by a patch (and at risk of breaking the kernel after
a patch -- whatever part of the UNIX patch that the Open3D kit was not
compatible with has been removed from your system and replaced by the
unpatched and perhaps defective Open3D module; and when you go to try
to install the NEXT patch, you may have to baseline the system).

------------------------------



Peyton Bland
University of Michigan, Radiology
voice: 734-647-0849
FAX: 734-764-8541
e-mail: bland_at_umich.edu
URL: http://www.med.umich.edu/dipl/
Received on Fri May 11 2001 - 18:12:20 NZST

This archive was generated by hypermail 2.4.0 : Wed Nov 08 2023 - 11:53:42 NZDT