> You really changed long to int? In this case, you may only have introduced a
> bigger overflow.
Yes, I'm aware of that, I just wanted to try how i386 variant behaves.
btw I just tried gdb to find out why i386 UML on x86_64 host hangs just
at the beginning, and it turned out to be same problem with
__const_udelay. well, it's not a big surprise now I guess.
So if You need further testing, please feel free to post patches etc ;)
regards
nik.
On Wed, 2006-10-18 at 01:39 +0200, Blaisorblade wrote:
> On Tuesday 17 October 2006 22:21, Nikola Ciprich wrote:
> You really changed long to int? In this case, you may only have introduced a
> bigger overflow.
> Jeff, I remember vaguely a recent (>=2.6.17) patch about udelay fixing a
> misbehaviour, would you please complete my recollection and verify the
> interaction with this?
>
> Also, since we take __const_udelay and __udelay() from asm/arch/delay.h:
> (for i386):
> #define udelay(n) (__builtin_constant_p(n) ? \
> ((n) > 20000 ? __bad_udelay() : __const_udelay((n) * 0x10c6ul)) : \
> __udelay(n))
>
> #define ndelay(n) (__builtin_constant_p(n) ? \
> ((n) > 20000 ? __bad_ndelay() : __const_udelay((n) * 5ul)) : \
> __ndelay(n))
>
> We then do _not_ take these definitions:
> arch/i386/lib/delay.c:
>
> void __udelay(unsigned long usecs)
> {
> __const_udelay(usecs * 0x000010c7); /* 2**32 / 1000000 (rounded up) */
> }
>
> void __ndelay(unsigned long nsecs)
> {
> __const_udelay(nsecs * 0x00005); /* 2**32 / 1000000000 (rounded up) */
> }
>
> instead for us __udelay and __const_udelay match, which is not likely to help
> at all. Their code is correct because the asm "mull" call divides the
> obtained product by 2^32 by throwing away the 32 low bits (i.e. EAX, since
> the mull result is in EDX:EAX), and the meaning of this is to do the division
> only at the very end (to improve accuracy).
>
> This bug is here at least since 2.6.16.
> Suggested solution:
> 1) have _our own_ delay.h, to avoid depending on subarchs' changes
> 2) first avoid playing so complex tricks, then maybe copy their
> implementation
> (note it is slightly different already among x86 and x86_64).
>
> > But I'm sure this is not the right solution, so what
> > do You guys suggest? And also is really i386 variant safely implemented?
>
> > thanks a lot!
> > nik.
>
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
