IRQ-Sharing verhindern

[xerxes22]

Liebe Linux-Freunde,
Am ExpressCard-Slot meines Laptops läuft seit kurzem unter lenny / goto10-repository
ein Firewire-Audio-Interface. Leider ist kein störungsfreier Betrieb möglich,
weil der 1394-Controller und die (ati-) Grafikkarte den selben IRQ belegen.

Code: Alles auswählen

# cat /proc/interrupts
           CPU0       
  0:        196   IO-APIC-edge      timer
  1:         83   IO-APIC-edge      i8042
  7:          1   IO-APIC-edge    
  8:          5   IO-APIC-edge      rtc0
  9:        274   IO-APIC-fasteoi   acpi
 12:       7371   IO-APIC-edge      i8042
 14:        555   IO-APIC-edge      ide0
 16:       1972   IO-APIC-fasteoi   ohci_hcd:usb1, wifi0, HDA Intel
 17:          2   IO-APIC-fasteoi   ohci_hcd:usb2, ohci_hcd:usb5
 18:       2688   IO-APIC-fasteoi   ohci1394, ohci_hcd:usb3, ohci_hcd:usb6, fglrx[0]@PCI:1:5:0
 19:        551   IO-APIC-fasteoi   ehci_hcd:usb4
 22:       8592   IO-APIC-fasteoi   ahci
220:          0   PCI-MSI-edge      eth0
NMI:          0   Non-maskable interrupts
LOC:      57302   Local timer interrupts
RES:          0   Rescheduling interrupts
CAL:          0   function call interrupts
TLB:          0   TLB shootdowns
TRM:          0   Thermal event interrupts
SPU:          0   Spurious interrupts
ERR:          1
MIS:          0

Wie kann ich die IRQ-Belegung beim Systemstart beeinflussen, so dass
das modul ohci1394 möglichst einen eigenen freien IRQ belegt ?
( Im Bios gibt es leider keine PnP- oder IRQ-Optionen. )

[gms]

vielleicht genügt es wenn du "noapic" oder "nosmp" als Kernelparameter angibst, ansonsten gibts noch die mühsamere Methode über "pirq="
http://www.mjmwired.net/kernel/Document ... O-APIC.txt

Gruß
gms

[xerxes22]

Danke für die Info, hat aber leider nicht zum Ziel geführt.
Bei "noapic" oder "nosmp" kommen beide PCI-Devices auf IRQ 10,
dafür lässt sich die Systemuhr nicht mehr einstellen u. weitere Problemchen...
pirq=0,0,0,10 o.ä. wird ignoriert oder wirkt sich auf andere Geräte aus,
die beiden treffen sich immer wieder auf dem selben IRQ.
Rein hardware-mässig muss es aber möglich sein, wenn ich mit knoppix starte,
landet VGA auf IRQ 10 und IEEE1394 auf IRQ 20.
seltsame geschichte..
Gibt's vielleicht irgendwelche Kernel-build-optionen, die ich verändern muss ?
Ich verwende Version 2.6.26.8 mir real-time patch, auf den neueren Kerneln liess
sich fglrx nicht kompilieren. Das o.g. HOWTO bezieht sich auf 2.6.30.
Oder kann ich vielleicht mit setpci o.ä. den IRQ ändern ?

[spiralnebelverdreher]

Hast Du mal versucht den Treiber mit

Code: Alles auswählen

modprobe -r ohci1394
modprobe ohci1394  irq=11

neu zu laden (oder irgend nen anderen Interrupt der nicht benutzt ist)?

Wenn ich mich recht erinnere kann man auch in /etc/moules beim entsprechenden Modul zusätzliche Parameter für dieses Modul angeben, so das dies auch automatisch beim ersten Laden des Moduls geschieht.

[gms]

Rein hardware-mässig muss es aber möglich sein, wenn ich mit knoppix starte,
landet VGA auf IRQ 10 und IEEE1394 auf IRQ 20.
seltsame geschichte..

das hätte ich jetzt nicht erwartet. Wird bei Knoppix auch IO-APIC verwendet ? Welche Kernelversion verwendet dein Knoppix ?

Hast Du mal versucht den Treiber mit

Code: Alles auswählen

