Following this CRIT kernel msg chrome continuously reports "Large audio delay, capture delay: 388ms; render delay: 49ms".  Not sure whether this 2 are related or not.  There is another bug crbug.com/801404 to track Large audio delay issue. 


[1:104:0117/090534.524580:WARNING:media_stream_audio_processor.cc(856)] Large audio delay, capture delay: 388ms; render delay: 49ms
[1:104:0117/090534.534549:WARNING:media_stream_audio_processor.cc(856)] Large audio delay, capture delay: 388ms; render delay: 49ms
[1:104:0117/090534.544531:WARNING:media_stream_audio_processor.cc(856)] Large audio delay, capture delay: 388ms; render delay: 49ms

localhost ~ # grep "Large audio delay, capture delay:" /var/log/chrome/chrome | wc -l
82716  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
localhost ~ # 

Issue can also be seen in R65-10315.0.0

2018-01-17T15:56:01.873473-08:00 ERR chrome[929]: [929:929:0117/155601.873453:INFO:remote_commands_invalidator.cc(83)] RemoteCommandsInvalidator state changed: 3
2018-01-17T15:56:27.486492-08:00 CRIT kernel: [ 1045.527092] CPU1: Package power limit notification (total events = 48803)
2018-01-17T15:56:27.486518-08:00 CRIT kernel: [ 1045.527102] CPU0: Package power limit notification (total events = 48794)
2018-01-17T15:56:27.486521-08:00 CRIT kernel: [ 1045.527111] CPU3: Package power limit notification (total events = 48771)
2018-01-17T15:56:27.486523-08:00 CRIT kernel: [ 1045.527114] CPU2: Package power limit notification (total events = 48758)

Guessing this has the same root cause as 803419, so I'm merging the bugs.

Hit the issue again when the device was in meeting session over night.

Kernel crash reported under /var/log/message with the below msg, logs attached

[  827.993575] ieee80211 phy0: device now idle
[  828.002782] CPU0: Core power limit notification (total events = 32856)
[  828.002783] CPU1: Core power limit notification (total events = 32874)
[  828.002785] CPU3: Core power limit notification (total events = 32820)
[  828.002786] CPU2: Core power limit notification (total events = 32813)
[  828.002787] CPU3: Package power limit notification (total events = 77916)
[  828.002788] CPU2: Package power limit notification (total events = 77876)
[  828.002792] CPU1: Package power limit notification (total events = 77861)
[  828.002834] CPU0: Package power limit notification (total events = 77818)
[  828.003794] CPU2: Core power limit normal
[  828.003797] CPU3: Core power limit normal
[  828.003799] CPU0: Core power limit normal
[  828.003800] CPU1: Core power limit normal
[  828.003800] CPU3: Package power limit normal
[  828.003801] CPU1: Package power limit normal
[  828.003802] CPU0: Package power limit normal
[  828.003826] CPU2: Package power limit norma

----------------

localhost ~ # cat /etc/lsb-release 
CHROMEOS_RELEASE_APPID={C0E4276B-35C7-023D-BB4A-42D642B91E65}
CHROMEOS_BOARD_APPID={C0E4276B-35C7-023D-BB4A-42D642B91E65}
CHROMEOS_CANARY_APPID={90F229CE-83E2-4FAF-8479-E368A34938B1}
DEVICETYPE=CHROMEBOX
CHROMEOS_RELEASE_BUILDER_PATH=panther-release/R65-10323.1.0
GOOGLE_RELEASE=10323.1.0
CHROMEOS_DEVSERVER=
CHROMEOS_RELEASE_BOARD=panther
CHROMEOS_RELEASE_BUILD_NUMBER=10323
CHROMEOS_RELEASE_BRANCH_NUMBER=1
CHROMEOS_RELEASE_CHROME_MILESTONE=65
CHROMEOS_RELEASE_PATCH_NUMBER=0
CHROMEOS_RELEASE_TRACK=testimage-channel
CHROMEOS_RELEASE_DESCRIPTION=10323.1.0 (Official Build) dev-channel panther test
CHROMEOS_RELEASE_BUILD_TYPE=Official Build
CHROMEOS_RELEASE_NAME=Chrome OS
CHROMEOS_RELEASE_VERSION=10323.1.0
CHROMEOS_AUSERVER=https://tools.google.com/service/update2

Deleted: kernel_warning.20180123.153800.0.log.gz 1.8 KB

kernel_warning.20180123.153800.0.log.gz 1.8 KB Download

If this results in a kernel crash, I don't think it should be duped to 803419, even if they have the same root cause. If this is indeed caused by overheating, CPU should be throttled before more serious issues arise.

Min, is this happening during manual tests or when running a test script?

Is it reproducible?

If that's the case, does it also occur on M61?

Todd, should we be concern about these warnings?

They are just a sign that thermal control circuit (TCC) w/in AP has been activated.

From,
https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/desktop-6th-gen-core-family-datasheet-vol-1.pdf

Reaching the maximum operating temperature activates the Thermal Control Circuit (TCC). When activated the TCC causes both the processor IA core and graphics core to reduce frequency and voltage adaptively. The Adaptive Thermal Monitor will remain active as long as the package temperature remains at its specified limit. Therefore, the Adaptive Thermal Monitor will continue to reduce the package frequency and voltage until the TCC is de-activated.

It does mean the userland thermal daemon hasn't been successful in maintaining the requested lower temperature but as long as

A) power limit returns to normal
B) frequency of these messages (event count really) is somewhat low
C) device doesn't shutdown

It should be ok.

Thank for explanation, Todd. 
I will close this bug.