[mythtv-users] Could realtime commercial flagging cause hard lockup/freeze/hang?

[Roger Heflin]

Greg Grotsky wrote:
> On Tue, Jun 3, 2008 at 10:10 PM, Brian Foddy <bfoddy at visi.com> wrote:
> 
>>  I'd guess its some kernel deadlock with a device driver.  What tuner card
>> is (are) running during the process.  If the machine is really busy, and
>> you have some of the kernel preempt settings on, and there is a bug
>> in the driver, it could cause a hard crash.
>>
> 
> I am using a pchdtv HD-3000 tuner using DVB.  If that was the case should it
> spit something out in the syslog?  Maybe there's a setting somewhere I can
> flip to increase verbosity when logging...?
> 
> 
>> What type of computer?  Multi-core, dual CPU?  Using SMP kernel?
>> These can cause driver bugs more readily.  If its an SMP instance,
>> try your test with SMP disabled (there is a kernel param that will do
>> this).
>>
> 
> It's an AMD X2 4200+ cpu, with SMP enabled in the kernel.  I'm using a
> custom built kernel so I'd have to recompile it without SMP enabled but
> that's something to try, it has been working fine for at least a year with
> this processor.  I previously had a AMD 3200+ single core and it worked for
> like three years with this processor.
> 
> 
>> The commercial scan itself is probably (haven't looked at code, but
>> I can't imagine) doing anything other than standard file I/O using
>> normal calls, so root or not, I don't see it the problem.  But if it
>> keeps the system busy, it could cause other faults to show up.
>>
>> In general, hard lock ups / crashes are due to faulty / buggy device
>> drivers
>> or hardware failures.
>>
> 
> Yeah, your arguement seems sound.  So far the machine has been running for
> 2.5 days without a crash after removing the "start commercial detection as
> soon as recording starts" option.  Maybe it is just that I'm spreading out
> the file I/O calls so they aren't on top of one another.
>

Have you made *ANY* hardware changes of any type?   I recently made a change to 
move a couple of my drives from a SIL controller to the faster on MB connected 
VIA sata controller, and this was apparently a mistake as the VIA chipset/sata 
controller does not appear to be able to properly play nice on the processor bus 
with other PCI devices, and eventually causes a wide variety of crashes/reboots 
and other failures, and did not show up for a week or two but when it started 
would cause a reboot, and then shortly after it got back up the raid5 rebuilding 
would cause more reboots and/or other things to fail.   Pretty ugly, once I 
moved things off of the via sata controller back to the way it was things became 
stable, but given the amount of time for the failure to show up it was not at 
all obvious that was the cause.

Not a change that I would have expected to cause that bad of result, but 
changing anything (even bios settings) can find a previous undiscovered hardware 
"feature". that may not show up for a while, and only shows up under certain 
conditions.  The condition mine required was using all 4 disks drives (raid 
rebuild)  and trying to record from all of the 3 PCI tuner cards at the same 
time, otherwise it was not obviously unstable.

                                   Roger