modprobe -r ohci1394
modprobe ohci1394  irq=11

neu zu laden (oder irgend nen anderen Interrupt der nicht benutzt ist)?

Wenn ich mich recht erinnere kann man auch in /etc/moules beim entsprechenden Modul zusätzliche Parameter für dieses Modul angeben, so das dies auch automatisch beim ersten Laden des Moduls geschieht.

aber nur wenn das Modul entsprechende Parameter unterstützt, was zumeist bei ISA Karten der Fall ist, nicht aber bei diesem Modul:

Code: Alles auswählen

gms1 gms # modinfo ohci1394
filename:       /lib/modules/2.6.31.1-gms/kernel/drivers/ieee1394/ohci1394.ko
license:        GPL
description:    Driver for PCI OHCI IEEE-1394 controllers
author:         Sebastien Rougeaux <sebastien.rougeaux@anu.edu.au>
srcversion:     53E4506D9E764E5FFCD056C
alias:          pci:v*d*sv*sd*bc0Csc00i10*
depends:        ieee1394
vermagic:       2.6.31.1-gms SMP preempt mod_unload modversions
parm:           phys_dma:Enable physical DMA (default = 1). (int)

Gruß
gms

[xerxes22]

Bei so viel Unterstützung werde ich hoffentlich eine Lösung finden ...
Knoppix bindet FireWire per udev ein (wo mir leider die Erfahrung fehlt..), zumindest wird das beim Systemstart angezeigt.

Code: Alles auswählen

>>>  knoppix# cat /boot/config-2.6.19 | grep -i apic
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y

>>>  knoppix# cat /etc/udev/rules.d/z25_persistent-net.rules
# This file was automatically generated by the /lib/udev/write_net_rules
# program, probably run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single line.
# MAC addresses must be written in lowercase.

# Firewire device 0000000000000344 (ohci1394)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:00:00:00:00:00:03:44", NAME="eth0"

# PCI device 0x10ec:0x8136 (r8169)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:1d:92:55:01:88", NAME="eth1"

>>>  knoppix# cat /boot/config-2.6.19 | grep 1394
# IEEE 1394 (FireWire) support
CONFIG_IEEE1394=m
# CONFIG_IEEE1394_VERBOSEDEBUG is not set
CONFIG_IEEE1394_OUI_DB=y
CONFIG_IEEE1394_EXTRA_CONFIG_ROMS=y
CONFIG_IEEE1394_CONFIG_ROM_IP1394=y
CONFIG_IEEE1394_EXPORT_FULL_API=y
CONFIG_IEEE1394_PCILYNX=m
CONFIG_IEEE1394_OHCI1394=m
CONFIG_IEEE1394_VIDEO1394=m
CONFIG_IEEE1394_SBP2=m
# CONFIG_IEEE1394_SBP2_PHYS_DMA is not set
CONFIG_IEEE1394_ETH1394=m
CONFIG_IEEE1394_DV1394=m
CONFIG_IEEE1394_RAWIO=m

Bei Debian sieht die Sache so aus

Code: Alles auswählen

>>> debian# cat /boot/config-2.6.26.8-rt16 | grep 1394
# IEEE 1394 (FireWire) support
CONFIG_IEEE1394=m
CONFIG_IEEE1394_OHCI1394=m
CONFIG_IEEE1394_PCILYNX=m
CONFIG_IEEE1394_SBP2=m
# CONFIG_IEEE1394_SBP2_PHYS_DMA is not set
CONFIG_IEEE1394_ETH1394_ROM_ENTRY=y
CONFIG_IEEE1394_ETH1394=m
CONFIG_IEEE1394_RAWIO=m
CONFIG_IEEE1394_VIDEO1394=m
CONFIG_IEEE1394_DV1394=m
# CONFIG_IEEE1394_VERBOSEDEBUG is not set
# CONFIG_PROVIDE_OHCI1394_DMA_INIT is not set

