Don’t panic! Don’t let your kernel do it either.
A system crash can be one of the most frustrating issues that administrators can encounter in their day to day work. They often strike without warning, require hard reboots, and can kill a process uncleanly, leaving various locked files in place that an admin must go back and manually clean up. These kind of interruptions can take a few minutes to a few hours to overcome. That’s time you could be spending engineering new solutions that change the world, or at the very least, drinking some coffee and catching up on your email.
Insights has your back when it comes to these day-wrecking errors. The Red Hat Knowledgebase is full of incidents that we have diagnosed and tracked down to specific causes. We use this data within Insights to catch these errors before they happen. We see the problems coming so you can take action to fix them before they pull you away from the creative work you’re doing.
| Rule | Description | Reference |
|---|---|---|
| Kernel panic when scanning network for LUNs in bnx2fc driver | When scanning the network for Logical Unit Numbers (LUNs), a kernel panic can occur due to a race condition in the bnx2fc driver. A kernel panic can also occur from scanning for an FCoE-served LUN after an initial LUN scan. | Why "bnx2fc: byte_count = 62 != scsi_bufflen = 0," messages appears while accessing FCOE provisioned LUNS in RHEL6? |
| Kernel panic when using TSO in bnx2x driver | When booting a system with TCP segmentation offload (TSO) enabled and the boot parameters '[intel|amd]_iommu=on', a kernel panic occurs during transmission of tunneled TSO packets. | kernel crashes with instruction pointer at "rb_erase+0x1fb/0x390" if [intel|amd]_iommu=on and TSO with bnx2x driver are enabled. |
| Kernel panic when using an Emulex network interface with GRO enabled in be2net driver | A kernel panic can occur when systems with an Emulex network interface are using the be2net driver with GRO set to "on." | Kernel panic when using the be2net driver occurs when networking is started |
| Kernel panic after 200+ days of uptime when using the TSC clock source | Early RHEL kernels were susceptible to a system panic after 208.5 of uptime when the system was using the TSC clock source. | Red Hat Enterprise Linux systems using the TSC clock source reboots or panics when 'sched_clock()' overflows after an uptime of 208.5 days |
| Kernel panic after 200+ days of uptime on certain Xeon CPUs | Intel Xeon P5, P5 v2, and P7 v2 CPUs running certain Red Hat Enterprise Linux kernels are susceptible to a bug that can lead to a system panic based on accumulated uptime. | Servers with Intel® Xeon® Processor E5, Intel® Xeon® Processor E5 v2, or Intel® Xeon® Processor E7 v2 and certain versions of Red Hat Enterprise Linux 6 kernels become unresponsive/hung or incur a kernel panic |
| Kernel panic when using HP Proliant Gen8 servers with older iLO4 firmware versions | HP ProLiant Gen8-series servers with Integrated Lights-Out 4 (iLO 4) firmware versions 1.30, 1.32, 1.40, and 1.50 have a bug that when combined with the HP watchdog driver (hpwdt) can cause system panics. | Why does the system crash with HP NMI Watchdog [hpwdt]? |
Register your machines now and spend less time fire-fighting crashed systems.
About The Author
Red Hat
Comments