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