On 07/15/2015 09:58 PM, Nathan Fontenot wrote: > On 07/15/2015 09:35 AM, Thomas Huth wrote: >> On 07/14/2015 11:22 PM, Benjamin Herrenschmidt wrote: >>> On Tue, 2015-07-14 at 20:43 +0200, Thomas Huth wrote: >>>> Any suggestions how to fix this? Simply revert 587f83e8dd50d? Use >>>> mdelay() instead of msleep() in rtas_busy_delay()? Something more >>>> fancy? >>> >>> A proper fix would be more fancy, the get_sensor should happen in a >>> kernel thread instead. >> >> I'm not very familiar with this stuff, but isn't the EPOW interrupt >> something that is very time-critical? Moving parts of the handler into a >> kernel thread then does not sound like a very good idea to me... >> >> Another question: Can it happen at all that this get-sensor call results >> in a sleep condition? Looking at commit ID >> 81b73dd92b97423b8f5324a59044da478c04f4c4 ("Fix might-sleep warning on >> removing cpus"), which apparently fixed a similar issue for CPU >> hot-plugging, indicates that at least some of the rtas calls are never >> returning the busy code? In that case we could fix this by introducing a >> similar rtas_get_sensor_fast() function? (or simply revert 587f83e8dd50d >> which would be quite similar, I think) >> > > Looking at the PAPR, the get-sensor-state rtas call for the EPOW sensor > is listed as a fast call and should not return a busy indication.
Great, good to know, thanks for looking that up! So IMHO we should either introduce a rtas_get_sensor_fast() function or revert 587f83e8dd50d ... any preferences? Shall I come up with a patch? > I'm curious as to why we're getting a busy return indication when > making this call. Looking at the code again, rtas_busy_delay() likely never slept ... it's likely just the "might_sleep()" annotation in that function that causes the BUG. Thomas
signature.asc
Description: OpenPGP digital signature