k_athlon-2.4.21-58.i586.rpm mit force installieren?
Eben habe ich gemerkt, dass bei der Installation für einen Athlon mit KT400A-Chipsatz ein Default-Kernel installiert wurde und komischerweise habe ich mit diesem Kernel nun auch keinen Netzwerkzugriff mehr, boote ich mit dem Vanilla-Kernel funktioniert das NW schon. Ok, diesen Kernel kann ich wohl überschreiben. Wegen nicht funktionierendem NW nur sinngemäß die Meldung: k_athlon-2.4.21-58.i586 confilcts for k_default ... Kann ich da einfach mit rpm -Uvh --force darübergehen oder gibt das automatisch Problem mit den Modulen? Al
Al Bogner wrote:
Eben habe ich gemerkt, dass bei der Installation für einen Athlon mit KT400A-Chipsatz ein Default-Kernel installiert wurde und komischerweise habe ich mit diesem Kernel nun auch keinen Netzwerkzugriff mehr, boote ich mit dem Vanilla-Kernel funktioniert das NW schon. Ok, diesen Kernel kann ich wohl überschreiben.
Wegen nicht funktionierendem NW nur sinngemäß die Meldung: k_athlon-2.4.21-58.i586 confilcts for k_default ...
Kann ich da einfach mit rpm -Uvh --force darübergehen oder gibt das automatisch Problem mit den Modulen?
Wieso deinstallierst Du den alten nicht vorher? Ein Upgrade eigentlich nur, wenn es dasselbe Paket ist nur in einer neueren Version. -- Andreas
Am Samstag, 30. August 2003 21:22 schrieb Andreas Winkelmann:
Eben habe ich gemerkt, dass bei der Installation für einen Athlon mit KT400A-Chipsatz ein Default-Kernel installiert wurde und komischerweise habe ich mit diesem Kernel nun auch keinen Netzwerkzugriff mehr, boote ich mit dem Vanilla-Kernel funktioniert das NW schon. Ok, diesen Kernel kann ich wohl überschreiben.
Wegen nicht funktionierendem NW nur sinngemäß die Meldung: k_athlon-2.4.21-58.i586 confilcts for k_default ...
Mit acpi=off funktioniert das Netzwerk. Was hat denn ACPI mit einer NIC zu tun? Hier also die Original-Meldung # rpm -Uvh k_athlon-2.4.21-58.i586.rpm error: failed dependencies: rpmlib(PartialHardlinkSets) <= 4.0.4-1 is needed by k_athlon-2.4.21-58 k_athlon conflicts with k_deflt-2.4.20-100 k_athlon conflicts with k_deflt-2.4.20-100 In ftp://ftp.suse.com/pub/people/mantel/next/RPM/README steht zwar "rpm -Uhv --nodeps" aber ich bin doch schon etwas irritiert, dass ein Default-Kernel durch einen Athlon-Kernel ersetzt werden soll. Hätte es bei der Installation eine Möglichkeit gegeben für den Athlon-PC einen Athlon-Kernel zu erzwingen?
Kann ich da einfach mit rpm -Uvh --force darübergehen oder gibt das automatisch Problem mit den Modulen?
Wieso deinstallierst Du den alten nicht vorher? Ein Upgrade eigentlich nur, wenn es dasselbe Paket ist nur in einer neueren Version.
Hmmh, mir ist zu wenig klar was das rpm macht. Ich gehe mal davon aus, dass das rpm den Kernel ersetzt, der gerade läuft. Ich kann also nicht mit einem Vanilla-Kernel booten und dann k_athlon-2.4.21-58.i586.rpm installieren. Wenn ich also den laufenden SuSE-Kernel deinstalliere, säge ich mir da nicht den eigenen Ast ab? Al
Al Bogner wrote:
Eben habe ich gemerkt, dass bei der Installation für einen Athlon mit KT400A-Chipsatz ein Default-Kernel installiert wurde und komischerweise habe ich mit diesem Kernel nun auch keinen Netzwerkzugriff mehr, boote ich mit dem Vanilla-Kernel funktioniert das NW schon. Ok, diesen Kernel kann ich wohl überschreiben.
Wegen nicht funktionierendem NW nur sinngemäß die Meldung: k_athlon-2.4.21-58.i586 confilcts for k_default ...
Mit acpi=off funktioniert das Netzwerk. Was hat denn ACPI mit einer NIC zu tun?
acpi hat z.B. etwas mit irq-zuordnung zu tun. Also im endeffekt mit nahezu jedem OnBoard-Device bzw. Karte in Deinem PC. Je neuer der Kernel desto weniger Probleme solltes es eigentlich geben, da die Mainboard-Blacklist ja immer erweitert wird.
Hier also die Original-Meldung
# rpm -Uvh k_athlon-2.4.21-58.i586.rpm error: failed dependencies: rpmlib(PartialHardlinkSets) <= 4.0.4-1 is needed by k_athlon-2.4.21-58 k_athlon conflicts with k_deflt-2.4.20-100 k_athlon conflicts with k_deflt-2.4.20-100
In ftp://ftp.suse.com/pub/people/mantel/next/RPM/README steht zwar "rpm -Uhv --nodeps" aber ich bin doch schon etwas irritiert, dass ein Default-Kernel durch einen Athlon-Kernel ersetzt werden soll.
Dieses --nodeps war wegen der RPM-4-Version. Wenn Du einen Kernel für einen anderen Prozessorarchitektur installierst, würde ich den alten deinstallieren. Vor einem neustart natürlich einen neuen installieren ;-)
Hätte es bei der Installation eine Möglichkeit gegeben für den Athlon-PC einen Athlon-Kernel zu erzwingen?
Ich habe letztens eine Anleitung dafür gesehen bei der Installation statt des gefundenen SMP-Kernel einen Non-SMP-Kernel zu installieren, also sollte es auch mit dem Athlon-Kernel gehen.
Kann ich da einfach mit rpm -Uvh --force darübergehen oder gibt das automatisch Problem mit den Modulen?
Wieso deinstallierst Du den alten nicht vorher? Ein Upgrade eigentlich nur, wenn es dasselbe Paket ist nur in einer neueren Version.
Hmmh, mir ist zu wenig klar was das rpm macht.
Schau mal in das spec-file vom rpm, dort gibt es eine %install-sektion. Das macht das rpm beim installieren.
Ich gehe mal davon aus, dass das rpm den Kernel ersetzt, der gerade läuft. Ich kann also nicht mit einem Vanilla-Kernel booten und dann k_athlon-2.4.21-58.i586.rpm installieren.
Wieso nicht, solange der Kernel anders heisst und die version in /lib/modules eine andere ist, ist das kein Problem. Mach doch einfach mal ein "rpm -qlp kernel_den_du_installieren_willst.rpm", dann siehst Du welche Dateien dazugehören. Und kannst prüfen, ob es sich mit Deinen beisst. Zum Kernel gehört der Kernel selber /boot/vmlinuz.version und die Module in /lib/modules/version/*. Wenn Du die Versionen änderst, kannst Du soviel Du willst parallel installieren.
Wenn ich also den laufenden SuSE-Kernel deinstalliere, säge ich mir da nicht den eigenen Ast ab?
Solange Du nicht neustartest... -- Andreas
Am Samstag, 30. August 2003 22:07 schrieb Andreas Winkelmann:
Wenn Du einen Kernel für einen anderen Prozessorarchitektur installierst, würde ich den alten deinstallieren. Vor einem neustart natürlich einen neuen installieren ;-)
So der Kernel ist gelöscht und die Fehlermeldung bleibt: # rpm --install k_athlon-2.4.21-58.i586.rpm error: failed dependencies: rpmlib(PartialHardlinkSets) <= 4.0.4-1 is needed by k_athlon-2.4.21-58 # rpm --install --nodeps k_athlon-2.4.21-58.i586.rpm Replacing file /boot/initrd with symlink to initrd-2.4.21-58-athlon using "/dev/hdb7" as root device (mounted on "/" as "ext3") creating initrd "/boot/initrd-2.4.21-58-athlon" for kernel "/boot/vmlinuz-2.4.21-58-athlon" (version 2.4.21-58-athlon) - insmod jbd (kernel/fs/jbd/jbd.o) - insmod ext3 (kernel/fs/ext3/ext3.o) So und jetzt hängt der PC beim Hochfahren beim Hardwarescan. Na dann drehen wir das mal ab und schauen was hdparm meint: hdparm -t /dev/hda /dev/hda: Timing buffered disk reads: 64 MB in 1.26 seconds = 50.59 MB/sec Das sieht also gut aus. Die Netzwerkverbindung funktioniert aber nur mit acpi=off. Beim Vanilla-Kernel brauche ich acpi=off nicht. Sehe ich es richtig, dass es vermutlich wenig bringt, den Mantel-Kernel selber zu kompilieren? Das ACPI-Problem wird wohl bleiben, oder? Al
Al Bogner wrote:
Wenn Du einen Kernel für einen anderen Prozessorarchitektur installierst, würde ich den alten deinstallieren. Vor einem neustart natürlich einen neuen installieren ;-)
So der Kernel ist gelöscht und die Fehlermeldung bleibt:
# rpm --install k_athlon-2.4.21-58.i586.rpm error: failed dependencies: rpmlib(PartialHardlinkSets) <= 4.0.4-1 is needed by k_athlon-2.4.21-58
Die Fehlermeldung ist oki (--nodeps). mr. mantel benutzt rpm-v4, wir alle haben noch rpm-v3, hat sich ja dann mit suse-9 erledigt.
# rpm --install --nodeps k_athlon-2.4.21-58.i586.rpm Replacing file /boot/initrd with symlink to initrd-2.4.21-58-athlon using "/dev/hdb7" as root device (mounted on "/" as "ext3")
creating initrd "/boot/initrd-2.4.21-58-athlon" for kernel "/boot/vmlinuz-2.4.21-58-athlon" (version 2.4.21-58-athlon) - insmod jbd (kernel/fs/jbd/jbd.o) - insmod ext3 (kernel/fs/ext3/ext3.o)
So und jetzt hängt der PC beim Hochfahren beim Hardwarescan. Na dann drehen wir das mal ab und schauen was hdparm meint:
hdparm -t /dev/hda /dev/hda: Timing buffered disk reads: 64 MB in 1.26 seconds = 50.59 MB/sec
Das sieht also gut aus.
Die Netzwerkverbindung funktioniert aber nur mit acpi=off. Beim Vanilla-Kernel brauche ich acpi=off nicht.
Sehe ich es richtig, dass es vermutlich wenig bringt, den Mantel-Kernel selber zu kompilieren? Das ACPI-Problem wird wohl bleiben, oder?
Wenn Du acpi=off benutzen musst, damit Dein System sauber funktioniert, unterstützt Dein Mainboard den ACPI-Standard nicht ordnungsgemäss. Dies könnte höchstens mit nem Bios-Update behoben werden, am Linux-Kernel wird da IMHO nicht viel passieren, da sind die stur. Es kann aber sein, dass Dein Mainboard in Zukunft in einer Blacklist steht, dann wird beim Booten acpi automatisch abgeschaltet, bzw. soweit runtergeregelt wie nötig. Vielleicht steht es da ja auch schon im 2.4.22, mantel ist ja noch 2.4.21. Wenn Du interesse hast, schau Dir mal nach dem booten die Ausgabe von dmesg genau an, da steht dann am Anfang wo acpi initialisiert wird was dazu. -- Andreas
Am Samstag, 30. August 2003 23:05 schrieb Andreas Winkelmann:
Wenn Du acpi=off benutzen musst, damit Dein System sauber funktioniert, unterstützt Dein Mainboard den ACPI-Standard nicht ordnungsgemäss.
Ja da habe ich schon Fehlermeldungen gesehen. Fakt ist aber, dass mit dem Vanilla-Kernel das Netzwerk funktioniert, ohne, dass ich acpi=off definiere. Bei Epox wird zum EP-8K9A9+ kein Bios-Download angeboten, also nehme ich an, dass es bis jetzt auch kein besseres gibt, als das ursprüngliche. Ich werden Support mal mit dem Problem "likely buggy ACPI BIOS" konfrontieren. In boot.msg findet man mehr Infos: <4>ENABLING IO-APIC IRQs <7>init IO_APIC IRQs <7> IO-APIC (apicid-pin) 2-0, 2-16, 2-17, 2-18, 2-19, 2-20, 2-21, 2-22, 2-23 not connected. <6>..TIMER: vector=0x31 pin1=2 pin2=0 <7>number of MP IRQ sources: 16. <7>number of IO-APIC #2 registers: 24. <6>testing the IO APIC....................... <4> <7>IO APIC #2...... <7>.... register #00: 02000000 <7>....... : physical APIC id: 02 <7>....... : Delivery Type: 0 <7>....... : LTS : 0 <7>.... register #01: 00178003 <7>....... : max redirection entries: 0017 <7>....... : PRQ implemented: 1 <7>....... : IO APIC version: 0003 <7>.... IRQ redirection table: <7> NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect: <7> 00 000 00 1 0 0 0 0 0 0 00 <7> 01 0FF 0F 0 0 0 0 0 1 1 39 <7> 02 0FF 0F 0 0 0 0 0 1 1 31 <7> 03 0FF 0F 0 0 0 0 0 1 1 41 <7> 04 0FF 0F 0 0 0 0 0 1 1 49 <7> 05 0FF 0F 0 0 0 0 0 1 1 51 <7> 06 0FF 0F 0 0 0 0 0 1 1 59 <7> 07 0FF 0F 0 0 0 0 0 1 1 61 <7> 08 0FF 0F 0 0 0 0 0 1 1 69 <7> 09 0FF 0F 0 0 0 0 0 1 1 71 <7> 0a 0FF 0F 0 0 0 0 0 1 1 79 <7> 0b 0FF 0F 0 0 0 0 0 1 1 81 <7> 0c 0FF 0F 0 0 0 0 0 1 1 89 <7> 0d 0FF 0F 0 0 0 0 0 1 1 91 <7> 0e 0FF 0F 0 0 0 0 0 1 1 99 <7> 0f 0FF 0F 0 0 0 0 0 1 1 A1 <7> 10 000 00 1 0 0 0 0 0 0 00 <7> 11 000 00 1 0 0 0 0 0 0 00 <7> 12 000 00 1 0 0 0 0 0 0 00 <7> 13 000 00 1 0 0 0 0 0 0 00 <7> 14 000 00 1 0 0 0 0 0 0 00 <7> 15 000 00 1 0 0 0 0 0 0 00 <7> 16 000 00 1 0 0 0 0 0 0 00 <7> 17 000 00 1 0 0 0 0 0 0 00 <7>IRQ to pin mappings: <7>IRQ0 -> 0:2 <7>IRQ1 -> 0:1 <7>IRQ3 -> 0:3 <7>IRQ4 -> 0:4 <7>IRQ5 -> 0:5 <7>IRQ6 -> 0:6 <7>IRQ7 -> 0:7 <7>IRQ8 -> 0:8 <7>IRQ9 -> 0:9 <7>IRQ10 -> 0:10 <7>IRQ11 -> 0:11 <7>IRQ12 -> 0:12 <7>IRQ13 -> 0:13 <7>IRQ14 -> 0:14 <7>IRQ15 -> 0:15 <6>.................................... done. <4>Using local APIC timer interrupts. <4>calibrating APIC timer ... <4>..... CPU clock speed is 1999.7771 MHz. <4>..... host bus clock speed is 266.6369 MHz. <4>cpu: 0, clocks: 2666369, slice: 1333184 <4>CPU0<T0:2666368,T1:1333184,D:0,S:1333184,C:2666369> <4>mtrr: v1.40 (20010327) Richard Gooch (rgooch@atnf.csiro.au) <4>mtrr: detected mtrr type: Intel <6>ACPI: Subsystem revision 20030813 <6>PCI: PCI BIOS revision 2.10 entry at 0xfb350, last bus=1 <6>PCI: Using configuration type 1 <6>ACPI: Interpreter enabled <6>ACPI: Using IOAPIC for interrupt routing <6>ACPI: System [ACPI] (supports S0 S1 S3 S4 S5) <6>ACPI: PCI Root Bridge [PCI0] (00:00) <4>PCI: Probing PCI hardware (bus 00) <7>ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] <4>ACPI: PCI Interrupt Link [LNKA] (IRQs 1 3 4 5 6 7 *10 11 12 14 15) <4>ACPI: PCI Interrupt Link [LNKB] (IRQs 1 3 4 5 6 7 10 *11 12 14 15) <4>ACPI: PCI Interrupt Link [LNKC] (IRQs 1 3 4 *5 6 7 10 11 12 14 15) <4>ACPI: PCI Interrupt Link [LNKD] (IRQs 1 3 4 5 6 7 10 11 *12 14 15) <4>ACPI: PCI Interrupt Link [ALKA] (IRQs 20, disabled) <4>ACPI: PCI Interrupt Link [ALKB] (IRQs 21, disabled) <4>ACPI: PCI Interrupt Link [ALKC] (IRQs 22, disabled) <4>ACPI: PCI Interrupt Link [ALKD] (IRQs 23, disabled) <6>PCI: Probing PCI hardware <7>IOAPIC[0]: Set PCI routing entry (2-16 -> 0xa9 -> IRQ 16 Mode:1 Active:1) <7>00:00:08[A] -> 2-16 -> IRQ 16 <7>IOAPIC[0]: Set PCI routing entry (2-17 -> 0xb1 -> IRQ 17 Mode:1 Active:1) <7>00:00:08[B] -> 2-17 -> IRQ 17 <7>IOAPIC[0]: Set PCI routing entry (2-18 -> 0xb9 -> IRQ 18 Mode:1 Active:1) <7>00:00:08[C] -> 2-18 -> IRQ 18 <7>IOAPIC[0]: Set PCI routing entry (2-19 -> 0xc1 -> IRQ 19 Mode:1 Active:1) <7>00:00:08[D] -> 2-19 -> IRQ 19 <7>Pin 2-17 already programmed <7>Pin 2-18 already programmed <7>Pin 2-19 already programmed <7>Pin 2-16 already programmed <7>Pin 2-18 already programmed <7>Pin 2-19 already programmed <7>Pin 2-16 already programmed <7>Pin 2-17 already programmed <7>Pin 2-19 already programmed <7>Pin 2-16 already programmed <7>Pin 2-17 already programmed <7>Pin 2-18 already programmed <7>Pin 2-18 already programmed <7>Pin 2-19 already programmed <7>Pin 2-16 already programmed <7>Pin 2-17 already programmed <7>Pin 2-19 already programmed <7>Pin 2-16 already programmed <7>Pin 2-16 already programmed <7>Pin 2-16 already programmed <4>ACPI: Unable to set IRQ for PCI Interrupt Link [ALKB] (likely buggy ACPI BIOS). Aborting ACPI-based IRQ routing. Try pci=noacpi or acpi=off <3>ERROR: Unable to locate IOAPIC for IRQ -19/nACPI: Unable to set IRQ for PCI Interrupt Link [ALKB] (likely buggy ACPI BIOS). Aborting ACPI-based IRQ routing. Try pci=noacpi or acpi=off <3>ERROR: Unable to locate IOAPIC for IRQ -19/nACPI: Unable to set IRQ for PCI Interrupt Link [ALKB] (likely buggy ACPI BIOS). Aborting ACPI-based IRQ routing. Try pci=noacpi or acpi=off <3>ERROR: Unable to locate IOAPIC for IRQ -19/nACPI: Unable to set IRQ for PCI Interrupt Link [ALKB] (likely buggy ACPI BIOS). Aborting ACPI-based IRQ routing. Try pci=noacpi or acpi=off <3>ERROR: Unable to locate IOAPIC for IRQ -19/nACPI: Unable to set IRQ for PCI Interrupt Link [ALKA] (likely buggy ACPI BIOS). Aborting ACPI-based IRQ routing. Try pci=noacpi or acpi=off <3>ERROR: Unable to locate IOAPIC for IRQ -19/nACPI: Unable to set IRQ for PCI Interrupt Link [ALKB] (likely buggy ACPI BIOS). Aborting ACPI-based IRQ routing. Try pci=noacpi or acpi=off <3>ERROR: Unable to locate IOAPIC for IRQ -19/nACPI: Unable to set IRQ for PCI Interrupt Link [ALKC] (likely buggy ACPI BIOS). Aborting ACPI-based IRQ routing. Try pci=noacpi or acpi=off <3>ERROR: Unable to locate IOAPIC for IRQ -19/nACPI: Unable to set IRQ for PCI Interrupt Link [ALKD] (likely buggy ACPI BIOS). Aborting ACPI-based IRQ routing. Try pci=noacpi or acpi=off <3>ERROR: Unable to locate IOAPIC for IRQ -19/n<7>Pin 2-16 already programmed <7>Pin 2-17 already programmed <7>Pin 2-18 already programmed <7>Pin 2-19 already programmed <4>ACPI: Unable to set IRQ for PCI Interrupt Link [ALKD] (likely buggy ACPI BIOS). Aborting ACPI-based IRQ routing. Try pci=noacpi or acpi=off <3>ERROR: Unable to locate IOAPIC for IRQ -19/nACPI: Unable to set IRQ for PCI Interrupt Link [ALKD] (likely buggy ACPI BIOS). Aborting ACPI-based IRQ routing. Try pci=noacpi or acpi=off <3>ERROR: Unable to locate IOAPIC for IRQ -19/nACPI: Unable to set IRQ for PCI Interrupt Link [ALKD] (likely buggy ACPI BIOS). Aborting ACPI-based IRQ routing. Try pci=noacpi or acpi=off <3>ERROR: Unable to locate IOAPIC for IRQ -19/nACPI: Unable to set IRQ for PCI Interrupt Link [ALKD] (likely buggy ACPI BIOS). Aborting ACPI-based IRQ routing. Try pci=noacpi or acpi=off <3>ERROR: Unable to locate IOAPIC for IRQ -19/nACPI: Unable to set IRQ for PCI Interrupt Link [ALKB] (likely buggy ACPI BIOS). Aborting ACPI-based IRQ routing. Try pci=noacpi or acpi=off <4>ACPI: Unable to set IRQ for PCI Interrupt Link [ALKB] (likely buggy ACPI BIOS). Aborting ACPI-based IRQ routing. Try pci=noacpi or acpi=off <4>ACPI: Unable to set IRQ for PCI Interrupt Link [ALKB] (likely buggy ACPI BIOS). Aborting ACPI-based IRQ routing. Try pci=noacpi or acpi=off <4>ACPI: Unable to set IRQ for PCI Interrupt Link [ALKB] (likely buggy ACPI BIOS). Aborting ACPI-based IRQ routing. Try pci=noacpi or acpi=off <4>ACPI: Unable to set IRQ for PCI Interrupt Link [ALKA] (likely buggy ACPI BIOS). Aborting ACPI-based IRQ routing. Try pci=noacpi or acpi=off <6>PCI: Using ACPI for IRQ routing <6>PCI: if you experience problems, try using option 'pci=noacpi' or even 'acpi=off' <6>PCI: Via IRQ fixup for 00:10.0, from 10 to 13 <6>PCI: Via IRQ fixup for 00:10.1, from 11 to 13 <6>PCI: Via IRQ fixup for 00:10.2, from 5 to 13 <6>Linux NET4.0 for Linux 2.4 <6>Based upon Swansea University Computer Society NET3.039 <4>Initializing RT netlink socket <6>apm: BIOS version 1.2 Flags 0x07 (Driver version 1.16) <5>apm: overridden by ACPI.
Al Bogner wrote:
Wenn Du acpi=off benutzen musst, damit Dein System sauber funktioniert, unterstützt Dein Mainboard den ACPI-Standard nicht ordnungsgemäss.
Ja da habe ich schon Fehlermeldungen gesehen. Fakt ist aber, dass mit dem Vanilla-Kernel das Netzwerk funktioniert, ohne, dass ich acpi=off definiere.
Dann zeig doch mal bitte die dmesg-ausgabe, wenn Du mit dem Vanilla-Kernel oben bist.
Bei Epox wird zum EP-8K9A9+ kein Bios-Download angeboten, also nehme ich an, dass es bis jetzt auch kein besseres gibt, als das ursprüngliche.
Ich werden Support mal mit dem Problem "likely buggy ACPI BIOS" konfrontieren.
Ich vermute mal: "Mit Windows funktioniert es doch! Nehmen Sie doch Windows..." o.ä.
<4>ACPI: Unable to set IRQ for PCI Interrupt Link [ALKB] (likely buggy ACPI BIOS). Aborting ACPI-based IRQ routing. Try pci=noacpi or acpi=off
-- Andreas
Am Samstag, 30. August 2003 23:50 schrieb Andreas Winkelmann:
Wenn Du acpi=off benutzen musst, damit Dein System sauber funktioniert, unterstützt Dein Mainboard den ACPI-Standard nicht ordnungsgemäss.
Ja da habe ich schon Fehlermeldungen gesehen. Fakt ist aber, dass mit dem Vanilla-Kernel das Netzwerk funktioniert, ohne, dass ich acpi=off definiere.
Dann zeig doch mal bitte die dmesg-ausgabe, wenn Du mit dem Vanilla-Kernel oben bist.
Damit es zu keinem Missverständnis kommt. Die vorige boot.msg stammte vom Vanilla-Kernel! Hier ist dmesg in voller Länge, falls auch noch andere Details interessant sind: # dmesg he hash table entries: 512 (order: 0, 4096 bytes) Buffer cache hash table entries: 32768 (order: 5, 131072 bytes) Page-cache hash table entries: 131072 (order: 7, 524288 bytes) CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 256K (64 bytes/line) Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU: After generic, caps: 0383fbff c1c3fbff 00000000 00000000 CPU: Common caps: 0383fbff c1c3fbff 00000000 00000000 CPU: AMD Athlon(tm) XP 2400+ stepping 01 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX enabled ExtINT on CPU#0 ESR value before enabling vector: 00000000 ESR value after enabling vector: 00000000 ENABLING IO-APIC IRQs init IO_APIC IRQs IO-APIC (apicid-pin) 2-0, 2-16, 2-17, 2-18, 2-19, 2-20, 2-21, 2-22, 2-23 not connected. ..TIMER: vector=0x31 pin1=2 pin2=0 number of MP IRQ sources: 16. number of IO-APIC #2 registers: 24. testing the IO APIC....................... IO APIC #2...... .... register #00: 02000000 ....... : physical APIC id: 02 ....... : Delivery Type: 0 ....... : LTS : 0 .... register #01: 00178003 ....... : max redirection entries: 0017 ....... : PRQ implemented: 1 ....... : IO APIC version: 0003 .... IRQ redirection table: NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect: 00 000 00 1 0 0 0 0 0 0 00 01 0FF 0F 0 0 0 0 0 1 1 39 02 0FF 0F 0 0 0 0 0 1 1 31 03 0FF 0F 0 0 0 0 0 1 1 41 04 0FF 0F 0 0 0 0 0 1 1 49 05 0FF 0F 0 0 0 0 0 1 1 51 06 0FF 0F 0 0 0 0 0 1 1 59 07 0FF 0F 0 0 0 0 0 1 1 61 08 0FF 0F 0 0 0 0 0 1 1 69 09 0FF 0F 0 0 0 0 0 1 1 71 0a 0FF 0F 0 0 0 0 0 1 1 79 0b 0FF 0F 0 0 0 0 0 1 1 81 0c 0FF 0F 0 0 0 0 0 1 1 89 0d 0FF 0F 0 0 0 0 0 1 1 91 0e 0FF 0F 0 0 0 0 0 1 1 99 0f 0FF 0F 0 0 0 0 0 1 1 A1 10 000 00 1 0 0 0 0 0 0 00 11 000 00 1 0 0 0 0 0 0 00 12 000 00 1 0 0 0 0 0 0 00 13 000 00 1 0 0 0 0 0 0 00 14 000 00 1 0 0 0 0 0 0 00 15 000 00 1 0 0 0 0 0 0 00 16 000 00 1 0 0 0 0 0 0 00 17 000 00 1 0 0 0 0 0 0 00 IRQ to pin mappings: IRQ0 -> 0:2 IRQ1 -> 0:1 IRQ3 -> 0:3 IRQ4 -> 0:4 IRQ5 -> 0:5 IRQ6 -> 0:6 IRQ7 -> 0:7 IRQ8 -> 0:8 IRQ9 -> 0:9 IRQ10 -> 0:10 IRQ11 -> 0:11 IRQ12 -> 0:12 IRQ13 -> 0:13 IRQ14 -> 0:14 IRQ15 -> 0:15 .................................... done. Using local APIC timer interrupts. calibrating APIC timer ... ..... CPU clock speed is 1999.7771 MHz. ..... host bus clock speed is 266.6369 MHz. cpu: 0, clocks: 2666369, slice: 1333184 CPU0<T0:2666368,T1:1333184,D:0,S:1333184,C:2666369> mtrr: v1.40 (20010327) Richard Gooch (rgooch@atnf.csiro.au) mtrr: detected mtrr type: Intel ACPI: Subsystem revision 20030813 PCI: PCI BIOS revision 2.10 entry at 0xfb350, last bus=1 PCI: Using configuration type 1 ACPI: Interpreter enabled ACPI: Using IOAPIC for interrupt routing ACPI: System [ACPI] (supports S0 S1 S3 S4 S5) ACPI: PCI Root Bridge [PCI0] (00:00) PCI: Probing PCI hardware (bus 00) ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: PCI Interrupt Link [LNKA] (IRQs 1 3 4 5 6 7 *10 11 12 14 15) ACPI: PCI Interrupt Link [LNKB] (IRQs 1 3 4 5 6 7 10 *11 12 14 15) ACPI: PCI Interrupt Link [LNKC] (IRQs 1 3 4 *5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKD] (IRQs 1 3 4 5 6 7 10 11 *12 14 15) ACPI: PCI Interrupt Link [ALKA] (IRQs 20, disabled) ACPI: PCI Interrupt Link [ALKB] (IRQs 21, disabled) ACPI: PCI Interrupt Link [ALKC] (IRQs 22, disabled) ACPI: PCI Interrupt Link [ALKD] (IRQs 23, disabled) PCI: Probing PCI hardware IOAPIC[0]: Set PCI routing entry (2-16 -> 0xa9 -> IRQ 16 Mode:1 Active:1) 00:00:08[A] -> 2-16 -> IRQ 16 IOAPIC[0]: Set PCI routing entry (2-17 -> 0xb1 -> IRQ 17 Mode:1 Active:1) 00:00:08[B] -> 2-17 -> IRQ 17 IOAPIC[0]: Set PCI routing entry (2-18 -> 0xb9 -> IRQ 18 Mode:1 Active:1) 00:00:08[C] -> 2-18 -> IRQ 18 IOAPIC[0]: Set PCI routing entry (2-19 -> 0xc1 -> IRQ 19 Mode:1 Active:1) 00:00:08[D] -> 2-19 -> IRQ 19 Pin 2-17 already programmed Pin 2-18 already programmed Pin 2-19 already programmed Pin 2-16 already programmed Pin 2-18 already programmed Pin 2-19 already programmed Pin 2-16 already programmed Pin 2-17 already programmed Pin 2-19 already programmed Pin 2-16 already programmed Pin 2-17 already programmed Pin 2-18 already programmed Pin 2-18 already programmed Pin 2-19 already programmed Pin 2-16 already programmed Pin 2-17 already programmed Pin 2-19 already programmed Pin 2-16 already programmed Pin 2-16 already programmed Pin 2-16 already programmed ACPI: Unable to set IRQ for PCI Interrupt Link [ALKB] (likely buggy ACPI BIOS). Aborting ACPI-based IRQ routing. Try pci=noacpi or acpi=off ERROR: Unable to locate IOAPIC for IRQ -19/nACPI: Unable to set IRQ for PCI Interrupt Link [ALKB] (likely buggy ACPI BIOS). Aborting ACPI-based IRQ routing. Try pci=noacpi or acpi=off ERROR: Unable to locate IOAPIC for IRQ -19/nACPI: Unable to set IRQ for PCI Interrupt Link [ALKB] (likely buggy ACPI BIOS). Aborting ACPI-based IRQ routing. Try pci=noacpi or acpi=off ERROR: Unable to locate IOAPIC for IRQ -19/nACPI: Unable to set IRQ for PCI Interrupt Link [ALKB] (likely buggy ACPI BIOS). Aborting ACPI-based IRQ routing. Try pci=noacpi or acpi=off ERROR: Unable to locate IOAPIC for IRQ -19/nACPI: Unable to set IRQ for PCI Interrupt Link [ALKA] (likely buggy ACPI BIOS). Aborting ACPI-based IRQ routing. Try pci=noacpi or acpi=off ERROR: Unable to locate IOAPIC for IRQ -19/nACPI: Unable to set IRQ for PCI Interrupt Link [ALKB] (likely buggy ACPI BIOS). Aborting ACPI-based IRQ routing. Try pci=noacpi or acpi=off ERROR: Unable to locate IOAPIC for IRQ -19/nACPI: Unable to set IRQ for PCI Interrupt Link [ALKC] (likely buggy ACPI BIOS). Aborting ACPI-based IRQ routing. Try pci=noacpi or acpi=off ERROR: Unable to locate IOAPIC for IRQ -19/nACPI: Unable to set IRQ for PCI Interrupt Link [ALKD] (likely buggy ACPI BIOS). Aborting ACPI-based IRQ routing. Try pci=noacpi or acpi=off ERROR: Unable to locate IOAPIC for IRQ -19/n<7>Pin 2-16 already programmed Pin 2-17 already programmed Pin 2-18 already programmed Pin 2-19 already programmed ACPI: Unable to set IRQ for PCI Interrupt Link [ALKD] (likely buggy ACPI BIOS). Aborting ACPI-based IRQ routing. Try pci=noacpi or acpi=off ERROR: Unable to locate IOAPIC for IRQ -19/nACPI: Unable to set IRQ for PCI Interrupt Link [ALKD] (likely buggy ACPI BIOS). Aborting ACPI-based IRQ routing. Try pci=noacpi or acpi=off ERROR: Unable to locate IOAPIC for IRQ -19/nACPI: Unable to set IRQ for PCI Interrupt Link [ALKD] (likely buggy ACPI BIOS). Aborting ACPI-based IRQ routing. Try pci=noacpi or acpi=off ERROR: Unable to locate IOAPIC for IRQ -19/nACPI: Unable to set IRQ for PCI Interrupt Link [ALKD] (likely buggy ACPI BIOS). Aborting ACPI-based IRQ routing. Try pci=noacpi or acpi=off ERROR: Unable to locate IOAPIC for IRQ -19/nACPI: Unable to set IRQ for PCI Interrupt Link [ALKB] (likely buggy ACPI BIOS). Aborting ACPI-based IRQ routing. Try pci=noacpi or acpi=off ACPI: Unable to set IRQ for PCI Interrupt Link [ALKB] (likely buggy ACPI BIOS). Aborting ACPI-based IRQ routing. Try pci=noacpi or acpi=off ACPI: Unable to set IRQ for PCI Interrupt Link [ALKB] (likely buggy ACPI BIOS). Aborting ACPI-based IRQ routing. Try pci=noacpi or acpi=off ACPI: Unable to set IRQ for PCI Interrupt Link [ALKB] (likely buggy ACPI BIOS). Aborting ACPI-based IRQ routing. Try pci=noacpi or acpi=off ACPI: Unable to set IRQ for PCI Interrupt Link [ALKA] (likely buggy ACPI BIOS). Aborting ACPI-based IRQ routing. Try pci=noacpi or acpi=off PCI: Using ACPI for IRQ routing PCI: if you experience problems, try using option 'pci=noacpi' or even 'acpi=off' PCI: Via IRQ fixup for 00:10.0, from 10 to 13 PCI: Via IRQ fixup for 00:10.1, from 11 to 13 PCI: Via IRQ fixup for 00:10.2, from 5 to 13 Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket apm: BIOS version 1.2 Flags 0x07 (Driver version 1.16) apm: overridden by ACPI. Starting kswapd VFS: Disk quotas vdquot_6.5.1 Journalled Block Device driver loaded Installing knfsd (copyright (C) 1996 okir@monad.swb.de). clgen: Driver for Cirrus Logic based graphic boards, v1.9.9.1 RAM (2048 kB) at 0xe8000000, Cirrus Logic chipset on PCI bus clgen: This board has 2097152 bytes of DRAM memory Cirrus Logic video mode: 8 bit color depth Console: switching to colour frame buffer device 80x30 Detected PS/2 Mouse Port. pty: 256 Unix98 ptys configured Serial driver version 5.05c (2001-07-08) with MANY_PORTS MULTIPORT SHARE_IRQ SERIAL_PCI enabled ttyS00 at 0x03f8 (irq = 4) is a 16550A ttyS01 at 0x02f8 (irq = 3) is a 16550A Real Time Clock Driver v1.10e Floppy drive(s): fd0 is 1.44M FDC 0 is a post-1991 82077 loop: loaded (max 8 devices) via-rhine.c:v1.10-LK1.1.19 July-12-2003 Written by Donald Becker http://www.scyld.com/network/via-rhine.html eth0: VIA VT6102 Rhine-II at 0xd000, 00:50:ba:2d:b7:4d, IRQ 17. eth0: MII PHY found at address 8, status 0x782d advertising 01e1 Link 45e1. Linux agpgart interface v0.99 (c) Jeff Hartmann agpgart: Maximum main memory to use for agp memory: 439M agpgart: Detected Via Apollo Pro KT400 chipset agpgart: unable to determine aperture size. [drm] Initialized radeon 1.7.0 20020828 on minor 0 Uniform Multi-Platform E-IDE driver Revision: 7.00beta4-2.4 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VP_IDE: IDE controller at PCI slot 00:11.1 VP_IDE: chipset revision 6 VP_IDE: not 100% native mode: will probe irqs later ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VP_IDE: VIA vt8235 (rev 00) IDE UDMA133 controller on pci00:11.1 ide0: BM-DMA at 0xe400-0xe407, BIOS settings: hda:DMA, hdb:DMA ide1: BM-DMA at 0xe408-0xe40f, BIOS settings: hdc:DMA, hdd:DMA hda: IC35L120AVV207-1, ATA DISK drive hdb: Maxtor 5T040H4, ATA DISK drive blk: queue c03cfee0, I/O limit 4095Mb (mask 0xffffffff) blk: queue c03d0020, I/O limit 4095Mb (mask 0xffffffff) hdc: TOSHIBA DVD-ROM SD-M1612, ATAPI CD/DVD-ROM drive hdd: Maxtor 96147H6, ATA DISK drive blk: queue c03d047c, I/O limit 4095Mb (mask 0xffffffff) ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 ide1 at 0x170-0x177,0x376 on irq 15 hda: attached ide-disk driver. hda: host protected area => 1 hda: 241254720 sectors (123522 MB) w/7965KiB Cache, CHS=15017/255/63, UDMA(100) hdb: attached ide-disk driver. hdb: host protected area => 1 hdb: 80043264 sectors (40982 MB) w/2048KiB Cache, CHS=4982/255/63, UDMA(100) hdd: attached ide-disk driver. hdd: host protected area => 1 hdd: 117231408 sectors (60022 MB) w/2048KiB Cache, CHS=116301/16/63, UDMA(33) hdc: attached ide-cdrom driver. hdc: ATAPI 48X DVD-ROM drive, 512kB Cache, UDMA(33) Uniform CD-ROM driver Revision: 3.12 Partition check: hda: hda1 hda2 hda3 hdb: hdb1 hdb2 hdb3 hdb4 < hdb5 hdb6 hdb7 hdb8 hdb9 > hdd: hdd1 usb.c: registered new driver usbdevfs usb.c: registered new driver hub host/uhci.c: USB Universal Host Controller Interface driver v1.1 host/uhci.c: USB UHCI at I/O 0xd800, IRQ -19 usb.c: new USB bus registered, assigned bus number 1 host/uhci.c: USB UHCI at I/O 0xdc00, IRQ -19 usb.c: new USB bus registered, assigned bus number 2 host/uhci.c: USB UHCI at I/O 0xe000, IRQ -19 usb.c: new USB bus registered, assigned bus number 3 Initializing Cryptographic API NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP IP: routing cache hash table of 4096 buckets, 32Kbytes TCP: Hash tables configured (established 32768 bind 65536) Linux IP multicast router 0.06 plus PIM-SM NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. kjournald starting. Commit interval 5 seconds EXT3-fs: mounted filesystem with ordered data mode. VFS: Mounted root (ext3 filesystem) readonly. Freeing unused kernel memory: 152k freed EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,71), internal journal Adding Swap: 200804k swap-space (priority 42) EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,71), internal journal kjournald starting. Commit interval 5 seconds EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,2), internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,67), internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,3), internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,72), internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,65), internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,70), internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,73), internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS 2.4-0.9.19, 19 August 2002 on ide1(22,65), internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,1), internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,69), internal journal EXT3-fs: mounted filesystem with ordered data mode. eth0: Setting full-duplex based on MII #8 link partner capability of 45e1. Unable to handle kernel paging request at virtual address aa000000 printing eip: c025f4e0 *pde = 00000000 Oops: 0000 CPU: 0 EIP: 0010:[<c025f4e0>] Not tainted EFLAGS: 00010282 eax: aa000000 ebx: 00000000 ecx: dfdb8efc edx: dea6f5e0 esi: dfe03e00 edi: 00000009 ebp: dfe03e00 esp: de9afe7c ds: 0018 es: 0018 ss: 0018 Process mount (pid: 710, stackpage=de9af000) Stack: 00000282 dea6f4c0 00000003 ded3b800 00000000 dfe03e00 ded3b800 c03db4e4 c025f649 dfe03e00 ded3b800 dfdb8ec0 dfdb8ee4 ded3b800 c02608c6 dfe03e00 ded3b800 00000000 00000000 00000002 ded3b800 00000000 c0372d90 de9c4000 Call Trace: [<c025f649>] [<c02608c6>] [<c0145b90>] [<c0145c78>] [<c0158eee>] [<c015921c>] [<c0159045>] [<c015960a>] [<c0107397>] Code: 8b 30 8d 47 ff 83 f8 7e 0f 97 c2 81 fe ff 00 00 00 0f 97 c0 <6>ehci_hcd 00:10.3: VIA Technologies, Inc. USB 2.0 hcd.c: request interrupt -19 failed hcd.c: init 00:10.3 fail, -16 ehci_hcd 00:10.3: VIA Technologies, Inc. USB 2.0 hcd.c: request interrupt -19 failed hcd.c: init 00:10.3 fail, -16 IPv6 v0.8 for NET4.0 IPv6 over IPv4 tunneling driver parport0: PC-style at 0x378 [PCSPP(,...)] parport0: irq 7 detected lp0: using parport0 (polling). usb.c: registered new driver serial eth0: no IPv6 routers present Al
Al Bogner wrote:
Wenn Du acpi=off benutzen musst, damit Dein System sauber funktioniert, unterstützt Dein Mainboard den ACPI-Standard nicht ordnungsgemäss.
Ja da habe ich schon Fehlermeldungen gesehen. Fakt ist aber, dass mit dem Vanilla-Kernel das Netzwerk funktioniert, ohne, dass ich acpi=off definiere.
Dann zeig doch mal bitte die dmesg-ausgabe, wenn Du mit dem Vanilla-Kernel oben bist.
Damit es zu keinem Missverständnis kommt. Die vorige boot.msg stammte vom Vanilla-Kernel!
Hier ist dmesg in voller Länge, falls auch noch andere Details interessant sind:
# dmesg
Hier vorne fehlt leider etwas. Dort käme dann so eine Meldung wie: BIOS passes blacklist oder: BIOS listed in blacklist, disabling ACPI support Aber, wenn das Mainboard neu ist und evtl. sogar noch was dran gemacht wird, dann werden die es nicht so schnell auf die blacklist setzen. Das wäre ja dann für immer...
he hash table entries: 512 (order: 0, 4096 bytes) Buffer cache hash table entries: 32768 (order: 5, 131072 bytes) Page-cache hash table entries: 131072 (order: 7, 524288 bytes) CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 256K (64 bytes/line)
ACPI: Unable to set IRQ for PCI Interrupt Link [ALKB] (likely buggy ACPI BIOS). Aborting ACPI-based IRQ routing. Try pci=noacpi or acpi=off ERROR: Unable to locate IOAPIC for IRQ -19/nACPI: Unable to set IRQ for PCI Interrupt Link [ALKB] (likely buggy ACPI BIOS). Aborting ACPI-based IRQ routing. Try pci=noacpi or acpi=off
eth0: Setting full-duplex based on MII #8 link partner capability of 45e1. Unable to handle kernel paging request at virtual address aa000000 printing eip: c025f4e0 *pde = 00000000 Oops: 0000 CPU: 0 EIP: 0010:[<c025f4e0>] Not tainted EFLAGS: 00010282 eax: aa000000 ebx: 00000000 ecx: dfdb8efc edx: dea6f5e0 esi: dfe03e00 edi: 00000009 ebp: dfe03e00 esp: de9afe7c ds: 0018 es: 0018 ss: 0018 Process mount (pid: 710, stackpage=de9af000) Stack: 00000282 dea6f4c0 00000003 ded3b800 00000000 dfe03e00 ded3b800 c03db4e4 c025f649 dfe03e00 ded3b800 dfdb8ec0 dfdb8ee4 ded3b800 c02608c6 dfe03e00 ded3b800 00000000 00000000 00000002 ded3b800 00000000 c0372d90 de9c4000 Call Trace: [<c025f649>] [<c02608c6>] [<c0145b90>] [<c0145c78>] [<c0158eee>] [<c015921c>] [<c0159045>] [<c015960a>] [<c0107397>]
Code: 8b 30 8d 47 ff 83 f8 7e 0f 97 c2 81 fe ff 00 00 00 0f 97 c0
Das ist jetzt der Kernel wo die Netzwerkkarte nicht funktioniert? Vielleicht gibt es auch einen Fehler im Treiber, der in Verbindung mit nicht ausgeschalteten acpi und den ganzen acpi-fehlermeldungen vorher unsinn macht.
<6>ehci_hcd 00:10.3: VIA Technologies, Inc. USB 2.0 hcd.c: request interrupt -19 failed hcd.c: init 00:10.3 fail, -16 ehci_hcd 00:10.3: VIA Technologies, Inc. USB 2.0 hcd.c: request interrupt -19 failed hcd.c: init 00:10.3 fail, -16 IPv6 v0.8 for NET4.0 IPv6 over IPv4 tunneling driver parport0: PC-style at 0x378 [PCSPP(,...)] parport0: irq 7 detected lp0: using parport0 (polling). usb.c: registered new driver serial eth0: no IPv6 routers present
-- Andreas
Am Sonntag, 31. August 2003 00:36 schrieb Andreas Winkelmann:
he hash table entries: 512 (order: 0, 4096 bytes) Buffer cache hash table entries: 32768 (order: 5, 131072 bytes) Page-cache hash table entries: 131072 (order: 7, 524288 bytes) CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 256K (64 bytes/line)
ACPI: Unable to set IRQ for PCI Interrupt Link [ALKB] (likely buggy ACPI BIOS). Aborting ACPI-based IRQ routing. Try pci=noacpi or acpi=off ERROR: Unable to locate IOAPIC for IRQ -19/nACPI: Unable to set IRQ for PCI Interrupt Link [ALKB] (likely buggy ACPI BIOS). Aborting ACPI-based IRQ routing. Try pci=noacpi or acpi=off
eth0: Setting full-duplex based on MII #8 link partner capability of 45e1. Unable to handle kernel paging request at virtual address aa000000 printing eip: c025f4e0 *pde = 00000000 Oops: 0000 CPU: 0 EIP: 0010:[<c025f4e0>] Not tainted EFLAGS: 00010282 eax: aa000000 ebx: 00000000 ecx: dfdb8efc edx: dea6f5e0 esi: dfe03e00 edi: 00000009 ebp: dfe03e00 esp: de9afe7c ds: 0018 es: 0018 ss: 0018 Process mount (pid: 710, stackpage=de9af000) Stack: 00000282 dea6f4c0 00000003 ded3b800 00000000 dfe03e00 ded3b800 c03db4e4 c025f649 dfe03e00 ded3b800 dfdb8ec0 dfdb8ee4 ded3b800 c02608c6 dfe03e00 ded3b800 00000000 00000000 00000002 ded3b800 00000000 c0372d90 de9c4000 Call Trace: [<c025f649>] [<c02608c6>] [<c0145b90>] [<c0145c78>] [<c0158eee>] [<c015921c>] [<c0159045>] [<c015960a>] [<c0107397>]
Code: 8b 30 8d 47 ff 83 f8 7e 0f 97 c2 81 fe ff 00 00 00 0f 97 c0
Das ist jetzt der Kernel wo die Netzwerkkarte nicht funktioniert?
Nein, das ist wie geewünscht der Vanilla 2.4.22-ac1-Kernel und mit dem funktioniert die Netzwerkkarte. Vielleicht sollte ich auch noch erwähnen, dass die D-Link DFE-530TX rev A einen via-rhine-chip verwendet und onboard-LAN via-rhine II (onboard-LAN ist aber im BIOS deaktiviert) hwinfo --netcard 13: PCI 09.0: 0200 Ethernet controller [Created at pci.65] Hardware Class: network Model: "D-Link DFE-530TX rev A" Vendor: pci 0x1106 "VIA Technologies, Inc." Device: pci 0x3065 "VT6102 [Rhine-II]" SubVendor: pci 0x1186 "D-Link System Inc" SubDevice: pci 0x1400 "DFE-530TX rev A" Revision: 0x43 I/O Ports: 0xd000-0xd0ff (rw) Memory Range: 0xea000000-??? (rw,non-prefetchable) IRQ: 17 (611 events) Driver Info #0: Driver Status: via-rhine is not active Driver Activation Cmd: "modprobe via-rhine" Driver Info #1: Driver Status: mii,via-rhine are not active Driver Activation Cmd: "insmod mii; insmod via-rhine" Config Status: cfg=yes, avail=yes, need=no Das verstehe ich nicht. Ich habe hwinfo vis ssh abgefragt und da steht: via-rhine is not active
Vielleicht gibt es auch einen Fehler im Treiber, der in Verbindung mit nicht ausgeschalteten acpi und den ganzen acpi-fehlermeldungen vorher unsinn macht.
Wen informiert man darüber? Hier ist noch die dmesg-Version mit k_athlon-2.4.21-58 und apci=on: Ist "Oops: 0000 2.4.21-58-athlon #1 Fri Aug 29 11:26:08 UTC 2003" kritisch? # dmesg 76k init, 0k highmem) Dentry cache hash table entries: 65536 (order: 7, 524288 bytes) Inode cache hash table entries: 32768 (order: 6, 262144 bytes) Mount cache hash table entries: 512 (order: 0, 4096 bytes) Buffer-cache hash table entries: 32768 (order: 5, 131072 bytes) Page-cache hash table entries: 131072 (order: 7, 524288 bytes) CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 256K (64 bytes/line) Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU: After generic, caps: 0383fbff c1c3fbff 00000000 00000000 CPU: Common caps: 0383fbff c1c3fbff 00000000 00000000 CPU: AMD Athlon(tm) XP 2400+ stepping 01 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.40 (20010327) Richard Gooch (rgooch@atnf.csiro.au) mtrr: detected mtrr type: Intel ACPI: Subsystem revision 20030619 PCI: PCI BIOS revision 2.10 entry at 0xfb350, last bus=1 PCI: Using configuration type 1 Looking for DSDT in initrd ... not found! ACPI: Interpreter enabled ACPI: Using IOAPIC for interrupt routing ACPI: System [ACPI] (supports S0 S1 S3 S4 S5) ACPI: PCI Root Bridge [PCI0] (00:00) PCI: Probing PCI hardware (bus 00) ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: PCI Interrupt Link [LNKA] (IRQs 1 3 4 5 6 7 *10 11 12 14 15) ACPI: PCI Interrupt Link [LNKB] (IRQs 1 3 4 5 6 7 10 *11 12 14 15) ACPI: PCI Interrupt Link [LNKC] (IRQs 1 3 4 *5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKD] (IRQs 1 3 4 5 6 7 10 11 *12 14 15) ACPI: PCI Interrupt Link [ALKA] (IRQs 20, disabled) ACPI: PCI Interrupt Link [ALKB] (IRQs 21, disabled) ACPI: PCI Interrupt Link [ALKC] (IRQs 22, disabled) ACPI: PCI Interrupt Link [ALKD] (IRQs 23, disabled) PCI: Probing PCI hardware IOAPIC[0]: Set PCI routing entry (2-16 -> 0x39 -> IRQ 16) Mode:1 Active:1 00:00:08[A] -> 2-16 -> IRQ 16 IOAPIC[0]: Set PCI routing entry (2-17 -> 0x41 -> IRQ 17) Mode:1 Active:1 00:00:08[B] -> 2-17 -> IRQ 17 IOAPIC[0]: Set PCI routing entry (2-18 -> 0x49 -> IRQ 18) Mode:1 Active:1 00:00:08[C] -> 2-18 -> IRQ 18 IOAPIC[0]: Set PCI routing entry (2-19 -> 0x51 -> IRQ 19) Mode:1 Active:1 00:00:08[D] -> 2-19 -> IRQ 19 Pin 2-17 already programmed Pin 2-18 already programmed Pin 2-19 already programmed Pin 2-16 already programmed Pin 2-18 already programmed Pin 2-19 already programmed Pin 2-16 already programmed Pin 2-17 already programmed Pin 2-19 already programmed Pin 2-16 already programmed Pin 2-17 already programmed Pin 2-18 already programmed Pin 2-18 already programmed Pin 2-19 already programmed Pin 2-16 already programmed Pin 2-17 already programmed Pin 2-19 already programmed Pin 2-16 already programmed Pin 2-16 already programmed Pin 2-16 already programmed ACPI: Unable to set IRQ for PCI Interrupt Link [ALKB] (likely buggy ACPI BIOS). Aborting ACPI-based IRQ routing. Try pci=noacpi or acpi=off ERROR: Unable to locate IOAPIC for IRQ -19/nACPI: Unable to set IRQ for PCI Interrupt Link [ALKB] (likely buggy ACPI BIOS). Aborting ACPI-based IRQ routing. Try pci=noacpi or acpi=off ERROR: Unable to locate IOAPIC for IRQ -19/nACPI: Unable to set IRQ for PCI Interrupt Link [ALKB] (likely buggy ACPI BIOS). Aborting ACPI-based IRQ routing. Try pci=noacpi or acpi=off ERROR: Unable to locate IOAPIC for IRQ -19/nACPI: Unable to set IRQ for PCI Interrupt Link [ALKB] (likely buggy ACPI BIOS). Aborting ACPI-based IRQ routing. Try pci=noacpi or acpi=off ERROR: Unable to locate IOAPIC for IRQ -19/nACPI: Unable to set IRQ for PCI Interrupt Link [ALKA] (likely buggy ACPI BIOS). Aborting ACPI-based IRQ routing. Try pci=noacpi or acpi=off ERROR: Unable to locate IOAPIC for IRQ -19/nACPI: Unable to set IRQ for PCI Interrupt Link [ALKB] (likely buggy ACPI BIOS). Aborting ACPI-based IRQ routing. Try pci=noacpi or acpi=off ERROR: Unable to locate IOAPIC for IRQ -19/nACPI: Unable to set IRQ for PCI Interrupt Link [ALKC] (likely buggy ACPI BIOS). Aborting ACPI-based IRQ routing. Try pci=noacpi or acpi=off ERROR: Unable to locate IOAPIC for IRQ -19/nACPI: Unable to set IRQ for PCI Interrupt Link [ALKD] (likely buggy ACPI BIOS). Aborting ACPI-based IRQ routing. Try pci=noacpi or acpi=off ERROR: Unable to locate IOAPIC for IRQ -19/n<7>Pin 2-16 already programmed Pin 2-17 already programmed Pin 2-18 already programmed Pin 2-19 already programmed ACPI: Unable to set IRQ for PCI Interrupt Link [ALKD] (likely buggy ACPI BIOS). Aborting ACPI-based IRQ routing. Try pci=noacpi or acpi=off ERROR: Unable to locate IOAPIC for IRQ -19/nACPI: Unable to set IRQ for PCI Interrupt Link [ALKD] (likely buggy ACPI BIOS). Aborting ACPI-based IRQ routing. Try pci=noacpi or acpi=off ERROR: Unable to locate IOAPIC for IRQ -19/nACPI: Unable to set IRQ for PCI Interrupt Link [ALKD] (likely buggy ACPI BIOS). Aborting ACPI-based IRQ routing. Try pci=noacpi or acpi=off ERROR: Unable to locate IOAPIC for IRQ -19/nACPI: Unable to set IRQ for PCI Interrupt Link [ALKD] (likely buggy ACPI BIOS). Aborting ACPI-based IRQ routing. Try pci=noacpi or acpi=off ERROR: Unable to locate IOAPIC for IRQ -19/nACPI: Unable to set IRQ for PCI Interrupt Link [ALKB] (likely buggy ACPI BIOS). Aborting ACPI-based IRQ routing. Try pci=noacpi or acpi=off ACPI: Unable to set IRQ for PCI Interrupt Link [ALKB] (likely buggy ACPI BIOS). Aborting ACPI-based IRQ routing. Try pci=noacpi or acpi=off ACPI: Unable to set IRQ for PCI Interrupt Link [ALKB] (likely buggy ACPI BIOS). Aborting ACPI-based IRQ routing. Try pci=noacpi or acpi=off ACPI: Unable to set IRQ for PCI Interrupt Link [ALKB] (likely buggy ACPI BIOS). Aborting ACPI-based IRQ routing. Try pci=noacpi or acpi=off ACPI: Unable to set IRQ for PCI Interrupt Link [ALKA] (likely buggy ACPI BIOS). Aborting ACPI-based IRQ routing. Try pci=noacpi or acpi=off PCI: Using ACPI for IRQ routing PCI: if you experience problems, try using option 'pci=noacpi' or even 'acpi=off' PCI: Via IRQ fixup for 00:10.0, from 10 to 13 PCI: Via IRQ fixup for 00:10.1, from 11 to 13 PCI: Via IRQ fixup for 00:10.2, from 5 to 13 Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket apm: BIOS version 1.2 Flags 0x07 (Driver version 1.16) apm: overridden by ACPI. PISCH: Plug In Scheduler Interface (Version 6) Starting kswapd bigpage subsystem: allocated 0 bigpages (=0MB). kinoded started VFS: Disk quotas vdquot_6.5.1 aio_setup: num_physpages = 32764 aio_setup: sizeof(struct page) = 48 Detected PS/2 Mouse Port. pty: 256 Unix98 ptys configured Serial driver version 5.05c (2001-07-08) with HUB-6 MANY_PORTS MULTIPORT SHARE_IRQ SERIAL_PCI enabled ttyS00 at 0x03f8 (irq = 4) is a 16550A ttyS01 at 0x02f8 (irq = 3) is a 16550A Real Time Clock Driver v1.10e Floppy drive(s): fd0 is 1.44M FDC 0 is a post-1991 82077 RAMDISK driver initialized: 16 RAM disks of 64000K size 1024 blocksize loop: loaded (max 16 devices) Uniform Multi-Platform E-IDE driver Revision: 7.00beta4-2.4 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VP_IDE: IDE controller at PCI slot 00:11.1 VP_IDE: chipset revision 6 VP_IDE: not 100% native mode: will probe irqs later ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VP_IDE: VIA vt8235 (rev 00) IDE UDMA133 controller on pci00:11.1 ide0: BM-DMA at 0xe400-0xe407, BIOS settings: hda:DMA, hdb:DMA ide1: BM-DMA at 0xe408-0xe40f, BIOS settings: hdc:DMA, hdd:DMA hda: IC35L120AVV207-1, ATA DISK drive hdb: Maxtor 5T040H4, ATA DISK drive blk: queue c03eec40, I/O limit 4095Mb (mask 0xffffffff) blk: queue c03eed9c, I/O limit 4095Mb (mask 0xffffffff) hdc: TOSHIBA DVD-ROM SD-M1612, ATAPI CD/DVD-ROM drive hdd: Maxtor 96147H6, ATA DISK drive blk: queue c03ef230, I/O limit 4095Mb (mask 0xffffffff) ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 ide1 at 0x170-0x177,0x376 on irq 15 hda: attached ide-disk driver. hda: host protected area => 1 hda: 241254720 sectors (123522 MB) w/7965KiB Cache, CHS=15017/255/63, UDMA(100) hdb: attached ide-disk driver. hdb: host protected area => 1 hdb: 80043264 sectors (40982 MB) w/2048KiB Cache, CHS=4982/255/63, UDMA(100) hdd: attached ide-disk driver. hdd: host protected area => 1 hdd: 117231408 sectors (60022 MB) w/2048KiB Cache, CHS=116301/16/63, UDMA(100) ide-floppy driver 0.99.newide Partition check: hda: hda1 hda2 hda3 hdb: hdb1 hdb2 hdb3 hdb4 < hdb5 hdb6 hdb7 hdb8 hdb9 > hdd: hdd1 ide-floppy driver 0.99.newide md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27 md: Autodetecting RAID arrays. md: autorun ... md: ... autorun DONE. NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP IP: routing cache hash table of 4096 buckets, 32Kbytes TCP: Hash tables configured (established 32768 bind 65536) Linux IP multicast router 0.06 plus PIM-SM NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. cryptoapi: loaded RAMDISK: Compressed image found at block 0 Freeing initrd memory: 390k freed VFS: Mounted root (ext2 filesystem). Journalled Block Device driver loaded kjournald starting. Commit interval 5 seconds EXT3-fs: mounted filesystem with ordered data mode. VFS: Mounted root (ext3 filesystem) readonly. Trying to move old root to /initrd ... failed Unmounting old root Trying to free ramdisk memory ... okay Freeing unused kernel memory: 176k freed md: Autodetecting RAID arrays. md: autorun ... md: ... autorun DONE. EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,71), internal journal LVM version 1.0.5+(mp-v6a)(22/07/2002) module loaded Adding Swap: 200804k swap-space (priority 42) hdd: dma_intr: status=0x51 { DriveReady SeekComplete Error } hdd: dma_intr: error=0x84 { DriveStatusError BadCRC } hdd: dma_intr: status=0x51 { DriveReady SeekComplete Error } hdd: dma_intr: error=0x84 { DriveStatusError BadCRC } hdd: dma_intr: status=0x51 { DriveReady SeekComplete Error } hdd: dma_intr: error=0x84 { DriveStatusError BadCRC } hdd: dma_intr: status=0x51 { DriveReady SeekComplete Error } hdd: dma_intr: error=0x84 { DriveStatusError BadCRC } ide1: reset: success EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,71), internal journal kjournald starting. Commit interval 5 seconds EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,2), internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,67), internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,3), internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,72), internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,65), internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,70), internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,73), internal journal EXT3-fs: mounted filesystem with ordered data mode. hdd: dma_intr: status=0x51 { DriveReady SeekComplete Error } hdd: dma_intr: error=0x84 { DriveStatusError BadCRC } kjournald starting. Commit interval 5 seconds EXT3 FS 2.4-0.9.19, 19 August 2002 on ide1(22,65), internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,1), internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,69), internal journal EXT3-fs: mounted filesystem with ordered data mode. via-rhine.c:v1.10-LK1.1.17 March-1-2003 Written by Donald Becker http://www.scyld.com/network/via-rhine.html eth0: VIA VT6102 Rhine-II at 0xd000, 00:50:ba:2d:b7:4d, IRQ 17. eth0: MII PHY found at address 8, status 0x782d advertising 01e1 Link 45e1. eth0: Setting full-duplex based on MII #8 link partner capability of 45e1. raw1394: /dev/raw1394 device initialized usb.c: registered new driver usbdevfs usb.c: registered new driver hub ehci_hcd 00:10.3: VIA Technologies, Inc. USB 2.0 hcd.c: request interrupt -19 failed hcd.c: init 00:10.3 fail, -16 usb-uhci.c: $Revision: 1.275 $ time 11:48:44 Aug 29 2003 usb-uhci.c: High bandwidth mode enabled usb-uhci.c: USB UHCI at I/O 0xd800, IRQ -19 usb-uhci.c: Detected 2 ports usb.c: new USB bus registered, assigned bus number 1 usb-uhci.c: request_irq -19 failed! usb-uhci.c: USB UHCI at I/O 0xdc00, IRQ -19 usb-uhci.c: Detected 2 ports usb.c: new USB bus registered, assigned bus number 2 usb-uhci.c: request_irq -19 failed! usb-uhci.c: USB UHCI at I/O 0xe000, IRQ -19 usb-uhci.c: Detected 2 ports usb.c: new USB bus registered, assigned bus number 3 usb-uhci.c: request_irq -19 failed! usb-uhci.c: v1.275:USB Universal Host Controller Interface driver uhci.c: USB Universal Host Controller Interface driver v1.1 uhci.c: USB UHCI at I/O 0xd800, IRQ -19 usb.c: new USB bus registered, assigned bus number 4 uhci.c: USB UHCI at I/O 0xdc00, IRQ -19 usb.c: new USB bus registered, assigned bus number 5 uhci.c: USB UHCI at I/O 0xe000, IRQ -19 usb.c: new USB bus registered, assigned bus number 6 ehci_hcd 00:10.3: VIA Technologies, Inc. USB 2.0 hcd.c: request interrupt -19 failed hcd.c: init 00:10.3 fail, -16 mice: PS/2 mouse device common for all mice Unable to handle kernel NULL pointer dereference at virtual address 000000c4 printing eip: c2efa54c *pde = 00000000 Oops: 0000 2.4.21-58-athlon #1 Fri Aug 29 11:26:08 UTC 2003 CPU: 0 EIP: 0010:[<c2efa54c>] Not tainted EFLAGS: 00010286 eax: c2f40000 ebx: 00000000 ecx: 00002f40 edx: fffffff4 esi: 00000d84 edi: 00000000 ebp: c2f40000 esp: c2f8df0c ds: 0018 es: 0018 ss: 0018 Process cat (pid: 758, stackpage=c2f8d000) Stack: 0804c8b8 c2f40000 000000d4 00000384 00000000 00000000 00000000 00000000 c2efeb10 00000000 000000d4 00000000 00000000 00000000 c285a6e4 0000027c c2effb20 c2f8df9c c2efa896 c2f8df9c c2f8dfa0 c2f8df7c c29a5c60 00000000 Call Trace: [<c2efeb10>] [<c2effb20>] [<c2efa896>] [<c014ab93>] [<c0109247>] Modules: [(usbcore:<c2ef0060>:<c2effb8c>)] Code: 8b 87 c4 00 00 00 85 c0 74 0c 8b 00 8b 5c 24 30 83 f8 ff 0f <6>IPsec Security Association Database (SADB): initialized. IPsec Security Policy Database (SPD): initialized. IPsec PF_KEY V2: initialized IPv6 v0.8 (usagi-cvs/IPsec6 based StS) for NET4.0 IPv6 over IPv4 tunneling driver NETDEV WATCHDOG: eth0: transmit timed out eth0: Transmit timed out, status 0002, PHY status 782d, resetting... eth0: Setting full-duplex based on MII #8 link partner capability of 45e1. parport0: PC-style at 0x378 [PCSPP,TRISTATE] parport0: irq 7 detected lp0: using parport0 (polling). usb.c: registered new driver serial NETDEV WATCHDOG: eth0: transmit timed out eth0: Transmit timed out, status 0002, PHY status 782d, resetting... eth0: Setting full-duplex based on MII #8 link partner capability of 45e1. eth0: no IPv6 routers present Installing knfsd (copyright (C) 1996 okir@monad.swb.de). Linux video capture interface: v1.00 NETDEV WATCHDOG: eth0: transmit timed out eth0: Transmit timed out, status 0003, PHY status 782d, resetting... eth0: Setting full-duplex based on MII #8 link partner capability of 45e1. Al
Al Bogner wrote:
he hash table entries: 512 (order: 0, 4096 bytes) Buffer cache hash table entries: 32768 (order: 5, 131072 bytes) Page-cache hash table entries: 131072 (order: 7, 524288 bytes) CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 256K (64 bytes/line)
ACPI: Unable to set IRQ for PCI Interrupt Link [ALKB] (likely buggy ACPI BIOS). Aborting ACPI-based IRQ routing. Try pci=noacpi or acpi=off ERROR: Unable to locate IOAPIC for IRQ -19/nACPI: Unable to set IRQ for PCI Interrupt Link [ALKB] (likely buggy ACPI BIOS). Aborting ACPI-based IRQ routing. Try pci=noacpi or acpi=off
eth0: Setting full-duplex based on MII #8 link partner capability of 45e1. Unable to handle kernel paging request at virtual address aa000000 printing eip: c025f4e0 *pde = 00000000 Oops: 0000 CPU: 0 EIP: 0010:[<c025f4e0>] Not tainted EFLAGS: 00010282 eax: aa000000 ebx: 00000000 ecx: dfdb8efc edx: dea6f5e0 esi: dfe03e00 edi: 00000009 ebp: dfe03e00 esp: de9afe7c ds: 0018 es: 0018 ss: 0018 Process mount (pid: 710, stackpage=de9af000) Stack: 00000282 dea6f4c0 00000003 ded3b800 00000000 dfe03e00 ded3b800 c03db4e4 c025f649 dfe03e00 ded3b800 dfdb8ec0 dfdb8ee4 ded3b800 c02608c6 dfe03e00 ded3b800 00000000 00000000 00000002 ded3b800 00000000 c0372d90 de9c4000 Call Trace: [<c025f649>] [<c02608c6>] [<c0145b90>] [<c0145c78>] [<c0158eee>] [<c015921c>] [<c0159045>] [<c015960a>] [<c0107397>]
Code: 8b 30 8d 47 ff 83 f8 7e 0f 97 c2 81 fe ff 00 00 00 0f 97 c0
Das ist jetzt der Kernel wo die Netzwerkkarte nicht funktioniert?
Nein, das ist wie geewünscht der Vanilla 2.4.22-ac1-Kernel und mit dem funktioniert die Netzwerkkarte. Vielleicht sollte ich auch noch erwähnen, dass die D-Link DFE-530TX rev A einen via-rhine-chip verwendet und onboard-LAN via-rhine II (onboard-LAN ist aber im BIOS deaktiviert)
hwinfo --netcard 13: PCI 09.0: 0200 Ethernet controller [Created at pci.65] Hardware Class: network Model: "D-Link DFE-530TX rev A" Vendor: pci 0x1106 "VIA Technologies, Inc." Device: pci 0x3065 "VT6102 [Rhine-II]" SubVendor: pci 0x1186 "D-Link System Inc" SubDevice: pci 0x1400 "DFE-530TX rev A" Revision: 0x43 I/O Ports: 0xd000-0xd0ff (rw) Memory Range: 0xea000000-??? (rw,non-prefetchable) IRQ: 17 (611 events) Driver Info #0: Driver Status: via-rhine is not active Driver Activation Cmd: "modprobe via-rhine" Driver Info #1: Driver Status: mii,via-rhine are not active Driver Activation Cmd: "insmod mii; insmod via-rhine" Config Status: cfg=yes, avail=yes, need=no
Das verstehe ich nicht. Ich habe hwinfo vis ssh abgefragt und da steht: via-rhine is not active
Wenn hinter dem Treiber "not active" steht, dann ist er nicht geladen. Schalte mal acpi aus, und versuch es nochmal. Dein Rechner kommt mit acpi nicht zurecht und macht sehr merkwürdige Dinge.
Vielleicht gibt es auch einen Fehler im Treiber, der in Verbindung mit nicht ausgeschalteten acpi und den ganzen acpi-fehlermeldungen vorher unsinn macht.
Wen informiert man darüber?
lkml = linux kernel mailing list. Ich hatte die mal interssehalber abonniert, wurde aber erschlagen von der Anzahl der Mails ;-) Aber dort lesen IMHO alle Entwickler mit und das wäre mit Sicherheit der richtige Ort für BugReports. Aber, das sieht nicht nach einem Bug aus, Du hast einfach nur ein acpi-problem. Das liegt unter dem Treiber, wenn dort schon was nicht stimmt, kann der Treiber da auch nicht mehr viel retten. Denke, wenn Du schon Initiative zeigen willst, wäre Dein Mainboardhersteller die richtige Adresse....
Hier ist noch die dmesg-Version mit k_athlon-2.4.21-58 und apci=on:
Ist "Oops: 0000 2.4.21-58-athlon #1 Fri Aug 29 11:26:08 UTC 2003" kritisch?
Wie wir schon im Film "Independence Day" gelernt haben, oops ist nicht gut ;-) Damit gibt der Kernel dir zu verstehen, dass etwas nicht stimmt. Das kann man auswerten, ist aber für normalsterbliche nichts.
# dmesg
ACPI: Unable to set IRQ for PCI Interrupt Link [ALKB] (likely buggy ACPI BIOS). Aborting ACPI-based IRQ routing. Try pci=noacpi or acpi=off ERROR: Unable to locate IOAPIC for IRQ -19/nACPI: Unable to set IRQ for PCI Interrupt Link [ALKB] (likely buggy ACPI BIOS). Aborting ACPI-based IRQ routing. Try pci=noacpi or acpi=off
Unable to handle kernel NULL pointer dereference at virtual address 000000c4 printing eip: c2efa54c *pde = 00000000 Oops: 0000 2.4.21-58-athlon #1 Fri Aug 29 11:26:08 UTC 2003 CPU: 0 EIP: 0010:[<c2efa54c>] Not tainted EFLAGS: 00010286 eax: c2f40000 ebx: 00000000 ecx: 00002f40 edx: fffffff4 esi: 00000d84 edi: 00000000 ebp: c2f40000 esp: c2f8df0c ds: 0018 es: 0018 ss: 0018 Process cat (pid: 758, stackpage=c2f8d000) Stack: 0804c8b8 c2f40000 000000d4 00000384 00000000 00000000 00000000 00000000 c2efeb10 00000000 000000d4 00000000 00000000 00000000 c285a6e4 0000027c c2effb20 c2f8df9c c2efa896 c2f8df9c c2f8dfa0 c2f8df7c c29a5c60 00000000 Call Trace: [<c2efeb10>] [<c2effb20>] [<c2efa896>] [<c014ab93>] [<c0109247>] Modules: [(usbcore:<c2ef0060>:<c2effb8c>)] Code: 8b 87 c4 00 00 00 85 c0 74 0c 8b 00 8b 5c 24 30 83 f8 ff 0f <6>IPsec Security Association Database (SADB): initialized.
Schalte einfach acpi aus. -- Andreas
Am Sonntag, 31. August 2003 12:35 schrieb Andreas Winkelmann:
Das verstehe ich nicht. Ich habe hwinfo vis ssh abgefragt und da steht: via-rhine is not active
Wenn hinter dem Treiber "not active" steht, dann ist er nicht geladen.
Jetzt fällt es mir ein, ich hab den Treiber fix in den Vanilla-Kernel gebaut. Erklärt das die Meldung?
lkml = linux kernel mailing list. Ich hatte die mal interssehalber abonniert, wurde aber erschlagen von der Anzahl der Mails ;-) Aber dort lesen IMHO alle Entwickler mit und das wäre mit Sicherheit der richtige Ort für BugReports. Aber, das sieht nicht nach einem Bug aus, Du hast einfach nur ein acpi-problem. Das liegt unter dem Treiber, wenn dort schon was nicht stimmt, kann der Treiber da auch nicht mehr viel retten.
Denke, wenn Du schon Initiative zeigen willst, wäre Dein Mainboardhersteller die richtige Adresse....
Das ist schon geplant. Ich will zum Epox EP-8K9A9+ aber solche Fakten liefern, dass sie sich nicht dumm rausreden können.
Hier ist noch die dmesg-Version mit k_athlon-2.4.21-58 und apci=on:
Ist "Oops: 0000 2.4.21-58-athlon #1 Fri Aug 29 11:26:08 UTC 2003" kritisch?
Wie wir schon im Film "Independence Day" gelernt haben, oops ist nicht gut ;-) Damit gibt der Kernel dir zu verstehen, dass etwas nicht stimmt. Das kann man auswerten, ist aber für normalsterbliche nichts.
# dmesg
ACPI: Unable to set IRQ for PCI Interrupt Link [ALKB] (likely buggy ACPI BIOS). Aborting ACPI-based IRQ routing. Try pci=noacpi or acpi=off ERROR: Unable to locate IOAPIC for IRQ -19/nACPI: Unable to set IRQ for PCI Interrupt Link [ALKB] (likely buggy ACPI BIOS). Aborting ACPI-based IRQ routing. Try pci=noacpi or acpi=off
Unable to handle kernel NULL pointer dereference at virtual address 000000c4 printing eip: c2efa54c *pde = 00000000 Oops: 0000 2.4.21-58-athlon #1 Fri Aug 29 11:26:08 UTC 2003 CPU: 0 EIP: 0010:[<c2efa54c>] Not tainted EFLAGS: 00010286 eax: c2f40000 ebx: 00000000 ecx: 00002f40 edx: fffffff4 esi: 00000d84 edi: 00000000 ebp: c2f40000 esp: c2f8df0c ds: 0018 es: 0018 ss: 0018 Process cat (pid: 758, stackpage=c2f8d000) Stack: 0804c8b8 c2f40000 000000d4 00000384 00000000 00000000 00000000 00000000 c2efeb10 00000000 000000d4 00000000 00000000 00000000 c285a6e4 0000027c c2effb20 c2f8df9c c2efa896 c2f8df9c c2f8dfa0 c2f8df7c c29a5c60 00000000 Call Trace: [<c2efeb10>] [<c2effb20>] [<c2efa896>] [<c014ab93>] [<c0109247>] Modules: [(usbcore:<c2ef0060>:<c2effb8c>)] Code: 8b 87 c4 00 00 00 85 c0 74 0c 8b 00 8b 5c 24 30 83 f8 ff 0f <6>IPsec Security Association Database (SADB): initialized.
Schalte einfach acpi aus.
Das werde ich wohl müssen. Mit acpi=off und dem 2.4.22-ac1-Vanilla-Kernel sieht das dann so aus. Die ACPI-Meldungen verstehe ich jetzt aber nicht, wo doch acpi=off ist. dmesg Linux version 2.4.22-ac1-alsa (root@sv) (gcc version 3.3 20030226 (prerelease) (SuSE Linux)) #1 Fri Aug 29 23:14:35 CEST 2003 BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 00000000000a0000 (usable) BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 000000001fff0000 (usable) BIOS-e820: 000000001fff0000 - 000000001fff3000 (ACPI NVS) BIOS-e820: 000000001fff3000 - 0000000020000000 (ACPI data) BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved) BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved) 511MB LOWMEM available. ACPI: have wakeup address 0xc0001000 found SMP MP-table at 000f5a40 hm, page 000f5000 reserved twice. hm, page 000f6000 reserved twice. hm, page 000f1000 reserved twice. hm, page 000f2000 reserved twice. On node 0 totalpages: 131056 zone(0): 4096 pages. zone(1): 126960 pages. zone(2): 0 pages. Intel MultiProcessor Specification v1.4 Virtual Wire compatibility mode. OEM ID: OEM00000 Product ID: PROD00000000 APIC at: 0xFEE00000 Processor #0 Pentium(tm) Pro APIC version 17 I/O APIC #2 Version 17 at 0xFEC00000. Processors: 1 xAPIC support is not present Enabling APIC mode: Flat. Using 1 I/O APICs Kernel command line: root=/dev/hdb7 splash=silent acpi=off Initializing CPU#0 Detected 1999.828 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 3984.58 BogoMIPS Memory: 515212k/524224k available (1872k kernel code, 8628k reserved, 652k data, 152k init, 0k highmem) Dentry cache hash table entries: 65536 (order: 7, 524288 bytes) Inode cache hash table entries: 32768 (order: 6, 262144 bytes) Mount cache hash table entries: 512 (order: 0, 4096 bytes) Buffer cache hash table entries: 32768 (order: 5, 131072 bytes) Page-cache hash table entries: 131072 (order: 7, 524288 bytes) CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 256K (64 bytes/line) Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU: After generic, caps: 0383fbff c1c3fbff 00000000 00000000 CPU: Common caps: 0383fbff c1c3fbff 00000000 00000000 CPU: AMD Athlon(tm) XP 2400+ stepping 01 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX enabled ExtINT on CPU#0 ESR value before enabling vector: 00000000 ESR value after enabling vector: 00000000 ENABLING IO-APIC IRQs Setting 2 in the phys_id_present_map ...changing IO-APIC physical APIC ID to 2 ... ok. init IO_APIC IRQs IO-APIC (apicid-pin) 2-0, 2-5, 2-10, 2-11, 2-12, 2-18, 2-20, 2-22, 2-23 not connected. ..TIMER: vector=0x31 pin1=2 pin2=0 number of MP IRQ sources: 19. number of IO-APIC #2 registers: 24. testing the IO APIC....................... IO APIC #2...... .... register #00: 02000000 ....... : physical APIC id: 02 ....... : Delivery Type: 0 ....... : LTS : 0 .... register #01: 00178003 ....... : max redirection entries: 0017 ....... : PRQ implemented: 1 ....... : IO APIC version: 0003 .... IRQ redirection table: NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect: 00 000 00 1 0 0 0 0 0 0 00 01 0FF 0F 0 0 0 0 0 1 1 39 02 0FF 0F 0 0 0 0 0 1 1 31 03 0FF 0F 0 0 0 0 0 1 1 41 04 0FF 0F 0 0 0 0 0 1 1 49 05 000 00 1 0 0 0 0 0 0 00 06 0FF 0F 0 0 0 0 0 1 1 51 07 0FF 0F 0 0 0 0 0 1 1 59 08 0FF 0F 0 0 0 0 0 1 1 61 09 0FF 0F 0 0 0 0 0 1 1 69 0a 000 00 1 0 0 0 0 0 0 00 0b 000 00 1 0 0 0 0 0 0 00 0c 000 00 1 0 0 0 0 0 0 00 0d 0FF 0F 0 0 0 0 0 1 1 71 0e 0FF 0F 0 0 0 0 0 1 1 79 0f 0FF 0F 0 0 0 0 0 1 1 81 10 0FF 0F 1 1 0 1 0 1 1 89 11 0FF 0F 1 1 0 1 0 1 1 91 12 000 00 1 0 0 0 0 0 0 00 13 0FF 0F 1 1 0 1 0 1 1 99 14 000 00 1 0 0 0 0 0 0 00 15 0FF 0F 1 1 0 1 0 1 1 A1 16 000 00 1 0 0 0 0 0 0 00 17 000 00 1 0 0 0 0 0 0 00 IRQ to pin mappings: IRQ0 -> 0:2 IRQ1 -> 0:1 IRQ3 -> 0:3 IRQ4 -> 0:4 IRQ6 -> 0:6 IRQ7 -> 0:7 IRQ8 -> 0:8 IRQ9 -> 0:9 IRQ13 -> 0:13 IRQ14 -> 0:14 IRQ15 -> 0:15 IRQ16 -> 0:16 IRQ17 -> 0:17 IRQ19 -> 0:19 IRQ21 -> 0:21 .................................... done. Using local APIC timer interrupts. calibrating APIC timer ... ..... CPU clock speed is 1999.9289 MHz. ..... host bus clock speed is 266.6571 MHz. cpu: 0, clocks: 2666571, slice: 1333285 CPU0<T0:2666560,T1:1333264,D:11,S:1333285,C:2666571> mtrr: v1.40 (20010327) Richard Gooch (rgooch@atnf.csiro.au) mtrr: detected mtrr type: Intel ACPI: Subsystem revision 20030813 ACPI: Interpreter disabled. PCI: PCI BIOS revision 2.10 entry at 0xfb350, last bus=1 PCI: Using configuration type 1 PCI: Probing PCI hardware PCI: ACPI tables contain no PCI IRQ routing entries PCI: Probing PCI hardware (bus 00) PCI: Using IRQ router VIA [1106/3177] at 00:11.0 PCI->APIC IRQ transform: (B0,I8,P0) -> 16 PCI->APIC IRQ transform: (B0,I9,P0) -> 17 PCI->APIC IRQ transform: (B0,I11,P0) -> 19 PCI->APIC IRQ transform: (B0,I16,P0) -> 21 PCI->APIC IRQ transform: (B0,I16,P1) -> 21 PCI->APIC IRQ transform: (B0,I16,P2) -> 21 PCI->APIC IRQ transform: (B0,I16,P3) -> 21 PCI: Via IRQ fixup for 00:10.0, from 10 to 5 PCI: Via IRQ fixup for 00:10.1, from 11 to 5 Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket apm: BIOS version 1.2 Flags 0x07 (Driver version 1.16) Starting kswapd VFS: Disk quotas vdquot_6.5.1 Journalled Block Device driver loaded Installing knfsd (copyright (C) 1996 okir@monad.swb.de). clgen: Driver for Cirrus Logic based graphic boards, v1.9.9.1 RAM (2048 kB) at 0xe8000000, Cirrus Logic chipset on PCI bus clgen: This board has 2097152 bytes of DRAM memory Cirrus Logic video mode: 8 bit color depth Console: switching to colour frame buffer device 80x30 Detected PS/2 Mouse Port. pty: 256 Unix98 ptys configured Serial driver version 5.05c (2001-07-08) with MANY_PORTS MULTIPORT SHARE_IRQ SERIAL_PCI enabled ttyS00 at 0x03f8 (irq = 4) is a 16550A ttyS01 at 0x02f8 (irq = 3) is a 16550A Real Time Clock Driver v1.10e Floppy drive(s): fd0 is 1.44M FDC 0 is a post-1991 82077 loop: loaded (max 8 devices) via-rhine.c:v1.10-LK1.1.19 July-12-2003 Written by Donald Becker http://www.scyld.com/network/via-rhine.html eth0: VIA VT6102 Rhine-II at 0xd000, 00:50:ba:2d:b7:4d, IRQ 17. eth0: MII PHY found at address 8, status 0x782d advertising 01e1 Link 45e1. Linux agpgart interface v0.99 (c) Jeff Hartmann agpgart: Maximum main memory to use for agp memory: 439M agpgart: Detected Via Apollo Pro KT400 chipset agpgart: unable to determine aperture size. [drm] Initialized radeon 1.7.0 20020828 on minor 0 Uniform Multi-Platform E-IDE driver Revision: 7.00beta4-2.4 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VP_IDE: IDE controller at PCI slot 00:11.1 VP_IDE: chipset revision 6 VP_IDE: not 100% native mode: will probe irqs later ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VP_IDE: VIA vt8235 (rev 00) IDE UDMA133 controller on pci00:11.1 ide0: BM-DMA at 0xe400-0xe407, BIOS settings: hda:DMA, hdb:DMA ide1: BM-DMA at 0xe408-0xe40f, BIOS settings: hdc:DMA, hdd:DMA hda: IC35L120AVV207-1, ATA DISK drive hdb: Maxtor 5T040H4, ATA DISK drive blk: queue c03cfee0, I/O limit 4095Mb (mask 0xffffffff) blk: queue c03d0020, I/O limit 4095Mb (mask 0xffffffff) hdc: TOSHIBA DVD-ROM SD-M1612, ATAPI CD/DVD-ROM drive hdd: Maxtor 96147H6, ATA DISK drive blk: queue c03d047c, I/O limit 4095Mb (mask 0xffffffff) ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 ide1 at 0x170-0x177,0x376 on irq 15 hda: attached ide-disk driver. hda: host protected area => 1 hda: 241254720 sectors (123522 MB) w/7965KiB Cache, CHS=15017/255/63, UDMA(100) hdb: attached ide-disk driver. hdb: host protected area => 1 hdb: 80043264 sectors (40982 MB) w/2048KiB Cache, CHS=4982/255/63, UDMA(100) hdd: attached ide-disk driver. hdd: host protected area => 1 hdd: 117231408 sectors (60022 MB) w/2048KiB Cache, CHS=116301/16/63, UDMA(33) hdc: attached ide-cdrom driver. hdc: ATAPI 48X DVD-ROM drive, 512kB Cache, UDMA(33) Uniform CD-ROM driver Revision: 3.12 Partition check: hda: hda1 hda2 hda3 hdb: hdb1 hdb2 hdb3 hdb4 < hdb5 hdb6 hdb7 hdb8 hdb9 > hdd: hdd1 usb.c: registered new driver usbdevfs usb.c: registered new driver hub host/uhci.c: USB Universal Host Controller Interface driver v1.1 host/uhci.c: USB UHCI at I/O 0xd800, IRQ 21 usb.c: new USB bus registered, assigned bus number 1 hub.c: USB hub found hub.c: 2 ports detected host/uhci.c: USB UHCI at I/O 0xdc00, IRQ 21 usb.c: new USB bus registered, assigned bus number 2 hub.c: USB hub found hub.c: 2 ports detected host/uhci.c: USB UHCI at I/O 0xe000, IRQ 21 usb.c: new USB bus registered, assigned bus number 3 hub.c: USB hub found hub.c: 2 ports detected Initializing Cryptographic API NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP IP: routing cache hash table of 4096 buckets, 32Kbytes TCP: Hash tables configured (established 32768 bind 65536) Linux IP multicast router 0.06 plus PIM-SM NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. kjournald starting. Commit interval 5 seconds EXT3-fs: mounted filesystem with ordered data mode. VFS: Mounted root (ext3 filesystem) readonly. Freeing unused kernel memory: 152k freed hub.c: new USB device 00:10.1-1, assigned address 2 usb.c: USB device 2 (vend/prod 0x9bf/0xdb) is not claimed by any active driver. EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,71), internal journal Adding Swap: 200804k swap-space (priority 42) EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,71), internal journal kjournald starting. Commit interval 5 seconds EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,2), internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,67), internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,3), internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,72), internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,65), internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,70), internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,73), internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS 2.4-0.9.19, 19 August 2002 on ide1(22,65), internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,1), internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,69), internal journal EXT3-fs: mounted filesystem with ordered data mode. eth0: Setting full-duplex based on MII #8 link partner capability of 45e1. ehci_hcd 00:10.3: VIA Technologies, Inc. USB 2.0 ehci_hcd 00:10.3: irq 21, pci mem e0a30000 usb.c: new USB bus registered, assigned bus number 4 PCI: 00:10.3 PCI cache line size set incorrectly (32 bytes) by BIOS/FW. PCI: 00:10.3 PCI cache line size corrected to 64. ehci_hcd 00:10.3: USB 2.0 enabled, EHCI 1.00, driver 2003-Jun-19/2.4 hub.c: USB hub found hub.c: 6 ports detected usb.c: USB disconnect on device 00:10.1-1 address 2 hub.c: new USB device 00:10.1-1, assigned address 3 usb.c: USB device 3 (vend/prod 0x9bf/0xdb) is not claimed by any active driver. mice: PS/2 mouse device common for all mice CSLIP: code copyright 1989 Regents of the University of California ISDN subsystem Rev: 1.1.4.1/1.1.4.1/1.1.4.1/1.1.4.1/1.1.4.1/1.1.4.1 loaded HiSax: Linux Driver for passive ISDN cards HiSax: Version 3.5 (module) HiSax: Layer1 Revision 1.1.4.1 HiSax: Layer2 Revision 1.1.4.1 HiSax: TeiMgr Revision 1.1.4.1 HiSax: Layer3 Revision 1.1.4.1 HiSax: LinkLayer Revision 1.1.4.1 HiSax: Approval certification failed because of HiSax: unauthorized source code changes usb.c: registered new driver auerswald auermain.c: device is a COMpact 2206,Ser# B0A3627, Kopfnr_MSN 431828 HiSax: Card 1 Protocol EDSS1 Id=auerswald_usb0 (0) HiSax: DSS1 Rev. 1.1.4.1 HiSax: 2 channels added HiSax: MAX_WAITING_CALLS added IPv6 v0.8 for NET4.0 IPv6 over IPv4 tunneling driver parport0: PC-style at 0x378 [PCSPP(,...)] parport0: irq 7 detected lp0: using parport0 (polling). usb.c: registered new driver serial usbserial.c: USB Serial Driver core v1.4 eth0: no IPv6 routers present Al
Al Bogner wrote:
Das verstehe ich nicht. Ich habe hwinfo vis ssh abgefragt und da steht: via-rhine is not active
Wenn hinter dem Treiber "not active" steht, dann ist er nicht geladen.
Jetzt fällt es mir ein, ich hab den Treiber fix in den Vanilla-Kernel gebaut. Erklärt das die Meldung?
Yep, dann wird ja nix geladen. Habe ich in der heutigen Zeit gar nichtmehr dran gedacht, heute packt man ja normalerweise alles in module.
lkml = linux kernel mailing list. Ich hatte die mal interssehalber abonniert, wurde aber erschlagen von der Anzahl der Mails ;-) Aber dort lesen IMHO alle Entwickler mit und das wäre mit Sicherheit der richtige Ort für BugReports. Aber, das sieht nicht nach einem Bug aus, Du hast einfach nur ein acpi-problem. Das liegt unter dem Treiber, wenn dort schon was nicht stimmt, kann der Treiber da auch nicht mehr viel retten.
Denke, wenn Du schon Initiative zeigen willst, wäre Dein Mainboardhersteller die richtige Adresse....
Das ist schon geplant. Ich will zum Epox EP-8K9A9+ aber solche Fakten liefern, dass sie sich nicht dumm rausreden können.
Dann wäre ein Anfang ihnen das Log ohne acpi=off, also das mit den ganzen Fehlermeldungen, zu schicken. Hmm, mich würde aber interessieren was die zu dem Thema sagen...
Schalte einfach acpi aus.
Das werde ich wohl müssen.
Mit acpi=off und dem 2.4.22-ac1-Vanilla-Kernel sieht das dann so aus. Die ACPI-Meldungen verstehe ich jetzt aber nicht, wo doch acpi=off ist.
Ja, ein wenig acpi wird wohl schon in der Tatsache liegen, dass durch "acpi=off" der Treiber ja nicht komplett übersprungen wird sondern zumindest soweit geladen wird, bis er erkennt, dass er ausgeschaltet ist ;-) Dazu kenne ich normalerweise eine Meldung wo er sagt, dass er disabled ist. Habe ich jetzt bei Dir zwar nicht gefunden, aber dafür sind ja auch die ganzen Fehlermeldungen und die Oopse wech. Was Du höchstens noch machen kannst, es gibt da zu acpi noch ein paar andere Kernel-Optionen. Schau Dir einfach mal http://sdb.suse.de/de/sdb/html/81_acpi.html an. Vielleicht musst Du es ja nicht ganz abschalten, sondern nur teilweise. -- Andreas
Am Sonntag, 31. August 2003 14:35 schrieb Andreas Winkelmann:
Jetzt fällt es mir ein, ich hab den Treiber fix in den Vanilla-Kernel gebaut. Erklärt das die Meldung?
Yep, dann wird ja nix geladen. Habe ich in der heutigen Zeit gar nichtmehr dran gedacht, heute packt man ja normalerweise alles in module.
Ich weiß nicht, ob das sinnvoll war, aber ich habe mir folgendes überlegt: Wenn der Rechner benutzt wird, dann normalerweise immer als Server, also über die Netzwerkkarte. Ich habe mal irgendwo gelesen, dass unbenutzte Module nach einer gewissen Zeit entladen werden, d.h. sobald eine Netzwerkanforderung kommt, müßte der Treiber wieder neu geladen werden.
Dann wäre ein Anfang ihnen das Log ohne acpi=off, also das mit den ganzen Fehlermeldungen, zu schicken. Hmm, mich würde aber interessieren was die zu dem Thema sagen...
Gute Idee. Vorerst warte ich aber noch ab, was zu MID <3019829.tfIr8ilpmD@usenet.pinguin.uni.cc> - KT400A: Acpi-Bios oder Kernel buggy? (Epox EP-8K9A9+) in de.comp.os.unix.linux.hardware gesagt wird. Wie Epox reagiert hat, werde ich berichten. Mal sehen wie linuxfreundlich die sind. Hoffentlich plagen mich die wie Maxtor nicht mit irgendwelchen Win-Tests, denn Win gibt es auf dem Rechner nicht.
Ja, ein wenig acpi wird wohl schon in der Tatsache liegen, dass durch "acpi=off" der Treiber ja nicht komplett übersprungen wird sondern zumindest soweit geladen wird, bis er erkennt, dass er ausgeschaltet ist ;-) Dazu kenne ich normalerweise eine Meldung wo er sagt, dass er disabled ist. Habe ich jetzt bei Dir zwar nicht gefunden, aber dafür sind ja auch die ganzen Fehlermeldungen und die Oopse wech.
Das ist ja schon etwas. Würde es Sinn machen beim Kernel kompilieren die ganzen ACPI-Dinge nicht auszuwählen?
Was Du höchstens noch machen kannst, es gibt da zu acpi noch ein paar andere Kernel-Optionen. Schau Dir einfach mal http://sdb.suse.de/de/sdb/html/81_acpi.html an. Vielleicht musst Du es ja nicht ganz abschalten, sondern nur teilweise.
Auf den ersten Blick finde ich da nichts, das mich anspricht. Ich schau mir das mal später näher an. Zur Zeit geht es darum, denn Rest des Rechners flott zu machen. Al
Al Bogner wrote:
Jetzt fällt es mir ein, ich hab den Treiber fix in den Vanilla-Kernel gebaut. Erklärt das die Meldung?
Yep, dann wird ja nix geladen. Habe ich in der heutigen Zeit gar nichtmehr dran gedacht, heute packt man ja normalerweise alles in module.
Ich weiß nicht, ob das sinnvoll war, aber ich habe mir folgendes überlegt: Wenn der Rechner benutzt wird, dann normalerweise immer als Server, also über die Netzwerkkarte. Ich habe mal irgendwo gelesen, dass unbenutzte Module nach einer gewissen Zeit entladen werden, d.h. sobald eine Netzwerkanforderung kommt, müßte der Treiber wieder neu geladen werden.
Aber nicht, wenn ein Device an den Treiber gebunden ist. Dann wird er nicht entlden, dann ist er ja auch benutzt. Ausserdem, wie sollte denn das System mitbekommen, dass es Daten gibt, wenn kein Treiber da ist sie zu empfangen?
Dann wäre ein Anfang ihnen das Log ohne acpi=off, also das mit den ganzen Fehlermeldungen, zu schicken. Hmm, mich würde aber interessieren was die zu dem Thema sagen...
Gute Idee. Vorerst warte ich aber noch ab, was zu MID <3019829.tfIr8ilpmD@usenet.pinguin.uni.cc> - KT400A: Acpi-Bios oder Kernel buggy? (Epox EP-8K9A9+) in de.comp.os.unix.linux.hardware gesagt wird. Wie Epox reagiert hat, werde ich berichten. Mal sehen wie linuxfreundlich die sind. Hoffentlich plagen mich die wie Maxtor nicht mit irgendwelchen Win-Tests, denn Win gibt es auf dem Rechner nicht.
Nö, an WinTests glaube ich in dem Zusammenhang nicht. Aber mal abwarten.
Ja, ein wenig acpi wird wohl schon in der Tatsache liegen, dass durch "acpi=off" der Treiber ja nicht komplett übersprungen wird sondern zumindest soweit geladen wird, bis er erkennt, dass er ausgeschaltet ist ;-) Dazu kenne ich normalerweise eine Meldung wo er sagt, dass er disabled ist. Habe ich jetzt bei Dir zwar nicht gefunden, aber dafür sind ja auch die ganzen Fehlermeldungen und die Oopse wech.
Das ist ja schon etwas. Würde es Sinn machen beim Kernel kompilieren die ganzen ACPI-Dinge nicht auszuwählen?
Nö, würde ich nicht machen.
Was Du höchstens noch machen kannst, es gibt da zu acpi noch ein paar andere Kernel-Optionen. Schau Dir einfach mal http://sdb.suse.de/de/sdb/html/81_acpi.html an. Vielleicht musst Du es ja nicht ganz abschalten, sondern nur teilweise.
Auf den ersten Blick finde ich da nichts, das mich anspricht. Ich schau mir das mal später näher an. Zur Zeit geht es darum, denn Rest des Rechners flott zu machen.
Viel Glück. -- Andreas
Am Sonntag, 31. August 2003 15:04 schrieb Al Bogner:
Gute Idee. Vorerst warte ich aber noch ab, was zu MID <3019829.tfIr8ilpmD@usenet.pinguin.uni.cc> - KT400A: Acpi-Bios oder Kernel buggy? (Epox EP-8K9A9+) in de.comp.os.unix.linux.hardware gesagt wird.
http://bugzilla.kernel.org/show_bug.cgi?id=845 This is an umbrella bug to help trace all the VIA ACPI/APIC bug people have been getting lately. Most of the failures hit USB and/or ethernet subsystems and occur with varying ACPI/LOCAL-APIC/IO-ACPI permutations on a wide range of motherboards [ simply put via acpi is broken right now only the actual symptoms differ ] People who hit this class of bug should open a new bug and mark it as blocker for this one so it can be closed once all repported via acpi problems are solved. It is very possible a single quirk will fix all via systems at once. Was ist ein "umbrella bug"? Al
Al Bogner wrote:
Gute Idee. Vorerst warte ich aber noch ab, was zu MID <3019829.tfIr8ilpmD@usenet.pinguin.uni.cc> - KT400A: Acpi-Bios oder Kernel buggy? (Epox EP-8K9A9+) in de.comp.os.unix.linux.hardware gesagt wird.
http://bugzilla.kernel.org/show_bug.cgi?id=845
This is an umbrella bug to help trace all the VIA ACPI/APIC bug people have been getting lately. Most of the failures hit USB and/or ethernet subsystems and occur with varying ACPI/LOCAL-APIC/IO-ACPI permutations on a wide range of motherboards [ simply put via acpi is broken right now only the actual symptoms differ ] People who hit this class of bug should open a new bug and mark it as blocker for this one so it can be closed once all repported via acpi problems are solved. It is very possible a single quirk will fix all via systems at once.
Was ist ein "umbrella bug"?
Eine Regenschirm-Wanze ;-) Unter bugzilla legt man bugs an und bekommt eine Nummer. Da die aber die Übersicht darüber behalten wollen, welche Tickets zu einem bestimmten Thema aufgemacht werden, gibt es wohl diese Id "845", dort schreibst Du dann welche Id du sonst noch aufgemacht hast. Und in welchem Status sich diese befinden, abgeschlossen oder sonstwas... -- Andreas
Al Bogner schrieb:
[...] Ist "Oops: 0000 2.4.21-58-athlon #1 Fri Aug 29 11:26:08 UTC 2003" kritisch? [...]
Ein Oops beim Kernel entspricht in etwa dem, was ein Segmentation Fault bei anderen Programmen ist. Es wird hier versucht, einen un- gueltigen Pointer zu dereferenzieren... Ein Oops ist ein Hinweis auf einen Bug im Kernel oder einem Kernel-Treiber und sollte gefixt werden. Daher sollte man solche Fehler melden (incl. kompletten Fehlerreport und einer "Dekodierung" durch ksymoops). Der Linux- Kernel ist sehr robust und im Gegensatz zu den meisten "normalen" Programmen muss ein Kernel durch einen Oops nicht abstuerzen oder instabil werden. Ein Oops hat also nichts mit einem Kernel Panic zu tun. Bei einem Kernel Panic ist der Linux-Kernel in einem Zustand, bei dem es nicht mehr weiter geht - das System muss rebootet werden. Natuerlich kann ein Oops einen Kernel Panic verursachen, wenn der Fehler in einem lebenswichtigen Teil des Kernel-Codes auftritt. Tritt der Fehler nur in einem Geraetetreiber auf, so wird es ver- mutlich nicht zu einem Kernel Panic kommen. Der Oops wird dann ueber die ueblichen Wege meist in /var/log/messages festgehalten. Gruesse, Th.
Al Bogner <suse-linux@ml.pinguin.uni.cc> [Sat, 30 Aug 2003 21:46:57 +0200]:
Mit acpi=off funktioniert das Netzwerk. Was hat denn ACPI mit einer NIC zu tun?
Dir ist offensichtlich nicht bewusst, was alles zu ACPI gehört :) Zu ACPI gehört auch die Verwaltung der Resourcen, unter Anderem also auch die IRQs und deren Zuordnung. Ich vermute mal, dass wegen fehlerhafter ACPI-Tabellen oder fehlerhaftem BIOS die Netzwerkkarte keinen IRQ bekommt. Ohne IRQ kann aber kein NIC funktionieren. Philipp
Am Samstag, 30. August 2003 23:54 schrieb Philipp Thomas:
Al Bogner <suse-linux@ml.pinguin.uni.cc> [Sat, 30 Aug 2003 21:46:57 +0200]:
Mit acpi=off funktioniert das Netzwerk. Was hat denn ACPI mit einer NIC zu tun?
Dir ist offensichtlich nicht bewusst, was alles zu ACPI gehört :)
Das gebe ich gerne zu. Ich bin nur ein "dummer" User, der versucht nach einer nforce2-Pleite ein System mit einem KT400A-Chipsatz einigermaßen hinzubekommen.
Zu ACPI gehört auch die Verwaltung der Resourcen, unter Anderem also auch die IRQs und deren Zuordnung. Ich vermute mal, dass wegen fehlerhafter ACPI-Tabellen oder fehlerhaftem BIOS die Netzwerkkarte keinen IRQ bekommt. Ohne IRQ kann aber kein NIC funktionieren.
k_athlon-2.4.21-58 (acpi=off): cat /proc/interrupts CPU0 0: 97338 XT-PIC timer 1: 2 XT-PIC keyboard 2: 0 XT-PIC cascade 5: 0 XT-PIC usb-uhci 8: 2 XT-PIC rtc 10: 0 XT-PIC usb-uhci 11: 71 XT-PIC eth0, usb-uhci 12: 0 XT-PIC Trident Audio, ehci_hcd 14: 5924 XT-PIC ide0 15: 44 XT-PIC ide1 NMI: 0 LOC: 0 ERR: 0 MIS: 0 vanilla-2.4.22-ac1: cat /proc/interrupts CPU0 0: 326826 IO-APIC-edge timer 1: 2 IO-APIC-edge keyboard 2: 0 XT-PIC cascade 8: 2 IO-APIC-edge rtc 9: 0 IO-APIC-edge acpi 14: 80611 IO-APIC-edge ide0 15: 70 IO-APIC-edge ide1 17: 54003 IO-APIC-level eth0 NMI: 0 LOC: 326781 ERR: 0 MIS: 0 Al
participants (4)
-
Al Bogner
-
Andreas Winkelmann
-
Philipp Thomas
-
Thomas Hertweck