|C H A P T E R 7|
Dynamic Reconfiguration on Sun Fire High-End Systems
Description: When a domain is configured with a large amount of memory (340 Gbytes or more), either at boot time or due to subsequent DR operations, the memory scrubbing thread monopolizes a particular system lock for 60 to 90 minutes once every 12 hours. Any DR operation that attempts to configure or unconfigure memory in the domain during one of these windows hangs until the system lock is released. As long as a DR operation remains hung for this reason, any additional DR operations also hang.
These messages are benign; the DVMA space is properly refreshed during the DR operation. No true kernel memory leak occurs. This bug affects domains running both Solaris 8 and Solaris 9 operating environments.
Description: A cfgadm(1M) unconfigure operation on permanent memory executed on a system with a glm driver that is active may hang. The problem is specific to DR operations involving permanent memory, which require that the system be quiesced via suspend/resume. The problem lies with the glm driver. This bug affects domains running both Solaris 8 and Solaris 9 operating environments.
Description: Unconfiguring a hsPCI or hsPCI+ I/O board while a PCI option card is being configured into it causes a system panic. For example, the panic would occur if the following commands were executed simultaneously. In this example, pcisch18:e03b1slot2 is one of the four PCI Slots on IO3:
Description: Under certain error conditions, using DR to unconfigure a processor can leave that processor in the powered-off state. If psradm(1M) is then used to transition the processor to the off-line state, a system panic may result. Factors contributing to the problem are that Solaris does not expect processors to be in the powered-off state long-term, and psradm(1M) does not allow transitioning of processors to the powered-off state.
Description: Processors added using DR are shown by various tools as running at the processor's rated frequency rather than its actual frequency. In most cases, the rated and actual frequencies for a processor are the same. Processors present in the system at boot display the correct, actual frequency.
Description: If automatic processor removal is enabled on a Sun Fire E25K/E20K system, an event notifying the system controller that a processor has been offlined due to L2 cache errors may not get delivered if the board was added using DR. The process of offlining the processor on the domain is not affected. Boards present in the domain at boot do not experience this problem.
Description: Sending a catchable signal, such as SIGINT sent by CTRL-C, to one or more cfgadm instances can cause those instances to hang. The problem is more likely to occur when multiple cfgadm processes are running, and can affect cfgadm instances on system boards, processors, I/O boards, and PCI slot attachment points. The problem has not been observed with a SIGKILL, and does not affect cfgadm status commands.
Description: If non-permanent memory is unconfigured, the system removes retired pages from the retired pages list to prevent them from becoming dangling pages - that is, pages that point to physical memory that would have been unconfigured. When permanent memory is unconfigured, a target board is identified and unconfigured first. Once a target board is ready, the contents of the source board (the permanent memory) are copied to the target board. The target board is then "renamed" (memory controllers are programmed) to have the same address range as the source board. What this means is that if the source board contained any retired pages, these pages would not be dangling pages after the rename. They would point to valid addresses, but the physical memory behind those addresses is in the target board. The problem is that the physical memory is probably good (does not contain ECC errors).
Description: Attempting to execute a DR operation on a system with Sun GigaSwift Ethernet MMF Option X1151A, part number 595-5773, attached to certain CISCO switches causes the link to fail. The problem is caused by a known bug in the following CISCO hardware/firmware:
CISCO WS-c4003 switch (f/w: WS-C4003 Software, Version NmpSW: 4.4(1))
CISCO WS-c4003 switch (f/w: WS-C4003 Software, Version NmpSW: 7.1(2))
CISCO WS-c5500 switch (f/w: WS-C5500 Software, Version McpSW: 4.2(1) and NmpSW: 4.2(1))