[linux-dvb] Problems with APIC/LAPIC

[Markus Rechberger]

On 8/8/07, Sven Mueller <linux-dvb at incase.de> wrote:
> Markus Rechberger schrieb:
> > On 8/6/07, Sven Mueller <linux-dvb at incase.de> 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 at 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 at 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