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
