[mythtv-users] Playback hung

[Will Dormann]

On 3/18/14, 12:53 AM, Dick Steffens wrote:
> I was just trying to be polite and not overload the list with a long
> log. The entire collection of events logged at 19:45:03 is included
> below. I've started with the entry before it and ended with the entry
> after it.
> 
> I do appreciate your willingness to wade through this collection.



Not a problem.   And your post wasn't too much for the list, IMO.   In
cases where the full log might be required, I think the recommended
route is to post to pastebin.

In the case of a kernel panic (or other crash, really) the call trace is
what tells you how you got there.  In your case:

> Call Trace:
> [<ffffffff811a8e4a>] ? traverse+0x5a/0x220
> [<ffffffff811a9830>] ? seq_put_decimal_ll+0x60/0x60
> [<ffffffff811a9b85>] seq_read+0x355/0x400
> [<ffffffff811a9830>] ? seq_put_decimal_ll+0x60/0x60
> [<ffffffff811e8202>] proc_reg_read+0x82/0xc0
> [<ffffffff81187950>] vfs_read+0xb0/0x180
> [<ffffffff81187a6a>] sys_read+0x4a/0x90
> [<ffffffff816a6a69>] system_call_fastpath+0x16/0x1b 

The other things like register values aren't quite as useful.  The way
that I interpret the above is that something failed filesystem-related.
  The question is how the system got into that state.

Perhaps from a live CD (to avoid using your own filesystem / disk), in
this order:
1) Run memtest86 to look for memory or related hardware issues
2) Run smartmontools (e.g. smartctl -a /dev/sda) to look for HD-related
hardware problems.
3) Check (e.g. fsck) all filesystems on your machine for errors.

Errors in 1) or 2) can cause problems with 3).



-WD