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
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
-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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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
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
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.
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:
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.
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
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
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
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
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
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
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:
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.
[...]
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
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
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:
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
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
#
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
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
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
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
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
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
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
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
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
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
#
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
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
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.
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
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.,
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
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
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
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
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
--
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
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
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
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.
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
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
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.
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:
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
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
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
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.
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
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
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:
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
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
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
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
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?
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).
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
[
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
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
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
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
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
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
83 matches
Mail list logo
