[DRBD-user] DRBD - on ARM (armel)

Nick nickdrbd at alfiecam.co.uk
Tue Jun 16 14:48:40 CEST 2009

Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.


Since there are no kernel changes, I have just updated the userland 
binaries at one end of the connection. I hope this is a valid test??

It has been working with fix 1.

Since applying fix2 & fix3, I get on one end

Jun 16 13:43:20 coral kernel: drbd: initialised. Version: 8.3.2rc1 
(api:88/proto:86-90)
Jun 16 13:43:20 coral kernel: drbd: GIT-hash: 
89629993d64aaa2e0f8339c7e349737360f44b6e drbd/drbd_main.c drbd/drbd_nl.c 
user/Makefile user/drbdsetup.c build by root at nasty, 2009-06-16 11:03:59
Jun 16 13:43:20 coral kernel: drbd: registered as block device major 147
Jun 16 13:43:20 coral kernel: drbd: minor_table @ 0xc59400a0
Jun 16 13:43:20 coral kernel: block drbd0: Starting worker thread (from 
cqueue [2279])
Jun 16 13:43:20 coral kernel: klogd 1.5.0, ---------- state change 
----------
Jun 16 13:43:20 coral kernel: block drbd0: disk( Diskless -> Attaching )
Jun 16 13:43:20 coral kernel: block drbd0: Found 4 transactions (6 
active extents) in activity log.
Jun 16 13:43:20 coral kernel: block drbd0: Method to ensure write 
ordering: barrier
Jun 16 13:43:20 coral kernel: block drbd0: max_segment_size ( = BIO size 
) = 32768
Jun 16 13:43:20 coral kernel: block drbd0: drbd_bm_resize called with 
capacity == 208696
Jun 16 13:43:20 coral kernel: block drbd0: resync bitmap: bits=26087 
words=816
Jun 16 13:43:20 coral kernel: block drbd0: size = 102 MB (104348 KB)
Jun 16 13:43:20 coral kernel: block drbd0: recounting of set bits took 
additional 0 jiffies
Jun 16 13:43:20 coral kernel: block drbd0: 36 KB (9 bits) marked 
out-of-sync by on disk bit-map.
Jun 16 13:43:20 coral kernel: block drbd0: disk( Attaching -> UpToDate )
Jun 16 13:43:20 coral kernel: block drbd0: Unknown tag: 4981
Jun 16 13:43:21 coral kernel: block drbd0: role( Secondary -> Primary )


and

> Jun 16 13:45:54 nasty kernel: drbd: initialised. Version: 8.3.2rc1 
> (api:88/proto:86-90)
> Jun 16 13:45:54 nasty kernel: drbd: GIT-hash: 
> 89629993d64aaa2e0f8339c7e349737360f44b6e drbd/drbd_main.c 
> drbd/drbd_nl.c user/Makefile user/drbdsetup.c build by root at nasty, 
> 2009-06-16 11:03:59
> Jun 16 13:45:54 nasty kernel: drbd: registered as block device major 147
> Jun 16 13:45:54 nasty kernel: drbd: minor_table @ 0xc6f80f20
> Jun 16 13:45:54 nasty kernel: block drbd0: Starting worker thread 
> (from cqueue [8513])
> Jun 16 13:45:54 nasty kernel: klogd 1.5.0, ---------- state change 
> ----------
> Jun 16 13:45:54 nasty kernel: block drbd0: disk( Diskless -> Attaching )
> Jun 16 13:45:54 nasty kernel: block drbd0: Found 4 transactions (6 
> active extents) in activity log.
> Jun 16 13:45:54 nasty kernel: block drbd0: Method to ensure write 
> ordering: barrier
> Jun 16 13:45:54 nasty kernel: block drbd0: max_segment_size ( = BIO 
> size ) = 32768
> Jun 16 13:45:54 nasty kernel: block drbd0: drbd_bm_resize called with 
> capacity == 208696
> Jun 16 13:45:54 nasty kernel: block drbd0: resync bitmap: bits=26087 
> words=816
> Jun 16 13:45:54 nasty kernel: block drbd0: size = 102 MB (104348 KB)
> Jun 16 13:45:54 nasty kernel: block drbd0: recounting of set bits took 
> additional 0 jiffies
> Jun 16 13:45:54 nasty kernel: block drbd0: 0 KB (0 bits) marked 
> out-of-sync by on disk bit-map.
> Jun 16 13:45:54 nasty kernel: block drbd0: disk( Attaching -> UpToDate )
> Jun 16 13:45:54 nasty kernel: block drbd0: conn( StandAlone -> 
> Unconnected )
> Jun 16 13:45:54 nasty kernel: block drbd0: Starting receiver thread 
> (from drbd0_worker [26752])
> Jun 16 13:45:54 nasty kernel: block drbd0: receiver (re)started
> Jun 16 13:45:54 nasty kernel: block drbd0: conn( Unconnected -> 
> WFConnection )

At the other end

The line

Jun 16 13:43:20 coral kernel: block drbd0: Unknown tag: 4981

looks like an alignment error again, but no clues (for me) at the other end

Nick

Philipp Reisner wrote:
> On Monday 15 June 2009 23:21:51 you wrote:
>   
>> Hi,
>>
>> With the latest patch, things are not working very well at all!
>>
>>
>> It think the problem may lie here:
>>
>>
>> #define put_unaligned(val, ptr) ({                    \
>> +    typeof(val) v;                            \
>> +    switch (sizeof(*(ptr))) {                    \
>> +    case 1:                                \
>> +        *(uint8_t *)(ptr) = (uint8_t)(val);            \
>> +        break;                            \
>> +    case 2:                                \
>> +    case 4:                                \
>> +    case 8:                                \
>> +        v = val;                        \
>> +        memcpy(ptr, &v, sizeof(*(ptr)));            \
>> +        break;                            \
>> +    default:                            \
>> +        __bad_unaligned_access_size();                \
>> +        break;                            \
>> +    }                                \
>> +    (void)0; })
>> +
>>
>>
>> When called with
>>
>> put_unaligned(tag, tl->tag_list_cpos++);
>>
>> ptr is evaluated in the switch statement, and twice in the memcpy call,
>> and hence the post-increment will be done three times ....not what we want!
>>
>> Maybe an inline function, or taking a copy of ptr if safer here
>>
>>     
>
> Hi Nick,
>
> No, typeof(), sizeof() do not evaluate the expression at runtime. They
> just deliver the type or the size at compile time. But in that macro 
> there was an error with the type conversation.
>
> I have again, attached a patch, that should fix the issue. Please verify.
>
>   




More information about the drbd-user mailing list