Cannot link after installing Adaptec driver !

[piperent]

I have a 5.0.5 site running an Adaptec 2940u2w controller ('blad' driver). The site rep attempted to install a tape drive on that controller, but the controller would not recognize it. So, he plugged in another SCSI controller (Adaptec 2940U, 'alad' driver) and attached the tape to it. Well, I guess SCO can't handle co-existing Adaptec's, consequently, when he tried to add the tape, the 'kernel re-link' failed. Now I have a kernel that works OK (because the relink failed), but can't be re-linked. It gives the following error:

i386ld: Symbol XscanPCICommandReg in /var/opt/K/SCO/link/1.1.1Eb/etc/conf/pack.d/blad/
driver.o is multiply defined. First defined in /var/opt/K/SCO/link/1.1.1Eb/etc/co
nf/pack.d/alad/driver.o

Multiply defined symbol Stpcfg in /var/opt/K/SCO/link/1.1.1Eb/etc/conf/pack.d/blad/s
pace.o has more than one size.

ERROR: Can not link-edit unix

I have read thread58-875836 which is almost identical to this problem, but there is no mention of how to undo, backout, or remove the offending 'alad' controller. Although there is mention of 'single user and custom', and 'single user and software manager'...

I have also searched the SCO TA's and Knowledge Base with no success.

If anybody has experienced this or has a clue how to correct it I would sure appreciate the help. Like I said, the system functions just fine, but at some point the kernel will need to be re-linked, as of now that's not going to happen.

Thanks for any help.
JP

 

[cdlvj]

Have you tried mkdev .scsi

which should allow a delete.

I have had problems with the new Adaptec stuff also, and have had to go to one of the real old cards.

 

[piperent]

What I found is the 'alad' table in sdevice.d was remaining in the active state ('Y' in all the table entries) even though I had already removed the tape drive, the physical controller device itself, and manually changed the cf.d/sdevice to deactivate it. Once I manually changed the 'alad' in sdevice.d to set everything to 'N', then the relink worked properly (the conf.c was rebuilt correctly without inclusion of the alad device).

Just one of those things. SCO still doesn't have a good sense of logic when it comes to looking at itself and making decisions based on what it sees. If there is some possible conflict between two similar devices, then the installation scripts should do some preliminary screening to avoid this type of incompatibility. Maybe it's there in later versions, but I don't think so.

JP