Re: [uml-devel] SKAS mode not working, x86_64 SMP host, x86_64 guest , problems with noprocmm

[Blaisorblade <blaisorblade@yahoo.it>]

On Tuesday 17 October 2006 22:21, Nikola Ciprich wrote:
> Hi guys,
> thanks for suggestions. Now I've been able to track the problem, and it
> seems to be arch/um/sys-x86_64/delay.c, function __const_udelay.
> halt process hangs at drivers/md/md.c, function md_notify_reboot(...):
> it never gets after the mdelay(1000*1) line, however according to my
> printk's I've added it seems that this function is being executed
> periodically, but it's certainly because of some overflow.
> I've noticed that it's being called with usecs value of 4294000, and
> I've also noticed following comment at include/linux/delay.h:
> /*
>  * Using udelay() for intervals greater than a few milliseconds can
>  * risk overflow for high loops_per_jiffy (high bogomips) machines. The
>  * mdelay() provides a wrapper to prevent this.  For delays greater
>  * than MAX_UDELAY_MS milliseconds, the wrapper is used.  Architecture
>  * specific values can be defined in asm-???/delay.h as an override.
>  * The 2nd mdelay() definition ensures GCC will optimize away the
>  * while loop for the common cases where n <= MAX_UDELAY_MS  --  Paul G.
>  */
> So maybe calling __const_udelay with such high value is problem? When I
> print value of n, it's always some big value (like 3419150745), so it
> seems that this variable is overflowing). When I compare um-i386 and
> um-x86_64 implementation of __const_udelay, it turns that difference
> between them is that i386 version uses plain unsigned ints, while x86_64
> version uses unsigned longs. So I've tried to change longs to ints (yup,
> it's certainly brain damaged, but I just wanted to try) and things seem
> to started working.

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.

-- 
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade
http://www.user-mode-linux.org/~blaisorblade
Chiacchiera con i tuoi amici in tempo reale! 
 http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com 


-------------------------------------------------------------------------
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