Ubuntu意外死机（LinuxCrash/Hang）解决

My results on N3540 running 4.10.1 (g8c10701) with and without v3 patch.Only 1 run each, so I don't know abou repeatability. I did as Len instructed (watching the gpu frequency). For me even one fullscreen glxgears was enough to cap the frequency to maximum, but running several small screens made the frequency change all the time.Unpacthed kernel froze in less than two hours, with v3 patch applied, freeze happened while running for about 8 hours with same test set.

Created attachment 255281 [details]attachment-16106-0.htmlI have been running Fedora 25 in my Dell Inspiron 15 3000 Series with IntelPentium N3540 and kernel 4.9 has been stable for around 3 weeks now,completely vanilla, has somebody in Fedora Project/Red Hat tweakedsomething? more people should try it too, makes no difference if I usewayland or xorg.2017-03-12 11:22 GMT-07:00 :> https://bugzilla.kernel.org/show_bug.cgi?id=109051>> --- Comment #755 from Juha Sievi-Korte (jsievikorte@gmail.com) ---> My results on N3540 running 4.10.1 (g8c10701) with and without v3 patch.>> Only 1 run each, so I don't know abou repeatability. I did as Len> instructed> (watching the gpu frequency). For me even one fullscreen glxgears was> enough to> cap the frequency to maximum, but running several small screens made the> frequency change all the time.>> Unpacthed kernel froze in less than two hours, with v3 patch applied,> freeze> happened while running for about 8 hours with same test set.>> --> You are receiving this mail because:> You are on the CC list for the bug.

Hi,I was able to test with wireless:https://launchpad.net/ubuntu/zesty/amd64/bcmwl-kernel-source/6.30.223.271+bdcom-0ubuntu2Some interesting results: - the laptop was on power when the wireless driver was installed. When doing the copy and unloading and loading the btusb driver twice, all kept working - after a reboot, without the power on, same action made an instant hang happen.So it seems that: - the laptop started without power affects this (noticed that earlier)Since @Len Brown mentioned that this worked on his Asus :intel_idle.max_cstate=2I tried that too. That actually works for my situation as well.Does that mean the C6 is the cause in combination with wireless?Is anyone at intel able to patch this up too :)?I would be very happy to see this resolved still. The machine I have is still dedicated to testing.Thank you

Arch users can test linux-baytrail410 & linux-baytrail411 (rc3).including patches from here and more.My Tablet seems to run much smoother (tested on Gnome 3 - very laggy before)On stock kernel it often freezes after the Login. This problem is gone for me.feel free to test and give some feedback.After some idle time the screen wents black. Sometimes it comes back after a longer time by ramdomly pushing all buttons.Hibernate and screen suspending are set to disabled.Anyone have a suggestion?

Hi,Just a quick observation for you guys ;]I'm running a Ubuntu 16.04 (GalliumOS 2.1 with 4.8.17 kernel) on an Acer CB3-111 Chromebook with Bay Trail CPU. I have been using it a lot for about a month now without any problems or freezes and suddenly today it started to freeze after a couple of minutes (about 15-20) or so and only power button could help (hard reset). I was looking for what might be the reason and I googled to here. After browsing through this thread I got an idea:I noticed that my Bluetooth is on in xface. I never used bluetooth on this device and so I just turned it off in GUI (xface) and the freezes seem to be no more. I am working for a couple of hours now. Will see in a couple of days but it seems like the issue is fixed now.What suggested me the solution was some post here about bluetooth (btmon I think). The issue is so annoying that I decided to share in case this simple solution might also work for someone else. I would not like to chang c-state as this would mean additional battery drainage.Stay safe ;]

The good news is that 4.11-rc4 has the v3 patch built in.  The bad news for me is that my build hard froze within 5 minutes on Mint 18.1.  The original patch can't be used anymore because some of the code it modified was rewritten. "Delightfully unstable" T100CHI - Z3775.Update: 4.11-rc4 with intel_idle.max_cstate=2 froze in about 20 minutes.  I'll retest when -rc5 comes out.

As AndyMG reported that Bluetooth may have an influence I have switched it off yesterday and had no freeze during 2 hours.Even intel_idle.max_cstate=0 did not help always with bluetooth on.Have a nice day

