On 11/07/2013 02:42 PM, Vaibhav Bedia wrote:
> Hi Nishanth :)
> On Thu, Nov 7, 2013 at 10:48 AM, Nishanth Menon <n...@ti.com> wrote:
>> On 11/07/2013 09:36 AM, Daniel Mack wrote:
>>> On 11/07/2013 04:18 PM, Nishanth Menon wrote:
>>>> Tested this on a vendor V3.12 tag based kernel:
>>>>
>>>> Test patch: http://pastebin.com/AmnktQ7B
>>>> test: echo -n "1">/sys/power/pm_print_times; rtcwake -d /dev/rtc0 -m
>>>> mem -s 5
>>>>
>>>>
>>>> with the current patch: http://pastebin.com/RujarRLV
>>>> suspend_late and resume_early: http://pastebin.com/RujarRLV
>>>
>>> These two are identical.
>>>
>>>> suspend_noirq and resume_noirq: http://pastebin.com/nKfbm7Mj
>>>
>>> And I can't see any difference between this one and the first one,
>>> except for slightly different timings. Am I missing anything?
>>
>> aah, that happens to be a little key :)
>> if you see the current patch, it happens around line 417,
>> with suspend_late, it moves deeper(or later) into suspend around 738
>> with noirq - it is as late as it can get - around line 823 just before
>> the last set of arch suspend calls are done.
>>
>
> That's some nifty analysis overnight ;)
>
> Yeah, the intention was to move the EDMA ops as late as possible.
> I am not sure if noirq thing takes care of the late i2c stuff to talk to the
> PMICs that happens on some OMAPs. Maybe the generic PM code
> handles that already but i am a bit rusty on the details right now so
> that would just mention that scenario to be considered.
>
To trigger the fail, I created a custom Test case on TI vendor kernel
based on v3.12 tag:
On beagleBone-Black
test scenario (BBB):
Boot from SD card
ensure firmware is loaded (rev 0x182)
run LTP fsstress [1] in background on EMMC
mkdir -p /tmp/testing
mke2fs /dev/mmcblk1p1
mount /dev/mmcblk1p1 /tmp/testing
fsstress -d /tmp/testing p 4 -n 1000 -l0 -v >/dev/null &
run ping in the background (to add yet another interface)
run memtester[2] (70% of free memory)
memtester 343M >/dev/null &
sleep 10 (to allow memtester to start up properly)
start=`date`;i=0; while [ 1 ]; do rtcwake -d /dev/rtc0 -m mem -s
2; i=$((i + 1)); echo "$i: start =$start, now="`date`; sleep 2; done
Eventual hang log (using the regular suspend-resume): [3] - took close
to two days of testing to trigger this.
Moving to a suspend_late and resume_early such as in [4], it passed
the test for over 4 days now.
Daniel,
will be good if you could post [4] for comments if you think that is
the right thing to do and helps solve the issue you saw as well.
[1]
https://github.com/linux-test-project/ltp/tree/master/testcases/kernel/fs/fsstress
[2] http://pyropus.ca/software/memtester
[3] http://pastebin.pandaboard.org/index.php/view/18307529
[4]
https://git.ti.com/ti-linux-kernel/ti-linux-kernel/commit/f8f9a8c38644d27dc8671009209922531b072110
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
