Bug#700333: Stack trace

2013-04-30 Thread vitalif
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-kernel-r

Bug#700333: Stack trace

2013-04-28 Thread vitalif
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

2013-04-27 Thread vitalif
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

2013-04-20 Thread vitalif
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

2013-03-07 Thread vitalif
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-kernel-requ...@lists.debian.org with a subject of "unsubscribe

Bug#700333: Stack trace

2013-03-06 Thread vitalif
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

2013-03-05 Thread vitalif
>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

2013-03-05 Thread vitalif
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 ]

Bug#700333: Anyone?

2013-02-15 Thread vitalif
Anyone? The bug still persists in 3.7.8-1~experimental.1. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/6cab98d3f95e5927ce5ba43edb197...@yourcmc.ru