Sun Enterprise[TM] 10000: panic cannot allocate i/o mmu tsb arrays

Asset ID:	1-72-1018120.1
Update Date:	2010-01-01
Keywords:

Solution Type Problem Resolution Sure

Solution 1018120.1 : Sun Enterprise[TM] 10000: panic cannot allocate i/o mmu tsb arrays

Related Items


Sun Enterprise 10000 Server

Related Categories


GCS>Sun Microsystems>Servers>High-End Servers

PreviouslyPublishedAs
229444

Symptoms
On an E10K, when booting net the domain panics with:
panic cannot allocate i/o mmu tsb arrays

This is an issue with the designation of the O/S for the domain and the boot image. When defining the domain, the O/S should be specified as 5.6, 5.7 or 5.8. If the O/S is specified as 2.8 for instance instead of 5.8, the domain will panic when it is booted over the network.

Resolution
Required Pre-Conditions :

Domain must be down you will need to do a bringup on the domain once this procedure is completed. Schedule an appropriate time with the customer.
Verify no pre-existing problems exist with the domain. Be sure to at least check

$SSVAR/adm/$SUNW_HOSTNAME/post/post*.log

directory files for successful recent bringup attempts. Be sure the domain has successfully completed at least a level 16 (default hpost level) bringup. You can also obtain a time estimate of how long the bringup will take by examining the last few lines in the post logs.
Verify host id information of the selected domain via the sys_id command. Write this info down to validate the eeprom image gets properly remapped.
Verify there are no additional copies of eeprom images in :

$SSPVAR/.ssp_private/.eeprom_save

What you SHOULD see is a file for EACH existing domain. During a rename or domain removal process, the selected domain's eeprom image should revert to a default eeprom image name. (typically eeprom.image_some_number. Once the domain is renamed or recreated, the eeprom image file will be renamed to match the newly designated name. (In the cas eof this procedure, the domain name will remain the same)

IF you have extra copies/backup eeprom images in this directory, it is possible to get images of working domains inadvertently overwritten.
IF you are NOT sure what any extra eeprom images are associated with, you can invoke the sys_id command on each to examine their contents.

Example : sys_id -d -f ./The_eeprom_image_I_dont_know_about

Solution: To change the O/S designation, for ssp 3.3 and above do:

ssp% domain_switch < domain name >

ssp% sys_id -d (Make note of hostid info for post-procedure checking)

ssp% netcon (verify domain is at ok prompt)

Type ~. to disconnect your netcon session

ssp% domain_status (Note which boards are associated with the domain)

ssp% domain_rename -d < domain name > -o < correct O/S version >

ssp% domain_switch < domain name >

ssp% domain_status (Verify all boards noted above are still in this domain)

ssp% sys_id -d (Verify the eeprom file host id info is correct)

ssp% bringup -A on -l7 (using level 7 hpost to expedite bringup, where you want to autoboot WITHOUT verifying network bootability)

-or-

ssp% bringup -A on -l16 (using default hpost level 16 to test domain, and where you want to autoboot WITHOUT verifying network bootability)

-or-

ssp% bringup -A off -l7 (using level 7 hpost to expedite bringup, where you want to verify network bootability from OBP prompt)

-or-

ssp% bringup -A off -l16 (using default hpost level 16 to test domain, and where you want to verify network bootability from OBP prompt)

For lower versions of the ssp,

ssp% domain_switch < domain name >

ssp% sys_id -d (Make note of hostid info for post-procedure checking)

ssp% domain_status (Note which boards are associated with the domain)

ssp% netcon (verify domain is at ok prompt)

Type ~. to disconnect your netcon session

ssp% domain_remove -d < domain name >

When it asks if you want to delete the files, make sure to retain the files.

The domain can then be recreated with the correct O/S by:

ssp% domain_create -d < domain name > -b <system_board_list> -o < correct O/S version > -p <platform_name> .

ssp% domain_switch < domain name >

ssp% domain_status (Verify all boards noted above are back in this domain)

ssp% sys_id -d (Verify the eeprom file has correct host id info)

ssp% bringup -A on -l7 (using level 7 hpost to expedite bringup, where you want to autoboot WITHOUT verifying network bootability)

-or-

ssp% bringup -A on -l16 (using default hpost level 16 to test domain, and where you want to autoboot WITHOUT verifying network bootability)

-or-

ssp% bringup -A off -l7 (using level 7 hpost to expedite bringup, where you want verify network bootability from OBP prompt)

-or-

ssp% bringup -A off -l16 (using default hpost level 16 to test domain, and where you want to verify network bootability from OBP prompt)

Post domain name change procedures:

Verify the domain can be successfully network booted If you directly go to autobooting the domain, be sure to schedule a time to verify the network bootability of the domain. (Else why did you go through this procedure )
Verifydomain's OBP parameter local-mac-address is set to false, else your network boot will likely timeout and never work. Having local-mac-address set to true will cause the domain to broadcast the mac address of the specific NIC rather than the mac address of the domain.
Verify the mac address displayed by the sys_id command matches your entry in /etc/ethers. Should someone have changed the /etc/ethers entry to reflect the mac address of the specific NIC and setup the install client with that mac address, know the domain will attempt to boot, but eventually hang before completing the network boot process.
IF you have ALSO changed the name of the domain as part of this procedure, you will also need to insure the ssp properly recognizes the new domain name. You will need to make changes in the /etc/hosts, /etc/ethers and etc/bootparams files to match the new information. If the ssp is setup as the network boot server for the domain,(as most are) you will need to do a remove_install_client, then change /etc/hosts and /etc/ethers then do add_install_client to properly update /etc/bootparams. Failure to do so may create problems when you attempt to boot the domain from the network when future maintenance requires it.
Once you have verified the domain can be network booted successfully, be sure to change any OBP parameters back such as local-mac-address
Be sure to run ssp_backup (ssp 3.2 & 3.3) or that updated files are propagated to the spare ssp via setdatasync command (ssp 3.4 & 3.5). Running ssp_backup will require a manual ftp transfer to the spare ssp, setdatasync will propagate file changes when setfailover is active between the main & spare ssp.

Product
Sun Enterprise 10000 Server

E10000, starfire, E10K, mmu, tsb, boot net, domain_remove, domain_rename
Previously Published As
42949
Product_uuid
29ddef46-0a18-11d6-92de-ae47474f0f6c|Sun Enterprise 10000 Server

Change History
Date: 2003-10-23
User Name: 81292
Action: Approved
Comment:
KCCP: OK to publish
Version: 0
Date: 2003-10-20
User Name: 116819
Action: Approved
Comment: ok
Version: 0

Attachments

This solution has no attachment