SCO OS 5.0.6 Initial install creates system panic on Compaq ML570
Judy Guenther
5304/128 Controller
During inital install SCO installs correctly, but during first boot
receives the following: PANIC: srmountfun - error 6 mounting rootdev
hd(1/42). This occurs each time regardless of which controller the
hard drives are attached. What has been determined is that after
system install and during inital boot of O/S if the defbootstr is
entered at the boot prompt and you quit and don't actually load the
btld then the system boots correctly and does so from then on. I know
that the kernel is not re-generated at this time, but is there a
timing issue or possibly something wrong with my hardware?
Mike Brown
Has the 5304 controller been set as the 1st controller in the BIOS ( RBSU )?
Are you loading the EFS5.58 BTLD at boot time with the string
defbootstr disable=ciss link=ciss hd=Sdsk Sdsk=ciss(0,0,0,0) Srom=wd(0,0,0)
I have not loaded a ML570 recently, but the 5304 works in 350/370/530 with
5.0.6.
Mike
--
Michael Brown
The Kingsway Group
Bela Lubkin
Can you please clarify the above statement? You're apparently using
some boot strings, maybe during ISL, maybe during post-ISL reboots.
Show us the actual strings used at each stage, and clearly state what
happens with each.
Parts I'm confused about: "regardless of which controller the hard
drives are attached" -- you only mentioned one controller. The machine
probably has another built in, but don't expect the reader to know that,
spell it out.
"if the defbootstr is entered at the boot prompt and you quit and don't
actually load the btld" -- haven't a clue what that means.
If you're using a BTLD (as it sounds like you must be), please name it.
What are the last few lines of output before the panic? I think
typically there would be some other explanatory error messages before
the "srmountfun" panic (something like "no root disk controller" -- but
please type in the exact text of the last few lines of output).
>Bela<
Bela Lubkin
> Judy Guenther wrote:
> >
> > Compaq ML570 Server w/4GB Ram, 6-32GB SCSI Hard Drives, Smart-Array
> > 5304/128 Controller
> >
> > During inital install SCO installs correctly, but during first boot
> > receives the following: PANIC: srmountfun - error 6 mounting rootdev
> > hd(1/42). This occurs each time regardless of which controller the
> > hard drives are attached. What has been determined is that after
> > system install and during inital boot of O/S if the defbootstr is
> > entered at the boot prompt and you quit and don't actually load the
> > btld then the system boots correctly and does so from then on. I know
> > that the kernel is not re-generated at this time, but is there a
> > timing issue or possibly something wrong with my hardware?
>
> Has the 5304 controller been set as the 1st controller in the BIOS ( RBSU )?
>
> Are you loading the EFS5.58 BTLD at boot time with the string
>
> defbootstr disable=ciss link=ciss hd=Sdsk Sdsk=ciss(0,0,0,0) Srom=wd(0,0,0)
Does that exact bootstring work? I would expect not, because of when
the "disable=ciss" and "link=ciss" keywords are acted upon. "link=ciss"
is done at boot time, by /link (the standalone linker). By the time the
kernel starts up, it contains the BTLD version of the "ciss" driver.
The kernel then acts on "disable=ciss", disabling the just-loaded
driver. At least that's how I would expect it to play out.
If that string _does_ work, my guess is that it would work equally well
without the "disable=ciss"; that what's happening is, the newly loaded
"ciss" driver isn't registered in the particular place where "disable="
looks, so it doesn't get disabled.
> I have not loaded a ML570 recently, but the 5304 works in 350/370/530 with
> 5.0.6.
>Bela<
Mike Brown
I will try it both ways on the next install and see if the disable= has any
effect. I know that for the IDA driver the following string does work
and is required:
defbootstr disable=ida link=ida hd=Sdsk Sdsk=ida(0,0,0,0) Srom=wd(0,0,0)
Without the disable= both versions of the ida driver load!
With the ciss driver when I leave out the disable= ( this is from memory )
I think the system did not boot up after the install.
Here is the most recent documentation from the current EFS, agreeing with
you that the disable= is not required:
--------------
6.6.3.2 SCO OpenServer Release 5.0.6
Boot using the SCO 5.0.6 installation CD,
At the Boot prompt, type in:
defbootstr link=ciss hd=Sdsk Sdsk=ciss(0,0,0,0) Srom=wd(0,0,0)
At the prompt, "Please insert the fd(65)ciss volume and press
<Return>,or `q' to quit:" (Insert the hp ProLiant BTLD diskette
of EFS 5.58 and press <Return> to continue.)
Follow normal Install Procedures as outlined in the SCO Manual.
For the install Method, choose the Preserve option so that
the System Partition is maintained and also to allow access
to the full capacity of the hard drive. SCO 5.0.6 defaults to
Primary Slave device. If your IDE CDROM drive is configured as
Primary Master, then select the CDROM as Primary Master.
Follow instructions until the installation is complete.
Install other OS supplements and packages before installing
the EFS (See section 5). Go into custom and select Software.
Then choose "Install" followed by "New Product" to install the
EFS. Follow the directions pertaining to your setup.
---------------
Note that with the 642 series raid controller and EFS5.58 that after the EFS is
loaded the CISS driver is disabled. It appears that the EFS install script
calls pci_get, but is looking for the wrong values for the 642 controller,
decides that no raid controller is present and disables CISS. As a work around
after the EFS is loaded cd to /etc/conf/sdevice.d and edit ciss, changing the
N to a Y, then relink ( /etc/conf/cf.d/link_unix ).
Judy Guenther
Sorry for the confusion. We are using EFS 5.58B.
Here is the exact error:
Error: PANIC: srmountfun - Error 6
mounting rootdev hd (1/42)
Error 6 opening dumpdev hd (1/41) Dump not completed
Warning: ciss <slot 5>: Event notifier disabled.
The boot string that was entered when the drives were connected to the
5304 is:
defbootstr link=ciss hd=Sdsk Sdsk=ciss(0,0,0,0) Srom=wd(0,0,0)
bootstring entered when connected to internal controller was:
defbootstr link=cha hd=Sdsk Sdsk=cha(0,0,0,0) Srom=wd(0,0,0)
Here is what is happening. The machine is currently up and running.
We used the first boot string when loading the OS. On first boot
after insallation, we enter the same boot string again. At the prompt
to enter efs diskette, we quit out and the OS came up. Then, we were
unable to see the CDROM drive. Rebooted and did not use the boot
string and OS came up and we were able to see CDROM.
Judy Guenther
It is set as the first controller in the BIOS. RBSU does not apply,
the server is ML570 G1.
The boot string we were using is:
Mike Brown
That looks okay. Check in the BIOS under PCI interrupts, and try to set them
up so the 5304 does not share its interrupt with any other card.
I have had some problems a while ago with card slots, is the controller in
a 64bit/66Mhz slot?
Jean-Pierre Radley
Why??? If you link in a particular BTLD at installation, the kernel that
is compiled when installtion finished *contains that driver*. You no
longer have to specify its use with a defbootstr command, it's in the
/stand/unix kernel.
| At the prompt to enter efs diskette, we quit out and the OS came up.
| Then, we were unable to see the CDROM drive. Rebooted and did not use
| the boot string and OS came up and we were able to see CDROM.
--
JP
Judy Guenther
With further research, HP/Compaq has decided that it's a problem. If
you build your SCO O/S with the CD-Rom being the "Slave" the above
situation happens everytime regardless of the server model you install
it on. (Tried on (2) ML570's and (1) ML370). If you build your O/S
with the CD-Rom being the "Master" then the installation works fine.
This has something to do with the latest firmware revisions for the
Server / Controller / Hard Drives?? HP is in the process of trying to
correct the problem. Even with the initial build with "Slave", you
can boot the O/S by entering the boot string and quitting out. After
this point you must down the server one more time and bring it up
normally without the boot string in order to use the CD-Rom.
Thanks for the great suggestions, they were very much appreciated!
Judy
Mike Brown
> With further research, HP/Compaq has decided that it's a problem. If
> you build your SCO O/S with the CD-Rom being the "Slave" the above
> situation happens everytime regardless of the server model you install
> it on. (Tried on (2) ML570's and (1) ML370). If you build your O/S
> with the CD-Rom being the "Master" then the installation works fine.
> This has something to do with the latest firmware revisions for the
> Server / Controller / Hard Drives?? HP is in the process of trying to
> correct the problem. Even with the initial build with "Slave", you
> can boot the O/S by entering the boot string and quitting out. After
> this point you must down the server one more time and bring it up
> normally without the boot string in order to use the CD-Rom.
>
> Thanks for the great suggestions, they were very much appreciated!
> Judy
Thanks for the information.
Do you have another IDE device installed that causes the CDROM to
become the "slave"? Normally if it is the only IDE device you would
have to jumper it CS or MASTER for it to work.
It looks like there is some dependency between HP/Compaq's CISS driver
and the controller mode ( master/slave ) of the CDROM. It is a real
stretch to guess at what the two have in common, but great detective
work figuring this one out.
Judy Guenther
Actually, Compaq had originally had me change the jumpers to CS two
years ago when I originally installed this server and set it to Slave.
The reason for this is because the server was not seeing the CD-Rom
drive at all and therefore I could not install the software.
Apparently, some where along the line they corrected this problem but
failed to notify anyone of the changes.
Thanks again for the help!
Judy