Date: Thu, 18 Oct 2012 13:44:59 +0400 From: Anton Yuzhaninov <citrin@citrin.ru> To: freebsd-stable@freebsd.org Subject: Re: Problem with IPMI KCS driver Message-ID: <507FCF9B.9080104@citrin.ru> In-Reply-To: <201209280848.35380.jhb@freebsd.org> References: <503DE2AB.6030702@citrin.ru> <201208290825.44198.jhb@freebsd.org> <506573DD.2030808@citrin.ru> <201209280848.35380.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 28.09.2012 16:48, John Baldwin wrote: >> kcs_wait_for_obf() at kcs_wait_for_obf+0xb6 point to >> > /usr/src/sys/dev/ipmi/ipmi_kcs.c:94 >> > >> > 91 while (ticks - start< MAX_TIMEOUT&& >> > 92 !(status& KCS_STATUS_OBF)) { >> > 93 DELAY(100); >> > 94 status = INB(sc, KCS_CTL_STS); >> > 95 } > Hummm. I'm a bit out of ideas then. Even the volatile change is a bug that > could have been confirmed (to see if volatile was preventing the compiler > from caching the value of 'ticks') by examining the assembly. > > Well, maybe this. This just avoids using 'ticks' altogether and depends on > DELAY(100) doing what it says: New patch also don't solve my problem. My guess was wrong. Loop in kcs_wait_for_obf() is not endless, at least with last patch. Whole function called in some loop, but because loop in kcs_wait_for_obf() takes much CPU time, backtrace always point to loop kcs_wait_for_obf(). This problem need further investigation. -- Anton Yuzhaninov
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?507FCF9B.9080104>