[PlanetCCRMA] Weird problems using RT on FC6

Fernando Lopez-Lezcano nando@ccrma.Stanford.EDU
Sun May 27 11:28:01 2007


[I'm copying Ingo Molnar just in case he has heard of this before]

On Sun, 2007-05-27 at 19:04 +0200, Stephan Neuhaus wrote:
> Fernando Lopez-Lezcano wrote:
> > Hmmm, sounds bad indeed and is probably a bug in the stock kernel with
> > your particular hardware configuration (as it happens in both the Fedora
> > kernel and the Planet CCRMA kernel with the rt patch).
> 
> It certainly looks that way.  That would be bad, however, so I'll just 
> home that there is an easy fix :-)
> 
> >  What is the  output of /sbin/lspci?
> 
> 00:00.0 Host bridge: VIA Technologies, Inc. P4M890 Host Bridge
> 00:00.1 Host bridge: VIA Technologies, Inc. P4M890 Host Bridge
> 00:00.2 Host bridge: VIA Technologies, Inc. P4M890 Host Bridge
> 00:00.3 Host bridge: VIA Technologies, Inc. P4M890 Host Bridge
> 00:00.4 Host bridge: VIA Technologies, Inc. P4M890 Host Bridge
> 00:00.5 PIC: VIA Technologies, Inc. P4M890 I/O APIC Interrupt Controller
> 00:00.6 Host bridge: VIA Technologies, Inc. P4M890 Security Device
> 00:00.7 Host bridge: VIA Technologies, Inc. P4M890 Host Bridge
> 00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI Bridge
> 00:02.0 PCI bridge: VIA Technologies, Inc. P4M890 PCI to PCI Bridge 
> Controller
> 00:03.0 PCI bridge: VIA Technologies, Inc. P4M890 PCI to PCI Bridge 
> Controller
> 00:0a.0 Multimedia audio controller: VIA Technologies Inc. ICE1712 
> [Envy24] PCI Multi-Channel I/O Controller (rev 02)
> 00:0f.0 IDE interface: VIA Technologies, Inc. VT8237A SATA 2-Port 
> Controller (rev 80)
> 00:0f.1 IDE interface: VIA Technologies, Inc. 
> VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 07)
> 00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 
> Controller (rev a0)
> 00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 
> Controller (rev a0)
> 00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 
> Controller (rev a0)
> 00:10.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 
> Controller (rev a0)
> 00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86)
> 00:11.0 ISA bridge: VIA Technologies, Inc. VT8237A PCI to ISA Bridge
> 00:11.7 Host bridge: VIA Technologies, Inc. VT8251 Ultra VLINK Controller
> 00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] 
> (rev 7c)
> 00:13.0 PCI bridge: VIA Technologies, Inc. VT8237A Host Bridge
> 02:00.0 VGA compatible controller: ATI Technologies Inc RV516 XT Radeon 
> X1600 Series Primary
> 02:00.1 Display controller: ATI Technologies Inc RV516 XT Radeon X1600 
> Series Secondary
> 04:01.0 Audio device: VIA Technologies, Inc. VIA High Definition Audio 
> Controller (rev 10)
> 
> > Does the machine run fine with any other operating system? This could be
> > something as simple as a bad ATA cable...
> 
> The machine is rock solid both under Linux (Stock FC6 kernel) and 
> Windows XP, as long as I don't launch jackd.  I haven't tried any other 
> RT application, but the same problems happen with the RT kernel even 
> when I don't use jackd.  Since this might be confusing, here is a little 
> diagram:
> 
>                  jackd   | no jackd
> -------------+----------+---------
> Stock kernel | unstable | stable
> -------------+----------+---------
> RT kernel    | unstable | unstable
> 
> I'm pretty sure that it has to do with the RT subsystem.  Should I post 
> this to any Fedora mailing lists?

Well, when you are running the stock kernel there's no rt patch
included. What happens in both cases is that jackd runs threads with
realtime priority. Which would suggest that something in the kernel is
being interrupted or preempted by a jack realtime thread when it
shouldn't (that is, some critical thing in the kernel is not being
properly protected against preemption - but I'm just guessing). When you
run the rt kernel the interrupt handlers run with realtime privileges
and then the problem does not depend on running jackd. And that is only
happening on your particular hardware configuration. 

You could try running jackd under the Fedora kernel without the "-R"
option to confirm this is the problem (but of course that defeats the
usefulness of jackd). 

Hmmm, I would post this info to the linux kernel mailing list... it is
unlikely this is Fedora specific. 

Ingo: this is the original thread:
http://cm-mail.stanford.edu/pipermail/planetccrma/2007-May/013271.html

-- Fernando