Am 21.09.2009 um 13:35 schrieb Lars Ellenberg:
something that Oopses at offset 0 of some function is most likely a
compile problem,
i.e. I suggest that your kernel and drbd module do not fit together.
Hi,
I have experienced a similar looking problem on a cluster system also
using Ubuntu:
Systems (identically configured): Ubuntu 9.04 Server x86_64 server
with Kernel 2.6.28-15-server (standard distro kernel)
DRBD: as included in Ubuntu Server (8.3.0)
Usage: KVM host (Software Raid 1 -> DRBD -> LVM -> KVM VMs)
The problem appeared on the secondary directly after issuing "drbdadm
verify all":
Sep 23 17:04:58 cluster2 kernel: [ 1579.818149] drbd0:
conn( Connected -> VerifyT )
Sep 23 17:04:59 cluster2 kernel: [ 1579.820914] drbd1:
conn( Connected -> VerifyT )
Sep 23 17:04:59 cluster2 kernel: [ 1579.830819] BUG: unable to
handle kernel NULL pointer dereference at 0000000000000030
Sep 23 17:04:59 cluster2 kernel: [ 1579.830877] IP:
[<ffffffffa0105373>] w_e_end_ov_req+0x43/0x1a0 [drbd]
Sep 23 17:04:59 cluster2 kernel: [ 1579.830924] PGD 0
Sep 23 17:04:59 cluster2 kernel: [ 1579.830949] Oops: 0000 [#1] SMP
Sep 23 17:04:59 cluster2 kernel: [ 1579.830979] last sysfs file: /
sys/module/drbd/parameters/cn_idx
Sep 23 17:04:59 cluster2 kernel: [ 1579.831011] Dumping ftrace buffer:
Sep 23 17:04:59 cluster2 kernel: [ 1579.831037] (ftrace buffer
empty)
Sep 23 17:04:59 cluster2 kernel: [ 1579.831063] CPU 0
Sep 23 17:04:59 cluster2 kernel: [ 1579.831087] Modules linked in:
tun r8169 mii ipt_REJECT xt_tcpudp iptable_filter ip_tables x_tables
bridge stp kvm_intel kvm video output input_polldev drbd
sha1_generic lp parport iTCO_wdt iTCO_vendor_support pcspkr raid10
multipath linear fbcon tileblit font bitblit softcursor r8168
raid456 async_xor async_memcpy async_tx xor raid1 raid0 3w_9xxx
3w_xxxx
Sep 23 17:04:59 cluster2 kernel: [ 1579.831340] Pid: 3286, comm:
drbd0_worker Not tainted 2.6.28-15-server #49-Ubuntu
Sep 23 17:04:59 cluster2 kernel: [ 1579.831389] RIP: 0010:
[<ffffffffa0105373>] [<ffffffffa0105373>] w_e_end_ov_req+0x43/0x1a0
[drbd]
Sep 23 17:04:59 cluster2 kernel: [ 1579.831453] RSP:
0018:ffff88023acc9e60 EFLAGS: 00010202
Sep 23 17:04:59 cluster2 kernel: [ 1579.831482] RAX:
0000000000000000 RBX: ffff880210115720 RCX: ffff88023acc9ecc
Sep 23 17:04:59 cluster2 kernel: [ 1579.831515] RDX:
0000000000000000 RSI: 00000000000000d0 RDI: ffff88023c8cb000
Sep 23 17:04:59 cluster2 kernel: [ 1579.831548] RBP:
ffff88023acc9e80 R08: 0000000000000004 R09: 0000000000000001
Sep 23 17:04:59 cluster2 kernel: [ 1579.831581] R10:
0000000000000000 R11: 00000000ffffffff R12: ffff88023c8cb000
Sep 23 17:04:59 cluster2 kernel: [ 1579.831614] R13:
ffff880210115720 R14: ffff88023c8cb118 R15: 0000000000000000
Sep 23 17:04:59 cluster2 kernel: [ 1579.831648] FS:
0000000000000000(0000) GS:ffffffff80a9a000(0000) knlGS:
0000000000000000
Sep 23 17:04:59 cluster2 kernel: [ 1579.831698] CS: 0010 DS: 0018
ES: 0018 CR0: 000000008005003b
Sep 23 17:04:59 cluster2 kernel: [ 1579.831728] CR2:
0000000000000030 CR3: 0000000000201000 CR4: 00000000000026a0
Sep 23 17:04:59 cluster2 kernel: [ 1579.831761] DR0:
0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Sep 23 17:04:59 cluster2 kernel: [ 1579.831795] DR3:
0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Sep 23 17:04:59 cluster2 kernel: [ 1579.831828] Process drbd0_worker
(pid: 3286, threadinfo ffff88023acc8000, task ffff88023bcdd980)
Sep 23 17:04:59 cluster2 kernel: [ 1579.831879] Stack:
Sep 23 17:04:59 cluster2 kernel: [ 1579.831901] ffff880210115720
ffff88023c8cb000 ffff88023acc9eb0 ffff88023c8cb118
Sep 23 17:04:59 cluster2 kernel: [ 1579.831943] ffff88023acc9f00
ffffffffa01046e7 ffff88023c8cb620 ffff88023c8cb100
Sep 23 17:04:59 cluster2 kernel: [ 1579.832004] ffff88023c8cb120
ffff88023c8cb0f0 ffff88023acc9eb0 ffff88023acc9eb0
Sep 23 17:04:59 cluster2 kernel: [ 1579.832082] Call Trace:
Sep 23 17:04:59 cluster2 kernel: [ 1579.832106]
[<ffffffffa01046e7>] drbd_worker+0x1e7/0x440 [drbd]
Sep 23 17:04:59 cluster2 kernel: [ 1579.832147]
[<ffffffff806997ad>] ? schedule_timeout+0x5d/0xd0
Sep 23 17:04:59 cluster2 kernel: [ 1579.832185]
[<ffffffffa011de03>] drbd_thread_setup+0xe3/0x200 [drbd]
Sep 23 17:04:59 cluster2 kernel: [ 1579.832230]
[<ffffffff80213979>] child_rip+0xa/0x11
Sep 23 17:04:59 cluster2 kernel: [ 1579.832264]
[<ffffffffa011dd20>] ? drbd_thread_setup+0x0/0x200 [drbd]
Sep 23 17:04:59 cluster2 kernel: [ 1579.832308]
[<ffffffff8021396f>] ? child_rip+0x0/0x11
Sep 23 17:04:59 cluster2 kernel: [ 1579.832340] Code: 89 1c 24 4c 89
74 24 18 49 89 f5 0f 85 ef 00 00 00 48 8b 46 20 f6 40 18 01 0f 84 d9
00 00 00 48 8b 87 c8 05 00 00 be d0 00 00 00 <44> 8b 70 30 49 63 fe
e8 c1 de 1d e0 48 85 c0 48 89 c3 0f 84 b5
Sep 23 17:04:59 cluster2 kernel: [ 1579.832595] RIP
[<ffffffffa0105373>] w_e_end_ov_req+0x43/0x1a0 [drbd]
Sep 23 17:04:59 cluster2 kernel: [ 1579.832639] RSP
<ffff88023acc9e60>
Sep 23 17:04:59 cluster2 kernel: [ 1579.832664] CR2: 0000000000000030
Sep 23 17:04:59 cluster2 kernel: [ 1579.833056] ---[ end trace
bfafe5c2861ff3a8 ]---
I had done some pretty intensive testing (Bonnie++, dd, etc.) before
and everything was ok...could not reproduce the problem afterwards,
either.
What bothers me (apart from the bug) is the following:
- Your changelog says that compatibility with Linux 2.6.27, 2.6.28
and 2.6.29 was added in 8.3.1, while Ubuntu Server with kernel 2.6.28
ships with DRBD 8.3.0. Btw., the DRBD module appear to has been
compiled in January, while the kernel was compiled in August.
Did the Ubuntu guys really screw it up that bloody? And if so, am I
the only one using the DRBD version included in Ubuntu server??
Thanks for your time,
Thomas
_______________________________________________
drbd-user mailing list
[email protected]
http://lists.linbit.com/mailman/listinfo/drbd-user
