P
Paul
(e-mail address removed) wrote:
[ Some answers inline... ]
So the SCSI setting was probably lost when the battery fell off.
You would need to slave the SCSI drive to another computer.
Either that, or boot your WinXP installer CD to the recovery console,
and see if the CHKDSK works in there. You may need to press F6 and offer
a driver for the SCSI controller. I've never done that here, as
usually I'm working with IDE drives on the chipset. So look at the
ID of the chip or card controlling your SCSI drive, and locate a
driver for it for WinXP (if using the WinXP disc for the recovery
console).
My SCSI work was mostly with my Macintosh. I've moved a SCSI card into
the PC a couple of times, but that was for usage of an old 9GB drive
as a data drive. Nothing really educational happened there, because
I wasn't trying to boot from it. (I have three or four cheap SCSI
cards here, that are very infrequently used. A 2906 still runs
my SCSI document scanner.)
If there is no hard disk detected, that might account for the BIOS screen.
Some SCSI setups might have a variable timeout setting (or, things
like staggered spin, for SCSI chains full of drives). Maybe it is
a timeout set too low or something.
IBA GE Slot 8388 appears to be a LAN card boot option. You would
think that would appear regularly, unless there is not sufficient
low memory for the INT 0x13 support for LAN boot to load. Depending on
how many SCSI controllers are present, other boot ROMs might not
get to load, making the boot order listing "flaky" in behavior.
Could be staggered spin. For SCSI, there can be jumper blocks or dip switches
that enable staggered spin. Staggered spin is used to reduce the
strain on the power supply. One disk at a time, takes turns drawing the
2-3 amp spinup current. It reduces the peak current the power supply must
support. You could defeat the staggered spin, if you wanted the drives
to spin up in unison. If the power supply has a reasonably hefty 5V and 12V
current rating, it probably wouldn't be a big deal to spin them all
at once. I spin up five drives regularly here, on a 460W power supply,
without staggered spin or anything of that nature.
It's been a long time since I looked at that stuff. I don't
know if I can help you with IRQ assignments. I seem to remember
needing to do something for Windows 98 with a sound card or
something. For modern OSes, you have "PNP OS" [yes or no] setting,
with [no] being normal for modern OSes. The BIOS then does the
resource assignment. You only need to move IRQ numbers, if
something isn't working right. The defaults would normally
be good enough I would think.
Some servers, you install a separate card in a special slot on
the motherboard, and that card allows remotely administering
the computer. That could be what the console redirection is
about. That allows a large number of servers to be administered
from a central location, hopefully without needing to enter
the server room.
And having your passwords cleared, is a relief.
Well, look for a WinXP driver for the SCSI controller you're currently
using. Since you also have an "embedded controller", the part number
on that would be another option. Or, use a Promise Ultra133 TX2, an
IDE driver, the Promise driver, a floppy diskette, and use the F6 method
to install a driver via floppy for that.
The RageXL graphics are ancient. ATI may have made drivers for
*server* versions of the OS (since ancient server graphics
like that get reused for a long time). There might not be a
reason to make a WinXP version. ATI would only stop selling
that chip, if the silicon fab could no longer make it. (Any time
a fab gets new lithography equipment, it usually means they can no
longer make the old designs. We "lost" all our chips at work on a
project once, because of that, and had to stop shipping our product.)
VRM = voltage regulator module (plugs into ugly looking slot with big pins)
VRD = voltage regulator down (normal for retail motherboards, soldered down)
On old servers, a VRM is required per socket. VRMs are usually relatively
low power, compared to the capabilities of some VRDs now.
On some two socket motherboards, a "terminator adapter" plugs into the
second CPU socket, when no CPU is installed in there. That has something to
do with proper GTL bus termination. Missing that might cause a crash
immediately at boot.
A second CPU isn't going to materially affect your current problems.
And is just a waste of electricity and time
So the only thing I'd be concerned about, is whether that
particular motherboard needs a terminator in the second CPU
socket when it's empty or not.
You've got enough RAM for the moment. You can dream about
this other stuff, when the box is running smoothly again.
You will need to learn to solder.
You could buy a CR2032 (assuming that is what fell out), and buy a pigtailed
version used in a laptop. That way, just cut off the two pin connector on the
end, strip the wires, and solder the wire ends to the two contact where the
socket for the battery used to be.
People have also used regular dry cells, anything that gives the
required 3V, and soldered that into the motherboard. (You would use
a battery holder from Radio Shack to hold the batteries in that case.)
If you want to do a proper repair, you'll need to find a battery
socket which is footprint compatible with the pattern already
present on the motherboard. Abusing a pigtailed battery is just
a lot simpler. If you want to "remove" the battery occasionally,
place a switch from Radio Shack (SPST or SPDT) in series with
one of the legs of the pigtailed battery, so you can interrupt
current flow when needed.
So you were very close to booting Now the trick will be,
tracing down which irritating SCSI problem could be causing it.
"INACCESSIBLE_BOOT_DEVICE Message After Changing a SCSI Adapter Resource"
http://support.microsoft.com/kb/302098
"How to troubleshoot 'Stop error code 0x0000007B (INACCESSIBLE_BOOT_DEVICE)'
error messages in Windows 2000"
http://support.microsoft.com/kb/822052
"Advanced troubleshooting for 'Stop error code 0x0000007B (INACCESSIBLE_BOOT_DEVICE)'
errors in Windows XP" [ WinXP being similar enough to Win2K for debug purposes ]
http://support.microsoft.com/default.aspx?scid=kb;en-us;324103
But what are the odds of someone leaving it in need of a CHKDSK run ?
The first procedure is encouraging (effectively resetting a registry
key used to keep track of what booted on the SCSI chain), but it's
pretty stupid in my opinion, when the ARC resource in boot.ini exists
to do something like that. To use the info in the first article,
you'd need a working computer, plug a SCSI controller into the machine,
then use regedit (or equivalent) to edit the registry hive on the
SCSI disk drive and delete the entries.
All these things are fixable. If you have a well equipped lab, that is.
I have some SCSI controllers here, and I could kludge something
together here to be able to read a drive like that from
my current PC. Then run CHKDSK, make a backup or whatever.
Paul
[ Some answers inline... ]
So the SCSI setting was probably lost when the battery fell off.
You would need to slave the SCSI drive to another computer.
Either that, or boot your WinXP installer CD to the recovery console,
and see if the CHKDSK works in there. You may need to press F6 and offer
a driver for the SCSI controller. I've never done that here, as
usually I'm working with IDE drives on the chipset. So look at the
ID of the chip or card controlling your SCSI drive, and locate a
driver for it for WinXP (if using the WinXP disc for the recovery
console).
My SCSI work was mostly with my Macintosh. I've moved a SCSI card into
the PC a couple of times, but that was for usage of an old 9GB drive
as a data drive. Nothing really educational happened there, because
I wasn't trying to boot from it. (I have three or four cheap SCSI
cards here, that are very infrequently used. A 2906 still runs
my SCSI document scanner.)
If there is no hard disk detected, that might account for the BIOS screen.
Some SCSI setups might have a variable timeout setting (or, things
like staggered spin, for SCSI chains full of drives). Maybe it is
a timeout set too low or something.
IBA GE Slot 8388 appears to be a LAN card boot option. You would
think that would appear regularly, unless there is not sufficient
low memory for the INT 0x13 support for LAN boot to load. Depending on
how many SCSI controllers are present, other boot ROMs might not
get to load, making the boot order listing "flaky" in behavior.
Could be staggered spin. For SCSI, there can be jumper blocks or dip switches
that enable staggered spin. Staggered spin is used to reduce the
strain on the power supply. One disk at a time, takes turns drawing the
2-3 amp spinup current. It reduces the peak current the power supply must
support. You could defeat the staggered spin, if you wanted the drives
to spin up in unison. If the power supply has a reasonably hefty 5V and 12V
current rating, it probably wouldn't be a big deal to spin them all
at once. I spin up five drives regularly here, on a 460W power supply,
without staggered spin or anything of that nature.
It's been a long time since I looked at that stuff. I don't
know if I can help you with IRQ assignments. I seem to remember
needing to do something for Windows 98 with a sound card or
something. For modern OSes, you have "PNP OS" [yes or no] setting,
with [no] being normal for modern OSes. The BIOS then does the
resource assignment. You only need to move IRQ numbers, if
something isn't working right. The defaults would normally
be good enough I would think.
Some servers, you install a separate card in a special slot on
the motherboard, and that card allows remotely administering
the computer. That could be what the console redirection is
about. That allows a large number of servers to be administered
from a central location, hopefully without needing to enter
the server room.
And having your passwords cleared, is a relief.
Well, look for a WinXP driver for the SCSI controller you're currently
using. Since you also have an "embedded controller", the part number
on that would be another option. Or, use a Promise Ultra133 TX2, an
IDE driver, the Promise driver, a floppy diskette, and use the F6 method
to install a driver via floppy for that.
The RageXL graphics are ancient. ATI may have made drivers for
*server* versions of the OS (since ancient server graphics
like that get reused for a long time). There might not be a
reason to make a WinXP version. ATI would only stop selling
that chip, if the silicon fab could no longer make it. (Any time
a fab gets new lithography equipment, it usually means they can no
longer make the old designs. We "lost" all our chips at work on a
project once, because of that, and had to stop shipping our product.)
VRM = voltage regulator module (plugs into ugly looking slot with big pins)
VRD = voltage regulator down (normal for retail motherboards, soldered down)
On old servers, a VRM is required per socket. VRMs are usually relatively
low power, compared to the capabilities of some VRDs now.
On some two socket motherboards, a "terminator adapter" plugs into the
second CPU socket, when no CPU is installed in there. That has something to
do with proper GTL bus termination. Missing that might cause a crash
immediately at boot.
A second CPU isn't going to materially affect your current problems.
And is just a waste of electricity and time
So the only thing I'd be concerned about, is whether that
particular motherboard needs a terminator in the second CPU
socket when it's empty or not.
You've got enough RAM for the moment. You can dream about
this other stuff, when the box is running smoothly again.
You will need to learn to solder.
You could buy a CR2032 (assuming that is what fell out), and buy a pigtailed
version used in a laptop. That way, just cut off the two pin connector on the
end, strip the wires, and solder the wire ends to the two contact where the
socket for the battery used to be.
People have also used regular dry cells, anything that gives the
required 3V, and soldered that into the motherboard. (You would use
a battery holder from Radio Shack to hold the batteries in that case.)
If you want to do a proper repair, you'll need to find a battery
socket which is footprint compatible with the pattern already
present on the motherboard. Abusing a pigtailed battery is just
a lot simpler. If you want to "remove" the battery occasionally,
place a switch from Radio Shack (SPST or SPDT) in series with
one of the legs of the pigtailed battery, so you can interrupt
current flow when needed.
So you were very close to booting
Now the trick will be,tracing down which irritating SCSI problem could be causing it.
"INACCESSIBLE_BOOT_DEVICE Message After Changing a SCSI Adapter Resource"
http://support.microsoft.com/kb/302098
"How to troubleshoot 'Stop error code 0x0000007B (INACCESSIBLE_BOOT_DEVICE)'
error messages in Windows 2000"
http://support.microsoft.com/kb/822052
"Advanced troubleshooting for 'Stop error code 0x0000007B (INACCESSIBLE_BOOT_DEVICE)'
errors in Windows XP" [ WinXP being similar enough to Win2K for debug purposes ]
http://support.microsoft.com/default.aspx?scid=kb;en-us;324103
But what are the odds of someone leaving it in need of a CHKDSK run ?
The first procedure is encouraging (effectively resetting a registry
key used to keep track of what booted on the SCSI chain), but it's
pretty stupid in my opinion, when the ARC resource in boot.ini exists
to do something like that. To use the info in the first article,
you'd need a working computer, plug a SCSI controller into the machine,
then use regedit (or equivalent) to edit the registry hive on the
SCSI disk drive and delete the entries.
All these things are fixable. If you have a well equipped lab, that is.
I have some SCSI controllers here, and I could kludge something
together here to be able to read a drive like that from
my current PC. Then run CHKDSK, make a backup or whatever.
Paul