Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Wed, Jun 10, 2009 at 09:58:01AM +0100, Nick wrote:
> Hi,
>
> I am a new user to DRBD, and currently not getting very far with it,
> primarily I believe because of the hardware platform I am running on.
>
> This is an ARM (armel - little endian) platform, with only
> 128MB of RAM in total. I have tried this with top showing 30 megs free,
> and 60 megs cached:
>
> nasty:~# vmstat
> procs -----------memory---------- ---swap-- -----io---- -system--
> ----cpu----
> r b swpd free buff cache si so bi bo in cs us sy
> id wa
> 0 0 1524 27248 4940 60736 12 13 141 95 68 75 4 2
> 94 0
>
>
> I am running a custom 2.6.29 kernel, and have tried the drbd 8.3.1 and
> 8.3.2rc1 packages, built against my kernel. The userland tools are the
> stock 8.3.1 debian tools from the debian armel build.
>
> Currently, as I am testing I am using a 100M loopback image on both
> systems, as the underlying storage. Perhaps this is the problem, but I
> am loathed to re-partition my disks at this stage..
>
> One system is i386 (no shortage of RAM here), which seems to behave
> correctly. Both running same version of kernel and DRBD.
> I don't think its getting as far as even attempting to communicate with
> the other system, however I
> mention it because, it works fine with the configuration I am using, on
> the i386.
>
>
> I have a very simple configuration:
>
> global {
> usage-count yes;
> }
>
> common {
> protocol C;
> }
>
> resource r0 {
> device /dev/drbd0;
> disk /dev/loop0;
> meta-disk internal;
>
> on nasty {
> address 192.168.0.1:7788;
> }
>
> on acid {
> address 192.168.0.2:7788;
> }
> }
>
>
> Loading the drbd driver seems fine:
>
> -----------
> kernel: drbd: initialised. Version: 8.3.1 (api:88/proto:86-89)
> kernel: drbd: GIT-hash: fd40f4a8f9104941537d1afc8521e584a6d3003c build
> by root at acid, 2009-06-09 23:39:13
> kernel: drbd: registered as block device major 147
> kernel: drbd: minor_table @ 0xc58dca20
> ----------
>
> I am able to initialise the device metadata:
>
>
> nasty:~# drbdadm create-md r0
> Writing meta data...
> initializing activity log
> NOT initialized bitmap
> New drbd meta data block successfully created.
> success
>
> However when I try to attach to the device:
>
> nasty:~# drbdadm attach r0
> No response from the DRBD driver! Is the module loaded?
> Bad: fgets returned NULL while waiting for data: Interrupted system call
>
>
> Looking in /var/log/kern.log
>
> ------------
> kernel: drbd0: Unknown tag: 1071
THAT is the real problem.
> kernel: Unable to handle kernel NULL pointer dereference at virtual
> address 00000015
and this is "only" an unexercised error path ;)
commit 3ca9b9285de9db7ce0be384e28675f81c0bfba20
Author: Lars Ellenberg <lars.ellenberg at linbit.com>
Date: Wed Jun 10 13:31:04 2009 +0200
don't dereference uninitialized pointers
diff --git a/drbd/drbd_nl.c b/drbd/drbd_nl.c
index 922ddb1..73dd439 100644
--- a/drbd/drbd_nl.c
+++ b/drbd/drbd_nl.c
@@ -781,14 +781,12 @@ STATIC int drbd_nl_disk_conf(struct drbd_conf *mdev, struct drbd_nl_cfg_req *nlp
}
/* allocation not in the IO path, cqueue thread context */
- nbc = kmalloc(sizeof(struct drbd_backing_dev), GFP_KERNEL);
+ nbc = kzalloc(sizeof(struct drbd_backing_dev), GFP_KERNEL);
if (!nbc) {
retcode = ERR_NOMEM;
goto fail;
}
- memset(&nbc->md, 0, sizeof(struct drbd_md));
- memset(&nbc->dc, 0, sizeof(struct disk_conf));
nbc->dc.disk_size = DRBD_DISK_SIZE_SECT_DEF;
nbc->dc.on_io_error = DRBD_ON_IO_ERROR_DEF;
nbc->dc.fencing = DRBD_FENCING_DEF;
@@ -799,9 +797,6 @@ STATIC int drbd_nl_disk_conf(struct drbd_conf *mdev, struct drbd_nl_cfg_req *nlp
goto fail;
}
- nbc->lo_file = NULL;
- nbc->md_file = NULL;
-
if (nbc->dc.meta_dev_idx < DRBD_MD_INDEX_FLEX_INT) {
retcode = ERR_MD_IDX_INVALID;
goto fail;
--
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com
DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.
__
please don't Cc me, but send to list -- I'm subscribed