What is the rtsbpp-polling process doing?

Question

In Ubuntu 12.04 LTS when I run the top command I see a process called rtsbpp-polling. Googling it gives only just a few hits to the Gentoo Linux forum that does not seem to be relevant (they don't mention the process).

$ ps ax | grep rtsbpp
541 root 20 0 0 0 0 S 0 0.0 0:37.08 [rtsbpp-polling] 

$ ps aux | grep rts
root       536  0.0  0.0      0     0 ?        S    17:41   0:00 [rts_bpp]
root       541  0.6  0.0      0     0 ?        S    17:41   0:38 [rtsbpp-polling]

Googling rts_bpp indicates it may be drivers for my card reader, but I am not sure it has anything to do with the rtsbpp-polling process.

So what does it do?

Edit: Following Sim's advice in the answer below it seems rts_bpp is indeed a driver:

$ sudo lspci -k | less
04:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. Device 5289 (rev 01)
    Subsystem: ASUSTeK Computer Inc. Device 1447
    Kernel driver in use: rts_bpp
    Kernel modules: rts_bpp`

rtsbpp-polling does not show up on that list and does not seem to do anything on the network, but it does seem to use some files. I am not sure what to make of it:

$ lsof -p 726
COMMAND   PID USER   FD      TYPE DEVICE SIZE/OFF NODE NAME
rtsbpp-po 726 root  cwd   unknown                      /proc/726/cwd (readlink: Permission denied)
rtsbpp-po 726 root  rtd   unknown                      /proc/726/root (readlink: Permission denied)
rtsbpp-po 726 root  txt   unknown                      /proc/726/exe (readlink: Permission denied)
rtsbpp-po 726 root NOFD                                /proc/726/fd (opendir: Permission denied)

`

Answer 1

PC Card Reader?

I believe that Gentoo thread is correct. I think it's related to a PC Card reader you may have installed on your system. I found this thread which has a similarly named kernel module. The thread is titled: [SOLVED] card reader doesn't work - RTL8411 - rts_bpp.

The process there, rts_bpp, especially makes me think that it's related. You can check to see if you have the corresponding kernel module installed to confirm it a bit more.

$ sudo lsmod | grep rts

Also you can see what hardware might be using the kernel module, if it's present:

$ sudo lspci -k | less

Then look through the output from any hardware that's using the kernel modules. For examples:

00:00.0 Host bridge: Intel Corporation Core Processor DRAM Controller (rev 02)
        Subsystem: Lenovo Device 2193
        Kernel driver in use: agpgart-intel

Note the kernel module that's being used, agpgart-intel. You'll likely see what hardware is using the rts_bpp module, if there is any at all.

Debugging it further

The other method of attack would be to scrutinize the process itself. You can see what file resources this mystery process is using as well as what TCP/UDP ports it may have in use. You can use these 2 tools to do this work.

netstat

You can find out what TCP/UCP or Unix sockets are being used by this process like so:

$ netstat -anp |grep udisk
unix  3      [ ]         STREAM     CONNECTED     16411  2198/udisks-daemon  
unix  3      [ ]         STREAM     CONNECTED     16404  2198/udisks-daemon  

The above is showing sample output for the process udisks-daemon. It's using just sockets.

Here's an example of a process using all three:

$ netstat -anp |grep rpc.statd
tcp        0      0 0.0.0.0:54927               0.0.0.0:*                   LISTEN      1431/rpc.statd      
tcp        0      0 :::46051                    :::*                        LISTEN      1431/rpc.statd      
udp        0      0 0.0.0.0:45563               0.0.0.0:*                               1431/rpc.statd      
udp        0      0 0.0.0.0:759                 0.0.0.0:*                               1431/rpc.statd      
udp        0      0 :::36515                    :::*                                    1431/rpc.statd      
unix  2      [ ]         DGRAM                    10790  1431/rpc.statd      

lsof

To see what files a process is using you can use the command line tool lsof. For example, here are the same 2 above processes udisks-daemon and rpc.statd. Also note that we're telling lsof the process IDs for these 2 processes using the -p # switch.

Here's udisks-daemon:

$ sudo lsof -p 2198 | tail
lsof: WARNING: can't stat() fuse.gvfs-fuse-daemon file system /home/saml/.gvfs
      Output information may be incomplete.
udisks-da 2198 root    8u  unix 0xffff880228108680      0t0      16411 socket
udisks-da 2198 root    9r  FIFO                0,8      0t0      16413 pipe
udisks-da 2198 root   10w  FIFO                0,8      0t0      16413 pipe
udisks-da 2198 root   11r   REG                0,3        0 4026531965 /proc/mdstat
udisks-da 2198 root   12u  sock                0,6      0t0      16423 can't identify protocol
udisks-da 2198 root   13r  FIFO                0,8      0t0    1768055 pipe
udisks-da 2198 root   14w  FIFO                0,8      0t0    1768055 pipe
udisks-da 2198 root   15r   REG                0,3        0      16424 /proc/2198/mountinfo
udisks-da 2198 root   16r  FIFO                0,8      0t0      16450 pipe
udisks-da 2198 root   17w  FIFO                0,8      0t0      16450 pipe

Here's rpc.statd:

$ sudo lsof -p 1431 | tail
lsof: WARNING: can't stat() fuse.gvfs-fuse-daemon file system /home/saml/.gvfs
      Output information may be incomplete.
rpc.statd 1431 rpcuser    0u   CHR                1,3      0t0    4066 /dev/null
rpc.statd 1431 rpcuser    1u   CHR                1,3      0t0    4066 /dev/null
rpc.statd 1431 rpcuser    2u   CHR                1,3      0t0    4066 /dev/null
rpc.statd 1431 rpcuser    4u  unix 0xffff88022e976d80      0t0   10790 socket
rpc.statd 1431 rpcuser    5u  IPv4              10902      0t0     UDP *:con 
rpc.statd 1431 rpcuser    6w   REG              253,0        5 1966234 /var/run/rpc.statd.pid
rpc.statd 1431 rpcuser    8u  IPv4              10907      0t0     UDP *:45563 
rpc.statd 1431 rpcuser    9u  IPv4              10911      0t0     TCP *:54927 (LISTEN)
rpc.statd 1431 rpcuser   10u  IPv6              10915      0t0     UDP *:36515 
rpc.statd 1431 rpcuser   11u  IPv6              10919      0t0     TCP *:46051 (LISTEN)