On 06/21/2012 04:21 PM, akpm@linux-foundation.org wrote:

> The mm-of-the-moment snapshot 2012-06-21-16-20 has been uploaded to
>
> http://www.ozlabs.org/~akpm/mmotm/
>
> It contains the following patches against 3.5-rc3:
> (patches marked "*" will be included in linux-next)



on i386:

Apparently from linux-next.patch:

drivers/built-in.o: In function `thin_iterate_devices':
dm-thin.c.text+0x206f07): undefined reference to `__udivdi3'
drivers/built-in.o: In function `pool_preresume':
dm-thin.c.text+0x207863): undefined reference to `__udivdi3'


--
~Randy

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel

Hi Randy,

On Fri, 22 Jun 2012 10:26:06 -0700 Randy Dunlap <rdunlap@xenotime.net> wrote:
>
> on i386:
>
> Apparently from linux-next.patch:
>
> drivers/built-in.o: In function `thin_iterate_devices':
> dm-thin.c.text+0x206f07): undefined reference to `__udivdi3'
> drivers/built-in.o: In function `pool_preresume':
> dm-thin.c.text+0x207863): undefined reference to `__udivdi3'

I assume that CONFIG_LDBAF is not set and I think this is caused by
commit ebf5d9e0425c ("Non power of 2 blocksize support is needed to
properly align thinp IO") from the device-mapper tree.

--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel

On 06/24/2012 07:44 AM, Stephen Rothwell wrote:

> Hi Randy,
>
> On Fri, 22 Jun 2012 10:26:06 -0700 Randy Dunlap <rdunlap@xenotime.net> wrote:
>>
>> on i386:
>>
>> Apparently from linux-next.patch:
>>
>> drivers/built-in.o: In function `thin_iterate_devices':
>> dm-thin.c.text+0x206f07): undefined reference to `__udivdi3'
>> drivers/built-in.o: In function `pool_preresume':
>> dm-thin.c.text+0x207863): undefined reference to `__udivdi3'
>
> I assume that CONFIG_LDBAF is not set and I think this is caused by
> commit ebf5d9e0425c ("Non power of 2 blocksize support is needed to
> properly align thinp IO") from the device-mapper tree.
>


Correct:
# CONFIG_LBDAF is not set


thanks,
--
~Randy

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel

On Mon, Jun 25, 2012 at 12:44:25AM +1000, Stephen Rothwell wrote:
> I assume that CONFIG_LDBAF is not set and I think this is caused by
> commit ebf5d9e0425c ("Non power of 2 blocksize support is needed to
> properly align thinp IO") from the device-mapper tree.

Ah yes, I'll fix that, and check we handle "too large" devices sensibly.

Alasdair

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel

On Sun, Jun 24, 2012 at 05:55:55PM +0100, Alasdair G Kergon wrote:
> Ah yes, I'll fix that, and check we handle "too large" devices sensibly.

What does it mean when sector_t is 32 bits but dm_block_t is 64 bits?

- You're loading a large pool device you created on a system where sector_t was 64 bits?
(and we refuse to load this device)

- The top 32 bits of dm_block_t would always be zero so we should make
dm_block_t match the type of sector_t?
(Because blocks are bigger than sectors?)

int sm_ll_extend(struct ll_disk *ll, dm_block_t extra_blocks)

old_blocks = dm_sector_div_up(ll->nr_blocks, ll->entries_per_block);

[ll->nr_blocks is 64 bits]

#define dm_sector_div_up(n, sz) (
{
sector_t _r = ((n) + (sz) - 1);

[sector_t might be 32 bits => truncation]

sector_div(_r, (sz));
_r;
}
)

Alasdair

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel