This is a not good, as in bad:[, sign; it may have to do with a driver, possibly the driver for the Pi's SMSC ethernet controller, probably something more obscure since it likely isn't something that's affected many people.
Those console messages are from the kernel, and that final one only occurs once in the kernel source, in kernel/sched/idle_task.c (bare with me for a bit if this is beginning to sound like gobbledygook). It's been around for at least a decade (probably closer to two) but there are surprisingly few references to it either in the linux kernel mailing list archive or online generally (and literally only a couple associated with "raspberry").
The "idle task" is one that runs when there's nothing else to do. Tasks, including this one, can be pre-empted so the CPU can be used to do something more urgent; they can also make themselves inactive (aka. idle), so something else can happen -- but not this one, because it's already "the idle task". It can't claim it has nothing to do, because it's what's supposed to happen when everything else has already said that. It should just keep doing nothing until pre-empted.
However, a kernelspace programming error could produce a situation where the idle task does claim it's not busy and should be made inactive. Since that is definitely not supposed to happen, the idle task then reports this error and produces a stack trace, which is a list of references to recently executed code leading up the problem. That's all the stuff before the "bad" message". Stack traces lead into the past, so the last thing there is the earliest thing to happen (nb., the message timestamps on the left have nothing to do with that). At the top of the screen there's some references to the TCP/IP networking module, and further up would be whatever actually triggered the error (which is why I'm guessing the ethernet driver, but that is not necessarily so).
I can't say whether this error in itself should be fatal to the system but it could, and is at least related to the chain of events.
Anyway...
Looking at the timestamps on the left (seconds since boot, looks like 3-4 days), that stack trace took at least a second to produce and hopefully it or something relevant that happened right before it got logged. Although the new version of Raspbian (8) uses a new logger (journald) in addition to the old logger (rsyslogd), all versions still use the latter to log everything in plain text to /var/log/syslog, including stuff from the kernel.
Everything in syslog has a dated timestamp; for the kernel stuff this is in addition to the seconds since boot. E.g.,
Nov 14 12:20:38 localhost kernel: [142480.895132] [<ffffffff811db24a>] __mark_inode_dirty+0x24a/0x310
^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^
This is also part of a stack trace (noticeable because there's a <memory address> there too); they are not necessarily indications of a fatal error. Point being, yours will be tagged something like that (your hostname may not be localhost) and if you can't find it in syslog then you can at least find the last thing there (also, with a little math you can correspond kernel timestamps to syslog timestamps).
"The last thing there" will be immediately before the messages for the next reboot. The very first one of those will include localhost rsyslogd: [blah blah blah] starting (again your hostname may be different), then a long block of kernel messages tagged [ 0.000000]. On the Pi at that point the syslog timestamp will be Dec 31 since the clock has not been set properly.
