Nun sind die Pfingsferien angebrochen und ich habe genug Zeit endlich SuSE, welches sich noch von meinen ersten Linux-Schritten von vor etwa einem Jahr auf dem Notebook befindet, zu loeschen und dafuer Debian Testing zu installieren.
Soweit ging eigentlich alles gut. Die Hardware des Acers Aspire 1602LM wurde sofort alles richtig erkannt und nach kleinen Problemen mit dem Touchpad <-> XF86Config-4 lief dann auch der X mit icewm.
Nun das Problem: Solang kein X gestartet ist, funktioniert die Netzwerkkarte noch. Im Gegensatz: Ist er gestartet, geht diese nicht mehr.
Ein Versuch von mir war, die Netzwerkkarte neu zu starten, das machte ich mit ifconfig eth0 down und danach ifconfig eth0 up, dann folgt nach einiger Zeit der Hinweis:
Message from syslogd@localhost at {Tag, Datum, Uhrzeit}
localhost kernel: Disabling IRQ #233
lspci -v sagt ueber die Netzwerkkarte folgendes:
0000:00:07.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
Subsystem: Wistron Corp.: Unknown device 1053
Flags: bus master, medium devsel, latency 64, IRQ 233
I/O ports at 1800 [size=256]
Memory at ec005000 (32-bit, non-prefetchable) [size=256]
Capabilities: [50] Power Management version 2
Hoffentlich kann mir hier jemand helfen. Ich selbst weiss nicht mehr weiter!
Linux 15.036 Themen, 107.107 Beiträge
Einen richtigen IRQ 233 Kanal gibt es nicht . Ich denke mal das die ACPI Funktion des Betriebsystemkerns nicht richtig funktioniert.
Ich würde mal einen eigenen Kern kompilieren und ACPI und APM deaktivieren. Man kann aber auch dem Standardbetriebsystemkern eine Option übergeben um ACPI abzuschalten. Ich weiß aber nicht die genaue Syntax davon.
Ich hatte nun testweise in lilo mit Hilfe von append="apci=off" ACPI abgeschalten. Nach dem Neustart hing sich der Rechner irgendwo ganz am Start auf. Mit Knoppix habe ich die Zeile wieder entfernt .....
Nun habe ich versucht, nach der gleichen Weise apic (NICHT acpi) zu entfernen. Leider brachte auch diesen keinen Erfolg, denn es gibt immer noch den IRQ #233.
Und nochwas: Unter Knoppix mit KDE funktioniert die Netzwerkkarte sowie ACPI richtig! Kann man hier eventuell irgendwelche Config-Dateien uebernehmen?
Hier nochmal die vollstaendigen Ausgaben von lspci -v unter Debian Testing sowie unter Knoppix.
Debian Testing:
MAJESTIX:~# lspci -v
0000:00:00.0 Host bridge: Silicon Integrated Systems [SiS] SiS645DX Host & Memory & AGP Controller (rev 01)
Subsystem: Wistron Corp.: Unknown device 4000
Flags: bus master, medium devsel, latency 64
Memory at e8000000 (32-bit, non-prefetchable) [size=64M]
Capabilities: [c0] AGP version 2.0
0000:00:01.0 PCI bridge: Silicon Integrated Systems [SiS] Virtual PCI-to-PCI bridge (AGP) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 99
Bus: primary=00, secondary=01, subordinate=01, sec-latency=68
I/O behind bridge: 0000a000-0000afff
Memory behind bridge: ec100000-ec1fffff
Prefetchable memory behind bridge: f0000000-f7ffffff
0000:00:02.0 ISA bridge: Silicon Integrated Systems [SiS] SiS962 [MuTIOL Media IO] (rev 14)
Flags: bus master, medium devsel, latency 0
0000:00:02.1 SMBus: Silicon Integrated Systems [SiS]: Unknown device 0016
Flags: medium devsel, IRQ 177
I/O ports at 2020 [size=32]
0000:00:02.3 FireWire (IEEE 1394): Silicon Integrated Systems [SiS] FireWire Controller (prog-if 10 [OHCI])
Subsystem: Wistron Corp.: Unknown device 1054
Flags: bus master, medium devsel, latency 64, IRQ 177
Memory at ec000000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [64] Power Management version 2
0000:00:02.5 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE] (prog-if 80 [Master])
Subsystem: Wistron Corp.: Unknown device 1056
Flags: bus master, medium devsel, latency 128, IRQ 185
I/O ports at 2000 [size=16]
0000:00:02.6 Modem: Silicon Integrated Systems [SiS] AC'97 Modem Controller (rev a0) (prog-if 00 [Generic])
Subsystem: Wistron Corp.: Unknown device 1059
Flags: medium devsel, IRQ 193
I/O ports at 1000 [size=256]
I/O ports at 1c00 [size=128]
Capabilities: [48] Power Management version 2
0000:00:02.7 Multimedia audio controller: Silicon Integrated Systems [SiS] Sound Controller (rev a0)
Subsystem: Wistron Corp.: Unknown device 200a
Flags: bus master, medium devsel, latency 173, IRQ 193
I/O ports at 1400 [size=256]
I/O ports at 1c80 [size=128]
Capabilities: [48] Power Management version 2
0000:00:03.0 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 Controller (rev 0f) (prog-if 10 [OHCI])
Subsystem: Wistron Corp.: Unknown device 1056
Flags: bus master, medium devsel, latency 64, IRQ 201
Memory at ec001000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [dc] Power Management version 2
0000:00:03.1 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 Controller (rev 0f) (prog-if 10 [OHCI])
Subsystem: Wistron Corp.: Unknown device 1056
Flags: bus master, medium devsel, latency 64, IRQ 209
Memory at ec002000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [dc] Power Management version 2
0000:00:03.2 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 Controller (rev 0f) (prog-if 10 [OHCI])
Subsystem: Wistron Corp.: Unknown device 1056
Flags: bus master, medium devsel, latency 64, IRQ 217
Memory at ec003000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [dc] Power Management version 2
0000:00:03.3 USB Controller: Silicon Integrated Systems [SiS] USB 2.0 Controller (prog-if 20 [EHCI])
Subsystem: Wistron Corp.: Unknown device 1056
Flags: bus master, medium devsel, latency 64, IRQ 225
Memory at ec004000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [50] Power Management version 2
0000:00:07.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
Subsystem: Wistron Corp.: Unknown device 1053
Flags: bus master, medium devsel, latency 64, IRQ 233
I/O ports at 1800 [size=256]
Memory at ec005000 (32-bit, non-prefetchable) [size=256]
Capabilities: [50] Power Management version 2
0000:00:09.1 CardBus bridge: Texas Instruments PCI1520 PC card Cardbus Controller (rev 01)
Subsystem: Wistron Corp.: Unknown device 3202
Flags: bus master, medium devsel, latency 168, IRQ 177
Memory at 20001000 (32-bit, non-prefetchable) [size=4K]
Bus: primary=00, secondary=06, subordinate=09, sec-latency=176
Memory window 0: 20c00000-20fff000 (prefetchable)
Memory window 1: 21000000-213ff000
I/O window 0: 00004800-000048ff
I/O window 1: 00004c00-00004cff
16-bit legacy interface ports at 0001
0000:01:00.0 VGA compatible controller: ATI Technologies Inc Radeon R250 Lf [Radeon Mobility 9000 M9] (rev 02) (prog-if 00 [VGA])
Subsystem: Wistron Corp.: Unknown device 2058
Flags: bus master, stepping, fast Back2Back, 66MHz, medium devsel, latency 66, IRQ 185
Memory at f0000000 (32-bit, prefetchable) [size=128M]
I/O ports at a000 [size=256]
Memory at ec100000 (32-bit, non-prefetchable) [size=64K]
Capabilities: [58] AGP version 2.0
Capabilities: [50] Power Management version 2
MAJESTIX:~#
Und hier von Knoppix:
knoppix@1[knoppix]$ lspci -v
0000:00:00.0 Host bridge: Silicon Integrated Systems [SiS] SiS645DX Host & Memory & AGP Controller (rev 01)
Subsystem: Wistron Corp.: Unknown device 4000
Flags: bus master, medium devsel, latency 64
Memory at e8000000 (32-bit, non-prefetchable) [size=64M]
Capabilities:
Wie man sieht liegen die IRQ "zu hoch". Anscheinend ist aber auch unter KNOPPIX der IRQ 16 doppelt belegt ....
Jemand eine Idee, wie man die IRQs aendern kann?
Ich würde einfach mal einen eigenen Kern kompilieren. Dazu brauchst du keinen Grafikmodus.
Vielleicht einfach mal ACPI, APIC und APM aus dem neu kompilierten Kern rausschmeißen. Das ist bei Notebooks oft die Fehlerursache.
Allerdings: ACPI sollte ja eigentlisch schon funktionieren, denn: Ein Laptop ohne ACPI ist nicht gerade so schoen :(
PS.: Vielleicht "verträgt" sich irgendeine andere Option des Standardkerns nicht mit deinen Chipsätzen im Notebook. Ich würde auf jeden Fall einen eigenen Kern kompilieren.
So, es war viel Arbeit. Sehr viel Arbeit sogar, aber nun geht es endlich. Die Loesung war eigentlich ganz einfach: APIC (nicht ACPI!) deaktivieren. Diese Idee bestand zwar schon eher, wurde aber falsch umgesetzt, denn APIC deaktiviert man ueber lilo anders als ACPI!
append="acpi=off" ist zum Deaktivieren von ACPI, jedoch ....
append="noapic, nolapic" um APCI abzuschalten.
Naja. Wieder was gelernt, auch wenn dafuer 'ne Menge Zeit floeten ging ....
Ich habe einen schönen Artikel gefunden, welcher den zweck von APIC erklärt:
http://www.hardtecs4u.com/reviews/2002/irq/index4.php
Mir erschien die IRQ Kanal-Nummer doch gleich ein wenig zu hoch, obwohl mit APIC mehr als 16 IRQ Kanöle gesteuert werden können.
Ich habe ACPI mit APIC verwechselt:
ACPI ist für die Energieverwaltung ,Hardwarerkennung und Gerätekonfiguration zuständig:
http://www.computerbase.de/lexikon/ACPI
Bin mal gespannt, ob nun wirklich alles funktioniert. Viele Geraete haben einen IRQ #11 drin stehen .... mal sehen ...
PPS.: Wahrscheinlich fehlen dann auch noch ein paar andere Treiber. Die Meldung "Unknown device" erscheint sehr häufig. Wenn ich mir einen Rechner für Linux kaufen, nehme ich meistens nVidia Grafikkarten ,den nForce-Chipsatz von NVidia und den Realtek RTL8139 Netzwerkchip. Dann müßte sogar der DMA-Modus der Festplatte funktionieren.
Ich kenne keinen anderen Hersteller als nVidia, der Treiber für Linux programmiert. Man ist sonst immer auf die Standardtreiber vom Linuxbetriebsystemkern angewiesen. Dann funktioniert meistens nicht mal der DMA-Modus der Festplatte .
Deshalb konfiguriere ich immer einen eigenen Kern, um mich zu informieren welche Treiber im aktuellen Kern schon drinn sind. Danach schaue ich beim Hersteller des Chips nach. Und wenn da auch kein Treiber zu bekommen ist, lasse ich es meistens sein und kaufe mir einen anderen Rechner. Ich laufe den Treiber für Linux nicht mehr hinterher. Die Hersteller müssen selbst wissen, wie wichtig ihnen Linux ist (um ihre Computer zu verkaufen).
Hallo Karsten,
300% Zustimmung zu Deinem letzten Absatz. Ich suche mir meine Hardware ebenfalls nach Linux-Verträglichkeit aus. Das schränkt mich bei der Auswahl nicht sehr ein und beschert mir seit Jahren einen absolut stressfreien Betrieb. Es würde auch kein Windows-User auf die Idee kommen, sich Hardware ohne entsprechende Treiber zuzulegen. Das gäbe zu viele gelbe Flecken im Gerätemanager.
Richtig!
Es sollte sowas wie ein "Linuxtauglichkeitsabzeichen" geben, also auf jeden Karton, der richtige Hardware enthält, auch ein kleiner Tux.
Und eine Aufschrift "Designed for Linux compatible" kommt vielleicht bald ;)