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 ([EMAIL PROTECTED]) (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 <[EMAIL PROTECTED]>. 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 -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)