Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Please scrub the first paragraph here.. I did update the kernel module
at both ends, to get these results! Apologies for the confusion.
Nick wrote:
> 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.
>>
>>
>>
>
> _______________________________________________
> drbd-user mailing list
> drbd-user at lists.linbit.com
> http://lists.linbit.com/mailman/listinfo/drbd-user
>
>