Adding a systemboard fails with: Can't allocate VA for page

Asset ID:	1-72-1983281.1
Update Date:	2015-02-27
Keywords:

Solution Type Problem Resolution Sure

Solution 1983281.1 : Adding a systemboard fails with: Can't allocate VA for page_ts

Applies to:

Sun Fire E20K Server - Version All Versions and later
Sun Fire 12K Server - Version All Versions and later
Sun Fire 15K Server - Version All Versions and later
Sun Fire E25K Server - Version All Versions and later
Oracle Solaris on SPARC (32-bit)
Oracle Solaris on SPARC (64-bit)

Symptoms

adding a board via DR does not add the memory:

Feb 23 16:38:52 xxxxxx unix: [ID 700753 kern.info] kphysm_add_memory_dynamic: adding 33554432K at 0x1c000000000

Feb 23 16:38:52 xxxxxx unix: [ID 265243 kern.warning] WARNING: kphysm_add_memory_dynamic: Can't allocate VA for page_ts

Feb 23 16:38:52 xxxxxx dr: [ID 801593 kern.warning] WARNING: Insufficient memory: dr@0:SB14::memory

Feb 23 16:38:52 xxxxxx genunix: [ID 408114 kern.info] /memory-controller@1c0,400000 (mc-us316) offline

Feb 23 16:38:52 xxxxxx genunix: [ID 408114 kern.info] /memory-controller@1c1,400000 (mc-us317) offline

Feb 23 16:38:52 xxxxxx genunix: [ID 408114 kern.info] /memory-controller@1c2,400000 (mc-us318) offline

Feb 23 16:38:52 xxxxxx genunix: [ID 408114 kern.info] /memory-controller@1c3,400000 (mc-us319) offline

Feb 23 16:38:52 xxxxxx dr: [ID 801593 kern.warning] WARNING: Internal error: dr_mem.c 950

Feb 23 16:38:52 xxxxxx dcs: [ID 467052 daemon.error] <12102> config_change_state: Hardware specific failure: configure SB14: Insufficient memory: dr@0:SB14::memory

xxxxxx

- CPUs has been configured ok
- memory attach has failed(see SB14 which was added here)

Ap_Id Receptacle Occupant Condition Information
When Type Busy Phys_Id
SB5::memory connected configured ok base address 0x10000000000, 33554432 KBytes total, 19216256 KBytes permanent
Jan 19 2011 memory n /devices/pseudo/dr@0:SB5::memory
SB6::memory connected configured ok base address 0xc000000000, 33554432 KBytes total
Jan 7 2011 memory n /devices/pseudo/dr@0:SB6::memory
SB8::memory connected configured ok base address 0xa000000000, 33554432 KBytes total
Jan 19 2011 memory n /devices/pseudo/dr@0:SB8::memory
SB14::memory connected unconfigured ok base address 0x1c000000000, 33554432 KBytes total
Feb 23 16:26 memory n /devices/pseudo/dr@0:SB14::memory

prtdiag -v shows also only SB14 CPUS in the domain but no memory:

/SB14/P0 448 1800 32.0 US-IV+ 2.2 on-line 02/23/2015 16:26:08.
/SB14/P1 449 1800 32.0 US-IV+ 2.2 on-line 02/23/2015 16:26:08.
/SB14/P2 450 1800 32.0 US-IV+ 2.2 on-line 02/23/2015 16:26:08.
/SB14/P3 451 1800 32.0 US-IV+ 2.2 on-line 02/23/2015 16:26:09.
/SB14/P0 452 1800 32.0 US-IV+ 2.2 on-line 02/23/2015 16:26:08.
/SB14/P1 453 1800 32.0 US-IV+ 2.2 on-line 02/23/2015 16:26:08.
/SB14/P2 454 1800 32.0 US-IV+ 2.2 on-line 02/23/2015 16:26:08.
/SB14/P3 455 1800 32.0 US-IV+ 2.2 on-line 02/23/2015 16:26:09.

Cause

this is a known issue
The DR failed due to a lack of memory when allocating memory from the heap_arena caused by high fragmentation

from SR 3-6763916597:

the vmem consumer should be able to handle the failure case. It's not fair to blame vmem, though fragment seemed to be
an issue here. I'll see if there is any way to improve it. But this is not going to be an easy way. To this end, no solution can be perfect.

to examine the issue a (live)dump of the system is needed before reboot

Solution

reboot domain

References

<BUG:15101179> - SUNBT4656269 RECLAIM START-OF-DAY PAGE_TS LOST DURING DETACH OF A BOARD WITH MEM
<BUG:15117880> - SUNBT4726797 DR:PROBLEMS WITH ATTACH A SB TO A DOMAIN.
<BUG:15166768> - SUNBT4887497 DR ATTACH OF SB FAILS WITH KPHYSM_ADD_MEMORY_DYNAMIC CAN'T ALLOCATE

Attachments

This solution has no attachment