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)