I've been having really good stability with the ck patchset kernel on Arch Linux (linux-ck-silvermont-4.10 available at https://mirror.archlinux.no/repo-ck/os/x86_64/) on my N2940 Lenovo 11eBeen running youtube videos, vlc and other general use for about 16 hours so farNo idea why this would be the case, but it's interesting

4.11-rc5 is stable so far without any cstate argument on my CHI w/v3 patch.  My rc4 was stable with cstate=1, so I'm beginning to suspect a build error (comment #760) Except for WiFi noise (brcm) in dmesg, 4.11-rc5 looks quite good overall for my system (T100CHI - Z3775).

Re: comment #750 - Avoid tweaking evaluation thresholds on Baytrail v3> Running this patch on 4.10, I've not yet seen a failure on> Dell-n3540, Acer-J1900, ASus-T100-CHI-Z3775 -- while I was able> to fail all of those machines in under 15-minutes without the patch.At 6 weeks + 1 hour of running my torture test,my Dell-N3540 hanged.  (Acer J1900 still running.)@ Juha Sievi-Korte Thanks for testing!Your n3540/Mika-v3 failure after 8-hours was much more promptthan my 6-week result!

@ Vincent GerrisRe: intel_idle.max_cstate=2Yes, that allows C1 (state1) and C6-no-shrink (state2),but disables C6-Shrink, C7 and C7-Shrink.  Here "shrink"refers to forcing the cache to be flushed on 1st entryinto that state -- an action that is good for power,as the cache can be powered-off, but bad for performance,assuming you plan to access again the cache state that was flushed.you'll be able to observe this with turbostat,The result is that you'll have Core C6 residency,but since the shared module cache will not be flushed, you'llnot often have module (pair of cores) residency, or package C6 residency.Package C6 is where the external voltage to the package will be changed.To enter package C6, the graphics must also be in Render-C6 (RC6).@frrRegarding voltage changes.  Linux does control them, but in-directly.Higher voltage is used for high frequency, lower voltage for lowerfrequency.  On the CPU, we write the PERF_CTRL MSR with a COOKIEthat includes the speed, and the hardware translates that intowhat it should do with the voltage.note that I generally run with a fixed frequency -- the highest --in an attempt to cause worst-case voltage swings.  The voltage doesn'tstay high -- the most frequent cause of voltage changes it the factthat when all cores go idle, the hardware automatically lowers thevoltage, and then ramps it back up on exit from idle.GFX has its own P-states, and they are under direct control of thei915 driver.  "Mika v3" and other patches are tweaking how and whenthe GFX P-state is changed -- and this area appears to be very closeto the most common pain (but no universal) point on these systems.

