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>