> Source: [sk163599](https://support.checkpoint.com/results/sk/sk163599)

# sk163599 - Appliance fails to boot after memory / RAM is upgraded

| Property | Value |
|----------|-------|
| Solution ID | sk163599 |
| Date Created | 2019-12-01 |
| Last Modified | 2019-12-05 |
| Technical Level | Advanced |
| Products | Security Gateway, Security Management Server |
| Versions | R82.10, R82, R81.20, R82.10, R82, R81.20, R82.20 |
| OS | Gaia |

## Symptoms

- * After a memory/RAM upgrade, the appliance fails to boot.
* There is a kernel panic after the GRUB boot menu, when the Linux kernel is loaded.
* Kernel panic messages on the serial console may show the following output for function "megasas_complete_cmd_dpc":

  ```
  
  0xffff812078b500c0     7463        1  1    0   R  0xffff812078b503a0 *gzip
  rsp                rip                Function (args)
   ======================= 
  0xffffffff805d9d20 0xffffffff880bf4a2 [megaraid_sas]megasas_handle_cpx_requests+0x52 (unknown)
  0xffffffff805d9ed8 0xffffffff880c1a9e [megaraid_sas]megasas_complete_cmd_dpc+0x10e (0xffff810171d704f8)
  0xffffffff805d9f18 0xffffffff80047739 tasklet_action+0x59
  0xffffffff805d9f38 0xffffffff80047663 __do_softirq+0x73
  0xffffffff805d9f68 0xffffffff8000b5dc call_softirq+0x1c
  0xffffffff805d9f80 0xffffffff8000cef5 do_softirq+0x35
  0xffffffff805d9f90 0xffffffff8000ce47 do_IRQ+0x97 (0xffff81207767bf58)
   ======================= 
  0xffff81207767bf78 0xffffffff8000a8f5 ret_from_intr (unknown, unknown, unknown, unknown, unknown, unknown)
  kdb_bb: address 0x0000000008049641 not recognised
  Using old style backtrace, unreliable with no arguments
  rsp                rip                Function (args)
   ======================= 
  0xffffffff805d9d20 0xffffffff880bf4a2 [megaraid_sas]megasas_handle_cpx_requests+0x52
  0xffffffff805d9d28 0xffffffff800df69f mpage_end_io_read+0x6f
  0xffffffff805d9d58 0xffffffff800374bb enqueue_task+0x4b
  0xffffffff805d9d78 0xffffffff8003750d __activate_task+0x2d
  0xffffffff805d9d98 0xffffffff800381f3 try_to_wake_up+0x63
  0xffffffff805d9de0 0xffffffff8004b2e9 lock_timer_base+0x29
  0xffffffff805d9e00 0xffffffff8004b45b __mod_timer+0xbb
  0xffffffff805d9e28 0xffffffff8004b2e9 lock_timer_base+0x29
  0xffffffff805d9e48 0xffffffff8004b7ed del_timer+0x6d
  0xffffffff805d9e78 0xffffffff8807f8ba [scsi_mod]scsi_delete_timer+0x1a
  0xffffffff805d9ed8 0xffffffff880c1a9e [megaraid_sas]megasas_complete_cmd_dpc+0x10e
  0xffffffff805d9f18 0xffffffff80047739 tasklet_action+
  ```

## Cause

If there is a system crash, the *kdump* kernel writes the contents of the system's memory to a file (vmcore), so that it can later be analyzed to determine the root cause of the system crash.

By default, the *kdump* feature is turned on in versions R76 and above.

The amount of memory reserved for *kdump* must be tuned according to the amount of installed memory on the system.

In RHEL-based OS (including Gaia with kernel version 2.6.18), there exists a problem in the *megaraid_sas* implementation for *kdump* , causing a kernel panic when there is insufficient memory reserved for the *kdump* kernel, or when the *kdump* reservation is at an overlapping offset with the *megaraid_sas* driver.

## Solution

This solution requires authentication. Please log in to view the full solution.

---

# Agent Instructions

This content is from the Check Point Support Center (https://support.checkpoint.com), the official knowledge base for Check Point cybersecurity products.

## Navigating This Knowledge Base

- **Complete index**: [llms.txt](https://support.checkpoint.com/llms.txt)
- **All SK articles**: [SecureKnowledge Sitemap](https://support.checkpoint.com/sitemaps/secureknowledge-sitemap-index.xml)
- **SK article URL pattern**: `https://support.checkpoint.com/results/sk/{skId}`
- **Markdown responses**: AI bot User-Agents automatically receive `text/markdown` content