[svlug] shufflin'around interrupts in software

Florin Andrei florin at sgi.com
Thu Jan 9 14:13:42 PST 2003


Before asking the question, let me describe first my system and the
problem i have. The actual question is towards the end.

System:
- MSI Computer nForce K7N420 Pro motherboard (NVidia chipset, GeForce2
embedded, nForce sound card embedded, network embedded):
http://www.msicomputer.com/product/detail_spec/product_detail.asp?model=K7N420_Pro
- AthlonXP 1800+ CPU
- IEEE1394 (FireWire) card
- Hauppauge TV card
- Red Hat 8.0 fully updated (over a RH Network subscription)
- updated RH Athlon kernels
- nVidia's latest drivers (GeForce and nForce) rebuilt by myself from
src.rpm
- ALSA latest drivers (0.9.something), compiled by me from sources

Problem:
Despite the system being quite powerful for 2D multimedia stuff (heck,
it's fairly ok even for 3D), when i play various video formats, every 10
seconds or so (very irregularly) the image makes a small (sub-second)
jerk or two; at the same moment, if i look in the CPU usage history,
there's a momentary (sub-second) increase in the CPU usage.

Details:
It does not depend on the file format and audio/video codec or
implementation (DivX, MPEG2, divx.com, XviD, ffmpeg, you name it).
It does not depend on the player (xine, mplayer, ogle, goggles, you name
it).
It does not depend on the AGP kernel module i'm using: it's all the same
whether i use agpgart or the nVidia AGP module.
It does not go away if i switch the players for audio output from ALSA
native to OSS (i compiled my ALSA drivers with OSS emulation).
It does not go away if i optimize my apps and libs for different CPU
architectures (i usually compile with "-O3 -march=athlon-xp" but i tried
many other options, and some apps insist on their own options to be
used).
I'm not sure, but i think Quake III Arena does not show this problem
(can't be sure because i didn't tried yet to find those Q3 performance
settings that provide perfectly smooth frames-per-second rate, and it's
much more difficult anyway to tell with a game instead of a movie). The
overall performance of the game 3D engine seems pretty good and seems to
be what one would expect from such a system (GeForce2 on AthlonXP 1800).

Possibly related:
If i grab an xterm with the mouse, and shake it a little bit, the motion
is jerky, not fluid, which is not what i would expect from this fairly
fast system (less powerful machines have a fluid motion of the window,
see next paragraph). Looks like 2D has problems, while 3D might be ok.

No problem:
I do NOT have this problem with exactly the same software (OS, drivers,
apps) running on a much weaker machine (PIII/600, cheap crappy no-name
mobo, GeForce2, good old first-model SBLive).

Possible cause:
I've been told that the problem may be caused by overlaping interrupts,
which makes sense completely: busy interrupt --> video/sound card(s)
cannot work --> image jerk.
Upon checking, i did notice overlaps in key places:

#################################
[root at rivendell root]# cat /proc/interrupts
           CPU0
  0:   25110512          XT-PIC  timer
  1:       3142          XT-PIC  keyboard
  2:          0          XT-PIC  cascade
  5:    4264253          XT-PIC  usb-ohci, ohci1394, NVidia NForce,
nvidia
  8:          1          XT-PIC  rtc
 11:   49861383          XT-PIC  usb-ohci, eth0
 12:     140791          XT-PIC  PS/2 Mouse
 14:     167147          XT-PIC  ide0
 15:     907089          XT-PIC  ide1
NMI:          0
ERR:          1
[root at rivendell root]#
###################################

("nvidia" must be the graphics card. "NVidia NForce" must be the nForce
chipset, which manages sound and network)

Possible remedy:
Shuffle IRQs around, possibly by shuffling PCI cards around. That was my
first reaction. That too was what everyone else said. That is the
typical out-the-top-of-your-head solution for bad interrupts.
However, that doesn't work on my system, because almost everything
that's important for multimedia playback is embedded.

Question(s), finally:
Is there any way to assign interrupts differently using a software
method?
Is there any option to the nVidia kernel module to tell it to use a
different IRQ? That would pretty much solve it, i hope.
Do you know any resource that documents the options of the nVidia kernel
modules? They seem to be pretty secretive regarding these things.
What's the best documentation (besides the source itself) for the way
the interrupts are assigned by the Linux kernel?

I did some research with Google and on the nVidia website (including the
discussion forum they recommend), but nothing relevant so far, so i
figured i finally have to ask on a mailing list or something.

Any idea is welcome. Thanks.

Just in case, here's my modules.conf:

#################################
# IDE-CD
options ide-cd dma=1

# LPT
alias parport_lowlevel parport_pc

# USB
alias usb-controller usb-ohci
alias usb-interface usb-ohci

# 1394
alias char-major-171 raw1394
alias ieee1394-controller ohci1394
post-install ohci1394 /sbin/insmod raw1394

# nVidia
alias eth0 nvnet
install eth0 /sbin/insmod -f nvnet
alias char-major-195 nvidia
alias sound-slot-1 nvaudio

# i2c
alias char-major-89     i2c-dev
options i2c-core        i2c_debug=1
options i2c-algo-bit    bit_test=1

# bttv
alias char-major-81     videodev
alias char-major-81-0   bttv
alias char-major-81-64  tuner
pre-install tuner       /sbin/modprobe bttv
options bttv            radio=1
#options tuner           debug=1

# Visor
alias char-major-188 visor

# ALSA native
alias char-major-116 snd
options snd major=116 cards_limit=1 device_mode=0666
alias snd-card-0 snd-intel8x0

# OSS/Free emulation
alias char-major-14 soundcore
alias sound-slot-0 snd-card-0
alias sound-service-0-0 snd-mixer-oss
alias sound-service-0-1 snd-seq-oss
alias sound-service-0-3 snd-pcm-oss
alias sound-service-0-8 snd-seq-oss
alias sound-service-0-12 snd-pcm-oss
#################################

(long message, i know; but it's been just copy/pasted from a .txt file
i've been scribbling in the last few days to describe the problem)

-- 
Florin Andrei

"If you had a giant corporation trying to stamp you out, and the entire
film and recording industry trying to restrict your software from
playing their media, then you'd be political too." - Bruce Perens




More information about the svlug mailing list