Re: irq routing conflict - einige varianten
Hallo Liste,
> Eine Bitte vorweg: könntest du eventuell bei weiteren Mails großzügiger
> mit Absätzen umgehen und vielleicht auch Groß/Kleinschreibung benutzen?
ok, ich versuche mein bestes ;-)
> Wie hast du den Kernel kompiliert? Debian-konform mit make-kpkg oder
> per Hand (mit make ...)?
ich habe ihn über make kompiliert und dann die arch/i386/boot/bzImage als
Kernelimage genommen, jeweils dann ins /boot Verzeichnis kopiert, mit lilo
korrekt verknüpft und lilo dann auch ausgeführt.
Die Module gewohnterweise mit make modules und danach make modules_install.
Die Debian Variante mit make-kpkg scheint mir irgendwie unnötig kompliziert
zu sein ;-)
> Hast du für Woddy auch die neuen module-init-tools, die für den 2.6.x
> Kernel benötigt werden, installiert (z.B. von www.backports.org)?
genau, die module-init-tools von backports.org.
> APM und ACPI dienen beide dem Power-Management. ACPI findet sich in
> neueren PCs/BIOSen und bietet mehr Möglichkeiten.
> PnP betrifft die automatische Konfiguration von ISA-Karten, im
> Gegensatz zur Konfig mit Jumpern (PlugAndPlay oder PlugAndPray, wie man
> will...). Keine ISA-Karten, keine PnP-Unterstützung nötig.
Vielen Dank für diese info :-)
ich dachte bisher, dass das noch irgendetwas mit pci-Karten zu tun hat -
werde ich nun abgeschalten (Kernel Image wieder etwas kompakter ...)
> APIC ist IMHO ein erweitertes Resourcen-Management, urspünglich dafür
> gedacht um Mehrprozessor-Systemen den geregelten Zugriff auf die
> Hardware(-IRQs) zu gewähren. Dabei werden die BIOS-seitig beschränkten
> IRQ/IO-Adressen logisch erweitert und umgeleitet (routing).
> Ist mittlerweile auch bei neueren Single-CPU-Systemen implementiert.
hmm... also ich habe hier am Windows-PC mit neuem Asus SK8V im Gerätemanager
IRQs bis 21, das wäre eine ersehnte Erklärung dafür, danke :-)
Soweit ich das nun verstanden habe, bedeutet ACPI unter anderem, dass es
beispielsweise
egal ist, welche IRQs das Bios den Geräten zuordnet, das Betriebssystem kann
dieses dann
selbst ggf. anders erledigen, unabhängig vom Bios.
Inwiefern steht APIC damit im Zusammenhang ?
Also kann, wenn APIC verfügbar ist (ist ACPI hierbei erforderlich?), das
Bios auch (also nur in der Tabelle während des Bootvorgangs) "virtuelle"
IRQs >15 vergeben ?
oder kann das IRQ > 15 generell nur das Betriebssystem, also das Bios nicht
?
bzw. ist aus Sicht des Betriebssystems nur ACPI nötig (also APIC optional) -
oder umgekehrt - oder braucht man beides -um diese IRQs > 15 vergeben zu
können ?
Abgesehen von APIC - funktioniert IRQ _sharing_ selbst andererseits nur,
wenn ACPI vom Kernel unterstützt wird ?
Falls ja, dann wäre ja der =>IRQ sharing Bestandteil<= von ACPI
möglicherweise eine rein softwareseitige Erweiterung. Also es wäre kein
spezielles Bios mit ACPI Unterstützung nötig,
um wirklich nur IRQ sharing (im Gegensatz zu anderen Bestandteilen von ACPI,
beispielsweise Standby-Modus, wo ja auch das Bios es unterstützen muss)
nutzen zu können.
Das wäre wirklich hilfreich, wenn man den Zusammenhang zwischen APIC und
ACPI und deren Bestandteilen genau wüsste ;-)
> Ich bin mir nicht sicher ob dein PII (ist ein PII 350Mhz ?) schon MMX
> unterstützt. cat /proc/cpuinfo gibt dir bei Flags Auskunft darüber.
> Evtl. ist
> > # CONFIG_MPENTIUMII is not set
> die bessere Wahl. Ist IMHO aber eher Nebensache.
okay, habe ich eingestellt (hatte ursprünglich nur pentium MMX gewählt, um
eine größere Kompatibilität des Kernels zu ermöglichen,
aber aufgrund der zahlreichen Tuningmöglichkeiten, deren genaue Bedeutung
ich jetzt erst im Nachhinein erfahren kann, scheint das keine gute Idee
gewesen zu sein ....)
> > CONFIG_SMP=y
>
> Würde ich disablen. Gerade bei älteren Boards/CPUs kann aktivierte
> SMP-Untestützung Probleme bereiten.
ok, ist deaktiviert (.. und das Kernelimage um einies kleiner ;-))
> CONFIG_X86_LOCAL_APIC=y
> CONFIG_X86_IO_APIC=y
> Du schriebst, du hättest deinen Kernel ohne APIC kompiliert. Hier ist
> es aber noch ativiert ? Würde ich abschalten, da dein BIOS sowieso kein
> APIC kann, s.u.
sorry, hatte einfach mal mit den Parametern irgendwie rumprobiert, da ich
nicht genau wusste, was
genau sie eigentlich bewirken, also deaktiviert ist es inzwischen :-)
> Ist ok, dein BIOS ist IMHO nicht ACPI-fähig.
hmm... bedeutet das, dass auch kein IRQ sharing möglich ist ?
> > CONFIG_ACPI_BOOT=y
> > #
> > # APM (Advanced Power Management) BIOS Support
> > #
> > # CONFIG_APM is not set
>
> Must du einschalten, wenn du (APM)-Powermanagement für Festplatten und
> Abschalten benutzen wilst.
okay, vielen dank - zumindest beim herunterfahren schaltet er die Festplatte
inzwischen ab und der Rechner schaltet sich auch automatisch ab - also auch
das scheint wohl ein Bestandteil von APM zu sein.
> > #
> > # Bus options (PCI, PCMCIA, EISA, MCA, ISA)
> > #
> > CONFIG_PCI=y
> > # CONFIG_PCI_GOBIOS is not set
> > # CONFIG_PCI_GOMMCONFIG is not set
> > # CONFIG_PCI_GODIRECT is not set
> > CONFIG_PCI_GOANY=y
> > CONFIG_PCI_BIOS=y
> > CONFIG_PCI_DIRECT=y
> > CONFIG_PCI_MMCONFIG=y
> > # CONFIG_PCI_MSI is not set
> > CONFIG_PCI_LEGACY_PROC=y
> > CONFIG_PCI_NAMES=y
>
> Ich kenne den 2.8.-Kernel nicht sehr gut, aber zu diesen Optionen würde
> ich mir die Hilfe mal durchlesen, ob da welche nicht dein Problem
> berühren. Bei Unklarheit lieber die Default-Werte nehmen.
aus den entsprechenden Optionen in menuconfig und einigen google-Recherchen
konnte ich
hier einiges herausfinden, doch weiß ich zwar nun, was die Parameter in etwa
bringen, doch ob es bei mir
nötig ist - keine ahnung *g*
> CONFIG_PCI=y
ob der kernel PCI generell unterstützt (is klar ....)
> # CONFIG_PCI_GOBIOS is not set
> # CONFIG_PCI_GOMMCONFIG is not set
> # CONFIG_PCI_GODIRECT is not set
> CONFIG_PCI_GOANY=y
in menuconfig Zusammengefasst unter "PCI Access mode":
( ) BIOS
( ) MMConfig
( ) Direct
(X) Any
nun, "Bios" bedeutet dann wohl, dass er die PCI Geräte über das Bios
anspricht, doch ist trotzdem
unklar, ob der Kernel dann auch die IRQ Verteilung des Bios übernimmt.
was "MMConfig" ist weiß ich nicht *g*
"Direct" müsste dann eigentlich zur Folge haben, dass das Bios nicht mehr
beteiligt ist - doch ist das nicht Sache von ACPI ?
Falls es unabhängig von ACPI ist, wird dann trotz des direkten Zugriffsmodus
der Bios-Interrupt übernommen - also "Direct" mit dem Interruptmanagement
selbst nichts tun tun hat ?
Da ich nicht weiß, was hier nun sinnvoll ist, hab ich einfach "Any"
gelassen.
dann gibt es ja noch
> CONFIG_PCI_BIOS=y
> CONFIG_PCI_DIRECT=y
> CONFIG_PCI_MMCONFIG=y
also ohne das "GO" - in menuconfig finde ich nichts dazu, möglicherweise ein
Aliasname oder aber betreffen die "GO"-Parameter das erkennen der Hardware
und
die ohne "GO" den regulären zugriff darauf....falls diese Theorie stimmt,
wäre das eine Erklärung, dass beim Laden des Moduls/Erkennen der Hardware
("found ...")
ein irq routing conflict kommt, die netzwerkkarten zumindest aber trotzdem
funktionieren.
> # CONFIG_PCI_MSI is not set
nun, dazu habe ich folgendes gefunden:
http://www.linuxhq.com/kernel/v2.6/8/Documentation/MSI-HOWTO.txt
"Message Signaled Interrupts":
> The MSI capability structure contains Message Control register,
> Message Address register and Message Data register. These registers
> support for better interrupt performance.
> [...]
> Since the target of the inbound message is the local APIC, providing
> -CONFIG_PCI_USE_VECTOR is dependent on whether CONFIG_X86_LOCAL_APIC
> -is enabled or not.
> +CONFIG_X86_LOCAL_APIC must be enabled as well as CONFIG_PCI_MSI.
es scheint also eine Art optimiertes Interruptmanagement zu sein, was nur
mit APIC möglich ist - also an dem Rechner irrelevant, wenn er kein APIC
hat.
> CONFIG_PCI_LEGACY_PROC=y
ob /proc/pci später verfügbar sein soll oder nicht
> CONFIG_PCI_NAMES=y
ob der Kernel unter anderem in /proc/pci / /proc/ioports etc. die Namen der
Karten oder nur deren Geräte-IDs anzeigt.
interessant ist auch:
http://tlug.up.ac.za/guides/lkcg/lkcg_config.html
> > Sep 12 15:49:17 server kernel: Cannot find map file.
> > Sep 12 15:49:17 server kernel: No module symbols loaded - kernel modules
not
> > enabled.
> Hm, das macht mich stutzig. Hast du die zu deinem Kernel passende
> System.map auch nach /boot installiert (wenn mit make bzImage gebaut) ?
> Diese Meldung und evtl. Probleme mit Modulen *könnten* mit dem Fehlen
> der Map-Datei zusammenhängen.
Nun, das hat mich auch bereits zum nachdenken gebracht, aber da hat sich
ergeben,
dass der klogd hier einen bug hat, also die Meldung unsinnig ist (module
laden geht ja auch)
http://lists.suse.com/archive/suse-laptop/2004-Jan/index.html#220
>>> Es stimmt, dass diese Fehlermeldung
>>> falsch ist, weil sie von ksyslogd (für 2.4) ausgegeben wird. Ich habe
>>> dasselbe Problem, der Kernel bootet korrekt, aber Netzwerkkarte,
>>> Soundkarte und TV-Karte funktionieren erst, wenn ich die Module manuell
>>> lade. Danach läuft alles einwandfrei. Ist die modules.conf von YaST
>>> nicht in Ordnung? (Ich habe einen 2.4er und einen 2.6.1er Kernel.)
nun, so ein ähnliches Problem hatte ich ja mit der realtek-karte ( 8139too
wurde nicht geladen, dmfe schon,
de4x5 probiert (karte ausgebaut)), aber dann fand ich heraus, dass es neben
der /etc/modules.conf und der
/etc/modprobe.conf eine weitere datei gibt - /etc/modules. Darin stand dmfe
und de4x5, das habe ich soweit
hinreichend geändert/angepasst, dann war das Problem gelöst.
Testweise ließ ich die Datei /etc/modules mal komplett leer, um zu testen,
ob der Kernel dann dmfe automatisch lädt - tat er nicht.
Das war zu dem Zeitpunkt, als modprobe wirkungslos war und eintragungen à la
"install 8139too /bin/true" in
/etc/modprobe.conf ebenfalls wirkungslos waren.
also habe ich /lib/modules/2.6.8.1 mal komplett gelöscht, und kernel
nochmals kompiliert, module installiert und depmod ausgeführt.
Dann funktionierte das automatische laden auch - also muss wohl irgendeine
datei in dem Ordner das Problem verursacht haben.
Später fand ich in menuconfig dann die Option "Loadable module support" /
"Automatic kernel module loading" - sie war aber bisher immer aktiviert.
Ärgerlich ist bei dem automatisch Laden aber, dass dies erst recht spät
während des Bootvorgangs erfolgt,
also nochmals ein "ifup -a --force" nötig ist, bei dem Rechner zumindest,
hatte ähnliche Installationen, bei welchen das auch ohne funktionierte.
Wie auch immer, nun habe ich die Module in der ominösen /etc/modules Datei
eingetragen, welche früher abgearbeitet wird.
> > Sep 12 15:49:17 server kernel: ACPI disabled because your bios is from
98
> > and too old
> > Sep 12 15:49:17 server kernel: You can enable it with acpi=force
>
> Ist klar, oder?
jo, welche Anforderungen stellt denn das ACPI des Kernels an das Bios ?
bzw. gibt es eine Art Richtwert, ab welcher Mainboardgeneration
(penium1/p2/p3/p4/k5/k6/athlon(k7)/k8) es funktioniert ?
> > Sep 12 15:49:17 server kernel: Kernel command line: auto
BOOT_IMAGE=Linux ro
> > root=301 pci=biosirq
> > Sep 12 15:49:17 server kernel: Local APIC disabled by BIOS --
reenabling.
> > Sep 12 15:49:17 server kernel: Found and enabled local APIC!
>
> Hier wird APIC kernelseitig eingeschaltet (weil einkompiliert) obwohl
> entweder im BIOS disabled bzw. nicht vorhanden.
hmm - dh die Meldung:
> Sep 12 15:49:17 server kernel: Found and enabled local APIC!
bedeutet nur, dass der Kernel APIC aktiviert hat, aber nicht, dass es auch
funktioniert in Form der Interaktion mit der APIC Hardware?
> > Versuche als Bootparameter nochmal noapic und nolapic, evtl. in
> > Kombination mit pci=biosirq
ok, ich habe APIC gleich komplett weglassen ;-)
> > Sep 12 15:49:17 server kernel: dmfe: Davicom DM9xxx net driver, version
> > 1.36.4 (2002-01-17)
> > Sep 12 15:49:17 server kernel: PCI: Found IRQ 12 for device 0000:00:0b.0
> > Sep 12 15:49:17 server kernel: IRQ routing conflict for 0000:00:0b.0,
have
> > irq 11, want irq 12
> > Sep 12 15:49:17 server kernel: eth0: Davicom DM9102 at pci0000:00:0b.0,
> > 00:80:ad:78:d2:c1, irq 11.
>
> Dieses have/want mag mit der APIC-Unterstützung des Kernels zu tun
> haben. APIC möchte eine andere Verteilung als das BIOS es vorgibt. Auf
> moderneren Systemen evtl. kein Problem, bei dir wahrscheinlich schon.
hmm - es wäre eine Erklärung.
Die Logdatei sieht mit abgeschaltetem APIC so aus:
(ACPI auch mal deaktiviert, möglichst wenig aktiviert => möglichst wenig
Fehlerquellen)
Sep 13 14:54:00 server kernel: klogd 1.4.1#10, log source = /proc/kmsg
started.
Sep 13 14:54:00 server kernel: Cannot find map file.
Sep 13 14:54:00 server kernel: No module symbols loaded - kernel modules not
enabled.
Sep 13 14:54:00 server kernel: Linux version 2.6.8.1 (root@server) (gcc
version 2.95.4 20011002 (Debian prerelease)) #8 Sun Sep 12 21:21:57 CEST
2004
Sep 13 14:54:00 server kernel: BIOS-provided physical RAM map:
Sep 13 14:54:00 server kernel: BIOS-e820: 0000000000000000 -
000000000009fc00 (usable)
Sep 13 14:54:00 server kernel: BIOS-e820: 000000000009fc00 -
00000000000a0000 (reserved)
Sep 13 14:54:00 server kernel: BIOS-e820: 00000000000f0000 -
0000000000100000 (reserved)
Sep 13 14:54:00 server kernel: BIOS-e820: 0000000000100000 -
000000000bfe0000 (usable)
Sep 13 14:54:00 server kernel: BIOS-e820: 000000000bfe0000 -
000000000bff8000 (ACPI data)
Sep 13 14:54:00 server kernel: BIOS-e820: 000000000bff8000 -
000000000c000000 (ACPI NVS)
Sep 13 14:54:00 server kernel: BIOS-e820: 00000000ffff0000 -
0000000100000000 (reserved)
Sep 13 14:54:00 server kernel: 191MB LOWMEM available.
Sep 13 14:54:00 server kernel: On node 0 totalpages: 49120
Sep 13 14:54:00 server kernel: DMA zone: 4096 pages, LIFO batch:1
Sep 13 14:54:00 server kernel: Normal zone: 45024 pages, LIFO batch:10
Sep 13 14:54:00 server kernel: HighMem zone: 0 pages, LIFO batch:1
Sep 13 14:54:00 server kernel: DMI 2.0 present.
Sep 13 14:54:00 server kernel: ACPI disabled because your bios is from 98
and too old
Sep 13 14:54:00 server kernel: You can enable it with acpi=force
Sep 13 14:54:00 server kernel: Built 1 zonelists
Sep 13 14:54:00 server kernel: Kernel command line: auto BOOT_IMAGE=Linux ro
root=301
Sep 13 14:54:00 server kernel: Initializing CPU#0
Sep 13 14:54:00 server kernel: CPU 0 irqstacks, hard=c03a1000 soft=c03a0000
Sep 13 14:54:00 server kernel: PID hash table entries: 1024 (order 10: 8192
bytes)
Sep 13 14:54:00 server kernel: Detected 350.922 MHz processor.
Sep 13 14:54:00 server kernel: Using tsc for high-res timesource
Sep 13 14:54:00 server kernel: Console: colour VGA+ 80x25
Sep 13 14:54:00 server kernel: Dentry cache hash table entries: 32768
(order: 5, 131072 bytes)
Sep 13 14:54:00 server kernel: Inode-cache hash table entries: 16384 (order:
4, 65536 bytes)
Sep 13 14:54:00 server kernel: Memory: 191224k/196480k available (1639k
kernel code, 4608k reserved, 907k data, 116k init, 0k highmem)
Sep 13 14:54:00 server kernel: Checking if this processor honours the WP bit
even in supervisor mode... Ok.
Sep 13 14:54:00 server kernel: Calibrating delay loop... 692.22 BogoMIPS
Sep 13 14:54:00 server kernel: Mount-cache hash table entries: 512 (order:
0, 4096 bytes)
Sep 13 14:54:00 server kernel: CPU: After generic identify, caps: 0183f9ff
00000000 00000000 00000000
Sep 13 14:54:00 server kernel: CPU: After vendor identify, caps: 0183f9ff
00000000 00000000 00000000
Sep 13 14:54:00 server kernel: CPU: L1 I cache: 16K, L1 D cache: 16K
Sep 13 14:54:00 server kernel: CPU: L2 cache: 512K
Sep 13 14:54:00 server kernel: CPU: After all inits, caps: 0183f9ff 00000000
00000000 00000040
Sep 13 14:54:00 server kernel: Intel machine check architecture supported.
Sep 13 14:54:00 server kernel: Intel machine check reporting enabled on
CPU#0.
Sep 13 14:54:00 server kernel: CPU: Intel Pentium II (Deschutes) stepping 02
Sep 13 14:54:00 server kernel: Enabling fast FPU save and restore... done.
Sep 13 14:54:00 server kernel: Checking 'hlt' instruction... OK.
Sep 13 14:54:00 server kernel: NET: Registered protocol family 16
Sep 13 14:54:00 server kernel: PCI: PCI BIOS revision 2.10 entry at 0xfd998,
last bus=1
Sep 13 14:54:00 server kernel: PCI: Using configuration type 1
Sep 13 14:54:00 server kernel: mtrr: v2.0 (20020519)
Sep 13 14:54:00 server kernel: ACPI: Subsystem revision 20040326
Sep 13 14:54:00 server kernel: ACPI: Interpreter disabled.
Sep 13 14:54:00 server kernel: PCI: Probing PCI hardware
Sep 13 14:54:00 server kernel: PCI: Probing PCI hardware (bus 00)
Sep 13 14:54:00 server kernel: PCI: Using IRQ router VIA [1106/0596] at
0000:00:07.0
Sep 13 14:54:00 server kernel: Machine check exception polling timer
started.
Sep 13 14:54:00 server kernel: apm: BIOS version 1.2 Flags 0x03 (Driver
version 1.16ac)
Sep 13 14:54:00 server kernel: audit: initializing netlink socket (disabled)
Sep 13 14:54:00 server kernel: audit(1095087227.4294965299:0): initialized
Sep 13 14:54:00 server kernel: Initializing Cryptographic API
Sep 13 14:54:00 server kernel: Activating ISA DMA hang workarounds.
Sep 13 14:54:00 server kernel: Linux agpgart interface v0.100 (c) Dave Jones
Sep 13 14:54:00 server kernel: Serial: 8250/16550 driver $Revision: 1.90 $ 8
ports, IRQ sharing disabled
Sep 13 14:54:00 server kernel: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
Sep 13 14:54:00 server kernel: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
Sep 13 14:54:00 server kernel: Using anticipatory io scheduler
Sep 13 14:54:00 server kernel: Floppy drive(s): fd0 is 1.44M
Sep 13 14:54:00 server kernel: FDC 0 is a post-1991 82077
Sep 13 14:54:00 server kernel: Uniform Multi-Platform E-IDE driver Revision:
7.00alpha2
Sep 13 14:54:00 server kernel: ide: Assuming 33MHz system bus speed for PIO
modes; override with idebus=xx
Sep 13 14:54:00 server kernel: hda: SAMSUNG SV1533D, ATA DISK drive
Sep 13 14:54:00 server kernel: hdc: LG CD-ROM CRD-8522B, ATAPI CD/DVD-ROM
drive
Sep 13 14:54:00 server kernel: ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Sep 13 14:54:00 server kernel: ide1 at 0x170-0x177,0x376 on irq 15
Sep 13 14:54:00 server kernel: hda: max request size: 128KiB
Sep 13 14:54:00 server kernel: hda: 29897280 sectors (15307 MB) w/472KiB
Cache, CHS=29660/16/63
Sep 13 14:54:00 server kernel: hda: hda1 hda2 < hda5 >
Sep 13 14:54:00 server kernel: hdc: ATAPI 48X CD-ROM drive, 128kB Cache
Sep 13 14:54:00 server kernel: Uniform CD-ROM driver Revision: 3.20
Sep 13 14:54:00 server kernel: mice: PS/2 mouse device common for all mice
Sep 13 14:54:00 server kernel: serio: i8042 AUX port at 0x60,0x64 irq 12
Sep 13 14:54:00 server kernel: serio: i8042 KBD port at 0x60,0x64 irq 1
Sep 13 14:54:00 server kernel: NET: Registered protocol family 2
Sep 13 14:54:00 server kernel: IP: routing cache hash table of 1024 buckets,
8Kbytes
Sep 13 14:54:00 server kernel: TCP: Hash tables configured (established
16384 bind 16384)
Sep 13 14:54:00 server kernel: ip_conntrack version 2.1 (1535 buckets, 12280
max) - 300 bytes per conntrack
Sep 13 14:54:00 server kernel: ip_tables: (C) 2000-2002 Netfilter core team
Sep 13 14:54:00 server kernel: ipt_recent v0.3.1: Stephen Frost
<sfrost@snowman.net>. http://snowman.net/projects/ipt_recent/
Sep 13 14:54:00 server kernel: arp_tables: (C) 2002 David S. Miller
Sep 13 14:54:00 server kernel: NET: Registered protocol family 1
Sep 13 14:54:00 server kernel: NET: Registered protocol family 17
Sep 13 14:54:00 server kernel: kjournald starting. Commit interval 5 seconds
Sep 13 14:54:00 server kernel: EXT3-fs: mounted filesystem with ordered data
mode.
Sep 13 14:54:00 server kernel: VFS: Mounted root (ext3 filesystem) readonly.
Sep 13 14:54:00 server kernel: Freeing unused kernel memory: 116k freed
Sep 13 14:54:00 server kernel: Adding 1277128k swap on /dev/hda5.
Priority:-1 extents:1
Sep 13 14:54:00 server kernel: EXT3 FS on hda1, internal journal
Sep 13 14:54:00 server kernel: dmfe: Davicom DM9xxx net driver, version
1.36.4 (2002-01-17)
Sep 13 14:54:00 server kernel: PCI: Found IRQ 12 for device 0000:00:0b.0
Sep 13 14:54:00 server kernel: IRQ routing conflict for 0000:00:0b.0, have
irq 11, want irq 12
Sep 13 14:54:00 server kernel: eth0: Davicom DM9102 at pci0000:00:0b.0,
00:80:ad:78:d2:c1, irq 11.
Sep 13 14:54:00 server kernel: 8139too Fast Ethernet driver 0.9.27
Sep 13 14:54:00 server kernel: PCI: Found IRQ 10 for device 0000:00:0c.0
Sep 13 14:54:00 server kernel: IRQ routing conflict for 0000:00:0c.0, have
irq 12, want irq 10
Sep 13 14:54:00 server kernel: eth1: RealTek RTL8139 at 0xd800,
00:50:22:d3:5f:36, IRQ 12
Sep 13 14:54:00 server kernel: eth1: Identified 8139 chip type
'RTL-8100B/8139D'
Sep 13 14:54:00 server kernel: eth1: link up, 100Mbps, full-duplex, lpa
0x45E1
Sep 13 14:54:00 server kernel: CSLIP: code copyright 1989 Regents of the
University of California
Sep 13 14:54:00 server kernel: PPP generic driver version 2.4.2
Sep 13 14:54:01 server kernel: process `named' is using obsolete setsockopt
SO_BSDCOMPAT
Sep 13 14:54:03 server kernel: spurious 8259A interrupt: IRQ7.
also die APIC Sache ist nun weg, doch beide IRQ routing conflicts existieren
noch.
Sep 13 14:54:00 server kernel: BIOS-e820: 000000000bfe0000 -
000000000bff8000 (ACPI data)
Sep 13 14:54:00 server kernel: BIOS-e820: 000000000bff8000 -
000000000c000000 (ACPI NVS)
Könnte das bedeuten, dass ACPI auch seitens des Bios doch verfügbar ist ?
:-)
wenn ja, beeinflusst das die Möglichkeit IRQ sharing zu aktivieren ?
Einige Dinge sind dabei auch seltsam:
Sep 13 14:54:00 server kernel: serio: i8042 AUX port at 0x60,0x64 irq 12
es scheint hier noch etwas auf irq12 zu sein. in der bios-tabelle wird es
aber nicht angezeigt - in /proc/interrupts auch nicht:
CPU0
0: 1325051 XT-PIC timer
2: 0 XT-PIC cascade
9: 34 XT-PIC HFC PCI
10: 1 XT-PIC HFC PCI
11: 531 XT-PIC eth0
12: 1709 XT-PIC eth1
14: 5043 XT-PIC ide0
15: 13 XT-PIC ide1
NMI: 0
ERR: 2
"serio: i8042" könnte serial input output heißen, also eine serielle
schnittstelle - ich werde die kernel unterstützung dafür nachher mal
rausnehmen, da
ich den port eh nicht brauche, vielleicht hilft das zumindest bei der
realtek Karte, die ja auf...
Sep 13 14:54:00 server kernel: IRQ routing conflict for 0000:00:0c.0, have
irq 12, want irq 10
...irq 12 ist, aber auf irq 10 "will".
warum aber bei irq 11 es noch ein Problem gibt ist damit aber nicht
unbedingt erklärt.
Außer natürlich ein Interruptkonflikt kann weitere nach sich ziehen, die
ISDN karten bringen ja auch einen routing conflict.
unverständlich ist auch die ausgabe von lsmod:
Module Size Used by
hfcpci 26784 0
mISDN_dsp 194176 0
l3udss1 32992 0
mISDN_l2 37280 0
mISDN_l1 9344 0
mISDN_core 67200 5 hfcpci,mISDN_dsp,l3udss1,mISDN_l2,mISDN_l1
ppp_async 9152 1
crc_ccitt 2016 1 ppp_async
ppp_generic 24684 5 ppp_async
slhc 6272 1 ppp_generic
8139too 19392 0
dmfe 17500 0
dmfe und 8139too sind nicht "benutzt" - also used by "0", sie funktionieren
aber zweifellos ....
liegt das vermutlich am lsmod, das zu alt ist, oder kann das andere gründe
haben ?
> Ich würde folgendes machen:
>
> a) im BIOS alles wieder auf Default stellen, gerade irgendwelche
> händische Einstellungen in der PCI-Tabelle.
okay, also nur "plug & play aware o/s" wieder auf "no" stellen - das müsste
sich ja dann eigentlich
nur auf ISA Karten auswirken, wenn diese vorhanden wären oder ?
> b) Kernel 2.4.x, 2.6.7 zum Gegentesten bereithalten.
okay, habe ich :-)
> c) 2.6.8 entweder:
> - vorkompiliert downlaoden (von www.backports.org ?)
> - neukompilieren mit o.a. Hinweisen zur Konfig
> - deinen momentanen mit den Optionen wie o.a. (noapic, nolapic,
> pci=biosirq) nochmal zum Test hernehmen.
ok, ich werde dann noch ein paar kompilier-versuche unternehmen, jeweils in
Kombination
mit den genannten Parametern ;-)
> Bei den Parametern mußt du nochml in der kernel-parameters.txt zum
> 2.6er Kernel schauen, ob es diese so noch gibt. Ich habe hier nur
> Zugriff auf die vom 2.4er.
>
> d) die ISDN-Karten ausbauen und erstmal beide NICs zum funktionieren
> bringen
die parameter scheint es noch zu geben; prinzipiell funktionieren die NICs
zwar, jedoch ist ein routing conflict doch eine relativ unschöne Sache, ich
werde es mal mit dem Ausbauen der ISDN Karten probieren.
> Und auch bei dir gilt, wie in einem ähnlichen Thread momentan auf
> dieser Liste,: du mußt systematisch vorgehen, nie mehere Sachen
> gleichzeitig ändern.
>
>So, ich hoffe das bringt sich etwas weiter.
jo, vielen Dank für deine Hilfe :-)
> Gruß
> Gerhard
mfg christoph
Reply to: