Bug#689268: Success with 3.2.0-4.drm-amd64
I use this kernel with success (or without freeze) since 3 days. On my computer : ASUSTeK P8H77-M Intel(R) Core(TM) i7-3770 Intel HD4000 Thanks !! --- Sebseb01
Bug#689268: linux-image-3.2.0-3-amd64: Intel HD 4000 (Ivy Bridge) graphics freeze
I had a similar issue as described in this bug. I recently installed debian wheezy on a thinkpad x230. As far as I know I use the same i915 module. I'm using amd64 system and my cpu is Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz My system would freeze sometimes. When it did, I wasn't able to move the mouse, write or anything. Trying to access through ssh didn't work either. My only alternative was to forcebly restart the system. When the system was back up there was no error log on /var/log/syslog, /var/log/dmesg or /var/log/kern.log. It didn't write anything it wouldn't normally write other times on the moment of the freeze. I installed linux 3.7 from experimental and my computer has not frozen since. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689268: Bug#692234: Processed: severity of 689268 is important
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 26.01.2013 23:37, schrieb Ben Hutchings: Julien Cristau prepared some packages for testing before we make this change. Here's how you would install them with APT: gpg --no-default-keyring --keyring /usr/share/keyrings/debian-keyring.gpg --export 310180050905E40C | apt-key add - echo deb http://people.debian.org/~jcristau/wheezy-drm34/ ./ /etc/apt/sources.list.d/jcristau-wheezy-drm34.list apt-get update apt-get install linux-image-3.2.0-4.drm-amd64 # or -486, or -686-pae Please test and send your results (good or bad) to 687...@bugs.debian.org I already posted here several weeks ago: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=692234#433 that I cannot test without the matching linux-header package! This headers are still missing in his repo. I'll test as soon as headers are available - please let me know. /Ingo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlEFDI8ACgkQx2YcFfrwLxMAUACfQ/9YomlVoJk1V1+YBfrMo+Op AckAnA1XiU/xGlRnoT+LV3cGhOtpK6XV =I+mX -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689268: Bug#692234: Processed: severity of 689268 is important
On Sat, 2013-01-26 at 19:48 +0100, Ingo wrote: Am 26.01.2013 19:06, schrieb Debian Bug Tracking System: Processing commands for cont...@bugs.debian.org: severity 689268 important Bug #689268 [src:linux] linux-image-3.2.0-3-amd64: Intel HD 4000 (Ivy Bridge) graphics freeze Bug #692234 [src:linux] Intel DH77EB (H77): sporadic freeze and increased power consumption during interactive use Bug #692500 [src:linux] [linux-image-amd64] system freezes with Ivy Brigde CPU Bug #692862 [src:linux] linux-image-3.2.0-4-amd64: hangs with Intel i5-3210M CPU / Intel HD 4000 graphics Severity set to 'important' from 'serious' Severity set to 'important' from 'serious' Severity set to 'important' from 'serious' Severity set to 'important' from 'serious' thanks Stopping processing here. Please contact me if you need assistance. Does that really mean that this bug is going to be released with Wheezy? If yes, this means Wheezy should not be installed on Ivy-Bridge systems with HD4000. I'm not going to insist that it's a blocker for the release though I will be very disappointed if we don't fix it. I think we will. Wouldn't it be a feasible alternative to accept kernel 3.4.x as an alternative in the repository (besides Wheezy's 3.2)? 3.4 is a long term kernel and well maintained by Greg K-H.. I am currently on 3.4.25 from kernel.org which is distributed by openSuse as well. It runs flawlessly on said hardware and does not show any incompatibilities with any Wheezy-component here. We can't support two different kernel versions but we can potentially update the DRM drivers to the versions in Linux 3.4.y. This is covered by bug #687442 which I've marked as blocking this bug. Julien Cristau prepared some packages for testing before we make this change. Here's how you would install them with APT: gpg --no-default-keyring --keyring /usr/share/keyrings/debian-keyring.gpg --export 310180050905E40C | apt-key add - echo deb http://people.debian.org/~jcristau/wheezy-drm34/ ./ /etc/apt/sources.list.d/jcristau-wheezy-drm34.list apt-get update apt-get install linux-image-3.2.0-4.drm-amd64 # or -486, or -686-pae Please test and send your results (good or bad) to 687...@bugs.debian.org I did nort yet install 3.4.26 which appearently got a major backport of Intel's drm/i915 - 25 commits in total. Most of those are bug fixes that we already had and that Julien requested for 3.4.y. Ben. -- Ben Hutchings Any smoothly functioning technology is indistinguishable from a rigged demo. signature.asc Description: This is a digitally signed message part
Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze
Le samedi 19 janvier 2013 à 19:23 +0100, Vincent Blut a écrit : Am 10.01.2013 09:39, schrieb Riku Voipio: getting hangs on anything other than the Debian 3.2.32-1 has been challenging. If if's just timing based, I might just have been lucky during my bisects. Here vanilla 3.4.24 from kernel.org runs absolutely stable since a few weeks. But me came up another idea: 'modinfo i916' list an option which appears to be a watchdog function: parm: enable_hangcheck:Periodically check GPU activity for detecting hangs. WARNING: Disabling this can cause system wide hangs. (default: true) (bool) which actually describes the symptoms. Could it be that in the Debian-kernel either the hangs are not detected securely, or that it just fails to reset the module? /Ingo Hi guys, Well I have the same issue on my Ivybridge system: $ lspci -nnv | grep VGA 00:02.0 VGA compatible controller [0300]: Intel Corporation 3rd Gen Core processor Graphics Controller [8086:0166] (rev 09) (prog-if 00 [VGA controller]) $ cat /var/log/Xorg.0.log | grep Graphics Chipset […] [ 8.388] (II) intel(0): Integrated Graphics Chipset: Intel(R) Ivybridge Mobile (GT2) On my system I observed this behavior: Debian 3.2.35-2: random hangs (at least one per day) Upstream 3.2.37: random hangs (at least one per day) Upstream 3.3-rc1+: no hangs (tested for 2 weeks) So that seems to be close to Riku's experience. Anyway what strikes me a bell is the last Ingo's comment about 'enable_hangcheck' module parameter which was introduced in v3.1-rc1: $ git tag --contains 6e96e7757a01 v3.1-rc1 […] v3.8-rc4 So I peeked about what kind of hangcheck changes could have been introduced in v3.3-rc1 and I found an interesting patch: commit e6bfaf854272ec4641a9ef7b1cb1ca963031ba95 drm/i915: don't bail out of intel_wait_ring_buffer too early The commit message is particularly interesting! I'll give it a try but if someone could beat me to it that would be cool (ULV CPU here). Unfortunately this commit has no positive effect! I got two freezes in less than 15 minutes, so I set up an SSH connection in order to catch some logs but after an uptime of 5h30 the system froze… the NIC too so absolutely nothing useful to report :-( Cheers, Vincent PS: Also, could you give a try to Julien Cristau's kernel images with DRM/KMS subsystem backported from 3.4 which might hit Wheezy? http://people.debian.org/~jcristau/linux-image-3.2.0-4.drm-amd64_3.2.35-3~jcristau.1_amd64.deb sha1sum f6711fe6d0d924aab82ec82fe1a86102a69a8c32 (There are i686 and i486 flavours if you want) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze
Am 10.01.2013 09:39, schrieb Riku Voipio: getting hangs on anything other than the Debian 3.2.32-1 has been challenging. If if's just timing based, I might just have been lucky during my bisects. Here vanilla 3.4.24 from kernel.org runs absolutely stable since a few weeks. But me came up another idea: 'modinfo i916' list an option which appears to be a watchdog function: parm: enable_hangcheck:Periodically check GPU activity for detecting hangs. WARNING: Disabling this can cause system wide hangs. (default: true) (bool) which actually describes the symptoms. Could it be that in the Debian-kernel either the hangs are not detected securely, or that it just fails to reset the module? /Ingo Hi guys, Well I have the same issue on my Ivybridge system: $ lspci -nnv | grep VGA 00:02.0 VGA compatible controller [0300]: Intel Corporation 3rd Gen Core processor Graphics Controller [8086:0166] (rev 09) (prog-if 00 [VGA controller]) $ cat /var/log/Xorg.0.log | grep Graphics Chipset […] [ 8.388] (II) intel(0): Integrated Graphics Chipset: Intel(R) Ivybridge Mobile (GT2) On my system I observed this behavior: Debian 3.2.35-2: random hangs (at least one per day) Upstream 3.2.37: random hangs (at least one per day) Upstream 3.3-rc1+: no hangs (tested for 2 weeks) So that seems to be close to Riku's experience. Anyway what strikes me a bell is the last Ingo's comment about 'enable_hangcheck' module parameter which was introduced in v3.1-rc1: $ git tag --contains 6e96e7757a01 v3.1-rc1 […] v3.8-rc4 So I peeked about what kind of hangcheck changes could have been introduced in v3.3-rc1 and I found an interesting patch: commit e6bfaf854272ec4641a9ef7b1cb1ca963031ba95 drm/i915: don't bail out of intel_wait_ring_buffer too early The commit message is particularly interesting! I'll give it a try but if someone could beat me to it that would be cool (ULV CPU here). Cheers, Vincent PS: Also, could you give a try to Julien Cristau's kernel images with DRM/KMS subsystem backported from 3.4 which might hit Wheezy? http://people.debian.org/~jcristau/linux-image-3.2.0-4.drm-amd64_3.2.35-3~jcristau.1_amd64.deb sha1sum f6711fe6d0d924aab82ec82fe1a86102a69a8c32 (There are i686 and i486 flavours if you want) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689268:
I think I am having the same issue here with Ivy Bridge. Recently got a new machine and running Ubuntu 12.10 (Quantal), I was on Wheezy before with the same issue. Using the standard kernel I was getting system lock-ups with the screen going corrupted and no input possible at all. I've followed this thread through trying out various different options with boot parameters (mtrr) and also have now got the system on the Liquorix 3.7.x kernel. Same crashes. It happens when there is user input, I can leave the machine run without touching it and it will be ok, but when I interact I'll randomly get a crash. These could be minutes apart, or hours. But right now are inevitable. I'm fairly technical, but not a kernel hacker, I'm quite comfortable compiling etc. So if there is anything I can try or add, then please let me know. Here are a few system details: Processor: Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz Memory: 32GB Chipset: $ uname -a Linux xpc 3.7.0-2.dmz.1-liquorix-amd64 #1 ZEN SMP PREEMPT Sun Jan 13 02:36:06 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux Kernel command line: BOOT_IMAGE=/vmlinuz-3.7.0-2.dmz.1-liquorix-amd64 root=/dev/mapper/vg-root ro rootdelay=10 mtrr_gran_size=8M mtrr_chunk_size=32M quiet splash vt.handoff=7 $ lsmod | grep i915 i915 554526 3 drm_kms_helper 39225 1 i915 drm 266634 4 i915,drm_kms_helper intel_agp 11514 1 i915 i2c_algo_bit5854 1 i915 intel_gtt 16817 2 i915,intel_agp i2c_core 26223 4 i915,drm_kms_helper,drm,i2c_algo_bit video 12284 1 i915 button 5368 1 i915 $ lspci 00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor DRAM Controller (rev 09) 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller (rev 09) 00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller (rev 04) 00:16.0 Communication controller: Intel Corporation 7 Series/C210 Series Chipset Family MEI Controller #1 (rev 04) 00:1a.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #2 (rev 04) 00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series Chipset Family High Definition Audio Controller (rev 04) 00:1c.0 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 1 (rev c4) 00:1c.6 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 7 (rev c4) 00:1d.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #1 (rev 04) 00:1f.0 ISA bridge: Intel Corporation Z77 Express Chipset LPC Controller (rev 04) 00:1f.2 SATA controller: Intel Corporation 7 Series/C210 Series Chipset Family 6-port SATA Controller [AHCI mode] (rev 04) 00:1f.3 SMBus: Intel Corporation 7 Series/C210 Series Chipset Family SMBus Controller (rev 04) 02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 06) Paul -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze
Hi Paul, Paul C wrote: I think I am having the same issue here with Ivy Bridge. [...] I've followed this thread through trying out various different options with boot parameters (mtrr) and also have now got the system on the Liquorix 3.7.x kernel. Same crashes. That doesn't match Per's experience --- he found that 3.5.5 already worked fine. Would you mind filing a new bug? We can always merge them later if they turn out to have the same cause. Thanks, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689268: linux-image-3.2.0-3-amd64: Intel HD 4000 (Ivy Bridge) graphics freeze
Hi, Hm, I'm a little confused. Are you sure 3.3-rc1 is not affected, and if not, why bisect between 3.2 and 3.3-rc1 instead of -rc6? What git tree are you using to bisect the Debian kernel? So far, the status seems: Debian3.2.32-1: hang in few hours of use Upstream 3.3-rc1 ... 3.3 no hang ever observed so far Debian3.2.35-2: hang once a week or so (2 hangs so far) getting hangs on anything other than the Debian 3.2.32-1 has been challenging. If if's just timing based, I might just have been lucky during my bisects. Riku -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689268: linux-image-3.2.0-3-amd64: Intel HD 4000 (Ivy Bridge) graphics freeze
Am 10.01.2013 09:39, schrieb Riku Voipio: getting hangs on anything other than the Debian 3.2.32-1 has been challenging. If if's just timing based, I might just have been lucky during my bisects. Here vanilla 3.4.24 from kernel.org runs absolutely stable since a few weeks. But me came up another idea: 'modinfo i916' list an option which appears to be a watchdog function: parm: enable_hangcheck:Periodically check GPU activity for detecting hangs. WARNING: Disabling this can cause system wide hangs. (default: true) (bool) which actually describes the symptoms. Could it be that in the Debian-kernel either the hangs are not detected securely, or that it just fails to reset the module? /Ingo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689268: Has this bug been fixed?
I still have this same problem using the latest CD image generated (24th December). This is preventing me from upgrading to Wheezy. How can I solve this problem? -- timd -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze
On Wed, Dec 05, 2012 at 07:39:01AM -0800, Jonathan Nieder wrote: Riku Voipio wrote: On Wed, Nov 28, 2012 at 07:52:51AM -0800, Jonathan Nieder wrote: If you can bisect to find the first unaffected kernel between 3.2 and 3.3-rc6 as described at [1], that would be excellent. Thanks much for your work. I have now been bisecting (I skipped the drm tree reset, this is bisect between 3.2 and 3.3-rc1) for one week, and so far only seen hangs on on the debian kernel. Hm, I'm a little confused. Are you sure 3.3-rc1 is not affected, and if not, why bisect between 3.2 and 3.3-rc1 instead of -rc6? What git tree are you using to bisect the Debian kernel? Now I've had comple of days with the debian 3.2.19-1 and no crashes either. Sigh, I notice I had i915.i915_enable_rc6=0 drm.debug=0x06 set in etc/default/grub. I remember some crashed with i915.i915_enable_rc6=0, so perhaps it's the debug prints that drive the timing off enough to hide the crash. Lets clear the command line and see if I can get crashes back... Riku -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689268: linux-image-3.2.0-3-amd64: Intel HD 4000 (Ivy Bridge) graphics freeze
On Wed, Nov 28, 2012 at 07:52:51AM -0800, Jonathan Nieder wrote: If you can bisect to find the first unaffected kernel between 3.2 and 3.3-rc6 as described at [1], that would be excellent. Thanks much for your work. I have now been bisecting (I skipped the drm tree reset, this is bisect between 3.2 and 3.3-rc1) for one week, and so far only seen hangs on on the debian kernel. While I continue this, someone else could try vanilla 3.2 and 3.2.23 in case this is a bug introduced in stable series. Riku [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=400;bug=692234 https://bugs.freedesktop.org/56333#c5 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze
Riku Voipio wrote: On Wed, Nov 28, 2012 at 07:52:51AM -0800, Jonathan Nieder wrote: If you can bisect to find the first unaffected kernel between 3.2 and 3.3-rc6 as described at [1], that would be excellent. Thanks much for your work. I have now been bisecting (I skipped the drm tree reset, this is bisect between 3.2 and 3.3-rc1) for one week, and so far only seen hangs on on the debian kernel. Hm, I'm a little confused. Are you sure 3.3-rc1 is not affected, and if not, why bisect between 3.2 and 3.3-rc1 instead of -rc6? What git tree are you using to bisect the Debian kernel? Curious, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689268: linux-image-3.2.0-3-amd64: Intel HD 4000 (Ivy Bridge) graphics freeze
On 2012-11-28 16:45, Riku Voipio wrote: Is there any updates since early november? I have a Ivy bridge PC now with PH8H77-V LE motherboard and 3570K cpu showing the mentioned symptomps. I can work on bisecting the issue if nobody else is already on it. I have been running the kernel mentioned above (3.3 with drm from 3.2) for 25 days now without any problems. /Per -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze
Per Foreby wrote: On 2012-11-28 16:45, Riku Voipio wrote: Is there any updates since early november? I have a Ivy bridge PC now with PH8H77-V LE motherboard and 3570K cpu showing the mentioned symptomps. I can work on bisecting the issue if nobody else is already on it. I have been running the kernel mentioned above (3.3 with drm from 3.2) for 25 days now without any problems. Yep, thanks much for that. That means that the symptom relief comes from a change outside the drm tree. If you run git reset --hard then you should be back on 3.3 again, and the instructions from [1] can narrow it down from there. Jonathan [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=400;bug=692234 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689268: linux-image-3.2.0-3-amd64: Intel HD 4000 (Ivy Bridge) graphics freeze
Hi, Is there any updates since early november? I have a Ivy bridge PC now with PH8H77-V LE motherboard and 3570K cpu showing the mentioned symptomps. I can work on bisecting the issue if nobody else is already on it. Riku -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689268: linux-image-3.2.0-3-amd64: Intel HD 4000 (Ivy Bridge) graphics freeze
Riku Voipio riku.voi...@iki.fi wrote: Is there any updates since early november? I have a Ivy bridge PC now with PH8H77-V LE motherboard and 3570K cpu showing the mentioned symptomps. I can work on bisecting the issue if nobody else is already on it. If you can bisect to find the first unaffected kernel between 3.2 and 3.3-rc6 as described at [1], that would be excellent. Thanks much for your work. Sincerely, Jonathan [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=400;bug=692234 https://bugs.freedesktop.org/56333#c5 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze
On 2012-11-03 09:14, Jonathan Nieder wrote: Could you try 3.3~rc6-1~experimental.1? (I expect it will also work fine, but there's always a chance that we could get lucky and narrow down the range by a lot.) As you expected, two days without problems. If it works ok, here are instructions for testing 3.3-rc6 with drm code from 3.2: 0. prerequisites apt-get install git build-essential 1. get the kernel history, if you don't already have it git clone \ git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 2. configure, build, test cd linux git checkout v3.3-rc6 cp /boot/config-$(uname -r) .config; # current configuration scripts/config --disable DEBUG_INFO make localmodconfig; # optional: minimize configuration make deb-pkg; # optionally with -jnum for parallel build dpkg -i ../name of package; # as root reboot Hopefully it works fine. So 3. try drm code from 3.2 cd linux git checkout v3.2 -- include/drm drivers/gpu/drm make deb-pkg; # maybe with -j4 dpkg -i ..name of package; # as root reboot Hopefully it reproduces the bug. Unfortunately this has so far been stable for two days. I'll keep running it to see if the bug just takes longer to show with this combo. /Per -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze
found 689268 linux/3.2.32-1 fixed 689268 linux/3.3.6-1~experimental.1 , linux/3.5.5-1~experimental.1 quit Per Foreby wrote: I've been running 3.3.6-1~experimental.1 for 10 days without problems. Just tried 3.2.32-1 and the system froze after 18 minutes. Now back on 3.3. Perfect. Marking so. Could you try 3.3~rc6-1~experimental.1? (I expect it will also work fine, but there's always a chance that we could get lucky and narrow down the range by a lot.) If it works ok, here are instructions for testing 3.3-rc6 with drm code from 3.2: 0. prerequisites apt-get install git build-essential 1. get the kernel history, if you don't already have it git clone \ git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 2. configure, build, test cd linux git checkout v3.3-rc6 cp /boot/config-$(uname -r) .config; # current configuration scripts/config --disable DEBUG_INFO make localmodconfig; # optional: minimize configuration make deb-pkg; # optionally with -jnum for parallel build dpkg -i ../name of package; # as root reboot Hopefully it works fine. So 3. try drm code from 3.2 cd linux git checkout v3.2 -- include/drm drivers/gpu/drm make deb-pkg; # maybe with -j4 dpkg -i ..name of package; # as root reboot Hopefully it reproduces the bug. If that works, we'll be ready to run a reverse bisect on the drm code like Daniel suggested. Thanks again for your patient efforts on this. Sorry it has been taking so long. Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze
Am 03.11.2012 09:14, schrieb Jonathan Nieder: found 689268 linux/3.2.32-1 fixed 689268 linux/3.3.6-1~experimental.1 , linux/3.5.5-1~experimental.1 quit Just a proposal: is it possible to apply this patch from Intel to the 3.2 kernel: http://lists.freedesktop.org/archives/intel-gfx/2012-February/015005.html? This would allow to figure out by manually activating different rc6 states whether rc6 implementation is the root cause. From kernel 3.3 on the settings and default beheavior of the parameter i915_enable_rc6 have changed. Wheezy's 3.2 kernel does not include this patch according to 'modinfo i915' Ingo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze
Ingo wrote: Just a proposal: is it possible to apply this patch from Intel to the 3.2 kernel: http://lists.freedesktop.org/archives/intel-gfx/2012-February/015005.html? This would allow to figure out by manually activating different rc6 states whether rc6 implementation is the root cause. What happens if you use i915.i915_enable_rc6=0 with the stock kernel? If that doesn't work, I doubt other modes (which are only more aggressive about power management) will. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze
Ingo wrote: Am 03.11.2012 21:05, schrieb Jonathan Nieder: Ingo wrote: I did set it now to 0 and suprisingly power consumption does not change by a single watt in both cases: idle desktop and graphics/monitor off by DPMS. I'll leave it now like this and see - last time it took 3 weeks until the freeze happend. I'll report here again if any freeze happens. Thanks. Do you mind if I forward this information to the bug log? Please go ahead, thanks. [...] linux-2.6 (3.2.7-1) unstable; urgency=low * [x86] drm/i915: do not enable RC6p on Sandy Bridge (Closes: #660265) What about Ivy Bridge - that's what me and Per are using. Is there anwhere a table on which devices which rc6 states are enabled? From drivers/gpu/drm/i915/intel_display.c: | static bool intel_enable_rc6(struct drm_device *dev) | { | /* |* Respect the kernel parameter if it is set |*/ | if (i915_enable_rc6 = 0) | return i915_enable_rc6; | | /* |* Disable RC6 on Ironlake |*/ | if (INTEL_INFO(dev)-gen == 5) | return 0; | | /* |* Disable rc6 on Sandybridge |*/ | if (INTEL_INFO(dev)-gen == 6) { | DRM_DEBUG_DRIVER(Sandybridge: RC6 disabled\n); | return 0; | } | DRM_DEBUG_DRIVER(RC6 enabled\n); | return 1; | } [...] | if (intel_enable_rc6(dev_priv-dev)) | rc6_mask = GEN6_RC_CTL_RC6_ENABLE | | ((IS_GEN7(dev_priv-dev)) ? GEN6_RC_CTL_RC6p_ENABLE : 0); Ivy Bridge is gen7. So RC6p is not masked out by default, and setting i915_enable_rc6=0 will mask it out along with RC6. If you pass drm.debug=0x2 (or anything with that bit set, such as 0xe) on the kernel command line then you can tell if RC6 is enabled by looking for an RC6 enabled line in the kernel log. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze
Jonathan Nieder wrote: Hi Ingo, [...] There seem to be some differences in symptoms here, so please file a separate bug. We can merge them later if they turn out to have the same cause. I've assigned you bug#692234. Please attach output from reportbug --template linux-image-$(uname -r) so we can get to know your hardware better. Thanks, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze
On 2012-10-24 02:39, Jonathan Nieder wrote: Hi Per, Per Foreby wrote: Just to clear some confusion: In a previous comment you suggested trying 3.2.30-1 first (which seems to have been replaced by 3.2.32-1 a few days ago). So what should I try, and in what order? I have downloaded the following packages: linux-image-3.2.0-4-amd64_3.2.30-1_amd64.deb linux-image-3.2.0-4-amd64_3.2.32-1_amd64.deb linux-image-3.3.0-trunk-amd64_3.3.6-1~experimental.1_amd64.deb linux-image-3.4-trunk-amd64_3.4.4-1~experimental.1_amd64.deb Good question, thanks. 3.3.6 first. If it works, the newest 3.2.y kernel available would come next. If it doesn't work, 3.4.4 would come next. I've been running 3.3.6-1~experimental.1 for 10 days without problems. Just tried 3.2.32-1 and the system froze after 18 minutes. Now back on 3.3. /Per -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze
Just a little bit of info I found reading the last changes to the X intel driver: Release 2.20.9 (2012-09-29) === And so it came to pass that a critical bug was uncovered in UXA. The kernel does not like to pageflip when the pipe is off, yet due to the delayed nature of a pageflip and the relaxed checking performed by UXA, we could request a pageflip after turning off the display (DPMS). The kernel rejected that pageflip and the error handling path failed to restore sanity, and when the screen came back it was stuck on the image seen before it went to sleep. (Note that there are also some related kernel bugs, but this update should prevent the most conspicious of the freezes.) Many thanks to Timo Aaltonen for his efforts in tracking down the issue. [...] This is not the kernel bug, but the graphics bug. However, maybe is not a bad idea to upgrade the X driver and see what happen with 3.2.x. -- Saludos de Javier jcant...@escomposlinux.org signature.asc Description: Digital signature
Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze
Am 24.10.2012 02:39, schrieb Jonathan Nieder: Hi Per, Per Foreby wrote: Just to clear some confusion: In a previous comment you suggested trying 3.2.30-1 first (which seems to have been replaced by 3.2.32-1 a few days ago). So what should I try, and in what order? I have downloaded the following packages: What I just found in the german Debian Forum https://debianforum.de/forum/viewtopic.php?f=26t=137332 is the same observed on a ThinkPad T430 with a i5-3320M 2.60 GHz, HD4000 graphics and Wheezy (reported 2012-07-26) - translated into English: ... to avoid *priodic freezes* I updated the kernel to 3.4.4-1 from experimental ... Meanwhile the author has updated to kernel 3.5.5-1-amd64 and all appears still fine. Just my 2 cents, Ingo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze
I am back and join the injured. today I again had the known freeze after 3 weeks of freedom with 256MB GPU-RAM BIOS setting. So my remedy did not cure the root cause. I now installed kernel 3.5.5-1 from experimental - let's see. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze
On 2012-10-22 00:00, Jonathan Nieder wrote: Oh, right --- I had forgotten. I think we should still move upstream after the experiment with vesa, though, and just be sure to mention which kernels were tried and what happened with each. Instructions for reporting are here: http://intellinuxgraphics.org/how_to_report_bug.html When doing so, please let us know the bug number so we can track it. I hate to sound like a broken record, but I still have no reason to believe the mtrr stuff is not a red herring. https://bugs.freedesktop.org/show_bug.cgi?id=56333 /Per -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze
Per Foreby wrote: On 2012-10-22 00:00, Jonathan Nieder wrote: Oh, right --- I had forgotten. I think we should still move upstream after the experiment with vesa, though, and just be sure to mention which kernels were tried and what happened with each. [...] https://bugs.freedesktop.org/show_bug.cgi?id=56333 Thanks again for your help and patience. Could you try 3.3 next? That would narrow down the search for the fix by quite a bit. Sincerely, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze
On 2012-10-23 22:10, Jonathan Nieder wrote: Per Foreby wrote: On 2012-10-22 00:00, Jonathan Nieder wrote: Oh, right --- I had forgotten. I think we should still move upstream after the experiment with vesa, though, and just be sure to mention which kernels were tried and what happened with each. [...] https://bugs.freedesktop.org/show_bug.cgi?id=56333 Thanks again for your help and patience. Could you try 3.3 next? That would narrow down the search for the fix by quite a bit. The upstream comments are just what I exepcted, and what I'm used to in my 25 years as a system manager: don't bother reporting anything unless you're on the latest and greatest release or have paid support. Which is very understandable. I'll give the suggested kernels a try to narrow down the problem. And I'll stay on 64 MB graphics memory since that seems to trigger the problem faster. /Per -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze
On 2012-10-23 23:45, Per Foreby wrote: Thanks again for your help and patience. Could you try 3.3 next? That would narrow down the search for the fix by quite a bit. Just to clear some confusion: In a previous comment you suggested trying 3.2.30-1 first (which seems to have been replaced by 3.2.32-1 a few days ago). So what should I try, and in what order? I have downloaded the following packages: linux-image-3.2.0-4-amd64_3.2.30-1_amd64.deb linux-image-3.2.0-4-amd64_3.2.32-1_amd64.deb linux-image-3.3.0-trunk-amd64_3.3.6-1~experimental.1_amd64.deb linux-image-3.4-trunk-amd64_3.4.4-1~experimental.1_amd64.deb /Per -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze
Hi Per, Per Foreby wrote: Just to clear some confusion: In a previous comment you suggested trying 3.2.30-1 first (which seems to have been replaced by 3.2.32-1 a few days ago). So what should I try, and in what order? I have downloaded the following packages: linux-image-3.2.0-4-amd64_3.2.30-1_amd64.deb linux-image-3.2.0-4-amd64_3.2.32-1_amd64.deb linux-image-3.3.0-trunk-amd64_3.3.6-1~experimental.1_amd64.deb linux-image-3.4-trunk-amd64_3.4.4-1~experimental.1_amd64.deb Good question, thanks. 3.3.6 first. If it works, the newest 3.2.y kernel available would come next. If it doesn't work, 3.4.4 would come next. Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze
On Sun, 2012-10-21 at 16:25 +0200, Ingo wrote: Am 21.10.2012 14:20, schrieb Per Foreby: Note that this is 1023 memory banks, not 1024, so it's not exactly 64 MB (65536 kB). Maybe the reason why it almost works with 256 MB is that the kernel always thinks that we have exactly 256 MB but the Mobo supplies one memory bank less. Just a theory.. Per, me came another idea. Some postings up Ben Hutching stated: The driver calls ioremap_wc() which will enable write-combining through the PAT in recent processors. Isn't this address translation how I/O remapping (IOMMU) also called VT-d works? [...] PAT is a feature of the ordinary MMU, not an IOMMU. (The last I heard, Intel's integrated GPUs were totally incompatible with VT-d (partly because they are not normal PCIe devices). Linux therefore doesn't allow them to be in a VT-d remapping domain.) Ben. -- Ben Hutchings Humour is the best antidote to reality. signature.asc Description: This is a digitally signed message part
Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze
On 2012-10-21 04:48, Jonathan Nieder wrote: Per Foreby wrote: Next thing to try is to blacklist the i915 module, but it doesn't seem to work. This is what I did: # echo blacklist i915 /etc/modprobe.d/i915-blacklist.conf # depmod -ae -F /boot/System.map-3.2.0-3-amd64 # update-initramfs -u -k all Module still loads. Does the i915 module still load if you boot in recovery mode (kernel 'single' or 'text')? If so, please attach lsmod output and output from grep . /etc/modprobe.d/*. The module was not loaded in recovery, and when booting multiuser, lsmod shows no dependencies. I did however find a working solution in the Arch wiki (https://wiki.archlinux.org/index.php/Kernel_modules#Using_files_in_.2Fetc.2Fmodprobe.d.2F_2). So using install i915 /bin/false in blacklist.conf, the i915 module is finally gone. The output from lspci/dmsg/Xorg.0.log is still identical and indicates 256 MB, but the Vesa driver also added this to Xorg.0.log: [22.177] (II) VESA(0): Total Memory: 1023 64KB banks (65472kB) [22.200] (II) VESA(0): VESA VBE Total Mem: 65472 kB Note that this is 1023 memory banks, not 1024, so it's not exactly 64 MB (65536 kB). Maybe the reason why it almost works with 256 MB is that the kernel always thinks that we have exactly 256 MB but the Mobo supplies one memory bank less. Just a theory.. /Per -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze
Am 21.10.2012 14:20, schrieb Per Foreby: Note that this is 1023 memory banks, not 1024, so it's not exactly 64 MB (65536 kB). Maybe the reason why it almost works with 256 MB is that the kernel always thinks that we have exactly 256 MB but the Mobo supplies one memory bank less. Just a theory.. Per, me came another idea. Some postings up Ben Hutching stated: The driver calls ioremap_wc() which will enable write-combining through the PAT in recent processors. Isn't this address translation how I/O remapping (IOMMU) also called VT-d works? Per's CPU i7-3770 should support VT-d (in case the motherboard offeres it), while mine i5-3570K does not support VT-d (like all K-CPU's). Worth to try to switch off VT-d in the BIOS, Per? Ingo P.S.: I am still assuming that Per's and mine obeservations have the same root cause: some mismatch of I/O-memory areas caused by whatever, BIOS-bug, Kernel-bug or even hardware. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze
Am 21.10.2012 14:20, schrieb Per Foreby: [22.177] (II) VESA(0): Total Memory: 1023 64KB banks (65472kB) [22.200] (II) VESA(0): VESA VBE Total Mem: 65472 kB Note that this is 1023 memory banks, not 1024, so it's not exactly 64 MB (65536 kB). Maybe the reason why it almost works with 256 MB is that the kernel always thinks that we have exactly 256 MB but the Mobo supplies one memory bank less. Just a theory.. I checked here (with 256MB VideoRAM set in BIOS and i915 loaded) - all is stable now. dmesg says: ... [0.985848] agpgart-intel :00:00.0: detected 65536K stolen memory ... Don't know where they have gone or who did reserve them. Maybe thats what Intel's Dynamic Video Memory Technology (DVMT) uses? Isn't there anybody out who has more insight into this issue and could give some explanation how things should work and give hints how to pin that down? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze
Per Foreby wrote: The output from lspci/dmsg/Xorg.0.log is still identical and indicates 256 MB That could be unrelated (and since it's a symptom that has shown up in the past on machines without this bug, I don't think we should jump to conclusions). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze
Per Foreby wrote: [22.177] (II) VESA(0): Total Memory: 1023 64KB banks (65472kB) [22.200] (II) VESA(0): VESA VBE Total Mem: 65472 kB Good, it looks like the vesa driver is loading instead of the i915 driver. Can you reproduce the bug in this setup? If not, we will have shown the bug is probably in the i915 driver and we can take this upstream. Hope that helps, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze
Ingo wrote: Worth to try to switch off VT-d in the BIOS, Per? Please, before making guesses let's establish the basic facts (which kernel versions are affected and whether some particular subsystem triggers it). That will let us get help from the experts. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze
Ingo wrote: I checked here (with 256MB VideoRAM set in BIOS and i915 loaded) - all is stable now. Also, please please please file a separate report. I'm serious. It will be much easier to track the two issues, compare them when appropriate, etc that way. By not doing that, you're asking us not to consider the symptoms from your machine, which is fine, but I don't think it's what you intend. Hoping that clarifies, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze
On 2012-10-21 21:02, Jonathan Nieder wrote: Per Foreby wrote: [22.177] (II) VESA(0): Total Memory: 1023 64KB banks (65472kB) [22.200] (II) VESA(0): VESA VBE Total Mem: 65472 kB Good, it looks like the vesa driver is loading instead of the i915 driver. Can you reproduce the bug in this setup? Everything is OK so far, and I hardy notice any difference (apart from having to enable software scaling in mplayer2, but that's not a problem with an i7 3770 :) I'll give it a few days, and then I'll try enable_mtrr_cleanup. If not, we will have shown the bug is probably in the i915 driver and we can take this upstream. Or maybe not, since I didn't experience any problems on the 3.5 kernel. With 256 MB GPU memory though. /Per -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze
Per Foreby wrote: On 2012-10-21 21:02, Jonathan Nieder wrote: Good, it looks like the vesa driver is loading instead of the i915 driver. Can you reproduce the bug in this setup? Everything is OK so far, and I hardy notice any difference (apart from having to enable software scaling in mplayer2, but that's not a problem with an i7 3770 :) I'll give it a few days, Thanks again for this. and then I'll try enable_mtrr_cleanup. If not, we will have shown the bug is probably in the i915 driver and we can take this upstream. Or maybe not, since I didn't experience any problems on the 3.5 kernel. With 256 MB GPU memory though. Oh, right --- I had forgotten. I think we should still move upstream after the experiment with vesa, though, and just be sure to mention which kernels were tried and what happened with each. Instructions for reporting are here: http://intellinuxgraphics.org/how_to_report_bug.html When doing so, please let us know the bug number so we can track it. I hate to sound like a broken record, but I still have no reason to believe the mtrr stuff is not a red herring. Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze
On 2012-10-20 00:39, Per Foreby wrote: I noticed something strange with allocation of GPU RAM. In the old BIOS, the default was 64 MB, but in the new bios, Auto was default. So I set it explicitly to 64 MB. However, this is what the OS reports: # lspci -vv ... 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller (rev 09) (prog-if 00 [VGA controller]) ... Region 0: Memory at f780 (64-bit, non-prefetchable) [size=4M] Region 2: Memory at e000 (64-bit, prefetchable) [size=256M] ... # dmesg | grep aperture [0.00] Checking aperture... [1.644376] agpgart-intel :00:00.0: AGP aperture is 256M @ 0xe000 # grep -i mem /var/log/Xorg.0.log [18.557] (--) PCI:*(0:0:2:0) 8086:0162:1043:84ca rev 9, Mem @ 0xf780/4194304, 0xe000/268435456, I/O @ 0xf000/64 (268435456 is 256*1024*1024.) I changed the iGPU memory setting to 64 MB once more, and rebooted with the 3.5.5 kernel to see how much memory was reported. No change from 3.2.0 - everything still says 256 MB. Could this be the problem? As Ingo reported, his problem disappeared with 256 MB GPU memory, and for me it took much longer for the next crash to occur, so maybe it not entirely correct when using 256 MB, but enough to make the freeze very rare? And for my success (for 11 days) with the 3.5.5 kernel, maybe memory allocation works differently so it never (or more seldom) tries to access GPU memory that doesn't exist. Haven't tried 3.5.5 with 64 MB though. Back on 3.2.0 with 64 MB now to test this theory. /Per -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze
New freeze after a few hours (vanilla kernel, 64 MB GPU Memory). Next thing to try is to blacklist the i915 module, but it doesn't seem to work. This is what I did: # echo blacklist i915 /etc/modprobe.d/i915-blacklist.conf # depmod -ae -F /boot/System.map-3.2.0-3-amd64 # update-initramfs -u -k all Module still loads. Tried adding modprobe.blacklist=i915 to the kernel command line, but still no success. What am I doing wrong here? /Pre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze
Per Foreby wrote: Next thing to try is to blacklist the i915 module, but it doesn't seem to work. This is what I did: # echo blacklist i915 /etc/modprobe.d/i915-blacklist.conf # depmod -ae -F /boot/System.map-3.2.0-3-amd64 # update-initramfs -u -k all Module still loads. Does the i915 module still load if you boot in recovery mode (kernel 'single' or 'text')? If so, please attach lsmod output and output from grep . /etc/modprobe.d/*. Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze
On 2012-10-18 12:37, Ingo wrote: Per, I am still watching this issue for interest (my case I do consider as wrong BIOS setting which solved it for me). Hmm, BIOS you said. I just check my BIOS version and found that the MB was delivered with the initial BIOS version from February. Since then ASUS have release five versions, all with Improve system stability among the few lines in the changelog. Now I'm on the latest BIOS (from August) and back on the 3.2.0 kernel. To my knowledge mtrr's are still used (not by i915 as Ben Hutchings stated) and probably here certain manufacturers of boards/BIOS probably set up different configurations. Probably it ist worth to try this kernel parameter with Wheezy's standard kernel: enable_mtrr_cleanup to allow kernel to re-arrange them and see if it has any influence in your case? I will try that if I get another freeze, and if that also fails, try the vesa driver, and then work my way up in the kernel versions as suggested by Jonathan. I noticed something strange with allocation of GPU RAM. In the old BIOS, the default was 64 MB, but in the new bios, Auto was default. So I set it explicitly to 64 MB. However, this is what the OS reports: # lspci -vv ... 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller (rev 09) (prog-if 00 [VGA controller]) ... Region 0: Memory at f780 (64-bit, non-prefetchable) [size=4M] Region 2: Memory at e000 (64-bit, prefetchable) [size=256M] ... # dmesg | grep aperture [0.00] Checking aperture... [1.644376] agpgart-intel :00:00.0: AGP aperture is 256M @ 0xe000 # grep -i mem /var/log/Xorg.0.log [18.557] (--) PCI:*(0:0:2:0) 8086:0162:1043:84ca rev 9, Mem @ 0xf780/4194304, 0xe000/268435456, I/O @ 0xf000/64 (268435456 is 256*1024*1024.) I also found this ubuntu bug report: lspci reports wrong video memory size (https://bugs.launchpad.net/ubuntu/+source/pciutils/+bug/607991). Could the same thing that fools lspci also make the kernel and the i915 driver think I have more GPU memory than I actually have? On the other hand, the last freeze I had was with 256 MB configured in bios. *UPDATE* BIOS update did no good. Just had a freeze while typing this email. It only took minutes from reboot, and the trigger this time was doubleclicking the URI in firefox in an attempt to copy the launchpad link above. Now I'm back up with 256 MB GPU RAM, still on the vanilla wheezy kernel. The output from lspci/dmesg/Xorg.0.log looks exactly the same as with 64 MB. Strange. /Per -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze
Per, I am still watching this issue for interest (my case I do consider as wrong BIOS setting which solved it for me). To my knowledge mtrr's are still used (not by i915 as Ben Hutchings stated) and probably here certain manufacturers of boards/BIOS probably set up different configurations. Probably it ist worth to try this kernel parameter with Wheezy's standard kernel: enable_mtrr_cleanup to allow kernel to re-arrange them and see if it has any influence in your case? Ingo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze
Ingo wrote: Per, Forwarding to Per, thanks. I am still watching this issue for interest (my case I do consider as wrong BIOS setting which solved it for me). A report for yours would still be worthwhile, so we can try to find a workaround in the kernel for the sake of others running into the same problem. I imagine other OSes work fine with the default BIOS settings and that it would be possible for Linux to learn to as well. To my knowledge mtrr's are still used (not by i915 as Ben Hutchings stated) and probably here certain manufacturers of boards/BIOS probably set up different configurations. Probably it ist worth to try this kernel parameter with Wheezy's standard kernel: enable_mtrr_cleanup to allow kernel to re-arrange them and see if it has any influence in your case? Ingo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689268: [wheezy] Intel HD 4000 (Ivy Bridge) graphics freeze
On 2012-10-17 05:21, Jonathan Nieder wrote: Per Foreby wrote: However my computer has been running without any problems for 11 days, so whatever caused this bug seems to be fixed in the 3.5.5 kernel. Drat. Ok. To recap: * Asus P8Z77-V LE. * Newish system. Works fine under load (e.g., Folding@Home) but when you started normal interactive use it started to freeze a few times a day while you were interacting with it (in particular, the freeze happens around the same time as a keyboard or mouse action). * The freeze is a bad one --- the fan spins down, the NIC stops responding, caps lock doesn't light up, ctrl+alt+del and magic sysrq have no effect. No messages about it in netconsole. * Happens reliably (how reliably? 80% of the time?) after a few hours of sustained use (?) * Logs available in the bug log. No obvious smoking guns. ;-) * Changing the amount of memory allocated to the integrated GPU in BIOS doesn't change anything. * The above describes 3.2.23-1. Based on a week and a half of running 3.5.5-1~experimental.1 it doesn't seem to be affected. Correct, apart from the timing. It's been from a few hours to five days between the freezes. But with very little interactive use during the five days. I can add that stressing the graphics doesn't seem to trigger the problem. None of the changes from 3.2 to 3.5.5 are jumping out as likely candidates for the fix, but that's a pretty wide range. What about the MTRR patch that Ben Hutchings mentioned above (commit 9e984bc1dffd405138ff22356188b6a1677c64c8)? Or maybe that's just a cosmetic change? According to https://bugs.freedesktop.org/show_bug.cgi?id=41648, this patch was added in 3.5-rc1. How reliably can you reproduce the hang on a known-bad kernel? If you have time to try 3.2.30-1 from sid, 3.4.4-1~experimental.1 from http://snapshot.debian.org/package/linux/ and 3.3.6-1~experimental.1 from http://snapshot.debian.org/package/linux-2.6/ then that could help narrow down the search. With up to five days (so far) for a freeze to occur, it might take long to narrow down the change, and the computer in question is semi production (working from home), so the freezes are very annoying. But I'll give it a try in the name of the good cause. Maybe I should start with running 3.5.5 for a few weeks, just to make sure that the freezes really are gone? Jonathan Nieder wrote: * Asus P8Z77-V LE. This makes as good a keyword for a web search as any. It found [1] which is not too encouraging. Maybe memtest86+ could be worth a try to rule some problems out. [1] http://thread.gmane.org/gmane.linux.debian.user.french/176707/focus=176710 Memory and cpu cooling were of course the first suspects. But I'm using a large Arctic heatpipe cooler and have never seen higher temperatures than +57.0°C on any core according to lm_sensors. And memtest86+ has been happy. I ran an extra pass today (about 2.5 hours) just to make sure, and everything was blue and white. The french discussion talks about RAM timing and voltage, but I'm not an overclocker (vanilla i7 3770, not 3770K) so that hardly applies. And please note that with FAH running 24/7, the computer is always under heavy load, but has never frozen while running unattended. Even when running interactively, the freezes have never been random, but has happened *exactly* when I was clicking or typing something. Btw, I found http://www.linuxbsdos.com/2012/10/06/ubuntu-12-04-lts-and-12-10-beta-2-on-intel-ivy-bridge-powered-computer/. One of the comments indicate that 3.4 fixes some sort of freeze problem on ivy bridge/HD4000. And the partiallysanedeveloper page that I linked to in the initial bug report says that the freezes are gone in 3.3. Here are some other other discussions of freezes on similar hardware on debian derivatives with the same kernel generation: http://forums.linuxmint.com/viewtopic.php?f=90t=114382 http://phoronix.com/forums/showthread.php?71895-Intel-Ivy-Bridge-On-Linux-Two-Month-Redux http://forums.linuxmint.com/viewtopic.php?f=198t=113070 http://ubuntuforums.org/showthread.php?t=1995945 /Per -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689268: [wheezy] Intel HD 4000 (Ivy Bridge) graphics freeze
Per Foreby wrote: Correct, apart from the timing. It's been from a few hours to five days between the freezes. But with very little interactive use during the five days. Right --- how much interactive use does it take? I'm guessing that the time when you're not interacting the computer doesn't affect this bug (regardless of load). [...] None of the changes from 3.2 to 3.5.5 are jumping out as likely candidates for the fix, but that's a pretty wide range. What about the MTRR patch that Ben Hutchings mentioned above (commit 9e984bc1dffd405138ff22356188b6a1677c64c8)? Or maybe that's just a cosmetic change? That should be cosmetic with your card, though there's always the possibility of something subtle happening. [...] With up to five days (so far) for a freeze to occur, it might take long to narrow down the change, and the computer in question is semi production (working from home), so the freezes are very annoying. But I'll give it a try in the name of the good cause. Maybe I should start with running 3.5.5 for a few weeks, just to make sure that the freezes really are gone? Selfishly, I would suggest first trying to reproduce it on a known-bad kernel and then trying 3.3 or disabling the intel driver. [...] And memtest86+ has been happy. I ran an extra pass today (about 2.5 hours) just to make sure, and everything was blue and white. Thanks for checking. [...] Btw, I found http://www.linuxbsdos.com/2012/10/06/ubuntu-12-04-lts-and-12-10-beta-2-on-intel-ivy-bridge-powered-computer/. One of the comments indicate that 3.4 fixes some sort of freeze problem on ivy bridge/HD4000. And the partiallysanedeveloper page that I linked to in the initial bug report says that the freezes are gone in 3.3. Yes, it would be nice to narrow this down... If you blacklist the i915 kernel module and use the vesa X driver, does that avoid trouble? Thanks, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689268: [wheezy] Intel HD 4000 (Ivy Bridge) graphics freeze
On 2012-10-18 00:02, Jonathan Nieder wrote: Per Foreby wrote: Correct, apart from the timing. It's been from a few hours to five days between the freezes. But with very little interactive use during the five days. Right --- how much interactive use does it take? Very little. I've had freezes so far, and all of the with almost no activity on the screen. Clicking a link, typing an email or closing an rxvt window. That should be cosmetic with your card, though there's always the possibility of something subtle happening. As a rule of thumb, every bugfix in a complex enough system introduces another bug. So I suppose that sometimes a bugfux might accidentally fix another bug :) With up to five days (so far) for a freeze to occur, it might take long to narrow down the change, and the computer in question is semi production (working from home), so the freezes are very annoying. But I'll give it a try in the name of the good cause. Maybe I should start with running 3.5.5 for a few weeks, just to make sure that the freezes really are gone? Selfishly, I would suggest first trying to reproduce it on a known-bad kernel and then trying 3.3 or disabling the intel driver. OK, I'll go back to 3.2.23 and work my way up. It might take some time though if the freeze doesn't behave... If you blacklist the i915 kernel module and use the vesa X driver, does that avoid trouble? Does the vesa driver support 1920x1200 these days? /Per -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689268: [wheezy] Intel HD 4000 (Ivy Bridge) graphics freeze
On 2012-10-06 04:29, Per Foreby wrote: New freeze. Last entry in the debug log was more than 10 minutes before the freeze. Now running 3.5-trunk-amd64 #1 SMP Debian 3.5.5-1~experimental.1 (still with 256 MB iGPU Memory). I was going to give it two weeks before reporting, but today we had a power outage so I didn't quite reach two weeks. However my computer has been running without any problems for 11 days, so whatever caused this bug seems to be fixed in the 3.5.5 kernel. /Per -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689268: [wheezy] Intel HD 4000 (Ivy Bridge) graphics freeze
Per Foreby wrote: However my computer has been running without any problems for 11 days, so whatever caused this bug seems to be fixed in the 3.5.5 kernel. Drat. Ok. To recap: * Asus P8Z77-V LE. * Newish system. Works fine under load (e.g., Folding@Home) but when you started normal interactive use it started to freeze a few times a day while you were interacting with it (in particular, the freeze happens around the same time as a keyboard or mouse action). * The freeze is a bad one --- the fan spins down, the NIC stops responding, caps lock doesn't light up, ctrl+alt+del and magic sysrq have no effect. No messages about it in netconsole. * Happens reliably (how reliably? 80% of the time?) after a few hours of sustained use (?) * Logs available in the bug log. No obvious smoking guns. ;-) * Changing the amount of memory allocated to the integrated GPU in BIOS doesn't change anything. * The above describes 3.2.23-1. Based on a week and a half of running 3.5.5-1~experimental.1 it doesn't seem to be affected. None of the changes from 3.2 to 3.5.5 are jumping out as likely candidates for the fix, but that's a pretty wide range. How reliably can you reproduce the hang on a known-bad kernel? If you have time to try 3.2.30-1 from sid, 3.4.4-1~experimental.1 from http://snapshot.debian.org/package/linux/ and 3.3.6-1~experimental.1 from http://snapshot.debian.org/package/linux-2.6/ then that could help narrow down the search. Thanks again for your help and patience. Regards, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689268: [wheezy] Intel HD 4000 (Ivy Bridge) graphics freeze
Jonathan Nieder wrote: * Asus P8Z77-V LE. This makes as good a keyword for a web search as any. :) It found [1] which is not too encouraging. Maybe memtest86+ could be worth a try to rule some problems out. [1] http://thread.gmane.org/gmane.linux.debian.user.french/176707/focus=176710 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze
With 256MB of RAM assigned to graphics all is 100% stable here since over 2 weeks. Also 512MB seem to be no problem, just if I enable Maximum DVMT. I checked with the specifications of my MoBo (Intel DH77EB) and it says: Dynamic Video Memory Technology (DVMT) 5.0 support Support of up to 1.7 GB Video Memory with 4 GB and above system memory configuration So these 1.7GB probably exceeds what the driver (or PAT) is capable? Regards, Ingo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze
Hi Ingo, Per Foreby wrote: Per Foreby wrote: So far I'm running whith the default wheezy kernel but with the iGPU memory set to 256 MB. My plan was to run with this setting, and if I had another crash, try the experimental kernel. [...] New freeze. Last entry in the debug log was more than 10 minutes before the freeze. Ingo wrote: With 256MB of RAM assigned to graphics all is 100% stable here since over 2 weeks. Also 512MB seem to be no problem, just if I enable Maximum DVMT. There seem to be some differences in symptoms here, so please file a separate bug. We can merge them later if they turn out to have the same cause. Thanks, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze
Sorry, I didn't receive the last 2 msgs in my mailbox, (especifically the questions Ingo asks me). Here the answers: a) Yes, I am using iceweasel. b) my phisical RAM is 8 GB The related kernel info is below, first kernel 3.5 related and then standard wheezy 3.2 kernel related. Note that with kernel 3.5 I don't have the MTRR allocation failed error. My integrated graphics BIOS configuration: Virtu Technology [Disabled] Integrated Graphics Share Memory [64MB] DVMT Memory [256MB] IGD Multimonitor [Disabled] -- Kernel 3.5 -- $ dmesg | grep mtrr $ $ dmesg | grep drm [3.749099] [drm] Initialized drm 1.1.0 20060810 [3.947156] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [3.947156] [drm] Driver supports precise vblank timestamp query. [4.004585] [drm] Enabling RC6 states: RC6 on, RC6p on, RC6pp off [4.373533] fbcon: inteldrmfb (fb0) is primary device [4.554815] fb0: inteldrmfb frame buffer device [4.554817] drm: registered panic notifier [4.555909] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 0 $ dmesg | grep i915 [3.690617] i915 :00:02.0: setting latency timer to 64 [3.707470] i915 :00:02.0: irq 43 for MSI/MSI-X [4.328751] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 0 $ dmesg | grep agp [0.459118] Linux agpgart interface v0.103 [0.459169] agpgart-intel :00:00.0: Intel Ivybridge Chipset [0.459210] agpgart-intel :00:00.0: detected gtt size: 2097152K total, 262144K mappable [0.459842] agpgart-intel :00:00.0: detected 65536K stolen memory [0.459931] agpgart-intel :00:00.0: AGP aperture is 256M @ 0xe000 The memory info: $ cat /proc/mtrr reg00: base=0x0 (0MB), size= 8192MB, count=1: write-back reg01: base=0x2 ( 8192MB), size= 512MB, count=1: write-back reg02: base=0x0e000 ( 3584MB), size= 512MB, count=1: uncachable reg03: base=0x0dc00 ( 3520MB), size= 64MB, count=1: uncachable reg04: base=0x0db80 ( 3512MB), size=8MB, count=1: uncachable reg05: base=0x21f80 ( 8696MB), size=8MB, count=1: uncachable reg06: base=0x21f60 ( 8694MB), size=2MB, count=1: uncachable $ cat /proc/meminfo MemTotal:8081148 kB MemFree: 7392304 kB Buffers: 14852 kB Cached: 280924 kB SwapCached:0 kB Active: 395024 kB Inactive: 214096 kB Active(anon): 313884 kB Inactive(anon):42596 kB Active(file): 81140 kB Inactive(file): 171500 kB Unevictable: 0 kB Mlocked: 0 kB SwapTotal: 7811068 kB SwapFree:7811068 kB Dirty:12 kB Writeback: 0 kB AnonPages:313372 kB Mapped:64608 kB Shmem: 43120 kB Slab: 26992 kB SReclaimable: 11196 kB SUnreclaim:15796 kB KernelStack:1808 kB PageTables:10844 kB NFS_Unstable: 0 kB Bounce:0 kB WritebackTmp: 0 kB CommitLimit:11851640 kB Committed_AS:1004672 kB VmallocTotal: 34359738367 kB VmallocUsed: 366716 kB VmallocChunk: 34359355879 kB HardwareCorrupted: 0 kB AnonHugePages: 0 kB HugePages_Total: 0 HugePages_Free:0 HugePages_Rsvd:0 HugePages_Surp:0 Hugepagesize: 2048 kB DirectMap4k: 55296 kB DirectMap2M: 7192576 kB -- Kernel 3.2 -- $ dmesg | grep mtrr [5.001176] mtrr: type mismatch for e000,1000 old: write-back new: write-combining $ cat /proc/mtrr reg00: base=0x0 (0MB), size= 8192MB, count=1: write-back reg01: base=0x2 ( 8192MB), size= 512MB, count=1: write-back reg02: base=0x0e000 ( 3584MB), size= 512MB, count=1: uncachable reg03: base=0x0dc00 ( 3520MB), size= 64MB, count=1: uncachable reg04: base=0x0db80 ( 3512MB), size=8MB, count=1: uncachable reg05: base=0x21f80 ( 8696MB), size=8MB, count=1: uncachable reg06: base=0x21f60 ( 8694MB), size=2MB, count=1: uncachable $ dmesg | grep drm [4.960827] [drm] Initialized drm 1.1.0 20060810 [5.001178] [drm] MTRR allocation failed. Graphics performance may suffer. [5.001350] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [5.001351] [drm] Driver supports precise vblank timestamp query. [5.344345] fbcon: inteldrmfb (fb0) is primary device [5.523815] fb0: inteldrmfb frame buffer device [5.523816] drm: registered panic notifier [5.585070] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 0 $ dmesg | grep i915 [4.973200] i915 :00:02.0: PCI INT A - GSI 16 (level, low) - IRQ 16 [4.973202] i915 :00:02.0: setting latency timer to 64 [5.001347] i915 :00:02.0: irq 43 for MSI/MSI-X [5.585070] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 0 $ dmesg | grep agp [0.977765] Linux agpgart
Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze
Interesting to see the differences between the 2 kernels. Compared to my messages I found following lines in dmesg have disappeared with 3.5: mtrr: type mismatch for e000,1000 old: write-back new: write-combining [drm] MTRR allocation failed. Graphics performance may suffer. [drm:intel_dsm_platform_mux_info] *ERROR* MUX INFO call failed i915 :00:02.0: PCI INT A - GSI 16 (level, low) - IRQ 16 i915 :00:02.0: restoring config space at offset 0xf (was 0x100, writing 0x10b) i915 :00:02.0: restoring config space at offset 0x1 (was 0x97, writing 0x900407) i915 :00:02.0: setting latency timer to 64 while enabling RC6 states has been added: [drm] Enabling RC6 states: RC6 on, RC6p on, RC6pp off Probably a hint to the root cause? I also compared the BIOS settings: Javier has these options/settings: Integrated Graphics Share Memory [64MB] DVMT Memory [256MB] I only have: IGD DVMT Memory [256MB] (which I called previously agp-aperture - ancient name when PC's had a dedicated AGP-Port). This is the setting which I did change from max - 256MB and got my system stable - which still holds right now. However the mtrr setups (/proc/mtrr) are still identical with both kernels. Seems the write-combining area has become obsolete - or still not implemented in i915? Ingo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze
On Sun, 2012-10-07 at 17:06 +0200, Ingo wrote: Interesting to see the differences between the 2 kernels. Compared to my messages I found following lines in dmesg have disappeared with 3.5: mtrr: type mismatch for e000,1000 old: write-back new: write-combining [drm] MTRR allocation failed. Graphics performance may suffer. [drm:intel_dsm_platform_mux_info] *ERROR* MUX INFO call failed i915 :00:02.0: PCI INT A - GSI 16 (level, low) - IRQ 16 i915 :00:02.0: restoring config space at offset 0xf (was 0x100, writing 0x10b) i915 :00:02.0: restoring config space at offset 0x1 (was 0x97, writing 0x900407) i915 :00:02.0: setting latency timer to 64 while enabling RC6 states has been added: [drm] Enabling RC6 states: RC6 on, RC6p on, RC6pp off Probably a hint to the root cause? Don't think so. I also compared the BIOS settings: Javier has these options/settings: Integrated Graphics Share Memory [64MB] DVMT Memory [256MB] I only have: IGD DVMT Memory [256MB] (which I called previously agp-aperture - ancient name when PC's had a dedicated AGP-Port). This is the setting which I did change from max - 256MB and got my system stable - which still holds right now. However the mtrr setups (/proc/mtrr) are still identical with both kernels. Seems the write-combining area has become obsolete - or still not implemented in i915? The driver calls ioremap_wc() which will enable write-combining through the PAT in recent processors. An MTRR is not needed and in 3.5 the driver doesn't even bother to allocate one: commit 9e984bc1dffd405138ff22356188b6a1677c64c8 Author: Adam Jackson a...@redhat.com Date: Wed Mar 14 11:22:11 2012 -0400 drm/i915: Don't do MTRR setup if PAT is enabled Ben. -- Ben Hutchings You can't have everything. Where would you put it? signature.asc Description: This is a digitally signed message part
Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze
Am 05.10.2012 23:53, schrieb Jonathan Nieder: Per Foreby wrote: So far I'm running whith the default wheezy kernel but with the iGPU memory set to 256 MB. My plan was to run with this setting, and if I had another crash, try the experimental kernel. That seems like a good plan. With me all is still fine since 1 week, however that does not mean its fixed. I am right now trying to stress my machine with high memory loads and graphics to verify the workaround. So far we have only 2 common things in all cases: a) it happens when browsing with iceweasel - Javier can you also confirm this? b) appears to be hardware/BIOS dependent and we all have 4GiB RAM installed. There obviously is different memory allocvation/interpretation, depending from where you gather the information: physical RAM installed 8GiB = 8.192MiB = 8.388.608 kiB cat /proc/mtrr reg00: base=0x0 (0MB), size= 8192MB, count=1: write-back reg01: base=0x2 ( 8192MB), size= 512MB, count=1: write-back reg02: base=0x0e000 ( 3584MB), size= 512MB, count=1: uncachable reg03: base=0x0dc00 ( 3520MB), size= 64MB, count=1: uncachable reg04: base=0x0db80 ( 3512MB), size=8MB, count=1: uncachable reg05: base=0x21f80 ( 8696MB), size=8MB, count=1: uncachable reg06: base=0x21f60 ( 8694MB), size=2MB, count=1: uncachable cat /proc/meminfo MemTotal:8095128 kB MemFree: 7543424 kB Buffers: 37428 kB Cached: 285136 kB SwapCached:0 kB Active: 178696 kB Inactive: 280040 kB Active(anon): 136512 kB Inactive(anon):68272 kB Active(file): 42184 kB Inactive(file): 211768 kB Unevictable: 0 kB Mlocked: 0 kB SwapTotal: 0 kB SwapFree: 0 kB Dirty:28 kB Writeback: 0 kB AnonPages:136164 kB Mapped:58996 kB Shmem: 68620 kB Slab: 37120 kB SReclaimable: 16488 kB SUnreclaim:20632 kB KernelStack:2096 kB PageTables:16172 kB NFS_Unstable: 0 kB Bounce:0 kB WritebackTmp: 0 kB CommitLimit: 4047564 kB Committed_AS: 712296 kB VmallocTotal: 34359738367 kB VmallocUsed: 367656 kB VmallocChunk: 34359368791 kB HardwareCorrupted: 0 kB AnonHugePages: 0 kB HugePages_Total: 0 HugePages_Free:0 HugePages_Rsvd:0 HugePages_Surp:0 Hugepagesize: 2048 kB DirectMap4k: 49152 kB DirectMap2M: 8247296 kB It would also be interesting whether Javier gets a mtrr with write-combining with the new kernel and whether BIOS settings for videoRAM are respected by the i915 module. Ingo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze
Ingo wrote: With me all is still fine since 1 week, however that does not mean its fixed. I am right now trying to stress my machine with high memory loads and graphics to verify the workaround. I have also tried the stress tactics, but it doesn't seem to have anything to do with load. a) it happens when browsing with iceweasel - Javier can you also confirm this? Not iceweasel in my case. I like my browsers bleading edge, so I use the 64-bit version of vanilla firefox. And my freezes have happened on various mouse or kbd input, not only klicking a link in the web browser (see my original bug report). /Per -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689268: linux-image-3.2.0-3-amd64: Intel HD 4000 (Ivy Bridge) graphics freeze
I can also confirm this bug. My hardware: i5-3570K MoBo: MSI Z77A-G65. If it helps, I am using now linux-image-3.5-trunk-amd64 (3.5.2-1~experimental.1) kernel with no freezes since the change. -- Saludos de Javier jcant...@escomposlinux.org signature.asc Description: Digital signature
Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze
Javier Cantero wrote: If it helps, I am using now linux-image-3.5-trunk-amd64 (3.5.2-1~experimental.1) kernel with no freezes since the change. That's good to hear. Per, Ingo, does that work around trouble on your machines, too? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze
On 2012-10-05 18:50, Jonathan Nieder wrote: Javier Cantero wrote: If it helps, I am using now linux-image-3.5-trunk-amd64 (3.5.2-1~experimental.1) kernel with no freezes since the change. That's good to hear. Per, Ingo, does that work around trouble on your machines, too? I hade two freezes last saturday, and two the day after. The next freeze was yesterday (five days later). So testing different options isn't that easy. So far I'm running whith the default wheezy kernel but with the iGPU memory set to 256 MB. My plan was to run with this setting, and if I had another crash, try the experimental kernel. But let me know if you'd rather have me reset the video memory to the default 64 MB and try the 3.5 kernel. Btw, my mobo is is an Asus P8Z77-V LE. /Per -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze
Per Foreby wrote: So far I'm running whith the default wheezy kernel but with the iGPU memory set to 256 MB. My plan was to run with this setting, and if I had another crash, try the experimental kernel. That seems like a good plan. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze
On 2012-10-05 23:53, Jonathan Nieder wrote: Per Foreby wrote: So far I'm running whith the default wheezy kernel but with the iGPU memory set to 256 MB. My plan was to run with this setting, and if I had another crash, try the experimental kernel. That seems like a good plan. New freeze. Last entry in the debug log was more than 10 minutes before the freeze. Now running 3.5-trunk-amd64 #1 SMP Debian 3.5.5-1~experimental.1 (still with 256 MB iGPU Memory). /Per -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689268: linux-image-3.2.0-3-amd64: Intel HD 4000 (Ivy Bridge) graphics freeze
I can confirm this bug here too and found a temporarly workaround. Ivy-Bridge i5-3570K on Intel DH77EB MoBo (H77 chipset), latest BIOS EB0089.BIO. These freezes happend most of the time when hitting a link in Iceweasel. They are so severe that even the MoBo reset button does not respond immediately, I had to hit it several times. Additionally when PC stalls, monitor continues to display the frozen desktop (via displayport) and power consumption rises from idle 38 watts to constant 86 watts - verry dangerous if also fan regulation fails. Upon next boot I get orphaned inodes - very much the same as Per Foreby describes. System here is Wheezy-amd64 with - kernel 3.2.23-1 - xserver-xorg-video-intel 2:2.19.0-5 Now I'll give the history what I did try with which result. Sorry if it's not scientific, but probably helps to pin down the root cause. It started when I was examining my logs and discovered the messages: [drm] MTRR allocation failed. Graphics performance may suffer. Checking mtrr's showed: cat /proc/mtrr reg00: base=0x0 (0MB), size= 8192MB, count=1: write-back reg01: base=0x2 ( 8192MB), size= 512MB, count=1: write-back reg02: base=0x0e000 ( 3584MB), size= 512MB, count=1: uncachable reg03: base=0x0dc00 ( 3520MB), size= 64MB, count=1: uncachable reg04: base=0x0db80 ( 3512MB), size=8MB, count=1: uncachable reg05: base=0x21f80 ( 8696MB), size=8MB, count=1: uncachable reg06: base=0x21f60 ( 8694MB), size=2MB, count=1: uncachable So I decided to boot with kernel parameter enable_mtrr_cleanup which seemed to solve the problem: reg00: base=0x0 (0MB), size= 2048MB, count=1: write-back reg01: base=0x08000 ( 2048MB), size= 1024MB, count=1: write-back reg02: base=0x0c000 ( 3072MB), size= 512MB, count=1: write-back reg03: base=0x0db80 ( 3512MB), size=8MB, count=1: uncachable reg04: base=0x0dc00 ( 3520MB), size= 64MB, count=1: uncachable reg05: base=0x1 ( 4096MB), size= 4096MB, count=1: write-back reg06: base=0x2 ( 8192MB), size= 512MB, count=1: write-back reg07: base=0x21f60 ( 8694MB), size=2MB, count=1: uncachable reg08: base=0x21f80 ( 8696MB), size=8MB, count=1: uncachable reg09: base=0x0e000 ( 3584MB), size= 256MB, count=1: write-combining At least since then (don't know whether before as well) the freezes/crashes were observed, sometimes more than once a day. Did try a lot to find the root cause and finally found following workaround: Default setting in the BIOS of the DH77EB for video agp-aperture is max (values of 64, 128, 256 and 512MB are offered as options). I played around with different BIOS settings and observed that these settings are not respected by the i915 module. Dmesg always reports 256MB for the aperture: dmesg | grep agp Linux agpgart interface v0.103 agpgart-intel :00:00.0: Intel Ivybridge Chipset agpgart-intel :00:00.0: detected gtt size: 2097152K total, 262144K mappable agpgart-intel :00:00.0: detected 65536K stolen memory agpgart-intel :00:00.0: AGP aperture is 256M @ 0xe000 So I decided to set the BIOS AGP-aperture to 256MB as well and removed the kernel parameter 'enable_mtrr_cleanup'. I now get for the mtrr's: reg00: base=0x0 (0MB), size= 8192MB, count=1: write-back reg01: base=0x2 ( 8192MB), size= 512MB, count=1: write-back reg02: base=0x0e000 ( 3584MB), size= 512MB, count=1: uncachable reg03: base=0x0dc00 ( 3520MB), size= 64MB, count=1: uncachable reg04: base=0x0db80 ( 3512MB), size=8MB, count=1: uncachable reg05: base=0x21f80 ( 8696MB), size=8MB, count=1: uncachable reg06: base=0x21f60 ( 8694MB), size=2MB, count=1: uncachable still suffering graphics performance and mtrr missmatch according to dmesg: mtrr: type mismatch for e000,1000 old: write-back new: write-combining [drm] MTRR allocation failed. Graphics performance may suffer. But since then I have never obseved any cras/freeze for days now. If more information is required, please let me know (logs did never contain any information related to the crashes). My suspicion for the cause is some memory or communication missmatch between BIOS-setting, mtrr's and agp-aperture. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689268: linux-image-3.2.0-3-amd64: Intel HD 4000 (Ivy Bridge) graphics freeze
On 2012-10-04 13:30, Ingo wrote: I just had a freeze, the first one sinc sunday. Actually while browsing your comment :) Jonathan: netconsole didn't log anything interesting. These freezes happend most of the time when hitting a link in Iceweasel. They are so severe that even the MoBo reset button does not respond immediately, Same here. I press reset and the computer reboots 20 seconds later. I had to hit it several times. Additionally when PC stalls, monitor continues to display the frozen desktop (via displayport) I also use displayport. It seems like the last screen is cached in the monitor (HP ZR24w) because if I turn the monitor off and on again, I just get a black screen. power consumption rises from idle 38 watts to constant 86 watts - verry dangerous if also fan regulation fails. Don't know about power, but if this is true, the reset delay may very well be the temperature rising until the temperature protection resets the computer. Upon next boot I get orphaned inodes Me too, but this is of course expected on a cold reset. [drm] MTRR allocation failed. Graphics performance may suffer. I've got this one too. Checking mtrr's showed: cat /proc/mtrr reg00: base=0x0 (0MB), size= 8192MB, count=1: write-back reg01: base=0x2 ( 8192MB), size= 512MB, count=1: write-back reg02: base=0x0e000 ( 3584MB), size= 512MB, count=1: uncachable reg03: base=0x0dc00 ( 3520MB), size= 64MB, count=1: uncachable reg04: base=0x0db80 ( 3512MB), size=8MB, count=1: uncachable reg05: base=0x21f80 ( 8696MB), size=8MB, count=1: uncachable reg06: base=0x21f60 ( 8694MB), size=2MB, count=1: uncachable In my case (with 32 GB): reg00: base=0x0 (0MB), size=32768MB, count=1: write-back reg01: base=0x8 (32768MB), size= 512MB, count=1: write-back reg02: base=0x0e000 ( 3584MB), size= 512MB, count=1: uncachable reg03: base=0x0d000 ( 3328MB), size= 256MB, count=1: uncachable reg04: base=0x0cf00 ( 3312MB), size= 16MB, count=1: uncachable reg05: base=0x81fe0 (33278MB), size=2MB, count=1: uncachable Default setting in the BIOS of the DH77EB for video agp-aperture is max (values of 64, 128, 256 and 512MB are offered as options). I played around with different BIOS settings and observed that these settings are not respected by the i915 module. Dmesg always reports 256MB for the aperture: So the problem seems to be that i915 ignores (or cannot read) the BIOS setting. My BIOS setting is called iGPU-Memory. It was by default at 64 MB. dmesg | grep agp Linux agpgart interface v0.103 agpgart-intel :00:00.0: Intel Ivybridge Chipset agpgart-intel :00:00.0: detected gtt size: 2097152K total, 262144K mappable agpgart-intel :00:00.0: detected 65536K stolen memory agpgart-intel :00:00.0: AGP aperture is 256M @ 0xe000 Identical to my logs. So I decided to set the BIOS AGP-aperture to 256MB as well and removed the kernel parameter 'enable_mtrr_cleanup'. Changed my setting to 256 MB as well. still suffering graphics performance and mtrr missmatch according to dmesg: mtrr: type mismatch for e000,1000 old: write-back new: write-combining [drm] MTRR allocation failed. Graphics performance may suffer. Me too. But since then I have never obseved any cras/freeze for days now. Keeping my fingers crossed for the same outcome. /Per -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689268: linux-image-3.2.0-3-amd64: Intel HD 4000 (Ivy Bridge) graphics freeze
But since then I have never obseved any cras/freeze for days now. Keeping my fingers crossed for the same outcome. /Per Still ok here - good luck. Me came up another thing which probably relates to that. As far as I could extract from internet searches regarding this issue, I concluded: 1. i915 drm driver uses kms and additionally requires framebuffer support. 2. for normal graphics operation and 3D acceleration it uses agp communication (use of mtrr is depreciated). 3. however framebuffer seems to use mtrr for communication. So finally both have to match somehow or properly switch over. When the problem/freeze occurred I had beforehand booted into my service system which is a minimal Wheezy without graphics, just terminal. This of course just uses framebuffer. Maybe the this switching also triggered the freeze? This is just a guess from me, beeing definitely no expert in Linux and I do not have any idea of the internals of driver or kernel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze
Per Foreby wrote: I just had a freeze, the first one sinc sunday. Actually while browsing your comment :) Jonathan: netconsole didn't log anything interesting. Thanks. Even the absence of output can be interesting; do you have the log from that boot and freeze? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze
Hi, Per Foreby wrote: This always happens on interactive input. So far these four events: - close a window - click a link in firefox - ctrl-r to reload a page in firefox - ctrl-k to delete a line in thunderbird's composer The computer is completely frozen. The cpu probably stops working since the fan spins down to it's lowest rpm, I can't ping the interface, caps lock doesn't light up, has to be power cycled. And no clues in the logs. Can you get a log from this happening with netconsole[1] or a serial console[2]? (It's ok if it doesn't catch the freeze --- it's just that as full a log as possible of the context would be useful.) If you can reproduce this with 3.5.y from experimental as well, please report this upstream following instructions from [3] and let us know the bug number so we can track it. Thanks and hope that helps, Jonathan [1] http://www.kernel.org/doc/Documentation/networking/netconsole.txt [2] http://www.kernel.org/doc/Documentation/serial-console.txt [3] http://intellinuxgraphics.org/how_to_report_bug.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze
Hi, serial ports are rare these days, but I have netconsole running now (logging to syslogd on my server). So far the only log messages on the remote server are from netconsole itself. Which leads me to this question: Are the default kernel debugging options OK, or do I need to enable more debugging? I'll wait for the freeze to happen once more, and if it does, I will try the latest kernel from experimental. /Per -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze
Per Foreby wrote: serial ports are rare these days, but I have netconsole running now (logging to syslogd on my server). Thanks! So far the only log messages on the remote server are from netconsole itself. Which leads me to this question: Are the default kernel debugging options OK, or do I need to enable more debugging? Does that mean it didn't capture the boot messages? Either way, if you can handle the log spew then drm.debug=0xe would be great. But a log without that would already be interesting since it would catch the basic setup at boot time and symptoms such as assertion failures (kernel BUG or WARNING) near the time of the freeze. Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze
On 2012-10-01 19:52, Jonathan Nieder wrote: So far the only log messages on the remote server are from netconsole itself. Which leads me to this question: Are the default kernel debugging options OK, or do I need to enable more debugging? Does that mean it didn't capture the boot messages? netconsole is compiled as a module, so I never rebooted, just loaded it with modprobe. Either way, if you can handle the log spew then drm.debug=0xe would be great. But a log without that would already be interesting since it would catch the basic setup at boot time and symptoms such as assertion failures (kernel BUG or WARNING) near the time of the freeze. OK, now freshly rebooted with this config: GRUB_CMDLINE_LINUX=netconsole=@/,514@192.168.201.1/ drm.debug=0xe The debug logging from drm isn't forwarded via netconsole, so I suppose it isn't supposed to? (Even though I've been working with unix/linux for the last 25 years, kernel debugging isn't my everyday trade.) But I have removed the minus from /var/log/kern.log in the syslog config, so hopefully everything should stick to the local log file. Or at least everything but the last crucial line, which netconsole hopefully will catch. So far i doesn't spew that much, it typically looks like this over and over again: [drm:i915_driver_open], [drm:i915_getparam], Unknown parameter 16 [drm:i915_getparam], Unknown parameter 17 [drm:i915_getparam], Unknown parameter 17 [drm:intel_crtc_cursor_set], [drm:intel_crtc_cursor_set], cursor off [drm:intel_crtc_cursor_set], [drm:intel_crtc_cursor_set], [drm:intel_crtc_cursor_set], cursor off Now we'll just have to wait and see. This is my workstation at home, and during the weekdays I don't use it as much as on weekends, so it might take longer to trigger the bug the next time. /Per -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze
Per Foreby wrote: The debug logging from drm isn't forwarded via netconsole, so I suppose it isn't supposed to? Oh, that's because of the console_loglevel setting[1]. You can change it by running dmesg -n 8 (or by adding the word debug or a loglevel= parameter to the kernel command line). Thanks again for your help and patience. [1] see http://www.kernel.org/doc/Documentation/networking/netconsole.txt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze
Hi, Sébastien Dinot wrote: The last log before a freeze is always like this: [ 8276.625165] usb 2-1.5: USB disconnect, device number 8 [ 8276.830839] usb 2-1.5: new low-speed USB device number 9 using ehci_hcd [ 8276.928992] usb 2-1.5: New USB device found, idVendor=045e, idProduct=00a4 [ 8276.928997] usb 2-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 8276.928999] usb 2-1.5: Product: Microsoft(R) Compact Optical Mouse [ 8276.929001] usb 2-1.5: Manufacturer: Microsoft [ 8276.934076] input: Microsoft Microsoft(R) Compact Optical Mouse as /devices/pci:00/:00:1d.0/usb2/2-1/2-1.5/2-1.5:1.0/input/input17 [ 8276.934434] hid-generic 0003:045E:00A4.0007: input,hidraw0: USB HID v1.10 Mouse [Microsoft Microsoft(R) Compact Optical Mouse] on usb-:00:1d.0-1.5/input0 Of course, I did not disconnect the mouse or shake its USB cable. :( Based on the timestamps, does that message come immediately before the freeze or just some time before it? (If the latter, it's hopefully a red herring.) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze
Sébastien Dinot wrote: Except in rare cases, the system is alive. I can open a remote SSH session and if I push the power button (on the computer case), the logout dialog appears. This seems like a different problem than Per experienced, since Per's locks up the machine, so please file a separate bug. If they turn out to have the same cause, we can merge them later. Thanks, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze
On 2012-10-01 23:29, Jonathan Nieder wrote: Per Foreby wrote: The debug logging from drm isn't forwarded via netconsole, so I suppose it isn't supposed to? Oh, that's because of the console_loglevel setting[1]. You can change it by running dmesg -n 8 (or by adding the word debug or a loglevel= parameter to the kernel command line). Ah, RTFM :) However, it looks like the netconsole documentation and the dmesg man page should be updated: # dmesg -n 8 dmesg: unknown level '8' Instead I tried # dmesg -n debug # dmesg -E but still nothing at the remote end. Instead I added remote logging of kern.* in rsyslog.conf, so now I have everything at the server. /Per -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze
Per Foreby p...@foreby.se writes: On 2012-10-01 23:29, Jonathan Nieder wrote: Per Foreby wrote: The debug logging from drm isn't forwarded via netconsole, so I suppose it isn't supposed to? Oh, that's because of the console_loglevel setting[1]. You can change it by running dmesg -n 8 (or by adding the word debug or a loglevel= parameter to the kernel command line). Ah, RTFM :) However, it looks like the netconsole documentation and the dmesg man page should be updated: # dmesg -n 8 dmesg: unknown level '8' Instead I tried # dmesg -n debug # dmesg -E but still nothing at the remote end. Yes, I vaguely remember having struggled with the same issue the last time I use netconsole. Try echo 8 /proc/sys/kernel/printk instead. I believe the bug is in the dmesg utility. It should shift all values by one. Setting dmesg -n debug will currently log all messages with a level *higher* than debug. Instead I added remote logging of kern.* in rsyslog.conf, so now I have everything at the server. As long as you don't crash anything... Bjørn -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze
On 2012-10-02 00:45, Bjørn Mork wrote: Per Foreby p...@foreby.se writes: On 2012-10-01 23:29, Jonathan Nieder wrote: Per Foreby wrote: The debug logging from drm isn't forwarded via netconsole, so I suppose it isn't supposed to? Oh, that's because of the console_loglevel setting[1]. You can change it by running dmesg -n 8 (or by adding the word debug or a loglevel= parameter to the kernel command line). Ah, RTFM :) However, it looks like the netconsole documentation and the dmesg man page should be updated: # dmesg -n 8 dmesg: unknown level '8' Instead I tried # dmesg -n debug # dmesg -E but still nothing at the remote end. Yes, I vaguely remember having struggled with the same issue the last time I use netconsole. Try echo 8 /proc/sys/kernel/printk instead. I believe the bug is in the dmesg utility. It should shift all values by one. Setting dmesg -n debug will currently log all messages with a level *higher* than debug. You're probably right about the bug. I don't know what the four values in /proc/sys/kernel/printk are, but the first value was 7, not 8: # cat /proc/sys/kernel/printk 7 4 1 7 # echo 8 /proc/sys/kernel/printk # cat /proc/sys/kernel/printk 8 4 1 7 However, this did not affect the remote logging, so I'm back to the remote syslog approach. /Per -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze
Per Foreby p...@foreby.se writes: On 2012-10-02 00:45, Bjørn Mork wrote: I believe the bug is in the dmesg utility. It should shift all values by one. Setting dmesg -n debug will currently log all messages with a level *higher* than debug. You're probably right about the bug. I don't know what the four values in /proc/sys/kernel/printk are, but the first value was 7, not 8: # cat /proc/sys/kernel/printk 7 4 1 7 # echo 8 /proc/sys/kernel/printk # cat /proc/sys/kernel/printk 8 4 1 7 From Documentation/sysctl/kernel.txt : quote printk: The four values in printk denote: console_loglevel, default_message_loglevel, minimum_console_loglevel and default_console_loglevel respectively. These values influence printk() behavior when printing or logging error messages. See 'man 2 syslog' for more info on the different loglevels. - console_loglevel: messages with a higher priority than this will be printed to the console - default_message_loglevel: messages without an explicit priority will be printed with this priority - minimum_console_loglevel: minimum (highest) value to which console_loglevel can be set - default_console_loglevel: default value for console_loglevel /quote However, this did not affect the remote logging, so I'm back to the remote syslog approach. Odd. Then there are other issues I don't understand here. But the dmesg bug is quite obvious, so I sent off a fix upstream. The bug was introduced with the support for level names in July 2011. Bjørn /Per -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689268: linux-image-3.2.0-3-amd64: Intel HD 4000 (Ivy Bridge) graphics freeze
Package: src:linux Version: 3.2.23-1 Severity: important I'm using the built-in graphics (HD4000) on a i7 3770 Ivy Bridge processor with Z77 chipset. The computer has been runing just fine under heavy load (Folding at Home) for some weeks, but a few days ago I started using it as a workstation, and since then it totally freezes a few times a day. This always happens on interactive input. So far these four events: - close a window - click a link in firefox - ctrl-r to reload a page in firefox - ctrl-k to delete a line in thunderbird's composer The computer is completely frozen. The cpu probably stops working since the fan spins down to it's lowest rpm, I can't ping the interface, caps lock doesn't light up, has to be power cycled. And no clues in the logs. After reboot, redoing the same actions doesn't trigger the bug. But about 3-4 hours later the computer hangs again. Maybe some data structure that is filled upp with time? Googling for solutions, I fond these pages: http://partiallysanedeveloper.blogspot.se/2012/05/ivy-bridge-hd4000-linux-freeze.html http://askubuntu.com/questions/155458/ubuntu-12-04-randomly-freezes-on-ivy-bridge-intel-hd-graphics-4000 http://askubuntu.com/questions/163890/weird-system-freeze-nothing-works-keyboard-mouse-reset-button-ubuntu-12-04-64 I haven't tried with another kernel yet. -- Package-specific info: ** Version: Linux version 3.2.0-3-amd64 (Debian 3.2.23-1) (debian-ker...@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-8) ) #1 SMP Mon Jul 23 02:45:17 UTC 2012 ** Command line: BOOT_IMAGE=/boot/vmlinuz-3.2.0-3-amd64 root=/dev/md0 ro ** Not tainted ** Kernel log: [5.621585] EXT4-fs (md0): ext4_orphan_cleanup: deleting unreferenced inode 5636493 [5.621624] EXT4-fs (md0): ext4_orphan_cleanup: deleting unreferenced inode 5636605 [5.621636] EXT4-fs (md0): ext4_orphan_cleanup: deleting unreferenced inode 5636595 [5.621651] EXT4-fs (md0): ext4_orphan_cleanup: deleting unreferenced inode 5636593 [5.621659] EXT4-fs (md0): ext4_orphan_cleanup: deleting unreferenced inode 5636592 [5.621667] EXT4-fs (md0): ext4_orphan_cleanup: deleting unreferenced inode 5636584 [5.621673] EXT4-fs (md0): ext4_orphan_cleanup: deleting unreferenced inode 5636520 [5.621680] EXT4-fs (md0): ext4_orphan_cleanup: deleting unreferenced inode 5636514 [5.621687] EXT4-fs (md0): ext4_orphan_cleanup: deleting unreferenced inode 5636501 [5.621694] EXT4-fs (md0): ext4_orphan_cleanup: deleting unreferenced inode 5636496 [5.621700] EXT4-fs (md0): ext4_orphan_cleanup: deleting unreferenced inode 5636491 [5.621706] EXT4-fs (md0): ext4_orphan_cleanup: deleting unreferenced inode 5636191 [5.621718] EXT4-fs (md0): ext4_orphan_cleanup: deleting unreferenced inode 5636508 [5.621743] EXT4-fs (md0): ext4_orphan_cleanup: deleting unreferenced inode 4064137 [5.621757] EXT4-fs (md0): 15 orphan inodes deleted [5.621808] EXT4-fs (md0): recovery complete [5.925942] EXT4-fs (md0): mounted filesystem with ordered data mode. Opts: (null) [7.181722] udevd[467]: starting version 175 [7.619643] ACPI: Requesting acpi_cpufreq [7.619661] input: Power Button as /devices/LNXSYSTM:00/device:00/PNP0C0C:00/input/input4 [7.619667] ACPI: Power Button [PWRB] [7.620061] Monitor-Mwait will be used to enter C-1 state [7.620080] Monitor-Mwait will be used to enter C-2 state [7.620099] Monitor-Mwait will be used to enter C-3 state [7.620111] ACPI: acpi_idle registered with cpuidle [7.622036] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input5 [7.622104] ACPI: Power Button [PWRF] [7.687301] i801_smbus :00:1f.3: PCI INT C - GSI 18 (level, low) - IRQ 18 [7.687369] ACPI: resource :00:1f.3 [io 0xf040-0xf05f] conflicts with ACPI region SMBI [io 0xf040-0xf04f] [7.687436] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver [7.700685] input: PC Speaker as /devices/platform/pcspkr/input/input6 [7.720941] wmi: Mapper loaded [7.722731] iTCO_vendor_support: vendor-support=0 [7.740352] alg: No test for __gcm-aes-aesni (__driver-gcm-aes-aesni) [7.759663] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.07 [7.759776] iTCO_wdt: Found a Panther Point TCO device (Version=2, TCOBASE=0x0460) [7.759880] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0) [7.869045] [drm] Initialized drm 1.1.0 20060810 [7.890031] i915 :00:02.0: PCI INT A - GSI 16 (level, low) - IRQ 16 [7.890087] i915 :00:02.0: setting latency timer to 64 [7.921302] mtrr: type mismatch for e000,1000 old: write-back new: write-combining [7.921372] [drm] MTRR allocation failed. Graphics performance may suffer. [7.921596] i915 :00:02.0: irq 55 for MSI/MSI-X [7.921599] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [7.921652] [drm] Driver supports precise vblank timestamp