Bug 128567 - assertion: "FALSE" failed in /usr/src/cluster/gfs-kernel/src/gfs/inode.c
assertion: "FALSE" failed in /usr/src/cluster/gfs-kernel/src/gfs/inode.c
Product: Red Hat Cluster Suite
Classification: Red Hat
Component: dlm (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: David Teigland
Cluster QE
Depends On:
  Show dependency treegraph
Reported: 2004-07-26 11:40 EDT by Corey Marthaler
Modified: 2009-04-16 16:29 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-01-05 17:39:44 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Corey Marthaler 2004-07-26 11:40:42 EDT
Description of problem: 
I was running I/O to three filesystems on my 6 node cluster over the 
weekend and hit this assertion failure: 
dlm: tarlow2: recover event 15 done 
dlm: tarlow2: process held requests 
dlm: tarlow2: processed 0 requests 
dlm: tarlow2: resend marked requests 
dlm: tarlow2: resent 0 requests 
dlm: tarlow2: recover event 15 finished 
dlm: tarlow1: granting lock on lockqueue 
dlm: lkb 
id 400a01d8 
remid 0 
flags 0 
status 1 
rqmode 3 
grmode -1 
nodeid 1 
lqstate 3 
lqflags 0 
dlm: request 
rh_cmd 6 
rh_lkid 3141032d 
remlkid 400a01d8 
flags 0 
status 0 
rqmode 0 
dlm: tarlow1: process_lockqueue_reply id 400a01d8 state 0 
GFS: Assertion failed on line 247 of file 
GFS: assertion: "FALSE" 
GFS: time = 1090835334 
GFS: fsid=morph-cluster:tarlow2.4: inode = 50980737/50980737 
Kernel panic: GFS: Record message above and reboot. 
Here are the cmdlines that I was running: 
./accordion -L flock -s 2097152 -e 1024 -w /mnt/tarlow0 -t -m 100000 
-S 54321 accd1 accd2 accd3 accd4 accd5 accd6 accd7 accd8 accd9 
accd10 & 
./genesis -S 12345 -n 7500 -s 1048576 -L flock -d 700 -w 
/mnt/tarlow1 & 
./genesis -S 12345 -n 7500 -s 1048576 -L flock -d 700 -w 
/mnt/tarlow2 &
Comment 1 David Teigland 2004-07-27 02:49:57 EDT
The "granting lock on lockqueue", lkb printout, and
"process_lockqueue_reply" are not a problem and probably not
related to the assertion.
Comment 2 Kiersten (Kerri) Anderson 2004-11-04 10:17:11 EST
Updates with the proper version and component name.
Comment 3 Corey Marthaler 2005-01-05 17:39:44 EST
hasn't been seen in over 5 months.

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