Chell / Cave randomly freezes |
||||||
Issue descriptionChromeOS stable 55.*, 56.*, 57.0.2987.123, 58.0.3029.31 beta HP Chromebook 13 G1 What steps will reproduce the problem? (Not reproducible on our Chell Chromebook 13 G1). 1. Sign in to the Chromebook. 2. Open the chrome browser > access normal or random sites without any apps or extension, What is the expected result? Continue browsing normally. What happens instead? The computer freezes, on some devices once per day, on some devices several times per hour, there are no signs of anything different except that everything on the screen stops exactly where it is. Links with reports / timestamps avaialble at: https://docs.google.com/a/google.com/spreadsheets/d/1xkYyZ3Mjc0cVuRo--g75i3qgf64iCdiQqoMDsYS2Rr0/edit?usp=sharing Video of frozen computer result: https://youtu.be/E8Alhr6K7Hs Waiting for result of: go/chromeos-hung
Showing comments 40 - 139
of 139
Older ›
,
May 10 2017
One user (joseph.gleason) had two freezes in the past sixteen hours. One while writing an email and one while casting a Google Doc. Is there any information I should be gathering right now, to help?
,
May 10 2017
@briggs if at any point you can reproduce this within an hour of use (from reboot) if you can post those logs here that would be best, hopefully we'll be able to narrow down reproduction steps.
,
May 10 2017
@briggs, shot in the dark here, tell me if this affects your system 1. select the address bar and hold a key (preferably a letter). 2. without letting up please circle your cursor in and out of the address bar this *may* cause a system hang, I'm curious if its similar to what you experience.
,
May 10 2017
@Matthew, I'll see what I can do about reproducing it within an hour, but unfortunately I have not had many freezes on my personal device lately. I just started using the computer of the user I mentioned above, hoping the issue will follow the computer instead of the user. Fingers crossed for a crash :) As for the address bar test, sadly no system failure. I held down a single letter key for a couple minutes, moving my pointer up and down over address bar at the same time. I did this three times at about a minute each time with no crash.
,
May 10 2017
the issue ive seen it can take a couple minutes if you have the time, did you experience *any* flickering of the screen (periodic black screen)?
,
May 10 2017
watching the video, it looks like this might be related to 712526 @snanda
,
May 10 2017
Yes, that's our assumption.
,
May 11 2017
@matthew, I plugged in a proper mouse and did the address bar test for about five minutes without as much as a flicker. I took a screencap of it but it's pretty boring. https://drive.google.com/open?id=0B8cgYzzCtUtVd1hzSUY4MXN3LWM
,
May 11 2017
Am I able to gain view access to the possible issue that you are referencing? #712526
,
May 11 2017
briggs.alden@ - unfortunately it's a private tracker with lots of partner specific confidential information that we cannot provide access to the issue we're referencing to here.
,
May 12 2017
@briggs, what version have you been seeing this on lately?
,
May 12 2017
@matthew, It's been pretty bad from probably 46 to 57. It seemed to get MUCH worse with 56, which I assumed was when the android code was introduced. The most recent survey was during 57. I can't say for sure how 58 is looking yet but I'm pretty sure (not 100%) that the individual with the two in one day (joseph.gleason) was already on 58. That being said, I've been using his old computer for the past couple days and the worst I've seen is a little stuttering during pretty heavy use. I'll send out another survey next week to see if there have been any changes.
,
May 12 2017
@yunleem, @snanda based on #51, looks like it may not be absolutely related to 712526. @briggs, any flickering in laptop only mode (no external monitors connected)?
,
May 12 2017
@matthew, I do not recall ever seeing flickering on these devices. With the exception of the first video, I try to avoid including any data that involves external monitors since the USB-C docks are a whole other can of horrible worms and only a few users have them.
,
May 15 2017
Just experienced freeze on my chell right now, in the middle of writing an email. Had around 10 tabs open. Here's the chrome://net-internals/#chromeos log from my unit. It froze right after the entire screen flash and none of the alt+vol_up+x or r rebooted the system, so had to do refresh+power. Google Chrome 59.0.3071.47 (Official Build) beta (64-bit) Revision 0 Platform 9460.34.0 (Official Build) beta-channel chell
,
May 15 2017
Yung, could you file a feedback report too assuming that the system hasn't been rebooted as yet? console-ramoops isn't captured via chrome://net-internals/#chromeos but is captured in feedback reports.
,
May 15 2017
Yes, of course I filed the feedback report before posting on this bug :) re: ramoops, can't we preserve it for "generate_logs" as well? https://feedback.corp.google.com/#/Report/60333846227 Description: @snanda - my chell froze up after a screen flash. Looks a lot like the old WM hang issue. None of alt+vol_up+x or r reset the system, so had to do refresh+power UI language: en-US Version: 59.0.3071.47 beta Product Specific Data (whitelisted): CHROME VERSION: 59.0.3071.47 beta CHROMEOS_AUSERVER: <URL: 3> CHROMEOS_RELEASE_BOARD: chell-signed-mpkeys CHROMEOS_RELEASE_DESCRIPTION: 9460.34.0 (Official Build) beta-channel chell CHROMEOS_RELEASE_TRACK: beta-channel CHROMEOS_RELEASE_VERSION: 9460.34.0 ENTERPRISE_ENROLLED: Managed
,
May 15 2017
And it confirms! the last line. [31311.705600] [drm:intel_cpu_fifo_underrun_irq_handler] *ERROR* CPU pipe A FIFO underrun
,
May 15 2017
However, it think it is premature to think that freezes that the customers observed is the same WM issue. I've not seen WM issue for several releases (from M54 or M55, and this popped up on M59 as soon as I moved onto M59) I think it's either 2 separate issues or WM issue getting progressively worse from M57 (for this particular customer for some reason)
,
May 15 2017
Is there information I can send the next time I encounter a freeze to help confirm or deny?
,
May 15 2017
briggs.alden@ - yes, please continue to file the feedback as you're doing now. What would be helpful is for each freeze case, if you can do alt+vol_up+x once (every 10 seconds, up to 3 times) and see if system reboots. If not also try alt+vol_up+r. Knowing whether any of those key combos reboot the system out of the freeze state, it'll give us a clue whether you have a different issue from the WM issue (the one I hit on M59 just yesterday)
,
May 15 2017
I haven't submitted any crash reports since the beginning of april. At that time, none of the freezes showed any response to the keystrokes you provided, as documented in the spreadsheet I've been maintaining. The top five (in yellow) were tested accordingly. https://docs.google.com/spreadsheets/d/1fiHqS7Nej3EOdji0oZ__BTbkjaYLZgRmMvxORbreogc/edit?usp=sharing Other than the keystroke test, which reports are most useful for me to start sending/recording again?
,
May 15 2017
@yungleem, via c#51 they've seen this behavior from R46-57. WM in this case was only enabled in R54 and recently in R58. I understand a pipe A under run is usually indicative to a WM issue, however in this case, I think not. WM was disabled for most of this time period.
,
May 15 2017
@matthew I should clarify, the freezing that we are experiencing now has not happened in the exact same way, along that timeline. Sorry for bad information. Before the freezing, we were getting rebooting. As I understand, that may have been related to the "offline files" issue a few months back. I'm afraid I can't recall when the rebooting stopped and the freezing started.
,
May 15 2017
The WM patches landed in M59 (9357.0.0 to be more precise) so any issues being reported from M58 are unlikely to be WM related. The kernel 3.18 patches here are the ones of interest: https://crosland.corp.google.com/log/9356.0.0..9357.0.0 https://chromium.googlesource.com/chromiumos/third_party/kernel/+log/2961c26bc528985ab07912a8183301453bcdc751..1741310996a714389c8ff5db6f82878c6e67506e?n=10000
,
May 15 2017
The fix for the WM flash & hang has landed in TOT and should land in M59 today: https://chromium-review.googlesource.com/#/c/506269/
,
May 15 2017
@snanda first link is google only. I'm confused as why the WM series is linked.
,
May 15 2017
briggs.alden@ - 1 more request. When the user sees the freeze, after the steps I've laid out on c#60, instead of long press power, do refresh + power to reboot the system so hopefully the memory is preserved? Then file the feedback log. Thanks!
,
May 16 2017
@yungleem, Is the Alt+Shift+i report all you need now following the restart?
,
May 16 2017
Yes, alt+shift+i after restart will do for filing feedback.
,
May 16 2017
Is there any kind of tag that I can put in the crash reports to make them stand out?
,
May 16 2017
yes, add something like "yungleem@" or "snanda@" or both in the feedback text, and it'll stand out. thanks!
,
May 16 2017
Crash report submitted at 14:20 EDT user: rachel.meyer@environmentalcharterschool.org Alt+vol_up+x had no effect. Neither did Alt+vol_up+r. Computer restarted with f3+power. Version 57.0.2987.146
,
May 16 2017
Crash report submitted at 15:04 EDT Computer froze around 14:50 EDT (i was not notified until after the fact) User: mark.williams@environmentalcharterschool.org Version 58.0.3029.112
,
May 17 2017
Crash reported at 11:42 EDT Crash happened at 11:30 EDT User tessa.karel@environmentalcharterschool.org The requested keystrokes had no effect. Version 57.0.2987.146
,
May 17 2017
below is the feedback filed with the log file. It has no ramoops information. Did the user use the refresh+power to reboot the system instead of the 5 second long press of the power button? (I am afraid the user did the latter based on not seeing ramoops log and the eventlog suggests so. https://feedback.corp.google.com/#/Report/60691151732 Description: "yungleem@ snanda@" <eventlog> 305 | 2017-05-17 08:55:50 | Wake Source | Power Button | 0 306 | 2017-05-17 08:55:51 | Power Button 307 | 2017-05-17 08:55:51 | ACPI Enter | S5 308 | 2017-05-17 08:56:08 | System boot | 43 309 | 2017-05-17 08:56:08 | SUS Power Fail 310 | 2017-05-17 08:56:08 | ACPI Wake | S5 311 | 2017-05-17 08:56:08 | Wake Source | Power Button | 0 312 | 2017-05-17 08:56:08 | EC Event | Power Button
,
May 17 2017
I will look at all other feedbacks filed as well.
,
May 17 2017
yungleem@, All three of the recent submissions were restarted with f3+power. The middle one (mark.williams) had quite a delay between the crash and the report though. The most recent was a fresh freeze that was processed exactly as you requested, as was the first one (rachel.meyers) but that computer had sat frozen for about thirty minutes before I could get to it.
,
May 17 2017
snanda@ - there are 2 more logs, that did seem to be rebooted by F3 + power but there are no ramoops :( I am not sure if there is anything in the log that we can use to debug this issue since no log at the time of the freeze is visible. briggs.alden@ - Those users who had the freeze, can you ask them to go to "chrome://net-internals/#chromeos" on their browser and click "Store Debug Logs" button, and share the log file stored in their "Downloads" folder and attach on this bug please? Maybe if we get lucky, some logs that may give us clue may have been saved in the previous messages although it's a slim shot.
,
May 17 2017
Here are the reports from the first and third that I sent.
,
May 17 2017
You can also see the debug files for all of the previous reports in the old spreadsheet. https://docs.google.com/spreadsheets/d/1fiHqS7Nej3EOdji0oZ__BTbkjaYLZgRmMvxORbreogc/edit?usp=sharing
,
May 17 2017
Yung, could you send me a link to those feedback reports? In c#76 eventlog there appears to be an intervening power button that would've caused the loss of console-ramoops.
,
May 17 2017
briggs.alden@environmentalcharterschool.org : to clarify, the power+refresh keys need to be pressed instantaneously only. Longer press of the power button will cause an additional power down which causes the loss of log contents that we are looking for.
,
May 17 2017
https://feedback.corp.google.com/#/Report/60714597492 Description: yungleem@ snanda@ In the middle of editing a Google Sheet when computer froze. The screenshot are the tabs that were open at the time. the requested keystrokes did not work. https://feedback.corp.google.com/#/Report/60691151732 Description: "yungleem@ snanda@" May 16 (19 hours ago) https://feedback.corp.google.com/#/Report/60595782696 Description: Chrome OS seem to freeze 1-2 times a day, mouse and nothings work. It's a all new HP Chromebook 13 G1 with Intel M5 processor and 8 GB ram. I am developer channel because there is no email app / web app to use so need to use Google Play apps but it is NOT good, so there is one more idea. It happens in many different apps. https://feedback.corp.google.com/#/Report/60576447287 Description: Hello yungleem@ snanda@ My computer froze while lesson planning. I had quite a few tabs open--12 or so. One was a youtube classical music channel that I was casting in the classroom at the time. https://feedback.corp.google.com/#/Report/60567501216 Description: yungleem@ snanda@ User returned to frozen computer with the screen still on. Alt+upvol+x three times had no effect. Neither did Alt+upvol+r. I restarted with f3+power.
,
May 17 2017
snanda@, When I have personally performed the refresh+power, it was only a tap, since it kills the computer instantly.
,
May 17 2017
Report submitted at 15:02 DST User: ashley.bergman
,
May 18 2017
Report submitted at 11:38 DST Crash happened around 11:05 DST User beth.flynn Version 58.0.3029.112 (64-bit)
,
May 18 2017
briggs.alden@ - What's really weird about the freezes your organization sees. 1. No other organizations have reported this issue, so isolated to your org. (I can confirm this as one viewing pretty much all the feedback reports of this device) 2. Freeze issue started appearing around Oct., well after Jun., when you first started using the devices. 3. The problem seems to follow the users - HP replacing PCBs didn't make any difference 4. When it hangs, it leaves no pstore stack trace from the previous hang state, making this bug almost impossible to debug. Also not being reproducible outside of your org., impossible to reproduce in our test/dev enviroment. Do you have a handful of users who have more bad luck with this device than others? One thing to try is to swap them with the unit that was never reported to have the hang issue and see what happens.
,
May 18 2017
As someone who has been tracking this and keeping various record throughout the life of the issue, There doesn't seem to be any noticeable pattern. The freezing almost seems to go in waves. For a short while, I was experiencing multiple crashes in a day then they seemed to stop (on the same device). When one user started having a couple a day, I swapped out his computer and everything seemed to be fine. I then took his computer and have only had one crash since then. Two of the recent set have never had any crashes before. We don't push out any extensions that could be causing issues. We might just be a little more media heavy than most workplaces. Several people have reported freezing during casting, but it's certainly not limited to that. Our computers connect exclusively to a 5ghz network. I feel like at this point the only effective troubleshooting we could do is replacing half of the devices with a different model and seeing if we still have the same issue. Unfortunately that is not financially an option for us. That all being said, one of the reports in that list in c84 (Report/60595782696 ) is not from our fleet. Is it possible that there just aren't that many companies using these devices full time, like we are?
,
May 18 2017
briggs.alden@ - can't say the number in public, but I can comfortably say that there are more than enough sample size to reach to the conclusion that your org is one of the few with this issue if not the only one. We have lots of full time users of this device at Google, and they really push these devices to the limit and not seeing this issue at all. First step to resolving this issue is to get alt+vol_up+r working (that does the warm reboot of the system) to preserve the memory stack from the previous boot so we hope to have more definite clue of what might have happened right before the freeze. That issue is being tracked on issue 721853
,
May 19 2017
ynugleem@, is this ticket pretty much on hold for now? If so, I'll just follow the other one until this one becomes relevant again.
,
May 24 2017
ynugleem@ is there any way for me to determine on my end if the memory data is being preserved after a f3+power restart? I feel like if there is even an off chance of it happening following a freeze, it would be worth checking. That way I can send you useful information without spamming you.
,
May 24 2017
Unfortunately, I do not believe so. What's left over will be stored in /dev/pstore but you have no way of accessing in normal mode. When filing the feedback log, the script grabs that info if it exists but you have no way of retrieving this on your end, afaik.
,
May 24 2017
Oh well. Thanks for the reply. I'll hold out hope for 721853
,
May 24 2017
@briggs, while I cant recommended it, because I don't know your organization you could look into putting a system into dev mode and seeing if you can reproduce and then checking /dev/pstore, please check with your system administrator if this is feasible for your uses. The steps to put a machine into dev mode can be found here: http://www.chromium.org/chromium-os/chromiumos-design-docs/developer-mode Because of this bug, I've personally taken a hp G1 home and have been trying to reproduce there, unfortunately I've logged about 20 hours and have yet to reproduce.
,
May 24 2017
c#93: actually there is a way to do that. When the system boots up, navigate to chrome://system and look for console-ramoops. If that line states <empty> then the contents have not been preserved. If it is non-empty we should have useful data that the feedback report will pick up.
,
May 24 2017
snanda@, Which is then the best way to send you the report, if it does exist? Alt+Shift+i or the chrome://net-internals/#chromeos deug log?
,
May 24 2017
alt-shift-i will include that file so lets use that. net-internals doesn't include that file.
,
May 25 2017
We have started seeing a lot of screen flickering going around in the past week. Is that possibly related to this in any way or should I submit a new case for it? https://goo.gl/photos/YRpCJrqyYBsWz3ZF8
,
May 25 2017
What build version is showing the flickering issues? Please do file feedback if you haven't already when the flickering happens. It's likely a different issue but we can confirm once we look at the feedback report.
,
May 25 2017
Thats different from the flickering I usually associate with Watermarks, gonna have a couple other folks look at it.
,
May 25 2017
The computer in question was running: Google Chrome Version 58.0.3029.140 Platform Version 9334.72.0 (Official Build) stable-channel chell Firmware Version Google_Chell.7820.253.0 The appearance of the flickering is very similar to what I see when plugged into a USB-C dock, but the external monitor flicker usually concentrates near the top of the screen. I'll make sure the user submits the report.
,
May 26 2017
@briggs, can you qualify this statement "Started seeing a lot of screen flickering going around" do they all look like the video. Is it multiple systems?
,
May 26 2017
"a lot" is probably an exaggeration. I'm just extrapolating out from the four or five people who have mentioned it to me this week. The flickering looks very similar to what we see when using a USB-C dock, where the window in focus briefly reveals the windows below it, in a jagged break. Before this week, I hadn't ever seen it on the laptop screens. I had an instance on my personal laptop (while not docked) where I could hold the cursor in just the right place and get a photo of the tear, but like an idiot I tried to do a screen shot. Shall we branch this off as a different issue?
,
Sep 8 2017
Since it looks like the ability to pull memory debug on a soft reset has been resolved (721853) in CHrome 60 (or is it 62) does that mean we will be able to gather some additional information on the freezing issue? -Briggs
,
Mar 6 2018
Any update on this, we have more user reporting this issue.
,
Mar 6 2018
The issue has not gone away for us either but I assumed it was a lost cause hardware issue at this point. Most of our faculty just know that when their computer freezes again, to hit Refresh + Power.
,
Mar 6 2018
briggs@ - sorry it has fallen under the radar thinking the problem went away but guess that's not the case. When you hit this issue, if you can follow the below instruction, really would appreciate. 1. Press alt+vol_up+x (wait 10 sec) 2. If nothing happens, alt+vol_up+x (wait another 10 sec) 3. If nothing happens, alt+vol_up+x (wait another 10 sec) 4. If nothing happens, alt+vol_up+r (wait another 10 sec) 5. If nothing happens, press refresh + power File a feedback report (Alt + Shift + i) immediately after the system restarts and mention up to which step mentioned above were you able to reach. Please provide as much information as you can about how you ran into this issue.
,
Mar 6 2018
This is the type of problems that issue 800495 "Request to enhance Chromeos feedback reports with time stamps" would help with.
,
Mar 6 2018
@yungleem We did this all before, a couple dozen times over and found that the console-ramoops was empty. Is there a certain level of confidence that it will be a bit more fruitful this time around? Just checking before I send another email out to the staff about reporting these issues.
,
Aug 3
This bug has an owner, thus, it's been triaged. Changing status to "assigned".
,
Aug 24
Has there been any movement on this issue? Now two years later, we have a new fleet of ASUS C302 that are doing the same thing. I was devastated to learn the C302 shared the same Glados/Skylake baseboard as the HP Chromebook 13 G1.
,
Aug 24
briggs.alden@ - so you still see this issue extensively as before? As I said in comment#91, this issue is not wide spread and not sure how we can debug this unless Intel team has different ideas. There seems to be certain usage pattern or configuration that's fairly unique to your organization and somehow this exposes low level hang that's only seen on Glados/SKL-Y platform. Can you think of anything that you think your organization might do differently from others? What other Chromebooks do you have other than HP 13 GB and Asus C302? Can you also share the most popular set up of how people use these devices? Standalone laptop or connected to docking or external monitors, any peripherals like USB/BT mouse,keyboard,speakers,camera. Anything that you can think of?
,
Aug 24
yungleem@ I thought the issue had started to die down, but it turns out everyone just learned the refresh+power keystroke. I just started handing out the new C302 fleet and I'm hearing reports again since the hardware power button is not in the same place on the new device and users don't know how to force a restart. I'm only about 30% through the deployment and I'm getting a couple mentions per day. All faculty members at our organisation (about 110) use either The HP Chromebook 13 G1 or the ASUS C302CA. About 12 people use them with USB-C Displaylink docks. Unfortunately I can't imagine what we might do differently than other businesses as this is the only chromebook org I have worked with. Some users spend a lot of time casting drive and docs tabs to chromecasts and most users keep far too many tabs open at any given time. They also seem to never reboot their computers unless they hit the 30 day limit I set in the admin console. I would be happy to have someone review my chrome management settings to look for an unusual configuration. For a while we tried disabling local file cache in drive to limit disk activity but that had no effect.
,
Aug 28
If it matters, alt+volup+x, alt+volup+x, alt+volup+r didn't work on a recently frozen device. We had to restart it with refresh+power and content was on the screen the whole time.
,
Aug 28
Just to eliminate the GPU/display issue, when device is frozen, don't do anything but plug in the external display to see if device is alive? If the content was on the screen then I wonder if system is up and running but unable to update the internal display.
,
Aug 31
I was "lucky" to have a freeze on my own device, so I was able to record the whole process. Unfortunately there was no video on an external monitor. https://drive.google.com/open?id=1ahjoDoFAO9MT-NrW0hh60g08486tlhi2 The camera was next to my head so I sound super breathy.
,
Aug 31
Sorry. I fixed the permissions on that video.
,
Sep 6
"Hey! My computer has frozen at least 3 times today. It also would not let me cast for longer than about 5 seconds until it kicked me off :( - Rebecca Boss Fourth Grade Teacher Environmental Charter School 412-247-7970 x115" I get about one of these tickets, per week. Is there any data I can be gathering or anything I can be doing to help? Am I just stuck with $60,000 worth of brand new computers that will randomly freeze up on us for the next two years?
,
Sep 6
briggs.alden@ - I am sorry but I am running out of ideas how to debug this. Do users in your org allow to login as their gmail personal account and use the devices at home? We know it's not a wide spread issue, and possibility of your org having 2 different models from different OEM but on the same reference all randomly having issue, so it has to do with some environment that's very specific to your org. Some other brainstorming thoughts. - Does this happen when it's plugged in to AC? or no relation? - Are there any power lines or transformers near by your location? - Are there a lot of wireless traffic? (e.g. BT, WiFi, other things) - Can users take the device home and use as personal device and see the same issue?
,
Sep 7
OMG! My computer just froze but it came BACK!! Hopefully that means the logs are intact. I sent in an incident report at 8:10am Eastern.
,
Sep 7
Regarding the above questions: - Does this happen when it's plugged in to AC? or no relation? + It seems to have no relation. Personally, my last two crashes were on battery - Are there any power lines or transformers near by your location? + All of our locations are back in residential neighborhoods so nothing special - Are there a lot of wireless traffic? (e.g. BT, WiFi, other things) + Our wireless saturation is quite high in the buildings. Two of them are old stone buildings and we have a higher than average number of access points to get coverage. We also have 20 Chromecasts that the teachers use pretty much all day. - Can users take the device home and use as personal device and see the same issue? + Our users are allowed to use their personal accounts and I know a lot of them use the device as their only computer. I know at least a year ago I had one report of a computer frozen at home, but I can't say if it had the company account logged on or not.
,
Sep 7
briggs.alden@ - I do not see feedback report. Can you file one more? Have it attention to yungleem@ in the message please. How long was the device frozen for before coming back alive? Thanks for answering my questions. So possibilities are, whether it happens more often in buildings with heavy WiFi, and/or happens only when using the company account.
,
Sep 7
,
Sep 11
Unfortunately It's been quite a while since that Freeze and I didn't notice the last message until now. I sent in two reports around the same time and in the second one I included "Issue 708005" at the bottom of the text. The computer froze up three times in close succession and all three times I was making a recovery disk for a computer that was freezing a lot. I was also using the computer heavily at the time, although I only had one account logged on. A final time, I ran the recovery disk creator on a different computer and did a full reset of Chrome OS on my computer. Regarding the heavy wifi theory, I do feel that I have had more freezes in one building than the others, but I don't really have any data to back that up. I'll put out a message to have people notify me of all crashes and see if I can get something useful.
,
Sep 12
Thanks for feedback ... https://listnr.corp.google.com/report/85645859241 Does seem like chrome is unhappy around the same time as usb thumbdrive arrives to make recovery stick, 2018-09-07 07:51:55.939 6 kernel : [51584.179056] usb 2-2: new SuperSpeed USB device number 14 using xhci_hcd 2018-09-07 07:51:55.951 6 kernel : [51584.191061] usb 2-2: New USB device found, idVendor=13fe, idProduct=5200, bcdDevice= 1.00 2018-09-07 07:51:55.951 6 kernel : [51584.191090] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=6 2018-09-07 07:51:55.951 6 kernel : [51584.191111] usb 2-2: Product: MKNUFDVP32GB 2018-09-07 07:51:55.951 6 kernel : [51584.191125] usb 2-2: Manufacturer: MUSHKIN 2018-09-07 07:51:55.951 6 kernel : [51584.191138] usb 2-2: SerialNumber: 11 2018-09-07 07:51:55.952 6 kernel : [51584.192183] usb-storage 2-2:1.0: USB Mass Storage device detected 2018-09-07 07:51:55.953 6 kernel : [51584.193156] scsi host3: usb-storage 2-2:1.0 ... 2018-09-07 07:51:58.913 3 1199:1199: answer_card_web_contents.cc(266): Failed to navigate: HasCommitted=0, IsErrorPage=0, IsInMainFrame=1 ... 2018-09-07 08:04:44.387 3 1199:1199: page_load_metrics_update_dispatcher.cc(190): Invalid first_paint (unset) for first_meaningful_paint 12.102 s 2018-09-07 08:04:44.387 3 1199:1199: 2018-09-07 08:04:44.387 3 1199:1199: Crash dump received by crash_reporter 2018-09-07 08:04:44.387 3 1199:1199: Parent failed to complete crash dump. 2018-09-07 08:04:44.387 3 1199:1199: [0907/080938.792316:WARNING:diagnostics_writer.cc(211)] [FAIL] 009 PathUserData (Path contents too large (13761526141) for: /home/chronos) 2018-09-07 08:04:44.387 3 1199:1199: [0907/080938.822152:WARNING:diagnostics_writer.cc(211)] [FAIL] 016 JSONLocalState (File too big) 2018-09-07 08:04:44.387 3 1199:1199: [0907/080938.841173:WARNING:diagnostics_writer.cc(211)] Finished 18 tests. 2018-09-07 08:04:44.387 3 1199:1199: [0907/080938.841252:WARNING:diagnostics_writer.cc(211)] Finished Recovery for: Install type 2018-09-07 08:04:44.387 3 1199:1199: [0907/080938.841286:WARNING:diagnostics_writer.cc(211)] Finished Recovery for: Chrome version test 2018-09-07 08:04:44.387 3 1199:1199: [0907/080938.841315:WARNING:diagnostics_writer.cc(211)] Finished Recovery for: User data path 2018-09-07 08:04:44.387 3 1199:1199: [0907/080938.841341:WARNING:diagnostics_writer.cc(211)] Finished Recovery for: Local state path 2018-09-07 08:04:44.387 3 1199:1199: [0907/080938.841367:WARNING:diagnostics_writer.cc(211)] Finished Recovery for: App dictionaries directory path 2018-09-07 08:04:44.387 3 1199:1199: [0907/080938.841393:WARNING:diagnostics_writer.cc(211)] Finished Recovery for: Resources path 2018-09-07 08:04:44.387 3 1199:1199: [0907/080938.841418:WARNING:diagnostics_writer.cc(211)] Finished Recovery for: Available disk space 2018-09-07 08:04:44.387 3 1199:1199: [0907/080938.841444:WARNING:diagnostics_writer.cc(211)] Finished Recovery for: User preferences integrity 2018-09-07 08:04:44.387 3 1199:1199: [0907/080938.841469:WARNING:diagnostics_writer.cc(211)] Finished Recovery for: Local state integrity 2018-09-07 08:04:44.387 3 1199:1199: [0907/080938.841530:WARNING:diagnostics_writer.cc(211)] Finished Recovery for: Bookmark file 2018-09-07 08:04:44.387 3 1199:1199: [0907/080938.841558:WARNING:diagnostics_writer.cc(211)] Finished Recovery for: Web Data database 2018-09-07 08:04:44.387 3 1199:1199: [0907/080938.841583:WARNING:diagnostics_writer.cc(211)] Finished Recovery for: Cookie database 2018-09-07 08:04:44.387 3 1199:1199: [0907/080938.841610:WARNING:diagnostics_writer.cc(211)] Finished Recovery for: Favicons database 2018-09-07 08:04:44.387 3 1199:1199: [0907/080938.841635:WARNING:diagnostics_writer.cc(211)] Finished Recovery for: History database 2018-09-07 08:04:44.387 3 1199:1199: [0907/080938.841661:WARNING:diagnostics_writer.cc(211)] Finished Recovery for: Top Sites database 2018-09-07 08:04:44.387 3 1199:1199: [0907/080938.841687:WARNING:diagnostics_writer.cc(211)] Finished Recovery for: Database tracker database 2018-09-07 08:04:44.387 3 1199:1199: [0907/080938.841723:WARNING:diagnostics_writer.cc(211)] Finished Recovery for: NSS certificate database 2018-09-07 08:04:44.387 3 1199:1199: [0907/080938.841750:WARNING:diagnostics_writer.cc(211)] Finished Recovery for: NSS Key database 2018-09-07 08:04:44.387 3 1199:1199: [0907/080938.841770:WARNING:diagnostics_writer.cc(211)] Finished All Recovery operations. ... 2018-09-07 08:29:14.655 3 session_manager[1153]: [ERROR:object_proxy.cc(582)] Failed to call method: org.chromium.LivenessServiceInterface.CheckLiveness: object_path= /org/chromium/LivenessService: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. 2018-09-07 08:29:22.005 4 crash_reporter[22829]: [user] Received crash notification for chrome[18440] sig 6, user 1000 (ignoring call by kernel - chrome crash; waiting for chrome to call us directly) 2018-09-07 08:29:22.457 4 crash_reporter[22850]: Received crash notification for chrome[18420] user 1000 (called directly) 2018-09-07 08:29:22.497 3 18420:22318: crash_handler_host_linux.cc(436): Failed to write crash dump for pid 22411 2018-09-07 08:29:22.497 3 18420:22820: crash_handler_host_linux.cc(436): Failed to write crash dump for pid 20235 2018-09-07 08:29:22.522 6 crash_reporter[22850]: Accessing crash dir '/home/user/99cbc19e888fd7cecde71069607c9744ef354e43/crash' via symlinked handle '/proc/self/fd/6' 2018-09-07 08:29:22.681 3 18420:22436: crash_handler_host_linux.cc(436): Failed to write crash dump for pid 18640 2018-09-07 08:29:22.683 3 18420:22316: crash_handler_host_linux.cc(436): Failed to write crash dump for pid 21566 2018-09-07 08:29:22.725 3 18420:22316: crash_handler_host_linux.cc(436): Failed to write crash dump for pid 20096 2018-09-07 08:29:22.725 3 18420:22316: crash_handler_host_linux.cc(436): Failed to write crash dump for pid 18668 2018-09-07 08:29:22.725 3 18420:22316: Cannot upload crash dump: failed to open 2018-09-07 08:29:22.728 3 18420:22820: crash_handler_host_linux.cc(436): Failed to write crash dump for pid 20322 2018-09-07 08:29:22.728 3 18420:22820: Cannot upload crash dump: failed to open 2018-09-07 08:29:22.738 3 18420:22820: crash_handler_host_linux.cc(436): Failed to write crash dump for pid 20326 2018-09-07 08:29:22.739 3 18420:22812: crash_handler_host_linux.cc(436): Failed to write crash dump for pid 21403 2018-09-07 08:29:22.740 3 18420:22820: crash_handler_host_linux.cc(436): Failed to write crash dump for pid 21323
,
Sep 12
Unfortunately, I figured these particular freezes were probably USB related, but I hoped they might still shine some light on something.
,
Sep 12
Just FYI, I've had many reports of freezes while casting today. I also sent out an email to submit crash reports with "Attn: yungleem@ Ref: Issue 708005" in the text, so I suspect there have already been a few today. Hopefully something useful will surface.
,
Sep 25
Though none of my personal freezes have been during casting, I'm getting many reports of freezing while casting tab content to a chromecast.
,
Sep 25
Think this is the set of freezes https://listnr.corp.google.com/report/85673480357 https://listnr.corp.google.com/report/85669331067 https://listnr.corp.google.com/report/85666797729 https://listnr.corp.google.com/report/85666558764 https://listnr.corp.google.com/report/85659213900 https://listnr.corp.google.com/report/85658994397 https://listnr.corp.google.com/report/85657059791 https://listnr.corp.google.com/report/85656991252 https://listnr.corp.google.com/report/85656906785 https://listnr.corp.google.com/report/85656867141 https://listnr.corp.google.com/report/85656335390 team @ecs recently filed .. thanks. There's at least 7 unique CLIENT_IDs. Looks like these two versions CHROMEOS_RELEASE_DESCRIPTION=10895.56.0 (Official Build) stable-channel cave Chrome Media Router : version 6918_723_0_0 CHROMEOS_RELEASE_DESCRIPTION=10718.88.2 (Official Build) stable-channel cave Chrome Media Router : version 6818_528_0_0 ** feedback:85657059791 301 | 2018-09-12 13:41:53 | EC Event | Key Pressed 302 | 2018-09-12 15:47:33 | System boot | 25 lastlog before hang, 2018-09-12 14:12:08.530 7 kernel : [17080.274094] SELinux: initialized (dev proc, type proc), uses genfs_contexts ** feedback:85656906785 321 | 2018-09-12 13:33:58 | EC Event | Lid Open 322 | 2018-09-12 14:41:53 | System boot | 18 lastlog before hang, 2018-09-12T14:32:02.128021-04:00 DEBUG kernel: [20384.443521] SELinux: initialized (dev proc, type proc), uses genfs_contexts ** feedback:85658994397 338 | 2018-09-13 12:21:42 | Wake Source | GPE # | 5 339 | 2018-09-13 13:34:46 | System boot | 19 lastlog before hang, 2018-09-13T12:57:02.125905-04:00 DEBUG kernel: [23400.292277] SELinux: initialized (dev proc, type proc), uses genfs_contexts - failures seem to be across various Battery levels & some are plugged vs unplugged. - none of the feedbacks have console-ramoops and at least for the above 3 things seem ok (benign log messages written) up until the device freezes. Hopefully with the repro of 'casting a tab' we have some luck repro'ing internally.
,
Nov 1
> alt+vol_up+x once (every 10 seconds, up to 3 times) and see if system reboots. If not also try alt+vol_up+r. Knowing whether any of those key combos reboot the system out of the freeze state, it'll give us a clue whether you have a different issue from ... > If it matters, alt+volup+x, alt+volup+x, alt+volup+r didn't work on a recently frozen device. We had to restart it with refresh+power > Is the Alt+Shift+i report all you need now following the restart? > https://bugs.chromium.org/p/chromium/issues/detail?id=708005#c109 Thanks to Brian all these shortcuts now have documentation: https://chromium.googlesource.com/chromiumos/docs/+/master/debug_buttons.md Moreover this documentation is "live/real-time": https://chromium.googlesource.com/chromiumos/docs/+log/master/debug_buttons.md
,
Nov 15
Is there anything more we can be doing on our end? I'm really not looking forward to two more years of freezing computes and we are well past the point of being able to return these.
,
Jan 11
Hello! This bug is receiving this notice because there has been no acknowledgment of its existence in quite a bit of time. - If you are currently working on this bug, please provide an update. - If you are currently affected by this bug, please update with your current symptoms and relevant logs. If there has been no updates provided by EOD Thursday, 01/17/19 (5pm EST), this bug will be archived and can be re-opened at any time deemed necessary. Thank you!
,
Jan 14
I guess this is the nail in the coffin for this issue. Unfortunately nothing has changed on our end and we will be stuck with freezing computers for the next year and a half. Once again, if there is anything we can do on our end to gather more information, we are happy to help.
,
Jan 14
I've not made any progress with repro of casting to chromecast. +Agnes for any insight for this problem on cave.
,
Jan 16
Unfortunately only three people replied to a question about freezing/rebooting at home. I mentioned this before, but it still seems relevant. When someone's computer starts to freeze up multiple times a day, a Factory Refresh fixes it for a while. It's almost like corruption starts to build up in the OS or something and a reset starts it off from scratch.
,
Jan 17
(6 days ago)
,
Today
(5 hours ago)
Was able to get a cave device from distro and did the following in hopes of reproducing failure but was unsuccessful so far. I attempted the following: 1. lots of casting (cast tab, cast YT, netflix) 2. added lots of accounts, apps & files to fill disk in hopes of replicating disk deprived environment. 3. lots of additional bursty stress. Run app, kill app. I will continue to pound on the device as part of my daily routine but any additional insights folks experiencing the failure would be great. For example, a. Is device plugged or unplugged from AC? If unplugged is battery full or empty? If plugged is battery full or empty when hang occurs? What charger is being used? My analysis of feedback logs in #c131 led me to believe its not relevant but would be good to confirm. b. Backlight levels (screen, keyboard) c. data from chrome://settings/storage about usage or failing device. - Does freeing storage instead of factory reset seem to fix as well? d. does failure occur on any account or just a managed account? Finally, if there's no success on either repro'ing on our end or debugging remotely via logfiles its probably time to think about sending an affected devie back in hopes we can make progress.
Showing comments 40 - 139
of 139
Older ›
|
||||||
►
Sign in to add a comment |
||||||