I merged a slightly better fix, you all were on cc. It's going into
3.10 and it's tagged stable, so it will show up in stable kernels
soon.
Thanks for the fix!
But where did you post it - on LKML?
(I didn't see it because I'm not subscribed to LKML?)
--
To UNSUBSCRIBE, email to
When you do a suspend/resume cycle.
OK, yes, I've found it there.
The bug says The photo shows a BUG in hrtimer_interrupt() after
making
the hibernation image and while resuming the non-boot CPUs. so I'm
guessing with Thomas' patch it suspends fine now?
Yeah, now I'm using a patched kernel
On Sun, Apr 28, 2013 at 05:26:07PM +0400, vita...@yourcmc.ru wrote:
When you do a suspend/resume cycle.
OK, yes, I've found it there.
The bug says The photo shows a BUG in hrtimer_interrupt() after
making
the hibernation image and while resuming the non-boot CPUs. so I'm
guessing with
On Sun, 28 Apr 2013, Borislav Petkov wrote:
On Sun, Apr 28, 2013 at 05:26:07PM +0400, vita...@yourcmc.ru wrote:
When you do a suspend/resume cycle.
OK, yes, I've found it there.
The bug says The photo shows a BUG in hrtimer_interrupt() after
making
the hibernation image and while
Looks like we can't do anything about that in the HPET code itself.
Vitaliy, could you try that patch ?
Thanks, I've tried it several days ago (and still using a patched
kernel :)) - the box survives.
But at which moment should I check for Spurious interrupt in dmesg?
--
To UNSUBSCRIBE,
On Sat, Apr 27, 2013 at 07:08:42PM +0400, vita...@yourcmc.ru wrote:
Looks like we can't do anything about that in the HPET code itself.
Vitaliy, could you try that patch ?
Thanks, I've tried it several days ago (and still using a patched
kernel :)) - the box survives.
But at which moment
On Mon, 22 Apr 2013, Thomas Gleixner wrote:
With the patch below, the box should survive and we should see a
Spurious HPET timer interrupt on HPET timer... entry in dmesg.
That's a first workaround to confirm my theory. I'll look into the
HPET code how we can avoid that at all.
Looks
On Sun, 21 Apr 2013, Borislav Petkov wrote:
+ tglx.
On Sun, Apr 21, 2013 at 01:38:33AM +0400, vita...@yourcmc.ru wrote:
Stack trace picture is here:
http://vmx.yourcmc.ru/var/pics/IMG_20130306_141045.jpg
Vitaliy reported that his system crashes when suspending to disk.
This
was a
Stack trace picture is here:
http://vmx.yourcmc.ru/var/pics/IMG_20130306_141045.jpg
Vitaliy reported that his system crashes when suspending to disk.
This
was a regression from 3.2 to 3.7, and remains in 3.8. Some details
of
this system are in the bug log at http://bugs.debian.org/700333.
+ tglx.
On Sun, Apr 21, 2013 at 01:38:33AM +0400, vita...@yourcmc.ru wrote:
Stack trace picture is here:
http://vmx.yourcmc.ru/var/pics/IMG_20130306_141045.jpg
Vitaliy reported that his system crashes when suspending to disk.
This
was a regression from 3.2 to 3.7, and remains in 3.8. Some
On Wed, 2013-03-06 at 15:27 +0400, vita...@yourcmc.ru wrote:
[...]
Stack trace picture is here:
http://vmx.yourcmc.ru/var/pics/IMG_20130306_141045.jpg
Vitaliy reported that his system crashes when suspending to disk. This
was a regression from 3.2 to 3.7, and remains in 3.8. Some details of
Hi Ben!
Did the stack help you to identify something?
Enabling non-boot CPUs seems suspicious to me - does that mean
instead of writing an image to disk and hibernating it's trying to
resume?
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of
No, but I think this kernel parameter will help:
pause_on_oops=
Halt all CPUs after the first oops has been printed for
the specified number of seconds. This is to be used if
your oopses keep scrolling off the
Hello
I've booted with no_console_suspend and got the stack trace, however
it's from 3.8-aptosid kernel. The problem with 3.8 is the same as with
3.7.
Can someone please help me - what does this stack mean?
Kernel panic - not syncing: Fatal exception in interrupt
[ cut here
On Tue, 2013-03-05 at 14:19 +0400, vita...@yourcmc.ru wrote:
Hello
I've booted with no_console_suspend and got the stack trace, however
it's from 3.8-aptosid kernel. The problem with 3.8 is the same as with
3.7.
Can someone please help me - what does this stack mean?
It means nothing
[Please reply-to-all.]
On Wed, Mar 06, 2013 at 12:25:45AM +0400, vita...@yourcmc.ru wrote:
Hi Ben!
It means nothing very much. How about the stack trace *before* this
line:
The problem is that the maximum available VESA mode is 1400x1050 on
my laptop and the stack is very long, and
It means nothing very much. How about the stack trace *before*
this
line:
The problem is that the maximum available VESA mode is 1400x1050 on
my laptop and the stack is very long, and obviously I can't scroll
it after a kernel panic :-)
How can I get to previous lines of it? :-)
There is
On Wed, 2013-03-06 at 01:49 +0400, vita...@yourcmc.ru wrote:
It means nothing very much. How about the stack trace *before*
this
line:
The problem is that the maximum available VESA mode is 1400x1050 on
my laptop and the stack is very long, and obviously I can't scroll
it after a
18 matches
Mail list logo
