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