>>> debian# grep 1394 /etc/udev/rules.d/*
50-udev.rules:# ieee1394 devices
50-udev.rules:KERNEL=="dv1394*",		NAME="dv1394/%n"
50-udev.rules:KERNEL=="video1394*",		NAME="video1394/%n"
60-persistent-storage.rules:KERNEL=="sd*[!0-9]|sr*",		ATTRS{ieee1394_id}=="?*", \
60-persistent-storage.rules:	ENV{ID_BUS}="ieee1394", ENV{ID_SERIAL}="$attr{ieee1394_id}"
60-persistent-storage-tape.rules:KERNEL=="st*[0-9]|nst*[0-9]",		ATTRS{ieee1394_id}=="?*", \
60-persistent-storage-tape.rules:	ENV{ID_BUS}="ieee1394", ENV{ID_SERIAL}="$attr{ieee1394_id}"
75-cd-aliases-generator.rules:	SUBSYSTEMS!="usb|ieee1394", \
75-cd-aliases-generator.rules:	SUBSYSTEMS=="usb|ieee1394", \
75-persistent-net-generator.rules:SUBSYSTEMS=="ieee1394", \
91-permissions.rules:SUBSYSTEM=="block", SUBSYSTEMS=="usb|ieee1394|mmc|pcmcia", GROUP="floppy"
91-permissions.rules:# ieee1394 devices
91-permissions.rules:KERNEL=="raw1394",				GROUP="audio"
91-permissions.rules:KERNEL=="dv1394*",				GROUP="video"
91-permissions.rules:KERNEL=="video1394*",				GROUP="video"

Danke für eure Hilfe. Die Sache mit modprobe -r .. hatte ich schon ausprobiert.
Vielleicht waren ja auch meine pirq= Versuche alle unbrauchbar. Deswegen hier ein kleines Foto von meinem PCI-BUS.

Code: Alles auswählen

>>>  debian$ lspci      # -v erspare ich euch...
00:00.0 Host bridge: ATI Technologies Inc RS690 Host Bridge
00:01.0 PCI bridge: ATI Technologies Inc RS690 PCI to PCI Bridge (Internal gfx)
00:04.0 PCI bridge: ATI Technologies Inc Device 7914
00:06.0 PCI bridge: ATI Technologies Inc RS690 PCI to PCI Bridge (PCI Express Port 2)
00:07.0 PCI bridge: ATI Technologies Inc RS690 PCI to PCI Bridge (PCI Express Port 3)
00:12.0 SATA controller: ATI Technologies Inc SB600 Non-Raid-5 SATA
00:13.0 USB Controller: ATI Technologies Inc SB600 USB (OHCI0)
00:13.1 USB Controller: ATI Technologies Inc SB600 USB (OHCI1)
00:13.2 USB Controller: ATI Technologies Inc SB600 USB (OHCI2)
00:13.3 USB Controller: ATI Technologies Inc SB600 USB (OHCI3)
00:13.4 USB Controller: ATI Technologies Inc SB600 USB (OHCI4)
00:13.5 USB Controller: ATI Technologies Inc SB600 USB Controller (EHCI)
00:14.0 SMBus: ATI Technologies Inc SBx00 SMBus Controller (rev 14)
00:14.1 IDE interface: ATI Technologies Inc SB600 IDE
00:14.2 Audio device: ATI Technologies Inc SBx00 Azalia (Intel HDA)
00:14.3 ISA bridge: ATI Technologies Inc SB600 PCI to LPC Bridge
00:14.4 PCI bridge: ATI Technologies Inc SBx00 PCI to PCI Bridge
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
01:05.0 VGA compatible controller: ATI Technologies Inc RS690M [Radeon X1200 Series]
02:00.0 Ethernet controller: Atheros Communications Inc. AR242x 802.11abg Wireless PCI Express Adapter (rev 01)
03:00.0 PCI bridge: Texas Instruments XIO2000(A)/XIO2200(A) PCI Express-to-PCI Bridge (rev 03)
04:00.0 FireWire (IEEE 1394): Texas Instruments XIO2200(A) IEEE-1394a-2000 Controller (PHY/Link) (rev 01)
05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 01)

Grüße, xerxes22

[storm]

