Text 452, 139 rader
Skriven 2007-02-01 07:27:14 av Mike Luther (1:117/3001.0)
Kommentar till text 448 av Holger Granholm (2:20/228)
Ärende: Re: Really strange
==========================
OK I now have very specific information for you Holger ..
HG> Something similar happened in my work machine recently. At a cold start
HG> it began deleting files from the OS/2 partition without any warning.
HG> If I had read the instructions you gave in yor mail to Sean I would have
HG> cut the power to the machine immeadetely. Now I didn't.
ML> What version of OS/2? = Warp 4
ML> Fix Pack level? = FP12
ML> IDE or SCSI drive? = SCSI HPFS
ML> If SCSI then what adapter and SCSI driver version?
HG> AHA-2940, AIC7870.ADD dated aug. 1996
Absolute spot on behavior for the MAJOR error pattern which surfaced at FP12
for Warp 4 with SCSI and Adaptec I described! I got into this first with file
deletion not only during boot, but with CHKDSK alone on an HPFS data partition
"E" on one Adaptec SCSI system. And the only way I managed to save all this
was to restore the files from tape backup and other box files until all this
got fixed. You would run CHKDSK on a partition and the files would vanish, in
my case being 'found' to be corrupt files, but they were not!
HG> I didn't try to restart. Instead I started OS/2 from the BootOS2
HG> diskettes I have and ran CHKDSK. It didn't report any damage on the HD.
HG> Both OS2*.INI files are original since last actual work session.
No, it doesn't! You will be working with OS/2 and after a boot run you will
suddenly just 'lose' files from some partition without warning. I used to have
the complete time line and fix notation pattern for all this which took a long
convoluted pigtrail to finally resolve. It was part of the push that first
focused into FP13, which had lots of problems internally, morphed into FP14 and
finally was decently fixed in FP15 for Warp4.
The early solutions for all this involved a specific patched CHDKSK32 from IBM,
a complete re-release of the Adaptec 7800 source file package for the Adaptec
hard disk drivers, a specific patched SYSINSTX from IBM. Worse, Adaptec
wouldn't listen to IBM over where part of the problem was in their driver work.
So .. IBM had to 'fix' the package for them and originally distributed that
special 'fixed' Adaptec package from the IBM site! Finally Adaptec got it
worked out with IBM and then released an official Adaptec package with OK code
in it which then wound up as the same named package on the IBM download site as
well.
For the curious, the only way you could tell which package was what was to know
the compile time and date on it. It was the first place where I got so
disturbed about the inability of the IBM Web Browser for OS/2 to presever the
actual date and time of a file on download from the IBM site! There was no
way, without hand altering the downloaded file to keep track of all the try
this, try that mess. Which has still not been 'fixed' even in Seamonkey 1.1
today! Oh well.
Bottom line:
HG> I haven't had time to delve deeper into the problem but have used this
HG> BBS machine instead but I intend to install Warp4 and FP12 on another
HG> chassis I have and compare the existing files and copy over the missing
HG> ones.
Please do *NOT* stop at FP12. If you are going to stay with Warp4, FP15 was
publically available and the best install method for it is posted on Hobbs and
a copy of it is on my BBS here! That complete file can simply be executed on
the box with an INSTALL tool which is a part of it! The composite of fixes
from IBM's part that solved what you are experiencing is in this FP15, per my
memory. That file is:
FIXPAK15.ZIP 25,779,472 bytes 05-29-03
You will find it in the IBMINFO section of the BBS here.
Second, the release of the Adaptec drivers with the needed changes was also a
public release, either from Adaptec or IBM. It is in a file:
7800FAM.EXE 451,388 bytes 09-28-02
You will find it in the IBMINFO section of the BBS here,
HG> Since I knew you'd ask and provided a nice questionnary I used it:
And as a last part of this, depending on the size of the SCSI drive you are
using, if the SCSI hard drive is larger than 32GB in size, there are actually
re-released new versions of the BIOS code for the Adaptec controller cards
which were involved with this too, even though the drive isn't that large! It
is my memory, from personal work with the Adaptec support engineer during this
mess, that unless you have the FP15 and later drivers, you could get in trouble
with the BIOS code on the controller card as part of this mess!
The most recent BIOS code for the Adaptec cards is still furnished from the
Adaptec support web site, even though the cards are now discontinued as far as
I know. You will also have to use a DOS boot disk for that. Jan Wijk's DFSEE
utility code set, I think, has a copy of FREEDOS which is a bootable such tool.
As well even DOS 6.2 boot disks will work. You must use a separate DOS boot
disk for each Adaptec controller you wish to flash. The Adaptec code program
first slushes your old card BIOS onto that floppy for backup purposes before it
reburns the BIOS new code on the card. That so you can recover if something
goes bad wrong. Besides! You'll get use out of the DOS boot floppy for
MEMTEST or DFSEE for DOS if you go there.
Also for the curious, a part of this mess in the driver work as well as for the
IBM system arises from the fact that PCI slot cards can use more than one IRQ!
And with the CORRECT device driver design, can SHARE an IRQ as well. But in
Adaptec's case, what very few people know is that a certain very less known
SCSI card, the 3940UW card which has a complete double hardware profile, the
second one for the external plug cable at the back triggered this whole mess!
In the case of the design, Adaptec uses a SECOND IRQ for that hardware, so that
the card actually consumes two IRQ's for that one slot. A conflict with that
second IRQ from something else in the system can lead to part of this! As a
part of what all we found. As well, in the design of this card it was found
that even though you didn't have ANYTHING tied to this external cable jack, if
something else in the system was using the other IRQ, you could corrupt the
whole card use and set off the corruption process. Which wasn't spotted by the
OS/2 system under certain circumstances.
\ /
(!)
@ @
The 3940UW card is designed so that even if the hardware burned up on the rear
channel, the server involved wouldn't fail with OS/2 so that in mission
critical service it would remain working from the internal OS/2 boot drive for
recovery purposes. If a huge problem happened which totally literally
destroyed a medical X-Ray system on the outside and then even burned up the
cable and the 3940UW card chips in the box, the system would stay working. I
was using an external SCSI drive at the 1:117/3000 communications site and this
is how we stumbled on to the generic errors which tripped part of the fixes in
that the other IRQ's were all being used for a host of other cards for
telecommunications needs for this and that. BLAM! It was a part of how all
this wound up on IBM's Testcase as well as with the Adaptec engineer.
To be continued in second half of this post, gloom.
--> Sleep well; OS/2's still awake! ;)
Mike @ 1:117/3001
--- Maximus/2 3.01
* Origin: Ziplog Public Port (1:117/3001)
|