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

2012-11-03 Thread Ingo

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

2012-11-02 Thread Per Foreby


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

2012-10-26 Thread Javier Cantero

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

2012-10-25 Thread Ingo

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

2012-10-25 Thread Ingo

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

2012-10-23 Thread Per Foreby


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

2012-10-23 Thread Jonathan Nieder

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

2012-10-23 Thread Per Foreby


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

2012-10-23 Thread Per Foreby


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

2012-10-23 Thread 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:

 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

2012-10-22 Thread Ben Hutchings

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

2012-10-21 Thread Per Foreby

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

2012-10-21 Thread Ingo

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

2012-10-21 Thread Ingo

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

2012-10-21 Thread Per Foreby


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

2012-10-20 Thread Per Foreby


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

2012-10-20 Thread Per Foreby


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

2012-10-20 Thread Jonathan Nieder

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

2012-10-19 Thread Per Foreby


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

2012-10-18 Thread Ingo

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

2012-10-18 Thread Jonathan Nieder

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: Intel HD 4000 (Ivy Bridge) graphics freeze

2012-10-10 Thread Ingo

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

2012-10-10 Thread Jonathan Nieder

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

2012-10-07 Thread Javier Cantero


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

2012-10-07 Thread Ingo

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

2012-10-07 Thread Ben Hutchings

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

2012-10-06 Thread Ingo

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

2012-10-06 Thread Per Foreby


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: Intel HD 4000 (Ivy Bridge) graphics freeze

2012-10-05 Thread Jonathan Nieder

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

2012-10-05 Thread Per Foreby


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

2012-10-05 Thread 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.


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

2012-10-05 Thread Per Foreby


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: Intel HD 4000 (Ivy Bridge) graphics freeze

2012-10-04 Thread Jonathan Nieder

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

2012-10-01 Thread Bjørn Mork

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