[vdr] DXR3 jams the whole system
sami.hakkarainen at gmail.com
Thu Apr 21 14:54:56 CEST 2005
What seems to be the weirdest thing about this is that VDR 1.3.12 +
DXR3 0.23-pre1 doesn't have this jamming problem. It does crash a lot,
especially when viewing recordings, but it never takes the whole
system down like the newer versions do. What is done differently in
the newer versions that could cause this kind of behaviour? I think
I'll soon be desperate enough to go through the old CVS versions one
by one to find out when the changes that cause this have been made. It
can't be a hardware issue if the older versions work fine, can it?
On 4/19/05, Jukka Tastula <jukka.tastula at kotinet.com> wrote:
> On Tuesday 19 April 2005 19:00, Sami Hakkarainen wrote:
> > issues. If you have any suggestions, need more details, anything, this
> > is a desperate man writing, please reply.
> If the whole system hangs that means there's a problem with some driver in
> the kernel or the hardware, not vdr. But then you say it still responds
> to ping so there's no telling if it's just some runaway program spawning
> processes as fast as it can making the system too busy (perhaps a good
> idea to set the sshd process to -20 priority to make sure it can always do
> what it needs to do) to respond before timeout or if some part of the
> kernel actually decided to stop working.
> "It just hangs" is not very much to go on but I guess the basic things to
> check are still worth mentioning, again.
> First disable the ACPI and APIC (and MSI if you were crazy enough to
> compile it in) irq nonsense (ie boot with pci=noacpi noapic). Most (all?)
> distributions enable these two troublemakers by default. I honestly have
> no idea why. Then (after you disabled the acpi pci irq routing thing, very
> important) check for irq conflicts in lspci. Change cards around in the
> pci slots until you find a non-conflicting setup. Sure, they should
> happily share irqs but try tell that to my computers; they're not
> listening to the theory at all. Yours probably isn't either.
> If you're using an AMD K7 cpu you probably want to disable athlon power
> saving with athcool in case your board (like both my boards (epox boards
> btw)) enables it by default. If you have this you've probably noticed it
> already. For me it causes constant dropouts in video and audio. Took a
> while to figure out what was going on. Sometimes the box just locks hard
> with this thing enabled. I didn't think it possible that some manufacturer
> would be stupid enough to enable this nonsense by default. Just leave it
> to epox, they'll manage to get it wrong.
> Make sure you're using the latest em8300 from cvs. Disable NPTL if your
> system was compiled with it. Try different kernel versions, not just
> different vdr versions. Vanilla kernels are probably the best place to
> start testing. On my vdr box 2.6.9+cvs lirc+cvs em8300+cvs dvb-kernel
> appears to be a very stable combination. Anything above that and it's five
> days and the kernel decides to disable the dvb card's irq.
> It would also be very interesting to see if there are any clues printed on
> the console or what kind of processes are running on the system when this
> "crash" occurs. You'll probably need a monitor and keyboard connected to
> the system to get this though.
> vdr mailing list
> vdr at linuxtv.org
More information about the vdr