Markus Rechberger schrieb: > On 8/8/07, Sven Mueller <linux-dvb@xxxxxxxxx> wrote: >> Markus Rechberger schrieb: >>> On 8/6/07, Sven Mueller <linux-dvb@xxxxxxxxx> wrote: >>>> Oliver Endriss wrote on 05/08/2007 06:14: >>>>> Sven Mueller wrote: >>>>>> Oliver Endriss wrote on 01/08/2007 00:27: >>>>>>> Sven Mueller wrote: >>>>>>>> Hi. >>>>>>>> >>>>>>>> I don't know which hardware interrupts those are mapped from/to and >>>>>>>> currently don't know how to find out. >>>>>>>> >>>>>>>> If you need any further data to give a helpful answer, don't hesitate >>>> to >>>>>>>> ask. >>>>>>> Which firmware are you using? >>>>>> Most recent AFAICT (261f). >>>>> Nope, the most recent firmware is >>>>> http://linuxtv.org/downloads/firmware/dvb-ttpci-01.fw-2622 >>>> I tested that one as well, but I wasn't sure wether it was actually >>>> newer, since the downloads I could find on the Technotrend pages only >>>> had 261f IIRC. >>>> >>>>>>> Does the VDR recover if you wait some time (1 or 2 minutes) before you >>>>>>> press the next key? >>>>>> Sometimes (if I interpret things correctly though, this is due to an >>>>>> internal watchdog in VDR triggering a restart, which now, on my system, >>>>>> includes module unload/reload due to my problems). >>>>> With recent firmware VDR should recover _without_ emergency exit. >>>> It might do, I currently don't have much time to do tests (and, to be >>>> honest: not much inclination to do tests just to find out if and how the >>>> system recovers after a failure). >>>> >>>>>>> You might also try whether this driver improves things: >>>>>>> http://linuxtv.org/hg/~endriss/v4l-dvb-av7110-refactoring/ >>>>>> Will take a look into that later once I find some time. >>>>>> >>>>>> One think fixed the problem for me, for now though: >>>>>> noapic nolapic >>>>>> on the kernel commandline (grub). >>>>> Are you sure that this did not disable SMP? >>>> Hmm, /proc/cpuinfo reports two CPUs and I had two processes (just some >>>> Perl processes with while loops counting up until a certain file was >>>> created) for which top reported near 100% CPU usage. So I'm quite >>>> certain it didn't disable SMP. >>>> >>>>>> However the system runs stable in every other aspect, so it seems to me >>>>>> that enabling apic/lapic does something which the dvb_ttpci driver >>>>>> doesn't handle properly on SMP systems. >>>>> There is no special handling for SMP or non-SMP systems. >>>>> Of course there might be a bug which will only show up with SMP. :-( >>>> Right, that is what I thought of first, too, but as said I'm almost 100% >>>> sure I now have a stable system running with SMP (though without >>>> APIC/LAPIC). So the bug (which I think is somewhere in dvb_ttpci) seems >>>> to be triggered by some LAPIC or APIC specific code somewhere in the >>>> kernel (i.e. not necessarily in the dvb_ttpci driver). >>>> >>> can you submit some logs? >>> >>> cat /proc/interrupts >>> cat /proc/cpuinfo >> >> sven@vdr:~$ cat /proc/cpuinfo >> processor : 0 >> vendor_id : GenuineIntel >> cpu family : 6 >> model : 15 >> model name : Genuine Intel(R) CPU 2160 @ 1.80GHz >> stepping : 2 >> cpu MHz : 1799.947 >> cache size : 1024 KB >> physical id : 0 >> siblings : 2 >> core id : 0 >> cpu cores : 2 >> fdiv_bug : no >> hlt_bug : no >> f00f_bug : no >> coma_bug : no >> fpu : yes >> fpu_exception : yes >> cpuid level : 10 >> wp : yes >> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge >> mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm >> constant_tsc pni monitor ds_cpl est tm2 cx16 xtpr lahf_lm >> bogomips : 3603.26 >> >> processor : 1 >> vendor_id : GenuineIntel >> cpu family : 6 >> model : 15 >> model name : Genuine Intel(R) CPU 2160 @ 1.80GHz >> stepping : 2 >> cpu MHz : 1799.947 >> cache size : 1024 KB >> physical id : 0 >> siblings : 2 >> core id : 1 >> cpu cores : 2 >> fdiv_bug : no >> hlt_bug : no >> f00f_bug : no >> coma_bug : no >> fpu : yes >> fpu_exception : yes >> cpuid level : 10 >> wp : yes >> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge >> mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm >> constant_tsc pni monitor ds_cpl est tm2 cx16 xtpr lahf_lm >> bogomips : 3599.67 >> >> sven@vdr:~$ cat /proc/interrupts >> CPU0 CPU1 >> 0: 22029407 0 XT-PIC timer >> 2: 0 0 XT-PIC cascade >> 3: 5970970 0 XT-PIC uhci_hcd:usb1, saa7146 (0) >> 6: 5 0 XT-PIC floppy >> 7: 1 0 XT-PIC parport0 >> 9: 0 0 XT-PIC acpi >> 10: 8232319 0 XT-PIC uhci_hcd:usb2, >> uhci_hcd:usb4, HDA Intel, eth0 >> 11: 174586011 0 XT-PIC uhci_hcd:usb3, >> ehci_hcd:usb5, libata, eth1, saa7146 (1) >> 14: 4995721 0 XT-PIC ide0 >> 15: 788051 0 XT-PIC ide1 >> NMI: 0 0 >> LOC: 21525478 21525481 >> ERR: 0 >> MIS: 0 >> >>> are you sure the irqs are balanced over the cores? >> So to the contrary, the IRQs are definitely not balanced over the cores. >> At least not with LAPIC and APIC disabled. >> >> I can't say what happens with LAPIC and APIC enabled, but I will post >> that information as soon as I can. > > there's also a tool available for irqbalancing, I also have apic and > lapic disabled at bootup although balancing seems to work with my > system. > So you might have a look at irqbalance and retry with it. Hmm, I'm not sure what you are trying to solve with that (since the system works quite nicely after I disabled LAPIC/APIC), but irqbalance doesn't seem to be the right tool. Its description says: Daemon to balance irq's across multiple CPUs on systems with the 2.4 or 2.6 kernel. This can lead to better performance and IO balance on SMP systems. Useful mostly just for 2.4 kernels, or 2.6 kernels with CONFIG_IRQBALANCE turned off. However my kernel config enables CONFIG_IRQBALANCE. regards, Sven _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
