> I even didn't have a backtrace.

> I even didn't have a backtrace.

[Igor Podlesny]

2008/12/29 Igor Podlesny <for.poige+linux@gmail.com>:
> 2008/12/29 Willy Tarreau <w@1wt.eu>:
>> On Mon, Dec 29, 2008 at 12:39:55PM +0700, Igor Podlesny wrote:
> [...]
>> Well, I won't say that I find them 100% rock solid, but you seem to be
>> able to reproduce a lot of serious issues. Have you filed bug reports
>> to get them fixed ? You cannot expect people to fix bugs they're not
>> aware of !
>
>        I even didn't have a backtrace. What's to fill in? "It just crashed 2
> times, Dear Bugzilla"? :-)
>
	BTW, I wonder -- can the kernel store crash related information (if
any) in RAM, at certain addresses, so it can survive warm reboot and
get displayed "in dmesg" on the next boot?

-- 
End of message. Next message?

Re: > I even didn't have a backtrace.

[Igor Podlesny]

2008/12/29 Sitsofe Wheeler <sitsofe@yahoo.com>:
> Igor Podlesny wrote:
>>
>>        BTW, I wonder -- can the kernel store crash related information (if
>> any) in RAM, at certain addresses, so it can survive warm reboot and
>> get displayed "in dmesg" on the next boot?
>
> Perhaps you are thinking of kdump - http://lwn.net/Articles/108595/ ?

	Similar, but no exactly. I just thought that unlikely BIOS erases
memory content during "fast checks", so kernel diagnostic could be
left at certain addresses, probably duplicated for safety, and newly
booted kernel could check if there were something left for it in RAM.
That's simpler than kdump/kexec, the question is only whether memory
is really left intact during BIOS work, at least partly.

-- 
End of message. Next message?

Re: > I even didn't have a backtrace.

[Sitsofe Wheeler]

Igor Podlesny wrote:
> 	Similar, but no exactly. I just thought that unlikely BIOS erases
> memory content during "fast checks", so kernel diagnostic could be

My understanding is that the only part of the BIOS that doesn't get 
cleared over a reboot (the hardware clock) is already being abused for 
suspend tracing  - 
http://mjmwired.net/kernel/Documentation/power/s2ram.txt .

Re: > I even didn't have a backtrace.

[Matthew Garrett]

On Mon, Dec 29, 2008 at 12:59:57PM +0000, Sitsofe Wheeler wrote:
> Igor Podlesny wrote:
> >	Similar, but no exactly. I just thought that unlikely BIOS erases
> >memory content during "fast checks", so kernel diagnostic could be
> 
> My understanding is that the only part of the BIOS that doesn't get 
> cleared over a reboot (the hardware clock) is already being abused for 
> suspend tracing  - 
> http://mjmwired.net/kernel/Documentation/power/s2ram.txt .

That's the only part of the system that's guaranteed to persist over a 
power cycle. You probably have a little more flexibility with a warm 
reboot.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: > I even didn't have a backtrace.

[Bodo Eggert]

Igor Podlesny <for.poige+linux@gmail.com> wrote:
> 2008/12/29 Sitsofe Wheeler <sitsofe@yahoo.com>:
>> Igor Podlesny wrote:

>>>        BTW, I wonder -- can the kernel store crash related information (if
>>> any) in RAM, at certain addresses, so it can survive warm reboot and
>>> get displayed "in dmesg" on the next boot?
>>
>> Perhaps you are thinking of kdump - http://lwn.net/Articles/108595/ ?
> 
> Similar, but no exactly. I just thought that unlikely BIOS erases
> memory content during "fast checks", so kernel diagnostic could be
> left at certain addresses, probably duplicated for safety, and newly
> booted kernel could check if there were something left for it in RAM.
> That's simpler than kdump/kexec, the question is only whether memory
> is really left intact during BIOS work, at least partly.

You may want to read "ISA System Architecture
 By Tom Shanley, Don Anderson, John Swindle, MindShare, Inc"

http://books.google.com/books?id=iXE6mwUCNWQC&pg=PA110&lpg=PA112&ots=ZH_c88LEqd&dq=post+reset+flag+0072+0040&ie=ISO-8859-1&output=htmlhttp://books.google.com/books?id=iXE6mwUCNWQC&pg=PA112&lpg=PA112&dq=post+reset+flag+0072+0040&source=web&ots=ZH_c88LEqd&sig=3EbSpcxbKrPvd1ixhysJK4AuOrA&hl=en&sa=X&oi=book_result&resnum=1&ct=result

HTH.

Re: > I even didn't have a backtrace.

[Alan Cox]

One place to hide stuff is the upper areas of video ram as a lot of
videocards don't clear the ram on a crash/reboot. I used to use a 3Dfx
32Mb card as a buffer with good effect.

Alan

Re: > I even didn't have a backtrace.

[Daniel Barkalow]

On Mon, 29 Dec 2008, Igor Podlesny wrote:

> 2008/12/29 Igor Podlesny <for.poige+linux@gmail.com>:
> > 2008/12/29 Willy Tarreau <w@1wt.eu>:
> >> On Mon, Dec 29, 2008 at 12:39:55PM +0700, Igor Podlesny wrote:
> > [...]
> >> Well, I won't say that I find them 100% rock solid, but you seem to be
> >> able to reproduce a lot of serious issues. Have you filed bug reports
> >> to get them fixed ? You cannot expect people to fix bugs they're not
> >> aware of !
> >
> >        I even didn't have a backtrace. What's to fill in? "It just crashed 2
> > times, Dear Bugzilla"? :-)
> >
> 	BTW, I wonder -- can the kernel store crash related information (if
> any) in RAM, at certain addresses, so it can survive warm reboot and
> get displayed "in dmesg" on the next boot?

Usually, you get one of:

 - some bus is locked, and the CPU can't get kernel code from RAM, let 
   alone write anything anywhere
 - triple fault, and the system spontaneously reboots
 - system is unaware that anything's wrong, but nothing runs
 - any attempt to get data useful for debugging hangs
 - system is alive enough that you can interact with it and get info

That doesn't leave a big possibility for the kernel to determine that the 
system has crashed and put something in memory for a warm reboot to find. 
There isn't really any case where the kernel reboots intentionally in a 
context where it thinks the system is crashing but has the ability to do 
lots of information gathering.

About the only common reasons for the kernel to panic these days are a 
missing filesystem or hardware driver, such that it can't find a root 
partition or init, and these really ought to allow the user to debug 
interactively (at least scroll up and look at messages) unless the system 
is configured to reboot.

On your original question: your .config and boot dmesg, and anything 
similar about the situations (like, "both times I was running hwclock" or 
"I was copying big files over XFS..."). If you can trigger it reliably or 
at least repeatably, that's at least as good as a backtrace.

You might post the oopses from your kernel logs, too. Also, 
failing-to-suspend tends to leave useful messages in dmesg and not be too 
hard to explain (at least as compared to failing to resume), and there's 
been a push for getting all drivers to support suspending, even ones for 
desktop hardware, so that can probably be fixed (of course, relatively few 
people actually try suspending desktops, so it's easier for bugs to go 
unnoticed there).

	-Daniel
*This .sig left intentionally blank*