Found on Metalink :

Problem Description:
====================

You are trying to start an instance with Oracle v8.0.4, and you receive the
following errors:

SVRMGR> connect internal
Connected.
SVRMGR> startup nomount

ORA-00600: internal error code, arguments: [SKGMBUSY], [1], [0], [0], [0],
[], [], []

ORA-27123: unable to attach to shared memory segment

HP-UX Error: 22: Invalid argument

SVRMGR>


Solution Description:
=====================

You need to remove the shared memory for this instance.

One way to get the shared memory and semaphore identifiers from production
instances that cannot be brought down is as follows:

1. Log in to svrmgrl for each separate instance, connect internal, and issue
the command:

SVRMGR> oradebug ipc

This will return the following information for the instance:

-------------- Shared memory --------------
Seg Id Address Size
529 c8b77000 5140480
Total: # of segments = 1, size = 5140480
-------------- Semaphores ----------------
Total number of semaphores = 50
Number of semaphores per set = 50
Number of semaphore sets = 1
Semaphore identifiers: 23260

2. Record the Seg Id and Semaphore identifiers numbers for that instance. Do
this for each running instance that cannot be brought down, compare these
with the output of: (Do this at the Unix prompt.)

% ipcs -b

and the semaphore and shared memory id numbers that are owned by the
Oracle user.

*NOTE: Do NOT remove any numbers that showed up in oradebug, these are
currently being used by your production instances. The remaining
shared memory and semaphores (owned by Oracle) are the ones that
need to be removed. These were reserved when your instance tried
to come up and were not removed when it did not mount successfully.

3. To remove these, do the following VERY CAREFULLY CHECKING YOUR NUMBERS
against the ones from oradebug:

% ipcrm -s [for Semaphores]

% %ipcrm -m [for Shared Memory]

4. Try to bring up your instance again.

*NOTE: Instances can have more than one semaphore set and/or shared memory.
Be SURE that you get ALL the id numbers for each instance, do not
assume that there is only one per instance.


Explanation:
============

There is a piece of shared memory still allocated for this particular instance.

Oracle 8.0.4 does not always clean up it's resources when an instance does not
successfully mount and they must be removed manually.


References:
===========

Search Words:
=============

ora-600, 600, Server Manager

Regards
Gert