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.

Best regards,

								Pavel
-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany