Bug 437803 - gfs2 crash - BUG: unable to handle kernel NULL pointer dereference at virtual address
gfs2 crash - BUG: unable to handle kernel NULL pointer dereference at virtual...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
5.1
All Linux
low Severity low
: rc
: ---
Assigned To: Steve Whitehouse
GFS Bugs
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-03-17 10:43 EDT by Maurizio Rottin
Modified: 2009-07-03 17:32 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-01-20 15:25:53 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Proposed fix (1000 bytes, patch)
2008-09-18 10:33 EDT, Steve Whitehouse
no flags Details | Diff
A second attempt at fixing this (1.99 KB, patch)
2008-09-25 10:17 EDT, Steve Whitehouse
no flags Details | Diff
RHEL5 version of the patch (2.01 KB, patch)
2008-10-07 10:48 EDT, Abhijith Das
no flags Details | Diff

  None (edit)
Description Maurizio Rottin 2008-03-17 10:43:34 EDT
Description of problem:
xen virtual machine crashes with 0002744: kernel BUG at fs/gfs2/glock.c:1131!

Version-Release number of selected component (if applicable):
Using Centos 5.1 for testing purpose
kernel-xen-2.6.18-53.1.6.el5
kernel-headers-2.6.18-53.1.6.el5
gfs2-utils-0.1.38-1.el5
gfs-utils-0.1.12-1.el5
kmod-gfs-xen-0.1.19-7.el5_1.1
kmod-gfs2-xen-1.52-1.16.el5


How reproducible:
I set up 6 nodes cluster, using gfs2 on 5 nodes (but it happens also when only
one node is mounting the fs).
The nodes are xen virtual mahcines mounting a lvm partition with "w!" directive

i got this when doing a
#tar jxvf file.tar.bz2 
from all the 5 five nodes at the same time in different directories.
where file.tar.bz2 is 100MB archive with a common website inside.


Additional info:
dlm: lockspace 30003 from 3 type 1 not found
dlm: lockspace 30003 from 5 type 1 not found
dlm: lockspace 30003 from 2 type 1 not found
dlm: drop message 7 from 5 for unknown lockspace 196611
dlm: lockspace 30003 from 2 type 1 not found
BUG: unable to handle kernel NULL pointer dereference at virtual address 00000054
 printing eip:
ee320e07
2b9c3000 -> *pde = 00000000:a8240001
2b94e000 -> *pme = 00000000:c0e03067
2bac3000 -> *pte = 00000000:00000000
Oops: 0002 [0000001]
SMP
last sysfs file: /kernel/dlm/gfs2http/control
Modules linked in: ipv6 lock_dlm gfs2 dlm configfs xennet dm_mirror dm_multipath
dm_mod parport_pc lp parport pcspkr xenblk ext3 jbd ehci_hcd ohci_hcd uhci_hcd
CPU: 0
EIP: 0061:[<ee320e07>] Not tainted VLI
EFLAGS: 00010286 (2.6.18-53.1.6.el5xen 0000001)
EIP is at revoke_lo_add+0x12/0x2f [gfs2]
eax: ed1ee000 ebx: ee320df5 ecx: ea2761f4 edx: 00000000
esi: ed1ee000 edi: ed1ee000 ebp: 00000000 esp: ed7dbe0c
ds: 007b es: 007b ss: 0069
Process pdflush (pid: 89, ti=ed7db000 task=ed7d8000 task.ti=ed7db000)
Stack: ee32f37d ea2a3dd4 ea2761e4 ee321ffd 00000000 ea2a3dd4 ea2761e4 c1983b80
       ed1ee000 ee322e6e 00000000 ea2a3dd4 00000000 c1983b80 ed05a4e4 000000b0
       00000000 ee322fff ed7dbf74 ed1ee000 c1983b80 00000001 00000000 ed7dbf74
