Re: problems compiling enbd-2.4.32pre and fr1-2.16 under kernel 2.6.8.1

edward mzj <[email protected]> wrote:
> hi peter

Hi!

> > This comes from your compiler not doing division adequately.
> 
> i don't think so.

It is so. It is passing long division to an external routine written in
assembler! Your message below cleverly points out why, however! :-0) 


> > Fix compiler! It probably can't divide by a variable value. But anyway,
> > why isn't it foxed by the line before?
> > 
> >         currspeed = (j-mddev->resync_mark_cnt)/2/((jiffies-mddev->resync_mark)/HZ +1)+1
> 
> Oh, the code in my md.c is a little bit different. the code i saw is:
> 
> currspeed = ((unsigned long)(j-mddev->resync_mark_cnt))/2/((jiffies-mddev->resync_mark)/HZ +1) +1;

That's the same apart from the cast. Well add the cast into the line
it can't compile too, and all should be well. 

Hmm .... my 2.6.8.1 also has that cast in currspeed. How curious.
Evidently my compiler (2.95.4) has no problem with the division with or
without the cast. I'll add the cast into the patch. Thank you for
drawing it to my attention.

> i did no modify that line, so it's directly from your patch(line 2009, 
> linux-2.6.8.1.patch).

> there is a cast which convert "j-mddev->resync_mark_cnt" from 64-bit 
> unsigned integer to a 32-bit unsigned integer. so the division is a 
> nomal 32-bit division and no 64-bit division code, __udivdi3, is needed.
> 
> i'm also wondering whether the cast should be there.
> 
> and the later one. there is no type cast. that's 64-bit division so
> the __udvidi3 comes in.
> 
> > 
> > So split the calculation up a bit and see if you can help the compiler
> 
> yes, i've tried to split the code to troubleshooting it and the 
> error went to line 3706.
> 
> ... Omitted ...
> #define _EJ_UDIVDI3_DEBUG_ 
> 
> #ifdef _EJ_UDIVDI3_DEBUG_
>         unsigned ___tmp1, ___tmp2;
>         sector_t ___tmp3;
> #endif /*_EJ_UDIVDI3_DEBUG_*/
> 
> ... Omitted ...
> 
> #ifdef _EJ_UDIVDI3_DEBUG_
>         ___tmp1 = ( jiffies - mddev->resync_mark ) / HZ;
>         ___tmp2 = 2 * ( ___tmp1 + 1 );
>         ___tmp3 = j - mddev->resync_mark_cnt - atomic_read(&md_throttle[mddev->md_minor]);
>         realspeed = ___tmp3 / ___tmp2 + 1; /* line 3706 */
>         /* realspeed = sector_div( ___tmp3, ___tmp2 ) + 1; */
> #else
>         realspeed = (j - mddev->resync_mark_cnt -
> atomic_read(&md_throttle[mddev->md_minor]))/2/((jiffies-mddev->resync_mark)/HZ +1) +1;
> #endif /*_EJ_UDIVDI3_DEBUG_ */ 
> ... Omitted ...
> 
> > out. What compiler is it?
> 
> actually, i tried to compile the code under CentOS 4 and Debian
> woody (3.0r4) and both produced the undefined symbol __udivdi3
> error. the gcc version is:
> 
> [root@CentOS4-2:/usr/src]gcc -v
> ... Omitted ...
> gcc version 3.4.3 20041212 (Red Hat 3.4.3-9.EL4)
> [root@CentOS4-2:/usr/src]
> 
> [root@DeB14:/usr/src]# gcc -v
> ... Omitted ...
> gcc version 2.95.4 20011002 (Debian prerelease)

That should be fine, since it's the one I use!

> i searched google and found a work around to the __udivdi3 using sector_div.
> i've tried and it seems ok.

Doesn't the cast fix it??

> and the enbd. i still can't build it outside the kernel src tree.
> here is part of the error msg.

But that's only because your fixdep has moved. Change the line in the
Makefile to point to where it is in your src. Anyone know when it
moved?

> 
> make[1]: Entering directory `/usr/src/linux-2.6.8.1'
> make -f /usr/src/nbd-2.4.32/kernel/linux-2.6.x/scripts/Makefile.build
> obj=/usr/src/nbd-2.4.32/kernel/linux-2.6.x/scripts
> make[2]: *** No rule to make target `/usr/src/nbd-2.4.32/kernel/linux-2.6.x/scripts/fixdep.c',
> needed by `/usr/src/nbd-2.4.32/kernel/linux-2.6.x/scripts/fixdep'.  Stop.
                                                    ^^^^^^^^^^^^^^^
                                                    scripts/basic/fixdep.c

> make[1]: *** [/usr/src/nbd-2.4.32/kernel/linux-2.6.x/scripts] Error 2
> make[1]: Leaving directory `/usr/src/linux-2.6.8.1'
> *************************************
> * please apply kernel patch instead *
> *************************************
> 
> any suggestions?

I thought I suggested what to last time! Point the Makefile at where
yours is (throughout the file) and all should be OK (crosses fingers).
Let me know what happens! I'd like very much to know.


Peter