SCIENTIFIC-LINUX-USERS Archives

March 2009

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Takashi Ichihara <[log in to unmask]>
Reply To:
Takashi Ichihara <[log in to unmask]>
Date:
Thu, 19 Mar 2009 13:52:37 +0900
Content-Type:
text/plain
Parts/Attachments:
text/plain (102 lines)
Troy Dawson wrote:
> Takashi Ichihara wrote:
>   
>>  Hi, all
>>
>> We have been using SL4.6/4.7 (i386 and X86_64) on several nodes
>> and have experienced kernel panic frequently during the system
>> rebooting or system shutdown or even by /etc/init.d/ip_tables restart
>> since last summer in 2008.
>>
>> This is a known bug and still unresolved as reported at the
>> upstream vender's bugzilla.
>> https://bugzilla.redhat.com/show_bug.cgi?id=456664
>>
>> With several investigation, this Kernel panic related to [ip_conntrack]
>> occurs in the the following condition in our environment.
>>
>> 1) Kernel is
>> kernel-smp-2.6.9-78.1EL (SMP or hugemem) (Aug. 2008) to
>> kernel-smp-2.6.9-78.13EL (SMP or hugemem) (latest kernel)
>>
>> 2) ip-tables is enabled and in /etc/sysconfig/iptables-config
>> IPTABLES_MODULES="ip_conntrack_ftp"
>> is included.
>>
>> In this situation, during the rebooting or /etc/init.d/iptables stop
>> or /etc/init.d/iptables restart operations,
>>
>> kernel panic relating with [ip_conntrack] accrues. This kernel bug
>> is still unresolved.
>>
>> However, there is a workaround to avoid this problem. It is
>> described in the comment 31 in
>> https://bugzilla.redhat.com/show_bug.cgi?id=456664
>>
>>     
>>> We have discovered that when the following is in the iptables-config:
>>>
>>> IPTABLES_MODULES="ip_conntrack_ftp ip_nat_ftp iptable_nat ipt_REJECT
>>>       
>> iptable_mangle"
>>     
>>> and on the 2.6.9-78.0.1 ( or .5) RHEL4 version kernel, the kernel
>>> panic does not occur when iptables is stopped.
>>>       
>> We have tested this workaround in several nodes of SL4.6/7 (both
>> i386 and X86_64) with the kernel 2.6.9-78.0.13.ELsmp.
>>
>> After updating the /etc/sysconfig/iptables-config to include
>> IPTABLES_MODULES="ip_conntrack_ftp ip_nat_ftp iptable_nat ipt_REJECT
>> iptable_mangle",
>> the first rebooting failed with kernel panic because this update was not
>> reflected. But in the second rebooting and also
>> /etc/init.d/ip_tables stop or /etc/init.d/ip_tables restart command,
>> the kernel panic does not occur. So I think this is the current best
>> workaround against this kernel panic of kernel-smp-2.6.9-78.* (1-13)
>> relating to [ip_conntrack] or [ip_tables].
>>
>> PS: This problem does not occure at SL 5.2 (kernel 2.6.18-*)
>>
>> Best Regards,
>> Takashi Ichihara (RIKEN)
>>
>>     
>
> Hi,
> Just for your information, a new kernel just came out right now for SL4,
> 2.6.9-78.0.17.EL
>
>
> As part of the things it's fixed is
>
> * when the iptables module was unloaded, it was assumed the correct entry
> for removal had been found if "wrapper->ops->pf" matched the value passed
> in by "reg->pf". If several ops ranges were registered against the same
> protocol family, however, (which was likely if you had both ip_conntrack
> and ip_contrack_* loaded) this assumption could lead to NULL list pointers
> and cause a kernel panic. With this update, "wrapper->ops" is matched to
> pointer values "reg", which ensures the correct entry is removed and
> results in no NULL list pointers. (BZ#477147)
>
> Looking at bugzilla 477147, it says
> "This bug has been copied from bug #456664"
>
> So, hopefully this new kernel will fix the problem.
>
> The new kernel should go into the errata tomorrow if all goes well.
>
> Troy
>   

Hi

New Kernel for SL4 2.6.9-78.0.17.EL arrived last nigh (18th March)
to our mirror (ftp.riken.jp). We have confirmed that this problem
( bug #456664") since last summer is resolved at last both in
i386 and X86_64 at the kernel 2.6.9-78.0.17.ELsmp.

Thank you for your information and update.

Takashi Ichihara

ATOM RSS1 RSS2