System lock or slow scanning of LUNs from SAN

  • 3920233
  • 14-May-2007
  • 30-Apr-2012

Environment

Novell SUSE Linux Enterprise Server 10


Situation

When loading many LUNs from a SAN from the initial ramdisk (i.e. as configured through anINITRD_MODULESsetting in /etc/sysconfig/kernel which includes HBA drivers) scanning may take a long time. This is due to the involvement of the VESA Framebuffer.
On some systems this may even introduce a buffer overflow condition that will hang the system altogether. This lockup is exhibited on x86_64 installations.

Resolution

There are three primary solutions:
  • Boot the kernel with the parameter vga=normal. E.g., when the default bootloader, GRUB, is used:
    1. Edit /boot/grub/menu.lst
    2. Change 'vga=XXX' to 'vga=normal'.
  • Use a serial console instead of the framebuffer console. For details, refer to the product documentation or to KB 3456486: Configuring a Remote Serial Console for SLES.
  • Change the kernel 'loglevel' parameter to decrease the verbosity of logging. For example, setting 'loglevel=4' will likely solve the problem. See the "additional notes" section for details.

Additional Information

The loglevel kernel parameter sets the verbosity of the kernel logging. The default loglevel is 7.
From /usr/src/linux/Documentation/kernel-parameters.txt
loglevel=       All Kernel Messages with a loglevel smaller than the
console loglevel will be printed to the console. It can
also be changed with klogd or other programs. The
loglevels are defined as follows:
0 (KERN_EMERG) system is unusable
1 (KERN_ALERT) action must be taken immediately
2 (KERN_CRIT) critical conditions
3 (KERN_ERR) error conditions
4 (KERN_WARNING) warning conditions
5 (KERN_NOTICE) normal but significant condition
6 (KERN_INFO) informational
7 (KERN_DEBUG) debug-level messages