[mythtv-users] New Hardware Build Troubleshooting (Possible XFS Kernel Bug?)

[Paul Gallaway]

*Fixed*

On Wed, Jun 3, 2009 at 10:37 PM,  <f-myth-users at media.mit.edu> wrote:
> If this is a new build, what makes you think this has anything to do
> with software?  I'd check your RAM and power supply first.  (Since
> you say it tends to hard-lock on heavy disk access, I'm suspicious
> of one of your power supply rails, but really, it could even be poor
> heatsinking on a northbridge or something.)

That's a good point. An initial problem I had (tuner wouldn't tune)
was related to the mythtv binaries I was using as no amount of
deleting cards, removing/reinstalling the program would fix it. I
switched to a different repository and the problem went away. I hadn't
noticed the crashing until I fixed the first problem as the system
never ran long enough to reach the crash point. At the time it seemed
natural to think that fixing one mythtv problem only to find another
problem meant that there was a good chance it was still a mythtv
problem - but that's why I sent this email.

> Turn off CPU scaling.  I've seen RAM bugs with this.  Unlikely, but if
> the problem goes away, you have something.

Actually, dmesg shows that setting the cpufreq governor fails as it
doesn't recognize my processor (AMD Phenom II X3 720). This is
probably next on my list to figure out how to enable!

> If those succeed, try building the simplest filesystem you can (maybe
> ext3? ext2?) but leave the same number of disks spinning to load the
> power supply, and then try repeatedly compiling gcc and/or the kernel
> from it.  Put it in a script and run it for a day...
> You seem to be jumping to the most annoying
> conclusions about what might be wrong first.)

I didn't quite get the system stripped down to the point of running on
a single disk and doing the the compile stress test. My root, /home
directories and backup files are all ext3. As I needed the PC to
provide music over the weekend, I went ahead and set up the [long]
task of moving data around between my TB drives and backup drive so I
could convert my storage drives from xfs to ext4 (with the intent of
running your trial on Monday if it was unsuccessful). With the drives
now using the ext4 file system the problem appears to have resolved
itself. The system has been running since Sunday without a crash or
reboot. So I don't have the logs to say it was the xfs bug but
anecdotally I can say it appears to have been the bug. Thanks again
for the response and the test idea.

So to anyone else out running a ~2.6.29 kernel using xfs for storage
and you're wondering why your system is crashing, look at running
without your xfs drives as a test (hint, temporarily add some other
directory that is unaffected to the default storage group for minimal
interruption). So far no problems with ext4, just modprob ext4 while
running an appropriate kernel (2.6.28 or higher) and then you can
reformat the drive with a program like gparted or cli.