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. regards, Sven _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
