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.
> >
> > Her
> 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. B
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 e
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 m
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 tre
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 be
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 fo
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)
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
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 cau
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-Febru
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.
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 followin
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
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.
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 do
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-
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
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 e
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.
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://intellinuxgr
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
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
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 thi
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
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-
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
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-bug
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 w
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 the
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-initr
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.
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-initr
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 controlle
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 the
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 int
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.
Pr
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
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.
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 allo
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_d
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 ker
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)
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.
>
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. La
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...@li
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 freez
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.d
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, emai
Per Foreby 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 wha
On 2012-10-02 00:45, Bjørn Mork wrote:
Per Foreby 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 b
Per Foreby 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"
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
log
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 se
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
> [
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)
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?
n
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, o
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 d
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 w
60 matches
Mail list logo
