On 06/24/2014 11:46 AM, Chris Redpath wrote:
On 24/06/14 09:42, Chris Redpath wrote:
On 24/06/14 08:56, Alex Shi wrote:
On 06/23/2014 03:30 PM, Naresh Kamboju wrote:
To avoid the lock using, could we try per_cpu cpuidle driver?
Naresh, could you like to test this patch?
Sure Alex.
I will test and post you results.
Hi, Naresh, did you test this patch?
Tixy, Chris,
Any comments for this idea?
Hi Alex,
I've had a look at the patch, I'm not sure if it will make any difference as the potential deadlock is on the same CPU.
I will try to have a better look at it this morning.
--Chris
Hi Alex,
I've had a better look - the per-cpu driver interface doesn't use locking at all so any potential deadlock will of course not occur.
The reason I used cpuidle_driver_ref was to ensure that driver data did not go away while I was reading it, as there isn't any notification for driver changes.
Hi,
theoretically nothing prevent the user to unload the module. In practice, that does not happen because the drivers are usually compiled in. But I wouldn't rely on that.
Also, in the code path, the different idle states are inspected to find the one fitting the ns_delay. On some architecture (eg. x86), one or several idle states can be removed at runtime if they switch to battery<->AC [1]
But the bug you are facing is probably coming from the same cpu is taking the same lock twice because of an interrupt.
-- Daniel
[1] https://git.linaro.org/people/daniel.lezcano/linux.git/commit/e484471d65c1af...
--Chris
linaro-kernel mailing list linaro-kernel@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-kernel
linaro-kernel mailing list linaro-kernel@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-kernel