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
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
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
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,
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
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
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.
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.
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
60 matches
Mail list logo