<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
  <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
  <META NAME="GENERATOR" CONTENT="GtkHTML/3.26.0">
</HEAD>
<BODY>
On Sat, 2009-10-10 at 15:41 +1300, Dylan Hall wrote:<BR>
<BLOCKQUOTE TYPE=CITE>
    On Fri, 2009-10-09 at 12:53 +1300, Steven Ellis wrote: 
    <BLOCKQUOTE TYPE=CITE>
<PRE>
On Thu, October 8, 2009 9:36 pm, Dylan Hall wrote:
&gt; I have a very odd problem, I have purchased two of the ASUS usb tuners
&gt; mentioned below in Stephen's post. I got the first, and was so impressed
&gt; I decided to get a second. This is where the problem starts...
&gt;
&gt; When I connect the second tuner the load average on the machine jumps to
&gt; 1 even when all the daemons etc have been shut down and the machine is
&gt; as idle as it's possible to get a linux box.
&gt;
&gt; I have VirtualBox running on the machine hosting a copy of ubuntu 9.04
&gt; server. With 1 tuner connected it's all good. Connect the second tuner
&gt; and the ping times to this virtual machine jump from &lt;1ms to 20-60ms
&gt; (varying all over the place).
&gt;
&gt; Despite the problems above, the second tuner appears to work fine.
&gt;
&gt; The server is a Core 2 Duo E6600 2.4Ghz, 6GB Ram, running ubuntu 9.04
&gt; server 32 bit, kernel version 2.6.28-15-server-52.
&gt;
&gt; I'm using the 32bit version of ubuntu because I'm testing SageTV for
&gt; linux which only ships with 32bit binaries. I have PAE enabled to get
&gt; access to the full 6GB of ram.
&gt;
&gt; I'm unsure how to progress from here.
&gt;
&gt; Any ideas anyone? seen something similar?
&gt;
&gt; Should I log a bug with the ununtu people or try and track down the devs
&gt; for the DVB driver and log a bug with them?
&gt;

First take a look at /proc/interrupts to see if there is a big jump over
time on any of the devices.

Next check what else is on the same USB controller, and keep an eye on
sharing USB 1.1 and USB 2 devices on the same controller.

I've used multiple USB DVB-T tuners on the same machine with no issue, but
they haven't been the same make/model.
</PRE>
    </BLOCKQUOTE>
    <BR>
    <BR>
    First off, thanks everyone for your suggestions and thoughts.<BR>
    <BR>
    Executive summary: I've modified the kernel module to not poll the non-existent IR receiver and this has sorted the issue.<BR>
    <BR>
    The details (this will be fairly lengthy, but hopefully useful for anyone else with the same issue):<BR>
    <BR>
    2 x &quot;ASUS My Cinema U3100 Mini DVBT Tuner&quot;.<BR>
    The two tuners are on different USB buses.<BR>
    There are no other processes doing anything significant in top.<BR>
    Using Munin to graph interrupt load the only change when adding the tuners is the regular IR receiver polling (10 or 20 interrupts per second).<BR>
    <BR>
    Attached is a graph from Munin showing the load on the system, nothing like a nice picture to demonstrate the issue :)<BR>
    <BR>
    The first thing was noticing that a single tuner also was causing issues, in summary:<BR>
    <BR>
    1 Tuner - Load jumps by around 0.5, intermittent high ping times to VirtualBox virtual machine.<BR>
    2 Tuners - Load jumps by around 1.0, almost continuous high ping times to VirtualBox virtual machine.<BR>
    <BR>
    dmesg when inserting tuner includes &quot;dvb-usb: schedule remote query interval to 50 msecs.&quot;.&nbsp; This bugs me as there isn't an IR receiver on this model of tuner.<BR>
    <BR>
    Found the following instructions for building your own support for the tuners before there was native support in the kernel:<BR>
    <BR>
    <A HREF="http://www.mythtv.org/wiki/Asus_My_Cinema_U3100_mini">http://www.mythtv.org/wiki/Asus_My_Cinema_U3100_mini</A><BR>
    <BR>
    Section 2.2 got me interested, it talks about disabling the IR polling.<BR>
    <BR>
    The following are the steps I followed (from memory so may be some typos):<BR>
    <BR>
    aptitude install linux-source<BR>
    cd /usr/src<BR>
    tar xjvf linux-source-2.6.28.tar.bz2<BR>
    cd linux-source-2.6.28<BR>
    <BR>
    modify drivers/media/dvb/dvb-usb/dvb-usb-remote.c as per section 2.2 above<BR>
    <BR>
    cp /boot/config-2.6.28-15-server .config<BR>
    make oldconfig<BR>
    make<BR>
    <BR>
    cp drivers/media/dvb/dvb-usb/dvb-usb.ko /lib/modules/2.6.28-15-server/kernel/drivers/media/dvb/dvb-usb/<BR>
    <BR>
    <BR>
    The last step above is a nasty hack, I should really build a whole kernel as a .deb and let the package management system handle it. I note that the replacement module is much larger than the old one, I wonder if it has debugging symbols or something like that turned on still.<BR>
    <BR>
    Rebooted machine and all good now :)<BR>
    <BR>
    My current theory is that the IR receiver polling is locking/blocking while it tries to poll non-existent hardware. This is causing the load-average measuring system to see a process waiting a whole bunch, hence the high load. I also think this is preventing VirtualBox from being able to pass interrupts from the host machine into the guest (network interrupts for example) in a timely fashion causing the poor ping times.<BR>
    <BR>
    Next step is to try a newer kernel (2.6.31.3 I think) to see if the problem still exists. If it does then to track down the maintains for the dvb-usb code and raise a bug. The hack above isn't really ideal as it disables IR receivers on all USB tuners, not just those missing the hardware.<BR>
    <BR>
    Lastly I'd like to know why this causes my system grief, but not others...<BR>
    <BR>
    Dylan<BR>
    <BR>
    <BR>
</BLOCKQUOTE>
<BR>
Found a better way to fix this. If I'd read the code more closely I'd have noticed there is a option you can pass the module to disable the IR receiver.<BR>
<BR>
Create /etc/modprobe.d/local.conf<BR>
<BR>
# disable remote control polling for usb dvb sticks<BR>
options dvb-usb disable_rc_polling=1<BR>
<BR>
<BR>
Dylan<BR>
<BR>
</BODY>
</HTML>