[08:58] <thoma> Good morning ;-)
[08:59] <thoma> Someone familiar with Machine Check Exceptions ?
[09:20] <apw> thoma, there is bound to be someone, if you have specific question do just ask
[09:25] <thoma> apw: Maybe you remember that we both had already little brainstorming about kernel issues.
[09:26] <thoma> Before blaming only the kernel I looked for alternative failure sources, e.g. hardware, since I saw kernel panic 2 or 3 times.
[09:28] <thoma> So I decided to watch what MCE logs - but it looks as if I were too stupid to analyze the mcelogs :-(
[09:29] <thoma> I would need some help with that ...
[09:29] <thoma> ... even too find the logs or to specify where to log ;-)
[09:31] <amitk> thoma: just install and run mcelog to parse and dump the mce logs in human-readable format (or have you done that already?)
[09:31] <thoma> mcelog should be up and running - but I don't see any output of it :-(
[09:32] <thoma> Don't even see how to query its status :-(
[09:32] <amitk> thoma: so there is no exceptions reported
[09:34] <thoma> As far as I understood there is a buffer that is written each time an exception is detected ?
[09:34] <thoma> How can I query this buffer ?
[09:35] <amitk> thoma: man mcelog
[09:37] <thoma> Would lead me to something like: mcelog /dev/mcelog ?
[09:41] <thoma> ... assumed a so called "warm reset" after the panic. What is - technically - a "warm reset" unlike a cold reset ?
[09:58] <apw> a warm reset is a reset from already running, a cold reset is normally the first reset after power on
[09:58] <apw> in principle some things can be optimised away on a warm reset, though little is
[12:26] <thoma> apw: If there was no chance for warm reset (each time the system was really unresponsible, means no more input possible to force reboot), will mcelog ever log anything ???
[13:14] <kenjo> What is the procedure to get the perf tool for a mainline image ?? 
[13:14] <kenjo> I need the corresponding linux-tools-3.19.0-18 for the mainline version 4.0.4 but its not on the servers.
[14:04] <thoma> ps
=== JanC_ is now known as JanC
[18:24] <ubuntu-kernel978> was looking for linux-image-3.13.0-39-generic-dbgsym
[18:24] <ubuntu-kernel978> can somebody point me to linux-image-3.13.0-39-generic-dbgsym?
[18:30] <infinity> ubuntu-kernel978: Long gone by now.  Until very recently, we only kept dbgsyms for current versions, and you're seven months out of date.
[18:39] <ubuntu-kernel978>  is there a way I can build one?
[18:40] <Krampus> Does the current Ubuntu kernel have the fix for the Haswell Futex bug baked into it?
[18:42] <ubuntu-kernel978> infinity: is there a way I can build one for the old version of kernel I am using?
[18:55] <bjf> Krampus, do you have an upstream commit id for the fix? and which series are you interested in? vivid?
[18:57] <Krampus> bjf: I don't, but it was part of 3.19.  It looks like it's in there, though unless the linux-source package for 3.19.0 in Vivid isn't the one that corresponds to the kernel. :)
[18:58] <Krampus> bjf: I'm going to grab 4.0.4 from the mainline ppa and see if that makes the problem go away.  I think I have the patch, but it sounds too much like the behavior i'm seeing.
[19:00] <bjf> Krampus, it should be there
[19:30] <infinity> ubuntu-kernel978: Not really, given than rebuilding it wouldn't produce a binary identical to what you're running.
[19:31] <infinity> ubuntu-kernel978: But the real question is, why are you okay with skipping seven months' worth of bugfixes and security updates?
[19:31] <infinity> ubuntu-kernel978: If you upgrade to the current kernel, and you still have a crash to debug, there are symbols available for that one.
[19:31] <infinity> s/given than/given that/
=== Elimin8r is now known as Elimin8er