Re: [cip-dev] cip/linux-4.4.y-cip usb: 4 runs, 2 regressions (v4.4.243-cip51-21-g1d9a9094c010)

[Guillaume Tucker <guillaume.tucker@collabora.com>]

[-- Attachment #1: Type: text/plain, Size: 3433 bytes --]

On 04/12/2020 17:48, Pavel Machek wrote:
> Hi!
> 
>>> *** gpg4o | HINT: Error while checking message with detached signature
>>> (PGP/MIME signature)!
>>> Couldn't locate the original MIME source of the mail to verify the signature!
>>> gpg4oh32.dll:: func_IV Init OK ***
>>>
>>> Hello, bot. Can you speak english?
>>
>> Beep boop.
>>
>> I've recently enabled these email reports. They come from KernelCI.org.
>> I meant to say yesterday, but forgot :(
> 
> No problem :-).
> 
>>>>      2020-12-03 05:04:20.968000+00:00  [   18.800704] Freezing remaining
>>> freezable tasks ... (elapsed 0.001 seconds) done.
>>>>      2020-12-03 05:04:20.972000+00:00  [   18.809224] Suspending console(s)
>>> (use no_console_suspend to debug)
>>>>      2020-12-03 05:04:23.674000+00:00  [   18.865290] hub 3-1:1.0: activate --> -
>>> 113
>>>>      2020-12-03 05:04:23.675000+00:00  [   18.867538] PM: suspend of devices
>>> complete after 51.550 msecs
>>>>      2020-12-03 05:04:23.685000+00:00  [   18.868293] PM: late suspend of
>>> devices complete after 0.750 msecs
>>>>      ... (66 line(s) more)
>>>
>>>
>>> I'm not sure where you see failure here, plus I find it hard to
>>> believe that we have broken anything between
>>> v4.4.243-cip51-10-gd7466739b72e9 and v4.4.243-cip51-21-g1d9a9094c010.
>>
>> Looking at the full test log [0] it looks like a comparison (before.txt with after-freeze.txt) has gone wrong. Presumably some corrupt data?
>>
>> 05:04:29.997473  + lava-test-case compare-freeze --shell diff -u before.txt after-f[   27.830724] <LAVA_SIGNAL_STARTTC compare-freeze>
>> 05:04:30.009142  reeze.txt
>> 05:04:30.009390  --- before.txt[   27.841181] <LAVA_SIGNAL_ENDTC compare-freeze>
>> 05:04:30.009581  	2019-02-14 10:12:01.895000001 +0000
>> 05:04:30.020487  +++ after-freeze.txt	2019-[   27.848337] <LAVA_SIGNAL_TESTCASE TEST_CASE_ID=compare-freeze RESULT=fail>
>> 05:04:30.020750  02-14 10:12:11.459256544 +0000
>> 05:04:30.032157  @@ -1,4 +1,5 @@
>> 05:04:30.032446   0424:9514
>> 05:04:30.032634  +0424:ec00
>> 05:04:30.032840   04f2:b443
>> 05:04:30.033020   1d6b:0002
>> 05:04:30.033195   1d6b:0002
> 
> This looks like USB id's. (1d6b: is Linux foundation, common in USB
> hubs). So I believe this tells us that someone plugged in device
> 0424:ec00 -- ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514
> Fast Ethernet Adapter ... and I don't think we have a bug to solve
> here.

This test dumps all the USB vendor/product IDs in a text file
before suspending the device, then does it again after resuming.
It then compares them to see if all the USB devices came back
from suspend.  In this case, it looks like the USB-Ethernet
adapter device failed.  This may be an intermittent issue, or
maybe it sometimes takes longer to resume and the test missed it
after resume.

If this was a clear regression, an automated bisection would have
most likely found the breaking commit.  There hasn't been any,
and since it's pretty unlikely anything between these 2 revisions
broke anything it's most likely an unstable test result.  It
shouldn't be specific to the CIP kernel tree, let's see if we get
the same problems in other kernel trees (stable, mainline, next).
We may also adjust timing in the test if that is what is causing
the problem.  It's not a suspend/resume performance test.

Thanks,
Guillaume

[-- Attachment #2: Type: text/plain, Size: 420 bytes --]


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5947): https://lists.cip-project.org/g/cip-dev/message/5947
Mute This Topic: https://lists.cip-project.org/mt/78682105/4520388
Group Owner: cip-dev+owner@lists.cip-project.org
Unsubscribe: https://lists.cip-project.org/g/cip-dev/leave/8129055/727948398/xyzzy [cip-dev@archiver.kernel.org]
-=-=-=-=-=-=-=-=-=-=-=-