Panic with HIGHMEM enabled in RHEL3
in [RedHat]
|
From: Lars on 5 Jul 2007 16:22 Hi, I have a RHEL3 Update 5 server that has been very stable, but when I run HP StorageWorks (./hp_ltt) and do device detection I get a kernel panic. According to HP this is "Due to a bug (32-bit overflow in vmap() check with >4GB memory) in the OS." As a solution, they recommend: - use RHEL 3 update 8 - or reconfigure the kernel with HIGHMEM OFF. Since this server has been very stable, I am hesitant to apply updates. I am not quite certain where to go from here. I could bring the server up to RHEL3(U8). If there is instability I could go back to the previous kernel version (2.4.21-32.0.1.ELsmp). But if I apply the full updates, many other files are updated as well (in addition to the kernel). Is there a reliable and clean way to back out of all updates. In other words, could you tell yum or up2date to update everything, but in such a way as to make a full (and clean) undo possible? Alternatively, I could simply update the kernel only, which is easy to "undo." Are there any potential problems with updating only the kernel (to update 8 version: 2.4.21-50.ELsmp or similar) and leave everything else at "update 5 versions?" Another approach would be to recompile the current kernel. cat config-2.4.21-32.0.1.ELsmp | grep HIGHMEM: CONFIG_DEBUG_HIGHMEM=y # CONFIG_NOHIGHMEM is not set # CONFIG_HIGHMEM4G is not set CONFIG_HIGHMEM64G=y # CONFIG_NOHIGHMEM is not set # CONFIG_HIGHMEM4G is not set CONFIG_HIGHMEM64G=y I have only 4GB in the server, so I guess I could go for CONFIG_HIGHMEM4G instead of CONFIG_HIGHMEM64G? If so, what is the easiest way to do this? Any help on this would be greatly appreciated! Thanks, Lars Ps. Here is a users with a similar problem: http://linux.derkeiler.com/Mailing-Lists/Kernel/2003-09/6497.html
From: J.O. Aho on 6 Jul 2007 00:32 Lars wrote: > Hi, > > I have a RHEL3 Update 5 server that has been very stable, but when I run HP > StorageWorks (./hp_ltt) and do device detection I get a kernel panic. > According to HP this is "Due to a bug (32-bit overflow in vmap() check with > >4GB memory) in the OS." > > As a solution, they recommend: > - use RHEL 3 update 8 > - or reconfigure the kernel with HIGHMEM OFF. > > Since this server has been very stable, I am hesitant to apply updates. I > am not quite certain where to go from here. Even if you install a new kernel, you will have your old left, so you can always easily go back to it if the new one would turn out to be unstable. As HP selles Servers with RedHat pre-installed, I don't think they would recommend a kernel that wouldn't be stable. > I could bring the server up to RHEL3(U8). If there is instability I could > go back to the previous kernel version (2.4.21-32.0.1.ELsmp). But if I > apply the full updates, many other files are updated as well (in addition to > the kernel). Is there a reliable and clean way to back out of all updates. Backing other software isn't as easy as reboot into the older kernel, but it's possible, you need to know all the packages thats been updated (best if you have those older RPMs locally), you can then force a downgrade if you use the RPM command directly. > Alternatively, I could simply update the kernel only, which is easy to > "undo." Are there any potential problems with updating only the kernel (to > update 8 version: 2.4.21-50.ELsmp or similar) and leave everything else at > "update 5 versions?" In RedHat you have strict dependency and I can image that a far newer kernel will want to have at least a new glibc installed, this for if you use an older glibc you won't get full use of all the new features, glibc will in it's own turn draw in some other packages. > Another approach would be to recompile the current kernel. > > cat config-2.4.21-32.0.1.ELsmp | grep HIGHMEM: > CONFIG_DEBUG_HIGHMEM=y > # CONFIG_NOHIGHMEM is not set > # CONFIG_HIGHMEM4G is not set > CONFIG_HIGHMEM64G=y > # CONFIG_NOHIGHMEM is not set > # CONFIG_HIGHMEM4G is not set > CONFIG_HIGHMEM64G=y > > I have only 4GB in the server, so I guess I could go for CONFIG_HIGHMEM4G > instead of CONFIG_HIGHMEM64G? If so, what is the easiest way to do this? cd /usr/src/linux-<version you want to use> cp ../<version you have used>/.config . make oldconfig <answer the questions you may get, default answer is ok> make menuconfig <now you can turn on/off features for the kernel> make dep && make vmlinux modules modules_install <copy the vmlinux to /boot and modify your lilo.conf or grub.conf> There should be some documentation at RedHat and/or Fedora that tells you how to compile a kernel. -- //Aho
From: Jan Gerrit Kootstra on 6 Jul 2007 01:37 J.O. Aho wrote: > Lars wrote: > >>Hi, >> >>I have a RHEL3 Update 5 server that has been very stable, but when I run HP >>StorageWorks (./hp_ltt) and do device detection I get a kernel panic. >>According to HP this is "Due to a bug (32-bit overflow in vmap() check with >> >4GB memory) in the OS." >> >>As a solution, they recommend: >>- use RHEL 3 update 8 >>- or reconfigure the kernel with HIGHMEM OFF. >> >>Since this server has been very stable, I am hesitant to apply updates. I >>am not quite certain where to go from here. > > > Even if you install a new kernel, you will have your old left, so you can > always easily go back to it if the new one would turn out to be unstable. > As HP selles Servers with RedHat pre-installed, I don't think they would > recommend a kernel that wouldn't be stable. > > > >>I could bring the server up to RHEL3(U8). If there is instability I could >>go back to the previous kernel version (2.4.21-32.0.1.ELsmp). But if I >>apply the full updates, many other files are updated as well (in addition to >>the kernel). Is there a reliable and clean way to back out of all updates. > > > Backing other software isn't as easy as reboot into the older kernel, but it's > possible, you need to know all the packages thats been updated (best if you > have those older RPMs locally), you can then force a downgrade if you use the > RPM command directly. > > > >>Alternatively, I could simply update the kernel only, which is easy to >>"undo." Are there any potential problems with updating only the kernel (to >>update 8 version: 2.4.21-50.ELsmp or similar) and leave everything else at >>"update 5 versions?" > > > In RedHat you have strict dependency and I can image that a far newer kernel > will want to have at least a new glibc installed, this for if you use an older > glibc you won't get full use of all the new features, glibc will in it's own > turn draw in some other packages. > > > >>Another approach would be to recompile the current kernel. >> >>cat config-2.4.21-32.0.1.ELsmp | grep HIGHMEM: >>CONFIG_DEBUG_HIGHMEM=y >># CONFIG_NOHIGHMEM is not set >># CONFIG_HIGHMEM4G is not set >>CONFIG_HIGHMEM64G=y >># CONFIG_NOHIGHMEM is not set >># CONFIG_HIGHMEM4G is not set >>CONFIG_HIGHMEM64G=y >> >>I have only 4GB in the server, so I guess I could go for CONFIG_HIGHMEM4G >>instead of CONFIG_HIGHMEM64G? If so, what is the easiest way to do this? > > > cd /usr/src/linux-<version you want to use> > cp ../<version you have used>/.config . > make oldconfig > <answer the questions you may get, default answer is ok> > make menuconfig > <now you can turn on/off features for the kernel> > make dep && make vmlinux modules modules_install > <copy the vmlinux to /boot and modify your lilo.conf or grub.conf> > > There should be some documentation at RedHat and/or Fedora that tells you how > to compile a kernel. > > Dear original poster, I would backup the system (not userdata) before doing the update to RHEL3U8 and keep that backup for some weeks until you feel save to say your system is stable. I recommend: Do not do a recompile of your kernel if you have Red Hat support, I do not know if HP�s support division accepts self compiled kernels. Red Hat support will tell you to install a Red Hat compiled kernel before a support ticket will be solved. Best regards, Jan Gerrit Kootstra
From: BearItAll on 6 Jul 2007 09:12 Lars wrote: > Hi, > > I have a RHEL3 Update 5 server that has been very stable, but when I run > HP StorageWorks (./hp_ltt) and do device detection I get a kernel panic. > According to HP this is "Due to a bug (32-bit overflow in vmap() check > with > >4GB memory) in the OS." > I'll make a bet with you, I bet your left sock:- I bet that the panic is because of the SCSI driver. Did I just hear you say 'but my drives are on that too and they are alright and anyway the SCSI don't get a mention here'? true true very true, but still, have a look on hp.com for your SCSI driver and the updated driver for your tape device while you are in there. If I'm right I get your left sock. If I am wrong I will put my own left sock between two slices of bread and eat it. (can I use brown saurce, Or does that break the rules of gambling?)
From: Lars on 6 Jul 2007 12:39
J.O. Aho and Jan Gerrit, thanks for your responses. Actually, I do not have a RH contract and I do not have an HP server. After thinking this over further, I really only have one option: update the kernel. Recompiling the existing kernel without HIGHMEM is not an option since I need the OS to use the 4GB I have in the server. J.O. Aho: Are you sure the kernel have dependencies on libc, etc?? [root(a)main5 tmp]# rpm -q --qf "[%{REQUIRENAME} %{REQUIREFLAGS:depflags} %{REQUIREVERSION}\n]" kernel-smp-2.4.21-47.0.1.EL /bin/sh fileutils initscripts >= 5.83 mkinitrd >= 3.2.6 modutils >= 2.4.18 rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(VersionedDependencies) <= 3.0.3-1 My understanding is that the kernel is quite independent of other packages. Lars "Jan Gerrit Kootstra" <jan.gerrit(a)kootstra.org.uk> wrote in message news:nykji.3205$%q4.1023(a)amstwist00... > J.O. Aho wrote: >> Lars wrote: >> >>>Hi, >>> >>>I have a RHEL3 Update 5 server that has been very stable, but when I run >>>HP StorageWorks (./hp_ltt) and do device detection I get a kernel panic. >>>According to HP this is "Due to a bug (32-bit overflow in vmap() check >>>with >>> >4GB memory) in the OS." >>> >>>As a solution, they recommend: >>>- use RHEL 3 update 8 >>>- or reconfigure the kernel with HIGHMEM OFF. >>> >>>Since this server has been very stable, I am hesitant to apply updates. >>>I am not quite certain where to go from here. >> >> >> Even if you install a new kernel, you will have your old left, so you can >> always easily go back to it if the new one would turn out to be unstable. >> As HP selles Servers with RedHat pre-installed, I don't think they would >> recommend a kernel that wouldn't be stable. >> >> >> >>>I could bring the server up to RHEL3(U8). If there is instability I >>>could go back to the previous kernel version (2.4.21-32.0.1.ELsmp). But >>>if I apply the full updates, many other files are updated as well (in >>>addition to the kernel). Is there a reliable and clean way to back out >>>of all updates. >> >> >> Backing other software isn't as easy as reboot into the older kernel, but >> it's >> possible, you need to know all the packages thats been updated (best if >> you >> have those older RPMs locally), you can then force a downgrade if you use >> the >> RPM command directly. >> >> >> >>>Alternatively, I could simply update the kernel only, which is easy to >>>"undo." Are there any potential problems with updating only the kernel >>>(to update 8 version: 2.4.21-50.ELsmp or similar) and leave everything >>>else at "update 5 versions?" >> >> >> In RedHat you have strict dependency and I can image that a far newer >> kernel >> will want to have at least a new glibc installed, this for if you use an >> older >> glibc you won't get full use of all the new features, glibc will in it's >> own >> turn draw in some other packages. >> >> >> >>>Another approach would be to recompile the current kernel. >>> >>>cat config-2.4.21-32.0.1.ELsmp | grep HIGHMEM: >>>CONFIG_DEBUG_HIGHMEM=y >>># CONFIG_NOHIGHMEM is not set >>># CONFIG_HIGHMEM4G is not set >>>CONFIG_HIGHMEM64G=y >>># CONFIG_NOHIGHMEM is not set >>># CONFIG_HIGHMEM4G is not set >>>CONFIG_HIGHMEM64G=y >>> >>>I have only 4GB in the server, so I guess I could go for CONFIG_HIGHMEM4G >>>instead of CONFIG_HIGHMEM64G? If so, what is the easiest way to do this? >> >> >> cd /usr/src/linux-<version you want to use> >> cp ../<version you have used>/.config . >> make oldconfig >> <answer the questions you may get, default answer is ok> >> make menuconfig >> <now you can turn on/off features for the kernel> >> make dep && make vmlinux modules modules_install >> <copy the vmlinux to /boot and modify your lilo.conf or grub.conf> >> >> There should be some documentation at RedHat and/or Fedora that tells you >> how >> to compile a kernel. >> >> > Dear original poster, > > > I would backup the system (not userdata) before doing the update to > RHEL3U8 and keep that backup for some weeks until you feel save to say > your system is stable. > > I recommend: Do not do a recompile of your kernel if you have Red Hat > support, I do not know if HP�s support division accepts self compiled > kernels. Red Hat support will tell you to install a Red Hat compiled > kernel before a support ticket will be solved. > > > Best regards, > > > Jan Gerrit Kootstra |