@ Mark_H Re: bluetooth> Even intel_idle.max_cstate=0 did not help always with bluetooth on.when that parameter is used, intel_idle is disabled and you run acpi_idle.What acpi_idle does varies from machine to machine.(wee what states it offers w/ :grep . /sys/devices/system/cpu/cpu0/cpuidle/*/*)So the question is if intel_idle.max_cstate=1 does not make a difference,but disabling bluetooth does.  If that is the case, then that may bea different bug.  If that is NOT the case, then BT may simply be verygood at helping us take interrupts and pop in and out of idle to makethe failure happen sooner.

I see the status as "NEEDINFO" but no obvious indication of what information is needed. This bug is pushing ~800 comments, most of them "me too" and related. What information needs to be provided from users and is there a matrix of affected/non-affected vs context (like the BT one mentioned a couple of comments above)?

@b.peguero See here for user reports: https://docs.google.com/spreadsheets/d/1oajcMYL9oSt0O6VTpaIj0osGJxKGKSPSYtLnqr3UHNk/edit#gid=0

@zgrabeAs bluetooth enabed seems to have impact, maybe there should be an additional column (e.g. bluetooth enabled? yes/no)

Dear gents,I've previously wallpapered enough of this forum in posts 728 and 752.Just to add a bit of recent experience, I've had two other industrial machines (models) pass through my lab, they both had a Celeron J1900, and both passed the torture chamber just fine (same test environment). In addition to the loopy video playback (same file as before, same OS setup and kernel), I've also tried GLXgears (while the video playback test was turned off), gradually stepping up the number of instances of GLXgears from 1 to 5 - I added another one after a day of flawless operation. No matter what I did, those two machines were stable. They were a Nexcom IPPC-1840P (very similar hardware to APPC-xx40 series which also seem to work good) and an AAOEN OMNI-5175 (engineering sample, apparently). I kept teasing them for a straight week, before I had to ship them to a customer.=> makes me feel as if the BayTrail is merely susceptible to some kinds of motherboard design and testing deficiency, that either Intel did not properly warn the mobo makers about, or the mobo makers did not take Intel's guidelines seriously enough and there are no tests in their QC benches for this particular "corner case"...

I don't know if it's the done thing, but I would like to propose this bug be closed, and a new one created referencing this one, and only current information be put in the new bug.This is because it's very hard to determine what the current situation is regarding the cstates that work in combination with which patches, and any specific hardware issues such as SDIO and video, which seem to trigger problems more quickly.

I'm using the 4.4.0-72 kernel, it looks like they fixed the problem. The freezes are over, I urge you to test this kernel.Hardware: Intel Celeron Bay Trail 4x CPU N2930 @ 1,83GHz

@gutosoni : your comment is less than helpful if you do not specify which exact kernel you mean, where you got it, etc. Please share some concrete links and tell which one did not work, and preferably what change you think fixed this.@Len BrownThank you for you elaborate explanation.Can you say if the issue I have (N3520, Yoga 2 11) will be fixed in this bug report, or do I need to file a new bug report?I also noticed this comment that I missed before (from Mika):Another long shot to try is to see if:'intel_reg write 0xa168 0x0'has any effect on occurrence.I will see if that does anything.As reported, I still have consistent freezes when doing a file transfer over wifi, on 4.11 with the latest patch (sometimes even without touching bluetooth).Kind regards,Vincent

(In reply to Vincent Gerris from comment #773)> > 'intel_reg write 0xa168 0x0'> > has any effect on occurrence.> Very likely a waste of time. That change wont last as we rewrite the pmintrmaskoften. You would need to change the mask in the kernel and recompile (there was a patch long way back).One intresting triaging point is not limiting the cstate but ratherlimiting the number of active cpus.Please try if 'maxcpus=2' will make a difference.

(In reply to Vincent Gerris from comment #773)> @gutosoni : your comment is less than helpful if you do not specify which> exact kernel you mean, where you got it, etc. Please share some concrete> links and tell which one did not work, and preferably what change you think> fixed this.> > @Len Brown> Thank you for you elaborate explanation.> Can you say if the issue I have (N3520, Yoga 2 11) will be fixed in this bug> report, or do I need to file a new bug report?> > I also noticed this comment that I missed before (from Mika):> Another long shot to try is to see if:> > 'intel_reg write 0xa168 0x0'> > has any effect on occurrence.> > I will see if that does anything.> As reported, I still have consistent freezes when doing a file transfer over> wifi, on 4.11 with the latest patch (sometimes even without touching> bluetooth).> > Kind regards,> Vincenthttp://packages.ubuntu.com/xenial/linux-image-4.4.0-72-genericI have been using it for over a week, so far everything is fine, no problems.

(In reply to gutosoni from comment #775)> http://packages.ubuntu.com/xenial/linux-image-4.4.0-72-generic> I have been using it for over a week, so far everything is fine, no problems.My office desktop (Zotac ZBOX-CI320NANO with Intel Celeron N2930) has that same exact version provided through Linux Mint 18.1 updates. Without intel_idle.max_cstate=1 it freezes within the hour. Same machine with 4.10.9-041009 (from http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.10.9/linux-image-4.10.9-041009-generic_4.10.9-041009.201704080516_amd64.deb) runs a bit longer - about 3-4 hours before freezing solid!When loading the kernel with intel_idle.max_cstate=1 the machine performs flawlessly for months with no crash.Hal

Looking at a 4.1.12 prempted-rt kernel with a bay trail 3805 ( headless ) meaning there is no graphics engine.  So the patch from comment# 683 https://bugzilla.kernel.org/show_bug.cgi?id=109051#c683 does not apply.What they are seeing is an occasional 5 – 7 mS of additional latency around some of our pthread_cond_timedwait() calls.   For example, if they tell pthread_cond_timedwait() to wait up to 50ms, it actually isn’t returning for 56 ms.   If they use intel_idle.max_cstate=1 on the kernel command line, the problem goes away.So I am wondering if we are looking for the issue in the wrong place.   OR should this be listed as a separate/ new bug?

(In reply to Fred from comment #777)> Looking at a 4.1.12 prempted-rt kernel with a bay trail 3805 ( headless )> meaning there is no graphics engine. So the patch from comment# 683> https://bugzilla.kernel.org/show_bug.cgi?id=109051#c683 does not apply.> > What they are seeing is an occasional 5 – 7 mS of additional latency around> some of our pthread_cond_timedwait() calls. For example, if they tell> pthread_cond_timedwait() to wait up to 50ms, it actually isn’t returning for> 56 ms. If they use intel_idle.max_cstate=1 on the kernel command line, the> problem goes away.> > So I am wondering if we are looking for the issue in the wrong place. OR> should this be listed as a separate/ new bug?Fred, please take a look at:https://bugzilla.kernel.org/show_bug.cgi?id=195255

(In reply to Mika Kuoppala from comment #778)> (In reply to Fred from comment #777)> > Looking at a 4.1.12 prempted-rt kernel with a bay trail 3805 ( headless )> > meaning there is no graphics engine. So the patch from comment# 683> > https://bugzilla.kernel.org/show_bug.cgi?id=109051#c683 does not apply.> > > > What they are seeing is an occasional 5 – 7 mS of additional latency around> > some of our pthread_cond_timedwait() calls. For example, if they tell> > pthread_cond_timedwait() to wait up to 50ms, it actually isn’t returning> for> > 56 ms. If they use intel_idle.max_cstate=1 on the kernel command line,> the> > problem goes away.> > > > So I am wondering if we are looking for the issue in the wrong place. OR> > should this be listed as a separate/ new bug?> > Fred, please take a look at:> https://bugzilla.kernel.org/show_bug.cgi?id=195255Thanks Mika!

(In reply to Mika Kuoppala from comment #774)> (In reply to Vincent Gerris from comment #773)> > > > 'intel_reg write 0xa168 0x0'> > > > has any effect on occurrence.> > > > Very likely a waste of time. That change wont last as we rewrite the> pmintrmask> often. You would need to change the mask in the kernel and recompile (there> was a patch long way back).> > One intresting triaging point is not limiting the cstate but rather> limiting the number of active cpus.> > Please try if 'maxcpus=2' will make a difference.Hi Mika,Thanks, maxcpus=2 makes it stable for me.How would you like me to proceed?

I've built the new 4.10.11 with the v3 patch backport.  It froze twice, once within 10 minutes and then again within an hour.  For third try, I added intel_idle.max_cstate=2 as previously recommended.  That resulted in a "soft" freeze within 3.5 hours (apparently a wifi issue - dmesg was spammed with brcmfmac error -110s.)  Technically, that wasn't a cstate hard freeze, but either way, all three tests ended with the system unusable.4.11-rc5, rc6 & rc7 all run fine without any cstate arguments, scripts or patches (v3 patch was mainstreamed in rc4.)  4.10.10 is rock solid with Mika's original patch.  Did something else need to be backported to avoid freezing in 4.10.11?  (Also see comment 754)For test #4 I'm using maxcpus=2.  9+ hours of run time so far.  I've had previous good results with maxcpus before (comments 191, 197) before settling on intel_idle.max_cstate=1.  Curiously, the wifi dmesg spam is conspicuously absent so far in this test.  I prefer cstate=1 workaround, since maxcpus cuts system performance - video streaming shows more stuttering.  I can test any new patches if/when available.  Thanks to all at Intel (and elsewhere) for applying some real horsepower to this cluster of baytrail freeze problems.  For my system - T100CHI, Z3775, 4.11 looks great.  4.10 has more issues muddying the waters.  Baytrail sound was still evolving and (broadcom) wifi has had chronic issues since early December backported to several kernel series.  4.10[EOL] can't happen soon enough!  YMMV.

(In reply to jbMacAZ from comment #781)> I've built the new 4.10.11 with the v3 patch backport.I repeated test 3 with wifi disabled and got a typical hard freeze in about 4 hours, better than the earlier test, but not good.  Setting intel_idle.max_cstate=1 appears to restore stability for my system with 4.10.11.  I also got my first freeze today on 4.11-rc7 after 2 weeks of successful 4.11 (rc5, rc6 & rc7) testing.  It's time to throw in the towel on this clunker.  Even other T100 models (e.g. T100TA...) are far less prone to freezing...

I have very similar problem, on LENOVO V510-15IKB with i7 7500U (Kaby Lake).With default kernel (4.4) on Ubuntu 16.04 freezes were very often (from 5 minutes up to maximum 2 hours of work). Now I've update kernel to 4.10.10 and set intel_idle.max_cstate=1, freezes still happens but in 3-12 hours of work.Somebody using Kaby Lake?How to diagnose that is it same c-state bug?

(In reply to Andrey from comment #783)> I have very similar problem, on LENOVO V510-15IKB with i7 7500U (Kaby Lake).> With default kernel (4.4) on Ubuntu 16.04 freezes were very often (from 5> minutes up to maximum 2 hours of work). > > Now I've update kernel to 4.10.10 and set intel_idle.max_cstate=1, freezes> still happens but in 3-12 hours of work.> > Somebody using Kaby Lake?> How to diagnose that is it same c-state bug?You probably have a different issue because the hallmark of this bug is setting intel_idle.max_cstate=1 virtually stops the freezes.  To diagnose, it is best to change things one at a time.  if setting intel_idle.max_cstate=1 with your default kernel still freezes under 2 hours (at least 2 attempts) then cstate is probably unrelated to your issue.BTW my Dell kabylake (i7-7500U) hasn't frozen on me yet, so that processor can run without freezing (about 2 months).

I have a laptop with a 2nd generation Intel i3 CPU (Ivy Bridge i3-3110) and ever since I installed Ubuntu 16.04 I have been have random freezes as well. But the thread suggests that with my CPU it is *not* the cstate bug. Can anyone suggest which bug thread it is for the people with the *same* random hangs as the cstate bug but for CPUs other than the Bay Fail?I've tried Xubuntu 16.04, 16.04.1, and 16.04.2 and all the kernels available, including the latest mainline ones. Same result. If I leave my machine running at some point it will freeze and nothing but a hard power off will solve it. Unfortunately, doing that has corrupted the file system twice and required reinstallation because fsck wasn't able to resolve it.

(In reply to slumbergod from comment #785)> I have a laptop with a 2nd generation Intel i3 CPU (Ivy Bridge i3-3110) and> ever since I installed Ubuntu 16.04 I have been have random freezes as well.> But the thread suggests that with my CPU it is *not* the cstate bug. > > Can anyone suggest which bug thread it is for the people with the *same*> random hangs as the cstate bug but for CPUs other than the Bay Fail?> > I've tried Xubuntu 16.04, 16.04.1, and 16.04.2 and all the kernels> available, including the latest mainline ones. Same result. If I leave my> machine running at some point it will freeze and nothing but a hard power> off will solve it. Unfortunately, doing that has corrupted the file system> twice and required reinstallation because fsck wasn't able to resolve it.Just for the heck of it why don't you try to load the kernel with intel_idle.max_cstate=1 and see if it helps to avoid freezing while you gather more info about i3-3110 specific issues. You might be onto something.The typical issues that I personally experienced with Ivy Bridge CPUs (not exactly your model) were graphics and USB related.

I have a laptop with a 2nd generation Intel i3 CPU (Ivy Bridge i3-3110) and ever since I installed Ubuntu 16.04 I have been have random freezes as well. But the thread suggests that with my CPU it is *not* the cstate bug. Can anyone suggest which bug thread it is for the people with the *same* random hangs as the cstate bug but for CPUs other than the Bay Fail?I've tried Xubuntu 16.04, 16.04.1, and 16.04.2 and all the kernels available, including the latest mainline ones. Same result. If I leave my machine running at some point it will freeze and nothing but a hard power off will solve it. Unfortunately, doing that has corrupted the file system twice and required reinstallation because fsck wasn't able to resolve it.

(there is no way to remove the repost that somehow happened?)@Hal, thanks. Yes, I am testing the cstate=1 solution but like the Bay Fail bug, whatever it is that affects the i3-3110 CPU is also *very random*. I could get 24 hours before a freeze or a couple of days. I suspect it is an Intel graphics driver bug, as you suggested. If I have no luck with the cstate=1 solution I will try rolling back to a pre-Ubuntu 16.04 kernel. I look back fondly and remember when my machine could run for weeks or months without a restart! Then came 16.04

slumbergod, (In reply to slumbergod from comment #788)As Andred posed above:> However, I fear (and has already been mentioned in earlier comments) this bug > report has long since lost any usefulness it might have once had and has just > turned into a dumping ground for random comments and updates and now reads> like > some web forum threadThis is not a support form. Please have some respect for others and stop SPAMing us with your unrelated issues.

Hi.It is very difficult to keep up.Could please someone summarize and clarify the current status of this bug?Please correct me if the following observations are wrong:- the symptom is known, but not the root cause.- for some reason, the bug does not affect Windows 10, but it affects Linux.- the bug affects 4-core Bay Trail CPUs, but not 2-core Bay Trail CPUs.- there is a workaround setting (the original subject of this bug) which is detrimental to battery runtime.- there is a workaround patch (by Mika), some users of the patch report that it makes things better, others still report crashes.- all in all, the bug is still unresolved.Thanks for clarifying.Thanks to everyone for their hard work on this bug, it is very appreciated. (I can't wait to use the cute little Bay Trail machine I have lying around here for my kids.)

Hi Luke, here's a big huge FUCK YOU for being A FUCKING ASSHOLE!!Go spam yourself you social rejects.

Sorry for asking again, but a clarification on the current status of this bug would be very much appreciated. See comment 790 on https://bugzilla.kernel.org/show_bug.cgi?id=109051#c790Thank you.

(In reply to Hanno Zulla from comment #790)> > - there is a workaround patch (by Mika), some users of the patch report that> it makes things better, others still report crashes.> The v3 patch was mainstreamed into 4.11-rc4 and has been back-ported into 4.9 and 4.10.  For my system, the original patch is effective in 4.9.25 and 4.10.13, but v3 (mainstreamed) patch is not.  Neither patch works for me in 4.11-rc8+, only setting .._cstate=1 will stop freezing.  (Asus T100-CHI Z3775)The lack of any other reports of continued freezing (that can still be fixed with .._cstate=1) suggest that the v3 patch might be sufficient for most users.

Hi,Thanks for the update, it was unclear to me and I guess others that the patch landed there.I wonder if it fixed most peoples issues, but any is a plus I would say.I am also wondering about status here because I still have the issue.Mika, can you let us know if you want to continue investigating the maxcpus path for the people affected?I am happy to contribute, but I would like to know if this will continue.My issue like some others, seems to be related to wireless/bluetooth and power management.I was hoping that these issues can also be fixed with current feedback and as posted before, I am happy to test!

I've been testing 4.11.0 (Ubuntu's compile) on my Zotac (ZBOX-CI320NANO with Intel Celeron N2930) as I gathered that some patched were applied to it.Without cstate=1 it freezes within 4 to 4.5 hours, no matter the workload. So, not out of the woods yet...Hal

correction:  The original c-state patch DOES stop freezing in 4.11.0.  There were other changes made about the same time as the v3 patch that interfere with applying the original patch.  Those other changes are probably the problem rather than the v3 patch itself, but I leave that to the experts to ponder.

Using kernel 4.10.14 from ubuntu on xubuntu 16.04.2 asus x453m laptop with intel baytrail, I'm running fine for several days now without any patch or workaround from cstate. I have tried both powersave and performance governor and still working fine on full load conditions.TL:DR; I assume this has been already fixed with 4.10.14 (ubuntu)

Fix is overstatement. As the commit message notes, we have only a workaroundthat only helps on some cases.One intresting datapoint is that with my J1900 using kernel param 'nohz=off' hangs the system in very short time.