On 03/04/2014 17:20, Gleb Klochkov wrote: > Hi everybody, and thank you all! > Excuse me, I did not answer for a long time. > The problem is fixed for now. I delete all old kernels initrd and configs. > The only question now is: why just upgrade to new kernel don`t fix it. > For new kernel it should use default config, shouldn`t it?
Please don't top post. It messes with people's mail apps. The kernel is self-contained. You can have 1 or 100 kernels in /boot, the only one that applies is the one you booted with. The other 99 have exactly zero influence over the one that is running. The config settings to kernel is built with are whatever you told it to use. If you don;t run *config at all, then the default settings are used. If it builds and runs, then it built and ran. The default config is nothing special, it's just a config. So that's not it, and it's not some magic influence. Most likely you had stuff mixed up in /boot and the image you booted from is not the one you thought you booted from. Or the initrd is out of sync. Something like that - it will be human error. I'll say it again because it is important - there is no magic interaction between kernel images and you can have as many as you want. There's another possibility: some userspace app on your system was the real problem and you updated it meanwhile, fixing things. You also deleted old kernels and now wrongly think that is what fixed it. > > > -------------------- > С уважением, Клочков Глеб > > > 2014-03-21 14:31 GMT+04:00 Volker Armin Hemmann > <[email protected] <mailto:[email protected]>>: > > Am 20.03.2014 11:24, schrieb Tom Wijsman: > > On Thu, 20 Mar 2014 11:39:58 +0400 > > Gleb Klochkov <[email protected] <mailto:[email protected]>> > wrote: > > > >> Tom, thank you for your answer. > >> > >> $ dmesg >> http://bpaste.net/show/187533/ > > There this can be seen: > > > > [ 18.074574] [drm] Wrong MCH_SSKPD value: 0x16040307 > > [ 18.074575] [drm] This can cause pipe underruns and display > > issues. > > [ 18.074575] [drm] Please upgrade your BIOS to fix this. > > [ 18.148162] [drm] GMBUS [i915 gmbus vga] timed out, falling > back > > to bit banging on pin 2 > > > > Above your messages seem interesting; some expected value is wrong, it > > also times out on a bus and then goes to use a pin instead. Not sure > > how much of this is intended, but try to upgrade your BIOS as > suggested. > > > >> $ cat /proc/interrupts >> http://bpaste.net/show/187537/ > > So, that would be this: > > > > 8: 63 0 0 0 IO-APIC-edge rtc0 > > > > Hmm, nothing about it in the dmesg; also, 63 seems low (on my system, > > however, it's only 1 as I think my system uses something different). > > > > You can try a different timer using this kernel parameter: > > > > clocksource=hpet > > > > Another note-worthy thing: > > > > 9: 699799454 0 0 0 IO-APIC-fasteoi acpi > > > > That there are ~700 million ACPI interrupts seems abnormally high; > > maybe the count is off by one, and 8 refers to 9? On my system, that's > > been running for a while by now, it's only at ~6000 (six thousand). > > uptime > 11:29:37 up 49 days, 15:48, 16 users, load average: 0,38, 0,31, 0,39 > > 8: 0 0 0 48 IO-APIC-edge > rtc0 > 9: 0 0 0 0 IO-APIC-fasteoi > acpi > > > > > > Changing the ACPI related kernel parameters to try to get it supported > > differently might be one thing to do here; other than that, it > might be > > something going on with the hardware (try disconnecting things?) > so the > > BIOS upgrade is certainly of interest. > > > > Try the BIOS upgrade first, then play around with the parameters; if > > things don't work out, I suggest you look for support on one of the > > Linux kernel mailing lists (perhaps acpi-devel*). Good luck. > > > > * https://lists.sourceforge.net/lists/listinfo/acpi-devel > > > imho he should first use a recent VANILLA kernel. 2.12 or 2.13. > > And build a config without all that unneeded garbage. Also increase the > dmesg buffer. Most interesting stuff is missing. > > -- Alan McKinnon [email protected]
