Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Thu, Oct 19, 2017 at 10:12:41AM +1100, Tobin C. Harding wrote: > Is anyone running DRDB-9.0 between two Raspberry Pis? > > I managed to set up a two node cluster using Raspian and v8.3 from the > repositories. Everything tests and works fine. 8.3? That is soo over EoL, are you sure someone ships that? > Next I attempted to run the master branch from GitHub for both utils and kernel module. > > To clean up I ran (on both nodes); > > $ sudo systemctl stop drbd > $ sudo systemctl disable drbd > $ sudo sudo dd if=/dev/zero of=/dev/sda1 bs=4k > > And rebooted. > > I built drdb-utils and drbdmanage on the Pis; > > $ drbdadm --version > DRBDADM_BUILDTAG=GIT-hash:\ 64fbff2fe396c14176712b477aa06ebf0893d75d\ build\ by\ tobin at rpis\,\ 2017-10-16\ 22:29:05 > DRBDADM_API_VERSION=2 > DRBD_KERNEL_VERSION_CODE=0x090009 > DRBD_KERNEL_VERSION=9.0.9 > DRBDADM_VERSION_CODE=0x090100 > DRBDADM_VERSION=9.1.0 > > $ sudo drbdmanage --version > drbdmanage 0.99.14; GIT-hash: UNKNOWN > > I built the kernel modules on the Pis also, and loaded drbd; > > $ sudo lsmod | egrep '(drbd|lru)' > drbd 558498 1 > lru_cache 9675 0 > > I moved the same resource config file used for 8.3 to /usr/local/drbd.d/ You should not. At best this confuses the drbd9 utils as there are changes in the syntax. > > $ sudo drbdmanage init I would start with a simple, manual written res file. > [ 132.862102] drbd: loading out-of-tree module taints kernel. > [ 132.900147] drbd: initialized. Version: 9.0.9-1 (api:2/proto:86-112) > [ 132.900165] drbd: GIT-hash: 41a6c87e94810f681cd57c49b7f1273cb802f018 Makefile build by tobin at rpis, 2017-10-16 22:53:39 > [ 132.900171] drbd: registered as block device major 147 > [ 136.816634] drbd .drbdctrl: Starting worker thread (from drbdsetup [661]) > [ 137.945004] Alignment trap: not handling instruction e1932f9f at [<bf213278>] > [ 137.945022] Unhandled fault: alignment exception (0x001) at 0xdabcb415 Hm, this would need further investigation. I heard stories that we had such cases on ARM and it was in fact a gcc bug/"optimization". > [ 137.953882] pgd = da8f8000 > [ 137.957720] [dabcb415] *pgd=1aa0041e(bad) > [ 137.962987] Internal error: : 1 [#1] ARM > [ 137.967995] Modules linked in: drbd(O) lru_cache cfg80211 rfkill snd_bcm2835 snd_pcm snd_timer snd bcm2835_gpiomem uio_pdrv_genirq fixed uio sg dm_mod ipv6 > [ 137.984399] CPU: 0 PID: 675 Comm: drbdsetup Tainted: G O 4.9.35+ #1014 > [ 137.994330] Hardware name: BCM2835 > [ 137.998899] task: d56a8da0 task.stack: d56a2000 > [ 138.005072] PC is at drbd_md_sync_page_io+0x170/0x508 [drbd] > [ 138.011997] LR is at 0xdabcb421 > [ 138.016328] pc : [<bf21327c>] lr : [<dabcb421>] psr: 60000013 > sp : d56a3be8 ip : 00000000 fp : d56a3c3c > [ 138.030241] r10: 00000078 r9 : 00000000 r8 : 00001ff8 > [ 138.036686] r7 : dabcb3c1 r6 : 00000000 r5 : da8be800 r4 : dd329400 > [ 138.044458] r3 : dabcb415 r2 : 00001000 r1 : 00001000 r0 : 00001000 > [ 138.052217] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user > [ 138.060629] Control: 00c5387d Table: 1a8f8008 DAC: 00000055 > [ 138.067670] Process drbdsetup (pid: 675, stack limit = 0xd56a2188) > [ 138.075130] Stack: (0xd56a3be8 to 0xd56a4000) > ... > Any suggestions on where to go from here please? >From the trace or from you PC you could do something like that: gdb ./drbd.ko l *($fkt_name+0x$adr) # obviously replace $fkt_name and $addr Regards, rck