stundenlang habe ich mich mit PCMCIA-Kernelmodulen herumgeschlagen, mit Hotplug, mit pcmcia-cs und pcmciautil. Alles hat nicht geholfen. Immer, wenn ich eine beliebige PCMCIA-Karte ins Notebuch eingesteckt habe, ist das BS verreckt.
Heute früh wollte ich eine entspr. Anfrage stellen; um eine brauchbare Diagnostik zu ermöglichen wollte ich die letzten Meldungen, die ich vor dem Verrecken bekomme, nochmal sehen, um sie buchstabengetreu weitergeben zu können.
Keine Fehlermeldung, Karte wird sauber erkannt, als /dev/sda eingebunden! Karte raus, Karte rein, Karte raus, Karte rein… auf einmal funktioniert alles!
Karte raus, Ladegerät an Notebook angeschlossen, Karte rein: BS verreckt! Ladegerät abgenommen, Karte erneut eingesteckt: Alles läuft! Unter parallel installiertem Windows funktioniert die Karte übrigens bisher unter allen Bedingungen.
Jetzt zu meiner Frage: Ist ein solches Verhalten als Hardwaredefekt oder -mangel zu betrachten, oder ist so etwas relativ normal, muss ich damit leben? Das Notebook ist nagelneu, muss ich bei solcher Symptomatik davon ausgehen, dass die Hardware recht bald den Geist aufgeben wird? Oder ist es denkbar, dass sich hier schlicht unter Linux in bestimmten Fällen ACPI- und Cardbridge-Module beissen?
wenn Du schreibst, dass die Sache unter Windows einwandfrei läuft, dann kann man einen Hardwarefehler wohl ausschließen. Da im umgekehrten Fall jetzt die Linux-Fraktion natürlich gleich einen einfachen Rat hätte, gebe ich den jetzt auch mal Setze ein anständiges Betriebssystem ein!
Aber mal im Ernst: Ich tippe auf Fehler in den Linux-Treibern bzgl. der Komponenten des Boards. Vielleicht gibt es ja schon eine neuere Version oder zumindest einen Workaround.
Gruß vom Wiz
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
Da es unter Win funktioniert, tippe ich auch auf einen Softwarefehler.
Wenn das Ladegerät angeschlossen ist, muss nicht so extrem Energiegespart werden, wie beim Betrieb ab Akku.
Um zwischen diesen beiden Modi umzuschalten, werden die Treiber über den Zustand informiert und können sich dann entsprechend unterschiedlich verhalten.
Was dein Treiber ja eindeutig auch macht (
wenn Du schreibst, dass die Sache unter Windows einwandfrei
läuft, dann kann man einen Hardwarefehler wohl ausschließen.
Sehe ich eher ähnlich .
Da im umgekehrten Fall jetzt die Linux-Fraktion natürlich
gleich einen einfachen Rat hätte, gebe ich den jetzt auch mal Setze ein anständiges Betriebssystem ein!
Gegen-Rat: verwende Hardware, deren Hersteller nicht vollständig aus Seattle korrumpiert wurde sondern standardkonformes oder dokumentiertes ACPI verwendet. Nichtdeterministisch agierende Hardware ist einfach nur ätzend.
Aber mal im Ernst: Ich tippe auf Fehler in den Linux-Treibern
bzgl. der Komponenten des Boards. Vielleicht gibt es ja schon
eine neuere Version oder zumindest einen Workaround.
Ja, vielleicht einfach mal den Kernel mit deaktiviertem ACPI booten. Oder mal testweise einzelne ACPI-Module blacklisten und so lange das Zeug nachladen, bis der Rechner wegkratzt. Dann kennt man wenigstens den Übeltäter.
mal eine ganz grundsätzliche Frage:
wenn ich ein Hardware habe, die ohne Probleme unter dem BS A*) läuft, warum sollte ich dann das BS B*) verwenden und dort so lange rumfummeln, bis meine vorhandene Hardware möglicherweise (denn sicher ist das ja keineswegs)läuft?
Der Sinn des Ganzen erschließt sich mir nicht so recht.
mal eine ganz grundsätzliche Frage:
wenn ich ein Hardware habe, die ohne Probleme unter dem BS A*)
läuft, warum sollte ich dann das BS B*) verwenden und dort so
lange rumfummeln, bis meine vorhandene Hardware möglicherweise
(denn sicher ist das ja keineswegs)läuft?
Deine Logik im Umehrschluß: Du hast Hardware und wählst dann dazu das Betriebssystem, was damit funtioniert. Interessante Strategie.
Warum man Betriebssystem X lieber nutzen will als Betreibssystem Y, dafür gibt es viele Gründe. Und oft genug zahlt sich die zeitliche Investition auch bei ausnahmsweise mal knifflieger Hardwareinstallarion mehr als aus.
Deine Logik im Umehrschluß: Du hast Hardware und wählst dann
dazu das Betriebssystem, was damit funtioniert. Interessante
Strategie.
Kommt z.B. beim Kauf eines gebrauchten Notebooks durchaus
nicht so selten vor.
Das ist auch beim Kauf von gebrauchten Notebooks kein sonderlich kluges Vorgehen.
Allenfalls schenken lassen kann man sich vorbehaltlos. Übrigens würde ich selbst, wenn ich beabsichtige, Windows zu benutzen, darauf achten, dass die Hardware auch für andere OS gut unterstützt wird, zumindest jedenfalls „brauchbar“. Gut unterstützte Hardware ist beileibe keine Seltenheit mehr heutzutage, da kann man es sich leisten, darauf zu achten.
Gegen-Rat: verwende Hardware, deren Hersteller nicht
vollständig aus Seattle korrumpiert wurde sondern
standardkonformes oder dokumentiertes ACPI verwendet.
Nichtdeterministisch agierende Hardware ist einfach nur
ätzend.
Jaja, du bist nicht der erste der mir sagt wie blöd ich bin, ein chinesisches NoName-Produkt zu kaufen, statt das gute chin. Thinkpad (vormals IBM) zum gleichen Preis.
Ich hätte hellhörig werden müssen, als der Händler versichert hat, das Gerät sei ‚Red Hat-zertifiziert‘ und im gleichen Atemzug gefragt hat, welches Betriebssystem ich denn einsetzen wolle, vielleicht XP? Zumindest laut lspci habe ich aber keine Exoten unter den Komponenten.
Ja, vielleicht einfach mal den Kernel mit deaktiviertem ACPI
booten. Oder mal testweise einzelne ACPI-Module blacklisten
und so lange das Zeug nachladen, bis der Rechner wegkratzt.
Dann kennt man wenigstens den Übeltäter.
Das werde ich, soweit ACPI modular eingebunden ist, mal machen. Den Kernel komplett neu zu bauen, habe ich beim gegenwärtigen Wetter wenig Lust. Aber es kommt ja auch mal wieder Regenwetter…
wenn Du schreibst, dass die Sache unter Windows einwandfrei
läuft, dann kann man einen Hardwarefehler wohl ausschließen.
Da im umgekehrten Fall jetzt die Linux-Fraktion natürlich
gleich einen einfachen Rat hätte, gebe ich den jetzt auch mal Setze ein anständiges Betriebssystem ein!
Mach ich doch! Aber auch mit einem gehärteten Windows, welches ich in der Firma völlig offen einsetze, gehe ich nicht in fremde oder öffentliche Netze, das hat mein Administrator mir verboten.
Aber mal im Ernst: Ich tippe auf Fehler in den Linux-Treibern
bzgl. der Komponenten des Boards. Vielleicht gibt es ja schon
eine neuere Version oder zumindest einen Workaround.
Da ich zunächst keinen Zusammenhang mit ACPI vermutet habe, waren meine Recherchen im Internet zu diesem Problem zunächst erfolglos, es schien keine Präzedenzfälle zu geben.
Nachdem ich meine Suche jetzt erweitert habe, habe ich doch recht schnell ein paar Fälle gefunden, wie’s aussieht schafft entweder eine Bootoption oder das Ausknipsen einer Option in der PCMCIA-Konfiguration Abhilfe.
Um zwischen diesen beiden Modi umzuschalten, werden die
Treiber über den Zustand informiert und können sich dann
entsprechend unterschiedlich verhalten.
Was dein Treiber ja eindeutig auch macht (
Inzwischen bin ich etwas schlauer, es gibt wohl Möglichkeiten, dieses Verhalten anzupassen. Siehe auch meine Antwort an Wiz.
mal eine ganz grundsätzliche Frage:
wenn ich ein Hardware habe, die ohne Probleme unter dem BS A*)
läuft, warum sollte ich dann das BS B*) verwenden und dort so
lange rumfummeln, bis meine vorhandene Hardware möglicherweise
(denn sicher ist das ja keineswegs)läuft?
Der Sinn des Ganzen erschließt sich mir nicht so recht.
Naja, mir erscheint diese Fummelei doch noch erfolgversprechender und weniger aufwändig, als das in der Firma offen benutzte BS A solange abzuhärten und mit PFs zu traktieren, dass ich damit ungefährdet auch in öffentliche oder fremde private Netze gehen kann. Ganz abgesehen von der von Sebastian schon genannten Softwarefrage.
nett, so einen Scherzkeks in unserer Mitte zu haben, wo doch der typische L***x-User ansonsten eher durch eine gewisse, offenbar systemimmanente Verbissenheit auffällt.
Gegen-Rat: verwende Hardware, deren Hersteller nicht
vollständig aus Seattle korrumpiert wurde …
Hallo,
es ist schon jämmerlich und beschämend, wenn man auch noch die eigenen Fehler dem bösen Konkurrenten unterschieben will - als ob der nicht genug machen würde.
Gegen-Rat: verwende Hardware, deren Hersteller nicht
vollständig aus Seattle korrumpiert wurde …
es ist schon jämmerlich und beschämend, wenn man auch noch die
eigenen Fehler dem bösen Konkurrenten unterschieben will - als
ob der nicht genug machen würde.