SUMMARY: Exabyte 8500C & Sol. 2.4

From: Jackie Rosinsky (
Date: Wed Mar 29 1995 - 08:35:56 CST

My orginial question was:

I just upgraded one of my systems to Solaris 2.4. That machine has a
Exabyte 8500C attached to it. Since the upgrade my backup's are taking
twice as long. I have noticed that I can dump a local 2 Gig filesystem
in about 1.2 hours ( That about what it took under 2.3) however to
dump a remote filesytem that is 1.7 G takes 3 hours. I still have a tape stacker
on a 2.3 machine and the same remote filesystem takes ~ 1 hour.
I have tried all of the following:

        Per Technical Bulletin 142.txt from a previous sun-manager FAQ
        I updated my st.conf to have
                tape-config-list ="EXABYTE EXB8500C","Exabyte 8500c","Exa8500c";
                Exa8500c= 1,0x35,0,0xd639,4,0x14,0x15,0x15,0x8c,1;
        rebooted the machine with boot -r and had the same results.

        Per R-Squared the vendor we purchased the tape stacker from
        I updated my st.conf to have
                tape-config-list =
        "EXABYTE\040EXB\0558500C","EXB-8500C from R Square", "EXB_8500C";
                EXB_8500C = 1,0x35,1024,0x1679,4,0x14,0x15,0x8c,0x8c,3;
        rebooted the machine with boot -r and had the same results.
        I even tried a very old FAQ and patched the driver as follows
> perl -pi.FCS -e s/EXB-8500/EXB8500C/ /kernel/drv/st
> modunload -l 'modinfo|grep -w st | awk '{print $1}'`
        Tried the ufsdump and had the same results.

I have been working with SUN but they have not come up with anything yet. They
thought it was the fact that my st.conf was wrong
                tape-config-list ="EXABYTE EXB8500C","Exabyte 8500c","Exa8500c";
                Exa8500c= 1,0x35,0,0xd639,4,0x14,0x15,0x15,0x8c,1;
They said that the third field of 0 indicated to use 0 block length. But
as I said above I changed that and it did not help.

First I would like to thank
Johnie (, Robert Kohler (, Russ Poffenberger (, Stephen Schneider (, and Steve ( for there suggestions.

It turns out that with some help from sun and alot of work on my part
I found the problem. As Stephen put it "I'll spare you the flames that I'd throw at Sun for how they mis-handled my problem and how long it took them to admit the problem was in 2.4." The problem is with a combination of patches.
First, you must have the latest 2.4 jumbo patch 101945-23 and you cannot
install patch 102002 (One of the patches on the CD). Once
I did these two steps my backups now take a reasonable amount of time.
Of course Sun will have to determine whats wrong with that patch.

Thanks for all advise
Jackie Rosinsky

This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:10:20 CDT