Call Trace:
 [<ee32f37d>] gfs2_trans_add_revoke+0x51/0x54 [gfs2]
 [<ee321ffd>] gfs2_remove_from_journal+0xf1/0x101 [gfs2]
 [<ee322e6e>] gfs2_invalidatepage+0xd5/0x12d [gfs2]
 [<ee322fff>] gfs2_writepage+0xb4/0xec [gfs2]
 [<c0485cfe>] mpage_writepages+0x19b/0x304
 [<ee322f4b>] gfs2_writepage+0x0/0xec [gfs2]
 [<c044dd92>] do_writepages+0x2b/0x32
 [<c048455a>] __writeback_single_inode+0x168/0x2a7
 [<c048496e>] sync_sb_inodes+0x170/0x213
 [<c0484bbf>] writeback_inodes+0x6a/0xb0
 [<c044e1d5>] wb_kupdate+0x7b/0xdb
 [<c044e5ed>] pdflush+0x0/0x1af
 [<c044e700>] pdflush+0x113/0x1af
 [<c044e15a>] wb_kupdate+0x0/0xdb
 [<c042cc71>] kthread+0xc0/0xeb
 [<c042cbb1>] kthread+0x0/0xeb
 [<c0403005>] kernel_thread_helper+0x5/0xb
 =======================
