The usage of sign-extension might be cause. The problem is that all these
variables are sector_t, which as far as I know, is a u64.
Even if it was using signed variable, all of them are 64bit and using
values much lower that 2^63.
As mips is not a 64-bit processor, the compiler must do it by parts. So,
where is this problem from? Compiler? Kernel?
I guess no one faced this problem before because it might be rare to
someone have a logical partition over 2147483648 sectors (2^31),
or a little over 1TB (1099 GB), in a arch for embebed systems.
---
Luiz Angelo Daros de Luca, Me.
[email protected]
2013/4/27 David Newall <[email protected]>
> On 27/04/13 11:15, Luiz Angelo Daros de Luca wrote:
>
>>
>> The correct output would be 2273342085 and not 18446744071687926405.
>> Comparing both, the MSB 32bit of first_sector becomes all 1.
>>
>> 2273342085 = 0x0000000087807285
>> 18446744071687926405 = 0xFFFFFFFF87807285
>>
>> Any idea of why? Maybe this has something to do with
>> target/linux/ar71xx/patches-3.**3/902-unaligned_access_hacks.**patch?
>>
>>
> Looks very much like sign-extension when converting a 32-bit negative
> value to 64-bit.
>
_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
