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: 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: 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: 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: 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: 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: 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: 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
