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] >> 05:04:30.009142 reeze.txt >> 05:04:30.009390 --- before.txt[ 27.841181] >> 05:04:30.009581 2019-02-14 10:12:01.895000001 +0000 >> 05:04:30.020487 +++ after-freeze.txt 2019-[ 27.848337] >> 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