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.
>
>