Ob ältere Version von udev oder nicht, spielt (wahrscheinlich) keine Rolle. Wichtiger ist die Tatsache, dass mit 2.6.22 (also genau zwischen 2.6.19 und 2.6.26) ein neuer firewire-Stack in den Kernel kam und auch viele andere Änderungen (zB. IRQ-Handling) eingeflossen sind. Die in den anderen Posts genannten Methoden gingen mir auch schon durch den Kopf, aber wenn keine wirkliche Abhilfe dabei ist, solltest du vielleicht auch mal in die andere Richtung suchen: welche Art Störungen bekommst du denn mit dem gegenwärtigen System? Sind es Aussetzer oder richtige Störgeräusche? Aus der scheduler-Diskussion (BSF vs. mainline) kenn ich den Vorwurf, dass ab (afair) 2.6.23 die Performance auf Desktop-Systemen mit jeder major-Kernel-Version etwas weiter abgenommen hat. Auch die Latenz wurde da angesprochen.

ciao, storm

[xerxes22]

- ok, die Idee, einen älteren Kernel auszuprobieren, ist mir noch nicht gekommen, aber ein wenig kriminalistischer Ehrgeiz
und eine Basis-Installation von Lenny minimal auf USB-Stick haben gezeigt -
siehe da, auch kernel 2.6.26 belegt zunächst die Grafikkarte mit IRQ 10, 1394 mit IRQ 18.
Sobald aber ein Grafiktreiber mit ins Spiel kommt, sei es fglrx oder radeon, schaltet dieser die Grafikkarte um auf IRQ 18.
Eins steht mal fest - der nächste Laptop hat nvidia. (ob's da so viel besser aussieht, ist 'ne andere Frage..)
Was gibt's für Alternativen bzgl. Grafiktreiber ? (wichtig , bitte antworten )
Oder hat vielleicht jemand Lust ein Programm zu schreiben, das den IRQ zur Laufzeit setzt ... .. bitte nicht alle auf einmal ..

welche Art Störungen bekommst du denn mit dem gegenwärtigen System?
Sind es Aussetzer oder richtige Störgeräusche?

Es sind Aussetzer, die ich mit einigem Konfigurationsaufwand (rt-Prioritäten und PCI-Latenzen anpassen etc.)
inzwischen etwas reduzieren konnte, trotzdem läuft bei mir das USB-Interface eines Bekannten ungleich stabiler. (auf eigenem IRQ !!)
Das Problem ist: wenn ich die Echtzeit-Priorität von Firewire erhöhe, steigt immer gleichermassen auch die der Grafikkarte.

Aus der scheduler-Diskussion (BSF vs. mainline) kenn ich den Vorwurf, dass ab (afair) 2.6.23 die Performance auf Desktop-Systemen mit jeder major-Kernel-Version etwas weiter abgenommen hat. Auch die Latenz wurde da angesprochen.

Bei mir ist Group-scheduling deaktiviert, hat aber nur geringe Verbesserung bewirkt. Weiterführende Links sind gern willkommen.
Niedrige Latenzen finde ich zweitrangig, wichtiger ist mir ein zuverlässiger Betrieb, v.a. bei Live-Aufnahmen. Es kann einfach nicht sein,
dass ich bei 64ms Latenz und 10% cpu-Belastung Aussetzer bekomme, wenn ich zwischendurch mal die Fenster verschiebe.
- werde bei Gelegenheit auch noch einen älteren Kernel ausprobieren.

Grüße, xerxes22

[xerxes22]

So, neuer Stand der Dinge - wenn ich mit Vesa-Treiber starte (Modul uvesafb), ist zwar die Grafik recht mässig,
ich erhalte Warnungen beim Systemstart, aber Grafikkarte auf IRQ10 und - wer hätte das gedacht - Ton läuft.
Der Rest ist Feinschliff - Vesa konfigurieren (da werd' ich morgen einen neuen Thread aufmachen. nee - ach was ),
Start-up-script, das die Konfigurations-Dateien passend zum gebootetem Kernel verlinkt, etc. pp
Vielen Dank, ohne Euch hätte ich es nicht geschafft.

[xerxes22]

Vielleicht interessiert es keinen mehr, aber inzwischen habe ich noch eine bessere Lösung gefunden :
das Paket xserver-xorg-video-radeonhd installiert, dann fglrx aus /etc/modules entfernt und in /etc/X11/xorg.conf
unter Section "Device" .... Driver "radeonhd" angegeben. Funktioniert bisher einwandtfrei.