Bug#700333: Stack trace

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 debian-bugs-dis

Bug#700333: Stack trace

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 hibernat

Bug#700333: Stack trace

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

Bug#700333: Stack trace

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 kerne

Bug#700333: Stack trace

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 whic

Bug#700333: Stack trace

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

Bug#700333: Stack trace

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

Bug#700333: Stack trace

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

Bug#700333: Stack trace

+ 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

Bug#700333: Stack trace

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 .

Bug#700333: Stack trace

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

Bug#700333: Stack trace

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

Bug#700333: Stack trace

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 screen

Bug#700333: Stack trace

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 sc

Bug#700333: Stack trace

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

Bug#700333: Stack trace

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

Bug#700333: Stack trace

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 not

Bug#700333: Stack trace

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 ]