3 Nov
2012
3 Nov
'12
10:40 a.m.
I noticed something interesting about kernel 3.6.5-rt14.
spinymouse@qrc:~$ uname -a
Linux qrc 3.5.0-17-lowlatency #18-Ubuntu SMP PREEMPT Tue Oct 9 20:04:43
UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
spinymouse@qrc:~$ /etc/init.d/rtirq status | grep radeon
768 FF 50 - 90 0.0 S irq/18-radeon
spinymouse@qrc:~$ /etc/init.d/rtirq status | grep irq/18
777 FF 85 - 125 0.0 S irq/18-snd_hdsp
56 FF 78 - 118 0.0 S irq/18-ohci_hcd
58 FF 77 - 117 0.0 S irq/18-ohci_hcd
768 FF 50 - 90 0.0 S irq/18-radeon
spinymouse@qrc:~$ uname -a
Linux qrc 3.6.5-rt14 #1 SMP PREEMPT RT Fri Nov 2 21:36:37 CET 2012
x86_64 x86_64 x86_64 GNU/Linux
spinymouse@qrc:~$ /etc/init.d/rtirq status | grep radeon
807 FF 50 - 90 0.0 S irq/43-radeon
spinymouse@qrc:~$ /etc/init.d/rtirq status | grep irq/18
832 FF 85 - 125 0.0 S irq/18-snd_hdsp
58 FF 78 - 118 0.0 S irq/18-ohci_hcd
60 FF 77 - 117 0.0 S irq/18-ohci_hcd
Unfortunately it didn't solve xrun issues for the RME card. However,
the kernel does switch to another IRQ for the graphics, for all other
kernels on different distros, the graphics always gets IRQ18, also if I
switch the integrated ATI with a Nvidia.
Regards,
Ralf
3 Nov
3 Nov
11:32 a.m.
On 11/03/2012 10:40 AM, Ralf Mardorf wrote:
I noticed something interesting about kernel
3.6.5-rt14.
[..]
Unfortunately it didn't solve xrun issues for the
RME card. However,
the kernel does switch to another IRQ for the graphics, for all other
kernels on different distros, the graphics always gets IRQ18, also if I
switch the integrated ATI with a Nvidia.
Hi, this is a long shot, but you might play around with the PCI bus
latency settings for different devices.. I.e. turn them down from the
default value and see if it helps at all. I'm no expert in this, so make
sure to read up on the subject.
http://www.mythtv.org/wiki/PCI_Latency
Maybe some device (most probably a GPU or a NIC) holds on to the PCI bus
for too long..
Flo
12:24 p.m.
On Sat, 03 Nov 2012 11:32:21 +0100
Florian Paul Schmidt <mista.tapas(a)gmx.net> wrote:
On 11/03/2012 10:40 AM, Ralf Mardorf wrote:
Thank you Flo :)
if I remove all USB stuff I still see irq/18-ohci_hcd [1].
Regards,
Ralf
[1]
$ top
2583 spinymou 20 0 1155m 310m 107m S 9.3 8.4 3:09.87
qtractor
2827 spinymou 20 0 392m 47m 21m S 1.7 1.3 0:05.03
plugin-containe
2562 spinymou 20 0 275m 89m 82m S 1.3 2.4 0:27.17
jackd
15 root -2 0 0 0 0 S 1.0 0.0 0:04.39
ksoftirqd/1
1264 root 20 0 150m 36m 14m S 1.0 1.0 1:05.48
Xorg
2577 spinymou 20 0 536m 110m 100m S 1.0 3.0 0:10.23
qjackctl.real
2785 spinymou 20 0 922m 139m 43m S 0.7 3.8 0:37.66
firefox
58 root -79 0 0 0 0 S 0.3 0.0 0:02.06
irq/18-ohci_hcd
60 root -78 0 0 0 0 S 0.3 0.0 0:03.43
irq/18-ohci_hcd
849 root -86 0 0 0 0 S 0.3 0.0 0:05.95
irq/18-snd_hdsp
2159 spinymou 20 0 163m 14m 9m S 0.3 0.4 0:08.91
panel-25-weathe
2487 spinymou 20 0 476m 18m 13m S 0.3 0.5 0:04.61
xfce4-terminal
1 root 20 0 24432 2320 1272 S 0.0 0.1 0:01.27
init
spinymouse@qrc:~$ cat /proc/interrupts | grep 18
18: 0 752885 IO-APIC-fasteoi ohci_hcd:usb4,
ohci_hcd:usb6, snd_hdspm
spinymouse@qrc:~$ /etc/init.d/rtirq status
PID CLS RTPRIO NI PRI %CPU STAT COMMAND
62 FF 90 - 130 0.0 S irq/8-rtc0
849 FF 85 - 125 0.1 S irq/18-snd_hdsp
908 FF 85 - 125 0.0 S irq/20-snd_ice1
911 FF 85 - 125 0.0 S irq/21-snd_ice1
54 FF 80 - 120 0.0 S irq/19-ehci_hcd
55 FF 80 - 120 0.0 S irq/16-ohci_hcd
56 FF 79 - 119 0.0 S irq/17-ohci_hcd
58 FF 78 - 118 0.0 S irq/18-ohci_hcd
59 FF 78 - 118 0.0 S irq/17-ohci_hcd
60 FF 77 - 117 0.0 S irq/18-ohci_hcd
61 FF 75 - 115 0.0 S irq/1-i8042
24 FF 50 - 90 0.0 S irq/9-acpi
46 FF 50 - 90 0.0 S irq/22-ahci
214 FF 50 - 90 0.0 S irq/14-pata_ati
215 FF 50 - 90 0.0 S irq/15-pata_ati
301 FF 50 - 90 0.0 S irq/22-firewire
720 FF 50 - 90 0.0 S irq/7-parport0
727 FF 50 - 90 0.0 S irq/43-radeon
1111 FF 50 - 90 0.0 S irq/42-eth0
3 FF 1 - 41 0.3 S ksoftirqd/0
15 FF 1 - 41 0.1 S ksoftirqd/1
I noticed something interesting about kernel
3.6.5-rt14.
[..]
Unfortunately it didn't solve xrun issues for
the RME card. However,
the kernel does switch to another IRQ for the graphics, for all
other kernels on different distros, the graphics always gets IRQ18,
also if I switch the integrated ATI with a Nvidia.
Hi, this is a long shot, but you might play around with the PCI bus
latency settings for different devices.. I.e. turn them down from the
default value and see if it helps at all. I'm no expert in this, so
make sure to read up on the subject.
http://www.mythtv.org/wiki/PCI_Latency
Maybe some device (most probably a GPU or a NIC) holds on to the PCI
bus for too long..
Flo
1:24 p.m.
On Sat, 03 Nov 2012 11:32:21 +0100
Florian Paul Schmidt <mista.tapas(a)gmx.net> wrote:
> Maybe some device (most probably a GPU or a NIC) holds on to the PCI
> bus for too long..
BIOS > Advanced > PCIPnP
Plug & Play O/S was [No] now it's [Yes]
Resources Controlled By was [Auto] now it's [Manual]
But this enables to assign only unimportant/unused IRQs, so I didn't
change the settings.
PCI Latency Timer (CLK) was [64] now it's [0]
*** PCI Express relative items ***
Maximum Playload size [4096] the max value
With latency timer set to 0 nothing seems to be different, I already
hear xruns while writing this mail. lspci does confirm that the RME
card is set to latency 0, but the other cards still have higher values,
so I set PCI Latency Timer (CLK) to the max [255]. No soundcheck,
regarding to lspci it's more worse than before, so I'll reboot now and
restore the default value [64] and then write a script as explained by
http://www.mythtv.org/wiki/PCI_Latency .
### BIOS value [0]
$ lspci -v
01:05.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI
RS690 [Radeon X1200 Series] (prog-if 00 [VGA controller]) Subsystem:
ASUSTeK Computer Inc. Device 826d Flags: bus master, fast devsel,
latency 64, IRQ 43 Memory at d0000000 (64-bit, prefetchable) [size=256M]
Memory at fdff0000 (64-bit, non-prefetchable) [size=64K]
I/O ports at ce00 [size=256]
Memory at fde00000 (32-bit, non-prefetchable) [size=1M]
Expansion ROM at <unassigned> [disabled]
Capabilities: <access denied>
Kernel driver in use: radeon
Kernel modules: radeon
02:00.0 Multimedia audio controller: Xilinx Corporation RME Hammerfall
DSP MADI (rev d4) Flags: bus master, fast devsel, latency 0, IRQ 18
Memory at fddf0000 (32-bit, non-prefetchable) [size=64K]
Capabilities: <access denied>
Kernel driver in use: snd_hdspm
Kernel modules: snd-hdspm
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)
Subsystem: ASUSTeK Computer Inc. P5B Flags: bus master, fast devsel,
latency 0, IRQ 42 I/O ports at de00 [size=256]
Memory at fd9ff000 (64-bit, non-prefetchable) [size=4K]
[virtual] Expansion ROM at fd800000 [disabled] [size=128K]
Capabilities: <access denied>
Kernel driver in use: r8169
Kernel modules: r8169
04:05.0 Multimedia audio controller: VIA Technologies Inc. ICE1712
[Envy24] PCI Multi-Channel I/O Controller (rev 02) Subsystem: TERRATEC
Electronic GmbH EWX 24/96 Flags: bus master, medium devsel, latency 64,
IRQ 20 I/O ports at bf00 [size=32]
I/O ports at be00 [size=16]
I/O ports at bd00 [size=16]
I/O ports at bc00 [size=64]
Capabilities: <access denied>
Kernel driver in use: snd_ice1712
Kernel modules: snd-ice1712
04:06.0 Multimedia audio controller: VIA Technologies Inc. ICE1712
[Envy24] PCI Multi-Channel I/O Controller (rev 02) Subsystem: TERRATEC
Electronic GmbH EWX 24/96 Flags: bus master, medium devsel, latency 64,
IRQ 21 I/O ports at bb00 [size=32]
I/O ports at ba00 [size=16]
I/O ports at b900 [size=16]
I/O ports at b800 [size=64]
Capabilities: <access denied>
Kernel driver in use: snd_ice1712
Kernel modules: snd-ice1712
04:07.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6306/7/8 [Fire
II(M)] IEEE 1394 OHCI Controller (rev c0) (prog-if 10 [OHCI])
Subsystem: ASUSTeK Computer Inc. M4A series motherboard Flags: bus
master, medium devsel, latency 64, IRQ 22 Memory at fdbff000 (32-bit,
non-prefetchable) [size=2K] I/O ports at b700 [size=128]
Capabilities: <access denied>
Kernel driver in use: firewire_ohci
Kernel modules: firewire-ohci
### BIOS value [255]
$ lspci -v
02:00.0 Multimedia audio controller: Xilinx Corporation RME Hammerfall
DSP MADI (rev d4) Flags: bus master, fast devsel, latency 0, IRQ 18
Memory at fddf0000 (32-bit, non-prefetchable) [size=64K]
Capabilities: <access denied>
Kernel driver in use: snd_hdspm
Kernel modules: snd-hdspm
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)
Subsystem: ASUSTeK Computer Inc. P5B Flags: bus master, fast devsel,
latency 0, IRQ 42 I/O ports at de00 [size=256]
Memory at fd9ff000 (64-bit, non-prefetchable) [size=4K]
[virtual] Expansion ROM at fd800000 [disabled] [size=128K]
Capabilities: <access denied>
Kernel driver in use: r8169
Kernel modules: r8169
04:05.0 Multimedia audio controller: VIA Technologies Inc. ICE1712
[Envy24] PCI Multi-Channel I/O Controller (rev 02) Subsystem: TERRATEC
Electronic GmbH EWX 24/96 Flags: bus master, medium devsel, latency
248, IRQ 20 I/O ports at bf00 [size=32]
I/O ports at be00 [size=16]
I/O ports at bd00 [size=16]
I/O ports at bc00 [size=64]
Capabilities: <access denied>
Kernel driver in use: snd_ice1712
Kernel modules: snd-ice1712
04:06.0 Multimedia audio controller: VIA Technologies Inc. ICE1712
[Envy24] PCI Multi-Channel I/O Controller (rev 02) Subsystem: TERRATEC
Electronic GmbH EWX 24/96 Flags: bus master, medium devsel, latency
248, IRQ 21 I/O ports at bb00 [size=32]
I/O ports at ba00 [size=16]
I/O ports at b900 [size=16]
I/O ports at b800 [size=64]
Capabilities: <access denied>
Kernel driver in use: snd_ice1712
Kernel modules: snd-ice1712
04:07.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6306/7/8 [Fire
II(M)] IEEE 1394 OHCI Controller (rev c0) (prog-if 10 [OHCI])
Subsystem: ASUSTeK Computer Inc. M4A series motherboard Flags: bus
master, medium devsel, latency 248, IRQ 22 Memory at fdbff000 (32-bit,
non-prefetchable) [size=2K] I/O ports at b700 [size=128]
Capabilities: <access denied>
Kernel driver in use: firewire_ohci
Kernel modules: firewire-ohci
1:43 p.m.
On 11/03/2012 01:24 PM, Ralf Mardorf wrote:
With latency timer set to 0 nothing seems to be
different, I already
hear xruns while writing this mail. lspci does confirm that the RME
card is set to latency 0, but the other cards still have higher values,
so I set PCI Latency Timer (CLK) to the max [255]. No soundcheck,
regarding to lspci it's more worse than before, so I'll reboot now and
restore the default value [64] and then write a script as explained by
http://www.mythtv.org/wiki/PCI_Latency .
http://wiki.linuxmusicians.com/doku.php?id=system_configuration#pci_bus_lat…
Your RME card should have a high latency value and the rest should be
lower. This allows your RME card to hold on to the PCI bus for a longer
period of time (higher latency value = device can hold on to the bus for
a longer period of time).
Regards,
Jeremy
1:57 p.m.
On Sat, 03 Nov 2012 13:43:27 +0100
Jeremy Jongepier <jeremy(a)autostatic.com> wrote:
On 11/03/2012 01:24 PM, Ralf Mardorf wrote:
Thank you Jeremy,
I understand this and started writing a script, but first I'll get rid
of firewire, I don't need it and then of Envy24 too, I don't need the
"MIDI devices" at the moment.
spinymouse@qrc:/mnt/music/quantal/01song$ cat tuning
#!/bin/bash
# bash tuning
# 2012/Nov/03
$ sudo rmmod firewire-ohci
$ sudo rmmod firewire_core
I'll add sudo rmmod snd_ice1712 and than set the latency of the RME and
other cards. Strange, in the morning I couldn't remove snd_ice1712, now
it does work, perhaps a typo.
Testing it may take some time, I've to do "weekend things", but I'll
set up latency now.
Regards,
Ralf
With latency timer set to 0 nothing seems to be
different, I already
hear xruns while writing this mail. lspci does confirm that the RME
card is set to latency 0, but the other cards still have higher
values, so I set PCI Latency Timer (CLK) to the max [255]. No
soundcheck, regarding to lspci it's more worse than before, so I'll
reboot now and restore the default value [64] and then write a
script as explained by http://www.mythtv.org/wiki/PCI_Latency .
http://wiki.linuxmusicians.com/doku.php?id=system_configuration#pci_bus_lat…
Your RME card should have a high latency value and the rest should be
lower. This allows your RME card to hold on to the PCI bus for a
longer period of time (higher latency value = device can hold on to
the bus for a longer period of time). 
4:43 p.m.
On Sat, November 3, 2012 5:24 am, Ralf Mardorf wrote:
With latency timer set to 0 nothing seems to be
different, I already
hear xruns while writing this mail. lspci does confirm that the RME
card is set to latency 0, but the other cards still have higher values,
so I set PCI Latency Timer (CLK) to the max [255]. No soundcheck,
regarding to lspci it's more worse than before, so I'll reboot now and
restore the default value [64] and then write a script as explained by
http://www.mythtv.org/wiki/PCI_Latency .
Playing with PCI_latency made things worse for me, no gain and an unstable
machine. This will have no effect whatever on PCIe cards.
--
Len Ovens
www.OvenWerks.net
10:06 p.m.
On Sat, 3 Nov 2012 08:43:11 -0700
"Len Ovens" <len(a)ovenwerks.net> wrote:
Playing with PCI_latency made things worse for me, no
gain and an
unstable machine. This will have no effect whatever on PCIe cards.
Okay, so I only will unbind 2 USB ports. FWIW some things need to be
done in a different way, than it's described by "linuxmusicians" and
stopping networking does cause trouble. I couldn't find out how to
unbind the 2 USB ports.
spinymouse@qrc:/mnt/music/quantal/01song$ sudo bash tuning
[sudo] password for spinymouse:
bluetooth stop/waiting
network-manager stop/waiting
cups stop/waiting
tuning: line 28: echo: write error: No such device
tuning: line 29: echo: write error: No such device
##############################
$ /etc/init.d/rtirq status
PID CLS RTPRIO NI PRI %CPU STAT COMMAND
62 FF 90 - 130 0.0 S irq/8-rtc0
896 FF 85 - 125 0.0 S irq/18-snd_hdsp
54 FF 80 - 120 0.0 S irq/19-ehci_hcd
55 FF 80 - 120 0.0 S irq/16-ohci_hcd
56 FF 79 - 119 0.3 S irq/17-ohci_hcd
58 FF 78 - 118 0.0 S irq/18-ohci_hcd
59 FF 78 - 118 0.0 S irq/17-ohci_hcd
60 FF 77 - 117 0.0 S irq/18-ohci_hcd
61 FF 75 - 115 0.0 S irq/1-i8042
24 FF 50 - 90 0.0 S irq/9-acpi
46 FF 50 - 90 0.1 S irq/22-ahci
257 FF 50 - 90 0.0 S irq/14-pata_ati
258 FF 50 - 90 0.0 S irq/15-pata_ati
695 FF 50 - 90 0.0 S irq/7-parport0
818 FF 50 - 90 0.0 S irq/43-radeon
3 FF 1 - 41 0.1 S ksoftirqd/0
15 FF 1 - 41 0.1 S ksoftirqd/1
$ cat /proc/interrupts | grep 18:
18: 0 2 IO-APIC-fasteoi ohci_hcd:usb4,
ohci_hcd:usb6, snd_hdspm
Sat Nov 3 21:32:46 CET 2012 - 3.6.5-rt14 - Ubuntu 12.10 \n \l
spinymouse@qrc:/mnt/music/quantal/01song$ cat -n tuning
1 #!/bin/bash
2
3 # sudo bash tuning - Ubuntu Studio Quantal
4 # 2012/Nov/03
5
6 ### http://www.mythtv.org/wiki/PCI_Latency
7 ###
http://wiki.linuxmusicians.com/doku.php?id=system_configuration#pci_bus_lat…
8
9 ### Bluetooth
10 service bluetooth stop
11
12 ### Network
13 service network-manager stop
14 #service networking stop # does cause serious issues
15 modprobe -r r8169 # Ethernet NIC driver
16
17 ### TerraTec EWX 24/96
18 modprobe -r snd_ice1712
19
20 ### Others
21 modprobe -r firewire-ohci
22 modprobe -r firewire_core
23 service cups stop
24 modprobe -r ppdev # parallel port
25 modprobe -r lp # printer
26
27 ### Unbinding devices
28 echo -n "0000:00/0000:00:13.2"
/sys/bus/pci/drivers/ohci_hcd/unbind
29
echo -n "0000:00/0000:00:13.4"
/sys/bus/pci/drivers/ohci_hcd/unbind
30
31 ### Log file
32 l="log/tuning.log"
33 #echo "$ lspci -v " > $l
34 #lspci -v >> $l
35 #echo >> $l
36 echo "$ /etc/init.d/rtirq status " > $l
37 /etc/init.d/rtirq status >> $l
38 echo >> $l
39 echo "$ cat /proc/interrupts | grep 18:" >> $l
40 cat /proc/interrupts | grep 18: >> $l
41 echo -n $(date)" - "$(uname -r)" - " >> $l
42 cat /etc/issue >> $l
43 echo "##############################" ; cat $l
44
45 exit 0
46
Regards,
Ralf
PS:
Btw.
sudo echo foo > /sys/...
doesn't work, it has to be
echo foo | sudo tee /sys/...
sudo bash -c "echo foo > /sys/..."
;)
4 Nov
4 Nov
12:40 p.m.
On 11/03/2012 10:05 PM, Ralf Mardorf wrote:
On Sat, 3 Nov 2012 08:43:11 -0700
"Len Ovens" <len(a)ovenwerks.net> wrote:
Now you've got:
echo -n "0000:00/0000:00:13.2" > /sys/bus/pci/drivers/ohci_hcd/unbind
echo -n "0000:00/0000:00:13.4" > /sys/bus/pci/drivers/ohci_hcd/unbind
Which yields:
Playing with PCI_latency made things worse for
me, no gain and an
unstable machine. This will have no effect whatever on PCIe cards.
Okay, so I only will unbind 2 USB ports. FWIW some things need to be
done in a different way, than it's described by "linuxmusicians" and
stopping networking does cause trouble. I couldn't find out how to
unbind the 2 USB ports.
tuning: line 28: echo: write error: No such device
tuning: line 29: echo: write error: No such device
Maybe you could try:
echo -n "0000:00:13.2" > /sys/bus/pci/drivers/ohci_hcd/unbind
echo -n "0000:00:13.4" > /sys/bus/pci/drivers/ohci_hcd/unbind
You should also check which driver the USB ports are using, ohci, ehci
or uhci. You can check this with cat /proc/interrupts | grep usb for
instance:
cat /proc/interrupts | grep usb
16: 39179 307 IO-APIC-fasteoi uhci_hcd:usb3, mmc0,
firewire_ohci, jmb38x_ms:slot0, eth1, nvidia
17: 0 0 IO-APIC-fasteoi uhci_hcd:usb4
18: 0 0 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb7
19: 0 0 IO-APIC-fasteoi uhci_hcd:usb8
20: 9 9 IO-APIC-fasteoi ehci_hcd:usb2, uhci_hcd:usb5
22: 0 0 IO-APIC-fasteoi uhci_hcd:usb6
As you can see the bus ID's get prepended with ohci_hcd, ehci_hcd or
uhci_hcd. So you have to write your bus ID's to the corresponding unbind
file. In your case the one in /sys/bus/pci/drivers/ohci_hcd/.
Regards,
Jeremy
1:41 p.m.
On Sun, 04 Nov 2012 12:40:06 +0100
Jeremy Jongepier <jeremy(a)autostatic.com> wrote:
Now you've got:
echo -n "0000:00/0000:00:13.2" > /sys/bus/pci/drivers/ohci_hcd/unbind
echo -n "0000:00/0000:00:13.4" > /sys/bus/pci/drivers/ohci_hcd/unbind
Which yields:
Thank you, this does work :)
spinymouse@qrc:/mnt/music/quantal/01song$ sudo bash tuning
[snip]
$ grep 18: /proc/interrupts
18: 0 2141551 IO-APIC-fasteoi snd_hdspm
Sun Nov 4 13:36:28 CET 2012 - 3.6.5-rt14 - Ubuntu 12.10
Regards,
Ralf
tuning: line 28: echo: write error: No such
device
tuning: line 29: echo: write error: No such device
Maybe you could try:
echo -n "0000:00:13.2" > /sys/bus/pci/drivers/ohci_hcd/unbind
echo -n "0000:00:13.4" > /sys/bus/pci/drivers/ohci_hcd/unbind
3 Nov
3 Nov
4:39 p.m.
On Sat, November 3, 2012 4:23 am, Ralf Mardorf wrote:
if I remove all USB stuff I still see irq/18-ohci_hcd
[1].
Ya, they will always show up because the ports are there. But if nothing
is plugged in there should be no interrupts generated. If you look at cat
/proc/interrupts, you will see which USB ports are are hooked to which
IRQs. Mine shows:
16: 353468 0 IO-APIC-fasteoi uhci_hcd:usb2,
uhci_hcd:usb5, nouveau
17: 292646 0 IO-APIC-fasteoi eth0
18: 1537 0 IO-APIC-fasteoi ata_piix, uhci_hcd:usb4
19: 0 0 IO-APIC-fasteoi uhci_hcd:usb3
20: 0 0 IO-APIC-fasteoi snd_ens1370
21: 255695 0 IO-APIC-fasteoi snd_ice1712
23: 334006 0 IO-APIC-fasteoi ehci_hcd:usb1
In my case I was able to move my sound card out of the pci slot that it
was sharing with USB1. You can tell which USB port is which by plugging in
a USB memstick and looking at the last few lines of dmesg to see which USB
port it is (great for finding the best port to plug a sound IF into BTW).
You notice also that I tried to set the sound card I use for recording to
a higher irq than the ens that I use as a midi card. Just switching those
two around made a difference. I happen to have 5 pci slots to play with as
this is an older machine.
--
Len Ovens
www.OvenWerks.net
4:08 p.m.
On Sat, November 3, 2012 2:40 am, Ralf Mardorf wrote:
I noticed something interesting about kernel
3.6.5-rt14.
spinymouse@qrc:~$ uname -a
Linux qrc 3.5.0-17-lowlatency #18-Ubuntu SMP PREEMPT Tue Oct 9 20:04:43
UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
spinymouse@qrc:~$ /etc/init.d/rtirq status | grep radeon
768 FF 50 - 90 0.0 S irq/18-radeon
spinymouse@qrc:~$ /etc/init.d/rtirq status | grep irq/18
777 FF 85 - 125 0.0 S irq/18-snd_hdsp
56 FF 78 - 118 0.0 S irq/18-ohci_hcd
58 FF 77 - 117 0.0 S irq/18-ohci_hcd
768 FF 50 - 90 0.0 S irq/18-radeon
spinymouse@qrc:~$ uname -a
Linux qrc 3.6.5-rt14 #1 SMP PREEMPT RT Fri Nov 2 21:36:37 CET 2012
x86_64 x86_64 x86_64 GNU/Linux
spinymouse@qrc:~$ /etc/init.d/rtirq status | grep radeon
807 FF 50 - 90 0.0 S irq/43-radeon
spinymouse@qrc:~$ /etc/init.d/rtirq status | grep irq/18
832 FF 85 - 125 0.0 S irq/18-snd_hdsp
58 FF 78 - 118 0.0 S irq/18-ohci_hcd
60 FF 77 - 117 0.0 S irq/18-ohci_hcd
Unfortunately it didn't solve xrun issues for the RME card. However,
the kernel does switch to another IRQ for the graphics, for all other
kernels on different distros, the graphics always gets IRQ18, also if I
switch the integrated ATI with a Nvidia.
Thats strange.
In any case, I would work at getting your hdsp off of irq18. Put it in a
different slot whatever. It made a difference for my stuff in terms of
xruns or not.
--
Len Ovens
www.OvenWerks.net
4819
days inactive
4820
days old
linux-audio-user@lists.linuxaudio.org
11 comments
4 participants
participants (4)
-
Florian Paul Schmidt -
Jeremy Jongepier -
Len Ovens -
Ralf Mardorf