[ENBD] (Fixed) FR1-2.15b and unknown symbol __udivdi3

[Graham Clinch]

Quick answer for people who don't want to read the whole lot.. I  
fixed the problem by using FR1-2.17, rather than FR1-2.15b,,

On 17 Feb 2006, at 07:43, Peter T. Breuer wrote:

> "Also sprach Graham Clinch:"
>> I've tried to use the FR1-2.15b patch against 2.6.8, and the patch
>> applies happily, and indeed, compiles happily.  However, when I try
>> to modprobe md:
>
> What architecture? And compiler?

This is x86, using gcc (GCC) 3.3.5 (Debian 1:3.3.5-13)

>> dtfsa301:~# nm /lib/modules/2.6.8/kernel/drivers/md/md.ko | grep udiv
>>           U __udivdi3
>> dtfsa301:~#
>>
>> So it's definitely somewhere within md, rather than a dependency.
>>
>> Actually, might it be the line
>>
>> disk_events <<= 32;
>
> Shifts are not optimised to division, and this one would be a
> multiplicaton.

Good job I don't have to write C for a living!

>> (Line 1786 of the patch), as guess the compiler (gcc version 3.3.5
>> (Debian 1:3.3.5-13)) may be optimizing it to a lot of divide-by-
>> twos.  My C is rusty, so even if it is this line, I'm not sure what
>> would make a good fixup..
>>
>> I've tried using md (raid1) without the FR1 patch applied, and
>> everything seems happy, the module loads and I can control arrays, so
>> I'm guessing it's got to be somewhere in the patch
>>
>> Any hints welcome!
>
> Well, I'd just be grepping for a "/" or a "%". You should be able to
> decompile the object module with objdump -disassemble and find out  
> which
> function the udivdi3 is in. You can locate roughly where in the  
> code it
> is by loking for calls to external routines in the disassembly and the
> source code. Then one can locate the line precisely by commmenting out
> bits of source and recmpiling.
>
> I'll just have a read of the md.c part of that patch ...
>
> I see nothing.
>
> Oh, it MUST be this line:
>
>    realspeed = (j - mddev->resync_mark_cnt - atomic_read 
> (&md_throttle[mddev->md_minor]))/2/((jiffies-mddev->resync_mark)/HZ  
> +1) +1;
>
> I see that I changed it in 2.17  to
>
>     realspeed = ((unsigned long)(j - mddev->resync_mark_cnt -  
> atomic_read(&md_throttle[mddev->md_minor])))/2/((jiffies-mddev- 
> >resync_mark)/HZ +1) +1;
>
> Even though I don't see a long long, why else would I have done that
> recasting?

Well, I've tried with 2.17 and I can now load md and it's all looking  
good.  This is entirely my fault for downloading 2.15b.  From the  
looks of it, I went for the link 'fr1-2.current.tgz', which is  
currently pointing at 2.15b, rather than 2.17.  This is a lesson in  
not trusting symlinks..

Thanks for your help,

Graham