From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751801AbdJTO7v (ORCPT ); Fri, 20 Oct 2017 10:59:51 -0400 Received: from mailgw1.fjfi.cvut.cz ([147.32.9.3]:56354 "EHLO mailgw1.fjfi.cvut.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751015AbdJTO7t (ORCPT ); Fri, 20 Oct 2017 10:59:49 -0400 X-CTU-FNSPE-Virus-Scanned: amavisd-new at fjfi.cvut.cz DKIM-Filter: OpenDKIM Filter v2.11.0 mailgw1.fjfi.cvut.cz A8B3EA0445 Date: Fri, 20 Oct 2017 16:59:44 +0200 (CEST) From: David Kozub To: Daniel Lezcano cc: Thomas Gleixner , linux-kernel@vger.kernel.org Subject: Re: [PATCH] clockevents/drivers/cs5535: improve resilience to spurious interrupts In-Reply-To: Message-ID: References: <20171019211651.039346004D@linux.fjfi.cvut.cz> <0ea5f585-5407-8bcb-1cc9-9a2f3f11b78e@linaro.org> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="546533125-353834333-1508510936=:10478" Content-ID: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --546533125-353834333-1508510936=:10478 Content-Type: text/plain; CHARSET=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8BIT Content-ID: On Fri, 20 Oct 2017, Daniel Lezcano wrote: > On 20/10/2017 09:49, David Kozub wrote: >> On Fri, 20 Oct 2017, Daniel Lezcano wrote: >> >>> On 20/10/2017 00:25, Thomas Gleixner wrote: >>>> On Fri, 20 Oct 2017, Daniel Lezcano wrote: >>>> >>>>> On 19/10/2017 22:57, David Kozub wrote: >>>>>> This solves a BUG on ALIX 2c3 where mfgpt_tick is called before >>>>>> clockevents_config_and_register returns. This caused mfgpt_tick to >>>>>> call a >>>>>> null function pointer. >>>>>> >>>>>> Thanks to Daniel Lezcano and Thomas Gleixner for helping me analyze >>>>>> this >>>>>> and suggesting a solution. >>>>>> >>>>>> Suggested-by: Thomas Gleixner >>>>>> Signed-off-by: David Kozub >>>>>> --- >>>>> >>>>> Thank for sending this fix. >>>>> >>>>> Can you check if the commit 8f9327cbb is the one introducing the >>>>> regression ? So we can add the proper tags and propagate the fix to >>>>> stable. >>>> >>>> No it's not. >>>> >>>> -       if (cs5535_tick_mode == CLOCK_EVT_MODE_SHUTDOWN) >>>> +       if (clockevent_state_shutdown(&cs5535_clockevent)) >>>> >>>> This particular problem of the missing detached state check has been >>>> there >>>> forever and went unnoticed for whatever reason. >>> >>> The detached condition was artificially caught by the initialized >>> variable: >>> >>> -static unsigned int cs5535_tick_mode = CLOCK_EVT_MODE_SHUTDOWN; >>> >>> The patch 8f9327cbb removes the variable, so very likely this is where >>> the problem appeared. >> >> I will try to test that. But I won't have access to the device till >> Sunday evening. I've had big trouble trying to run kernels > 4.1-rc5 on >> the device and if I'm looking correctly the commit was introduced in >> 4.3-rc1. But I'll try to figure something out. > > David, > > thanks again for taking the time to report and investigate this issue. > Usually people just give up and drop the legacy hardware without letting > us know the kernel is broken with it. So don't spend too much time with > it, just check if the commit before works, if not, just add in the log > the kernel version you noticed the breakage. > > In case you are interested in doing some debugging to narrow down the > offending commit and you know the versions working and not working, you > can try the command git-bisect. It will use a dichotomy approach to find > out the culprit. Hi Daniel, I originally didn't see this issue simply because 4.1-rc7 would not output anything on the serial on the device. For kernels >= 4.1-rc7 the kernel either reboots immediatelly or freezes, in both cases without giving any output in the serial. I tried to find the cause of this with git bisect but in the end I was none the wiser. I also suspected my build environment. Eventually I found out the following: * 4.1-rc6 boots OK * 4.1-rc7 restarts immediatelly, but if I revert f18c34e48 it works but I have no idea why would this commit break anything, the commit looks OK * 4.1 - works if I revert f18c34e48 * e75c73ad6 feeezes even after reverting f18c34e48 * 4.2-rc1 - reboots, even after reverting f18c34e48 Only recently I tried a current kernel and I was more lucky: it gave me some useful output on the serial. To verify 8f9327cbb I was thinking I could take it and apply it onto 4.1-rc6 (if that was possible), but as Thomas suggested it might not be worth it, then I forget about that. Thanks for all the help to you and to Thomas. Best regards, David --546533125-353834333-1508510936=:10478--