Bug 112365 - Kernel Panic when running pulse deamon
Summary: Kernel Panic when running pulse deamon
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel   
(Show other bugs)
Version: 3.0
Hardware: i686 Linux
medium
high
Target Milestone: ---
Assignee: Jeff Moyer
QA Contact: Brian Brock
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-12-18 14:22 UTC by Olivier de Liocourt
Modified: 2007-11-30 22:06 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-01-19 20:37:18 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2004:017 normal SHIPPED_LIVE Important: Updated kernel packages available for Red Hat Enterprise Linux 3 Update 1 2004-01-13 05:00:00 UTC

Description Olivier de Liocourt 2003-12-18 14:22:57 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5)
Gecko/20031015 Firebird/0.7

Description of problem:
installed on 2 Dell Poweredge 1750, with 2 Xeon in each, and 2 Go of
memory in each:

RHEL 3 ES with latest erratas installed, and ClusterSuite installed.

Configuration of LVS done with Piranha.

pulse has been run on the 2 nodes. All seems okay....5 minutes.

After 5 minutes, the master node get a kernel panic, the backup node
takes the net traffic automtically, and 5 minutes later, the backup
node get a kernel panic too.

Version-Release number of selected component (if applicable):
ipvsadm-1.21-9 kernel-2.4.21-4.0.1.EL

How reproducible:
Always

Steps to Reproduce:
1.install RHEL 3 on two PE 1750
2.install cluster suite, configure lvs.cf
3. run pulse on each node, and wait
    

Actual Results:  kernel panic

Expected Results:  nothing

Additional info:

did the installation at the customer site back to RHEL 2.1AS.
Running without any problem.

Comment 1 Mike McLean 2003-12-18 18:11:46 UTC
This is not a problem with ipvsadm, but with the ip_vs patch in the
kernel.  ip_vs is simply broken with the RHEL 3 smp kernel.  The
kernel gets stuck when ip_vs tries to expire a connection (this is why
it takes a few minutes).

WORKAROUND: use the up kernel.

Here is a quick reproducer requiring only two machines, one ipvs
router and one client:

Set up Machine A as an ipvs router:
% IP=192.168.xx.xx  #the ip address of Machine A
% RS=192.168.xx.xx  #some other address (doesn't need to reach anything)
% ipvsadm -A -t $IP:80 -s rr
% ipvsadm -a -t $IP:80 -r $RS:80 -g -w 1
% ipvsadm --set 30 30 30   #optional - shortens the timeout

Use Machine B to send a single request to the router
% IP=192.168.xx.xx  #the ip address of Machine A
% echo 'GET /' | nc -nvw 3 $IP 80

Comment 3 Jeff Moyer 2004-01-12 20:41:03 UTC
This bug was fixed in kernel-2.4.21-4.9.EL, and will appear in update
1.  Essentially, del_timer_sync was called from the timer expiry
routine, causing it to block on itself.  The call was changed to:

if (timer_pending())
        del_timer()


Comment 5 Hernando Garcia 2004-01-13 13:48:00 UTC
A client of us has reported this issue. The problem is also in RHEL
2.1 smp kernel.

WORKAROUND: use the up kernel too.

If you require more information please do contact me.




Comment 6 Jeff Moyer 2004-01-13 13:50:42 UTC
What kernel version?

Comment 7 Hernando Garcia 2004-01-14 11:07:23 UTC
Jeffrey,

You can ignore comment #5, I have got the OS version wrong. 

Many apologies.

Comment 8 Mike McLean 2004-01-19 20:37:18 UTC
This is fixed in by the kernel errata in RHEL3 Update 1


Note You need to log in before you can comment on or make changes to this bug.