Code: 19 33 ee 68 ab 18 33 ee b9 db ff 32 ee 89 f0 e8 bf e8 00 00 58 5a 5b 5e c3
89 d1 89 e2 81 e2 00 f0 ff ff 8b 12 8b 92 cc 04 00 00 <ff> 42 54 c7 42 34 01 00
00 00 8d 90 e4 05 00 00 ff 80 c8 05 00
EIP: [<ee3
Comment 1 Steve Whitehouse 2008-06-02 06:39:40 EDT
Can you reproduce this in 5.2? The GFS2 code in 5.1 is very old and not supported.
Comment 3 Adam Hough 2008-08-11 16:49:23 EDT
This is the message I have recieved on kernel 2.6.18-92.1.6.el5 (Centos 5.2) and I have been able to cause it on kernel 2.6.18-92.1.10.el5 (Centos 5.2) as well.


Unable to handle kernel NULL pointer dereference at 0000000000000078 RIP:
 [<ffffffff88536f52>] :gfs2:revoke_lo_add+0x1a/0x32
PGD 152ab1067 PUD 152ab2067 PMD 0
Oops: 0002 [1] SMP
last sysfs file: /devices/pci0000:00/0000:00:00.0/irq
CPU 1
Modules linked in: nfsd exportfs lockd nfs_acl auth_rpcgss autofs4 hidp l2cap bluetooth lock_dlm gfs2 dlm configfs sunrpc dm_round_robin sg ib_iser rdma_cm ib_cm iw_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp libiscsi scsi_transport_iscsi 8021q bonding ip_conntrack_netbios_ns ipt_REJECT xt_state ip_conntrack nfnetlink iptable_filter ip_tables ip6t_REJECT xt_tcpudp ip6table_filter ip6_tables x_tables ipv6 xfrm_nalgo crypto_api dm_multipath video sbs backlight i2c_ec i2c_core button battery asus_acpi acpi_memhotplug ac parport_pc lp parport e1000e bnx2 i5000_edac shpchp pcspkr serio_raw edac_mc dm_snapshot dm_zero dm_mirror dm_mod ata_piix libata cciss sd_mod scsi_mod ext3 jbd uhci_hcd ohci_hcd ehci_hcd
Pid: 314, comm: kswapd0 Not tainted 2.6.18-92.1.6.el5 #1
RIP: 0010:[<ffffffff88536f52>]  [<ffffffff88536f52>] :gfs2:revoke_lo_add+0x1a/0x32
RSP: 0018:ffff81016f8edae8  EFLAGS: 00010282
RAX: 0000000000000000 RBX: ffff81012bc8acd0 RCX: ffff810063a9bf60
RDX: ffff810063a9bf90 RSI: ffff8101598337c0 RDI: ffff810159833000
RBP: ffff810063a9bf70 R08: ffff81016ffb7c86 R09: ffff81016f8edb20
R10: ffff810104ba33b0 R11: ffffffff88536f38 R12: ffff810159833000
R13: 0000000000000000 R14: ffff81012bc8acd0 R15: ffff810159833000
FS:  0000000000000000(0000) GS:ffff81016ffb7b40(0000) knlGS:0000000000000000
CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 0000000000000078 CR3: 000000015215f000 CR4: 00000000000006e0
Process kswapd0 (pid: 314, threadinfo ffff81016f8ec000, task ffff81016f740860)
Stack:  ffffffff8853855f 000000006f8ede50 ffff81012bc8acd0 ffff810104254080
 0000000000000000 0000000000000000 ffffffff885396e0 0000000000000004
 ffff810104254080 00000000000000b0 ffff81016f8edcf0 ffff810159833000
Call Trace:
 [<ffffffff8853855f>] :gfs2:gfs2_remove_from_journal+0x11a/0x12c
 [<ffffffff885396e0>] :gfs2:gfs2_invalidatepage+0xea/0x151
 [<ffffffff88539445>] :gfs2:gfs2_writepage_common+0x95/0xb1
 [<ffffffff88539929>] :gfs2:gfs2_jdata_writepage+0x2a/0xa0
 [<ffffffff800c48dc>] shrink_inactive_list+0x3fd/0x7f9
 [<ffffffff80012be6>] shrink_zone+0xf6/0x11c
 [<ffffffff8005780a>] kswapd+0x336/0x459
 [<ffffffff8009df5d>] autoremove_wake_function+0x0/0x2e
 [<ffffffff8009dd45>] keventd_create_kthread+0x0/0xc4
 [<ffffffff800574d4>] kswapd+0x0/0x459
 [<ffffffff8009dd45>] keventd_create_kthread+0x0/0xc4
 [<ffffffff8003253d>] kthread+0xfe/0x132
 [<ffffffff8005dfb1>] child_rip+0xa/0x11
 [<ffffffff8009dd45>] keventd_create_kthread+0x0/0xc4
 [<ffffffff8003243f>] kthread+0x0/0x132
 [<ffffffff8005dfa7>] child_rip+0x0/0x11
 [<ffffffff8009dd45>] keventd_create_kthread+0x0/0xc4
 [<ffffffff8003243f>] kthread+0x0/0x132
 [<ffffffff8005dfa7>] child_rip+0x0/0x11


Code: ff 40 78 c7 40 50 01 00 00 00 ff 87 94 07 00 00 48 89 d7 e9
RIP  [<ffffffff88536f52>] :gfs2:revoke_lo_add+0x1a/0x32
 RSP <ffff81016f8edae8>   
CR2: 0000000000000078
 <0>Kernel panic - not syncing: Fatal exception
Comment 4 Nate Straz 2008-09-16 09:37:33 EDT
I was able to hit this during testing with coherency with jdata enabled.  The rm of the test file after the test case completed caused the panic.  The test cases which hit this were sync-write-readv and sync-pwrite-readv thus far.

Unable to handle kernel NULL pointer dereference at 0000000000000078 RIP: 
 [<ffffffff8852b66e>] :gfs2:revoke_lo_add+0x1a/0x32
PGD 703c067 PUD 1fa7d067 PMD 0 
Oops: 0002 [1] SMP 
last sysfs file: /kernel/dlm/brawl0/id
CPU 0 
Modules linked in: sctp lock_dlm(U) gfs2(U) dlm gnbd(U) configfs autofs4 hidp rd
Pid: 25349, comm: rm Tainted: G      2.6.18-110.el5 #1
RIP: 0010:[<ffffffff8852b66e>]  [<ffffffff8852b66e>] :gfs2:revoke_lo_add+0x1a/02
RSP: 0018:ffff810024b49ce0  EFLAGS: 00010282
RAX: 0000000000000000 RBX: ffff810001e537f0 RCX: ffff810016b67a80
RDX: ffff81003b958750 RSI: ffff810003a987b0 RDI: ffff810003a98000
RBP: ffff81003b958730 R08: 000000000000000d R09: ffff8100193df2e8
R10: ffff8100325b52d0 R11: ffffffff8852b654 R12: ffff810003a98000
R13: 0000000000000000 R14: ffff810001e537f0 R15: ffff810003a98000
FS:  00002b032c667250(0000) GS:ffffffff803b6000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000078 CR3: 0000000022abd000 CR4: 00000000000006e0
Process rm (pid: 25349, threadinfo ffff810024b48000, task ffff8100193df100)
Stack:  ffffffff8852cb03 0000000000000292 ffff810001e537f0 ffff8100009ea150
 0000000000000000 0000000000000000 ffffffff8852de8b 0000000000000000
 ffff8100009ea150 000000000000697f 0000000000000000 0000000000000000
Call Trace:
 [<ffffffff8852cb03>] :gfs2:gfs2_remove_from_journal+0x11a/0x12c
 [<ffffffff8852de8b>] :gfs2:gfs2_invalidatepage+0xea/0x151
 [<ffffffff8001cde2>] truncate_complete_page+0x1b/0x40
 [<ffffffff8002b7c5>] truncate_inode_pages_range+0x9b/0x2ba
 [<ffffffff885351d3>] :gfs2:gfs2_delete_inode+0x17a/0x18d
 [<ffffffff88535059>] :gfs2:gfs2_delete_inode+0x0/0x18d
 [<ffffffff8002f73a>] generic_delete_inode+0xc6/0x143
 [<ffffffff8003c79f>] do_unlinkat+0xd5/0x141
 [<ffffffff8005d229>] tracesys+0x71/0xe0
 [<ffffffff8005d28d>] tracesys+0xd5/0xe0


Code: ff 40 78 c7 40 50 01 00 00 00 ff 87 84 07 00 00 48 89 d7 e9 
RIP  [<ffffffff8852b66e>] :gfs2:revoke_lo_add+0x1a/0x32
 RSP <ffff810024b49ce0>
CR2: 0000000000000078
 <0>Kernel panic - not syncing: Fatal exception
Comment 7 Steve Whitehouse 2008-09-18 10:33:14 EDT
Created attachment 317086 [details]
Proposed fix

I think this might do the trick. It needs testing of course, but if we can get away with just moving the common page of writepage under the transaction, then that should solve the problem. If we still see problems, then I'll have to think again as potentially it makes things much more complicated.
Comment 8 Nate Straz 2008-09-22 15:05:12 EDT
The patch from comment #7 did not help.  I was able to hit the same panic.

BUG: unable to handle kernel NULL pointer dereference at virtual address 00000054
 printing eip:
f8db1723
*pde = 9ee2f067
Oops: 0002 [#1]
SMP 
last sysfs file: /devices/pci0000:00/0000:00:00.0/irq
Modules linked in: sctp lock_nolock gfs(U) lock_dlm gfs2 dlm gnbd(U) configfs autofs4 hidp rfcomm l2cap bluetooth sunrpc ipv6 xfrm_nalgo crypto_api dm_multipath scsi_dh video backlight sbs i2c_ec button battery asus_acpi ac lp parport_pc ide_cd i2c_i801 parport floppy pcspkr intel_rng cdrom i2c_core e1000 sg e7xxx_edac edac_mc dm_snapshot dm_zero dm_mirror dm_log dm_mod qla2xxx scsi_transport_fc ata_piix libata sd_mod scsi_mod ext3 jbd uhci_hcd ohci_hcd ehci_hcd
CPU:    1
EIP:    0060:[<f8db1723>]    Tainted: G      VLI
EFLAGS: 00010286   (2.6.18-115.gfs2abhi.001 #1) 
EIP is at revoke_lo_add+0x12/0x2f [gfs2]
eax: c6cff000   ebx: f8db1711   ecx: f556bd34   edx: 00000000
esi: c6cff000   edi: c6cff000   ebp: 00000000   esp: f30d6e3c
ds: 007b   es: 007b   ss: 0068
Process rm (pid: 29803, ti=f30d6000 task=f745d550 task.ti=f30d6000)
Stack: f8dc1479 cadc161c f556bd24 f8db2759 00000000 cadc161c f556bd24 c124c880 
       c6cff000 f8db39d4 00000000 cadc161c 00000000 f8db38ff 00000009 c124c880 
       00012210 c04748f9 c124c880 c045e7d4 0001287c c045e89a f30d6ecc 00000000 
Call Trace:
 [<f8dc1479>] gfs2_trans_add_revoke+0x51/0x54 [gfs2]
 [<f8db2759>] gfs2_remove_from_journal+0xef/0xff [gfs2]
 [<f8db39d4>] gfs2_invalidatepage+0xd5/0x12d [gfs2]
 [<f8db38ff>] gfs2_invalidatepage+0x0/0x12d [gfs2]
 [<c04748f9>] do_invalidatepage+0x16/0x18
 [<c045e7d4>] truncate_complete_page+0x18/0x3a
 [<c045e89a>] truncate_inode_pages_range+0xa4/0x256
 [<c045ea55>] truncate_inode_pages+0x9/0xc
 [<f8dba725>] gfs2_delete_inode+0x169/0x178 [gfs2]
 [<f8dba5bc>] gfs2_delete_inode+0x0/0x178 [gfs2]
 [<c04893d5>] generic_delete_inode+0xa5/0x10f
 [<c0488e79>] iput+0x64/0x66
 [<c0481ae9>] do_unlinkat+0xa7/0x10e
 [<c0407f46>] do_syscall_trace+0xab/0xb1
 [<c0404f17>] syscall_call+0x7/0xb
 =======================
Code: 38 dc f8 68 50 37 dc f8 b9 c3 20 dc f8 89 f0 e8 9c 00 01 00 58 5a 5b 5e c3 89 d1 89 e2 81 e2 00 f0 ff ff 8b 12 8b 92 cc 04 00 00 <ff> 42 54 c7 42 34 01 00 00 00 8d 90 d0 05 00 00 ff 80 b4 05 00 
EIP: [<f8db1723>] revoke_lo_add+0x12/0x2f [gfs2] SS:ESP 0068:f30d6e3c
 <0>Kernel panic - not syncing: Fatal exception
Comment 9 Steve Whitehouse 2008-09-25 10:17:08 EDT
Created attachment 317691 [details]
A second attempt at fixing this

It looks like there was a path to ->invalidatepage outside of a transaction in ->delete_inode which was causing the reported problem. Normally this never
happens, or if it does it makes no difference for non-jdata.

Now and then, due to remote nodes holding the inode open, its not possible to deallocate the inode when we call ->delete_inode and in that case we were invalidating the pages outside of a transaction. Normally thats ok, but not in the jdata case.

So this is an update on the previous patch. I'm still looking at this though and there may be some more changes, but this is all I can find at the moment.
Comment 10 Nate Straz 2008-09-30 11:10:58 EDT
I was able to reproduce this on kernel-2.6.18-116.gfs2abhi.001 which includes the patch in comment #9.

Unable to handle kernel NULL pointer dereference at 0000000000000078 RIP: 
 [<ffffffff88615656>] :gfs2:revoke_lo_add+0x1a/0x32
PGD 674c067 PUD 2dc64067 PMD 0 
Oops: 0002 [1] SMP 
last sysfs file: /kernel/dlm/brawl0/id
CPU 0 
Modules linked in: sctp gnbd(U) lock_nolock gfs(U) lock_dlm gfs2(U) dlm configfs ipt_MASQUERADE iptable_n
at ip_nat xt_state ip_conntrack nfnetlink ipt_REJECT xt_tcpudp iptable_filter ip_tables x_tables bridge a
utofs4 hidp rfcomm l2cap bluetooth dm_log_clustered(U) sunrpc ipv6 xfrm_nalgo crypto_api dm_multipath scs
i_dh video backlight sbs i2c_ec button battery asus_acpi acpi_memhotplug ac parport_pc lp parport sg i300
0_edac edac_mc qla2xxx scsi_transport_fc i2c_i801 i2c_core shpchp tg3 pcspkr libphy serio_raw ide_cd cdro
m dm_snapshot dm_zero dm_mirror dm_log dm_mod ata_piix libata sd_mod scsi_mod ext3 jbd uhci_hcd ohci_hcd 
ehci_hcd
Pid: 4576, comm: rm Tainted: G      2.6.18-116.gfs2abhi.001 #1
RIP: 0010:[<ffffffff88615656>]  [<ffffffff88615656>] :gfs2:revoke_lo_add+0x1a/0x32
RSP: 0018:ffff8100066cbce0  EFLAGS: 00010286
RAX: 0000000000000000 RBX: ffff810013633bb0 RCX: ffff810015e8dfc0
RDX: ffff810008d57a50 RSI: ffff81002bbf57b0 RDI: ffff81002bbf5000
RBP: ffff810008d57a30 R08: 000000000000000e R09: ffff810000ce3720
R10: ffff8100127146d0 R11: ffffffff8861563c R12: ffff81002bbf5000
R13: 0000000000000000 R14: ffff810013633bb0 R15: ffff81002bbf5000
FS:  00002b42246a5250(0000) GS:ffffffff803b8000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000078 CR3: 0000000029788000 CR4: 00000000000006e0
Process rm (pid: 4576, threadinfo ffff8100066ca000, task ffff810007557040)
Stack:  ffffffff88616aeb ffff810000bfc8a8 ffff810013633bb0 ffff810000f376a8
 0000000000000000 0000000000000000 ffffffff88617e73 0000000000000000
 ffff810000f376a8 00000000000076ac 0000000000000000 0000000000007620
Call Trace:
 [<ffffffff88616aeb>] :gfs2:gfs2_remove_from_journal+0x11a/0x12c
 [<ffffffff88617e73>] :gfs2:gfs2_invalidatepage+0xea/0x151
 [<ffffffff8001cdf5>] truncate_complete_page+0x1b/0x40
 [<ffffffff8002b26d>] truncate_inode_pages_range+0x9b/0x2ba
 [<ffffffff8861f0b7>] :gfs2:gfs2_delete_inode+0x17a/0x18d
 [<ffffffff8861ef3d>] :gfs2:gfs2_delete_inode+0x0/0x18d
 [<ffffffff8002f2b6>] generic_delete_inode+0xc6/0x143
 [<ffffffff8003c33a>] do_unlinkat+0xd5/0x141
 [<ffffffff8005d229>] tracesys+0x71/0xe0
 [<ffffffff8005d28d>] tracesys+0xd5/0xe0


Code: ff 40 78 c7 40 50 01 00 00 00 ff 87 84 07 00 00 48 89 d7 e9 
RIP  [<ffffffff88615656>] :gfs2:revoke_lo_add+0x1a/0x32
 RSP <ffff8100066cbce0>
CR2: 0000000000000078
 <0>Kernel panic - not syncing: Fatal exception
Comment 11 Robert Peterson 2008-10-02 16:38:24 EDT
I concur with Steve as to the cause of the problem.  However, to me
it looks like truncate_inode_pages_range calls truncate_complete_page
for all pages found in the address space.  In turn, function
truncate_complete_page calls do_invalidatepage if the page is private,
which calls gfs2_invalidatepage, which calls gfs2_remove_from_journal,
as shown in the call trace.

What I don't understand is why gfs2_delete_inode calls function
truncate_inode_pages both inside the transaction and a second time
after the transaction has been closed down.  The second call seems
wrong to me.  Can't we just remove the second call?  In other words:

diff -pur a/fs/gfs2/ops_super.c b/fs/gfs2/ops_super.c
--- a/fs/gfs2/ops_super.c	2008-10-01 16:12:54.000000000 -0500
+++ b/fs/gfs2/ops_super.c	2008-10-02 15:33:32.000000000 -0500
@@ -515,7 +515,6 @@ out_uninit:
 	if (error && error != GLR_TRYFAILED)
 		fs_warn(sdp, "gfs2_delete_inode: %d\n", error);
 out:
-	truncate_inode_pages(&inode->i_data, 0);
 	clear_inode(inode);
 }
 

I remember that it was rationalized to me once, but I forgot what it
was.  The fact that we have pages that haven't been truncated by the
first call implies that someone else is messing with the pages for
this address space outside of a transaction too, and perhaps that is
the root of the problem.
Comment 12 Nate Straz 2008-10-03 15:51:56 EDT
After further inspecting my configuration while trying to verify 462579, I discovered that I had an old kmod-gfs2 package installed and I was loading gfs2.ko built Sep 19 instead of the kmod from the 2.6.18-116.gfs2abhi.001 kernel built Sep 29.  I need to rerun these tests.
Comment 13 Nate Straz 2008-10-06 10:25:49 EDT
After re-running with kmod-gfs2 removed and confirming that GFS2 was built the same day as the kernel, my tests have all succeeded.
Comment 14 Steve Whitehouse 2008-10-07 06:52:58 EDT
Now posted upstream.
Comment 15 Abhijith Das 2008-10-07 10:48:22 EDT
Created attachment 319650 [details]
RHEL5 version of the patch 

This is the RHEL5 version of the patch above in comment #9
Comment 16 Steve Whitehouse 2008-10-07 11:54:22 EDT
Now posted to rhkernel-list
Comment 17 Don Zickus 2008-10-20 11:12:39 EDT
in kernel-2.6.18-120.el5
You can download this test kernel from http://people.redhat.com/dzickus/el5
Comment 19 Nate Straz 2008-11-13 17:15:52 EST
Verified with kernel-2.6.18-122.el5.
Comment 21 errata-xmlrpc 2009-01-20 15:25:53 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2009-0225.html

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