iwi0: fatal firmware error

Ich würde dir empfehlen, die iwi gegen eine ral auszutauschen. Das bringt nicht nur mehr Leistung, sondern du sparst dir auch das lästige Firmware-gefummel. Außerdem sind die Karten günstiger und du könntest die iwi z.B. auf ebay verkaufen.

auf bald
oenone
 
Normalerweise kann man auch bei Centrino die WLAN-Karte tauschen. Das ist einfach eine Mini-PCI Karte. Bei vielen Notebooks ist sogar ein extra Deckel um direkt an die Karte zu kommen ohne das Gerät auseinander zu nehmen (wie beim Arbeitsspeicher).
 
Tja... dummweise haben viele IBMs und HP Notebooks im BIOS ne Whitelist mit PCI IDs.

Damit laesst nicht jede Karte einbauen und man muss, wenn man ne beliebige Karte einbauen will, im BIOS patchen. Ausbauen sollte aber wohl funktionieren.

Notfalls PCMCIA oder USB verwenden, inwieweit OpenBSD da Support fuer hat, weiss ich aber leider nicht.
 
Auch wenn es dir nicht hilft:

Meine iwi in meinen fsc-centrino läuft unter 4.1 nachdem ich die Firmware ins entsprechende verzeichnis kopiert habe zu 100% ohne irgendwelche einschränkungen.

Ich werde nachher wenn ich zugriff aufs nb habe mal gucken was ich da genau runtergeladen habe und wohin ichs kopiert habe!
 
Meine Intel PRO/Wireless 2200BG läuft in meinem Centrino Notebook leider auch nicht problemlos.
Als Alternative hätte ich für 5 Euro eine miniPCI-WLAN-Karte mit einem Realtek RTL8180L Chipsatz zur Verfügung, es gibt laut openbsd.org Unterstützung für diesen Chip, die Frage ist allerdings ob ich damit mehr Freude hab.
Hat jemand bereits Erfahrungen mit dem Realtek Chipsatz?
 
Ich meine mich entsinnen zu können, das die Ralink Chips empfehlenswert sind, da Ralink die Dokumentation offen gelegt hat und somit die Treiber ohne Probleme entwickelt werden konnten.
Meiner Meinung nach lohnt es sich einen solchen Hersteller zu unterstützen.

P.S.: Wie gesagt, bin mir nicht ganz sicher ob es Ralink war, aber die Azahl der Unterstützten Devices spricht dafür.

@ hades: Welche Probleme hast du mit der 2200BG?
 
Ja das ist Ralink.

Auch bei mir tritt ab und zu ein 'fatal firmware error' auf, allerdings ohne bemerkbare Auswirkungen.
Leider gibts es vom obigen Problem abgesehen beim verbinden auf ältere Accesspoints Schwierigkeiten. Das läge - wie man mir sagte - an den Accesspoints, die mit DHCP Probleme hätten. Bei den teilweise verbauten Cisco-APs treten diese Probleme auch nicht auf. Komischerweise hatte ich mit dem gleichen Notebook unter Fedora keine Probleme.
 
Kurzfassung: ROTZ!

Kurzfassung: "Ich bin einem BSD Forum und schimpfe über Treiberprobleme (!) ohne die Hardware je unter einem BSD verwendet zu haben."

Ich habe eine ral(4) Karte in einem meiner Rechner der als Access Point fungiert. Die Karte wird zwar nicht sehr heftig genutzt, aber OpenVPN (der einzige Weg um über jenes WLAN irgendwo hin zu gelangen) funktioniert einwandfrei. Auch bei größeren Datenmengen und -raten. Lediglich die Signalqualität lässt zu wünschen übrig, bin mir aber nicht sicher ob's an der Karte, der Antenne oder am Standpunkt liegt.
 
Kurzfassung: "Ich bin einem BSD Forum und schimpfe über Treiberprobleme (!) ohne die Hardware je unter einem BSD verwendet zu haben."

Ich habe eine ral(4) Karte in einem meiner Rechner der als Access Point fungiert. Die Karte wird zwar nicht sehr heftig genutzt, aber OpenVPN (der einzige Weg um über jenes WLAN irgendwo hin zu gelangen) funktioniert einwandfrei. Auch bei größeren Datenmengen und -raten. Lediglich die Signalqualität lässt zu wünschen übrig, bin mir aber nicht sicher ob's an der Karte, der Antenne oder am Standpunkt liegt.

Kurzfassung: Du bist in einem BSD-Forum und liest nicht was andere Schreiben!
Nur mal so: ral != rtl!

---

So, etwas konstruktiver: Ich verwende eine iwi, die sich als "Intel PRO/Wireless 2200BG" im dmesg ausgibt. Völlig Problemlos, ohne abstrüze o.ä. - ich hab OpenBSD 4.2 (nutze also 4.1) aber noch nicht drauf, da ich das NB auch nicht SO häufig nutze ... habe über die karte aber auch ohne probleme schon einige gb kopiert.
Ich habe mich bei der installation übrigens auch einfach an die einleitung gehalten und die o.G. dateien verwendet.
 
hades schrieb:
Immerhin bietet OpenBSD dafür Unterstützung.
Ich hatte die Karte 2003 erworben und verwendet!
Das war lange bevor es überhaupt einen OpenBSD-Treiber gab,
der gemäß der rtw man page erst mit 3.7 rauskam!
 
Das mag ja sein, aber überleg dir einmal, wieso ich das in einem OpenBSD-Thread gepostet habe?
Es geht mir weder darum ob diese Karte unter Linux oder Windows nicht oder nur schlecht funktioniert, sondern wie die Unterstützung seitens OpenBSD ist.
 
Kurzfassung: Du bist in einem BSD-Forum und liest nicht was andere Schreiben!
Nur mal so: ral != rtl!

Ich entschuldige mich für den Ton. Die Aussage selbst aber bleibt.

Treiberprobleme beim Einsatz mit einem anderen Betriebssystem sagen nichts über die Hardware aus. Hinzu kommt: Das Gerücht, Realtek-Chips seien per Definition schlecht hält sich seit Bill Paul seinen berühmten Kommentar im rl(4) Treiber hinterlassen hat. Irgendwie wird dieses uralte (der Treiber und der Kommentar sind beide mittlerweile 10 Jahre alt) Vorurteil blind auf andere Chips des selben Herstellers übertragen. Aber gerade bei Wireless-Chips hat sich Realtek sehr durch Offenheit hervorgetan - es gibt frei erhältliche Dokumentation für die Chips. Ausserdem brauchen Realtek Chips im Gegensatz zu anderen Herstellern in der Regel keine Firmware.

Die Aussage, dass die Realtek-Chips Grütze seien, ist daher die eigentliche Grütze.
 
Das mag ja sein, aber überleg dir einmal, wieso ich das in einem OpenBSD-Thread gepostet habe?
Erklärt mir doch erst mal, warum Ihr alle OFF TOPIC postet!

Stellt irgendjemand in Frage, dass der Thread eindeutig mit der Thematik "Intel PRO/Wireless 2200BG" und OpenBSD 4.2 eröffnet wurde?

Das es mit OpenBSD 3.9 und 4.0 problemlos und mit 4.1 mit einzelnen Problemen ging hatte ich bereits initial erwähnt.

KEINER hat bisher zur der Thematik einen sinnvollen Beitrag geleistet!

Warum sollte ich ein Stück Hardware rauswerfen, dass in vorherigen Versionen eindeutig funktionierte?
 
Erklärt mir doch erst mal, warum Ihr alle OFF TOPIC postet!

Stellt irgendjemand in Frage, dass der Thread eindeutig mit der Thematik "Intel PRO/Wireless 2200BG" und OpenBSD 4.2 eröffnet wurde?

Das es mit OpenBSD 3.9 und 4.0 problemlos und mit 4.1 mit einzelnen Problemen ging hatte ich bereits initial erwähnt.

KEINER hat bisher zur der Thematik einen sinnvollen Beitrag geleistet!

Warum sollte ich ein Stück Hardware rauswerfen, dass in vorherigen Versionen eindeutig funktionierte?

huhu

Da ich ja als einziger die gleiche Karte verwende, upgrade ich für dich gerade auf OpenBSD 4.2 (na gut, es war eh nötig). (Verbaut in einem FSC Lifebook S7020, mit 1,8Ghz Centrino, 1gb ram)
Den Updatevorgang hab ich nach der Update-Anleitung per cd gemacht, anschließend "normal" gebootet, mit iwi als netzwerkkarte.
Seit ca. einer halben stunden update saugt er über die iwi die packages, bislang ohne jeden Fehler. Ich habe aber KEINE neue Firmware heruntergeladen, die ist nach dem update offensichtlich erhalten geblieben.
(ich weis leider nicht mehr genau welche dateien das genau waren die ich heruntergeladen hatte - evtl. könnte ich dir die zuschicken oder so?)
Ich verwende statische IP-Addressen und 128-Bit WEP-Verschlüsselung.

Was mir noch eingefallen ist da ich es etwas "vergessen" hatte: Unter 4.1 lief die iwi GARNICHT (aber afair auch ohne fehlermeldung) wenn ich die ethernet-broadcom-lan zusätzlich während des boots konfigurieren lassen habe.
 
Da ich ja als einziger die gleiche Karte verwende, upgrade ich für dich gerade auf OpenBSD 4.2 (na gut, es war eh nötig). (Verbaut in einem FSC Lifebook S7020, mit 1,8Ghz Centrino, 1gb ram)
Besten Dank für die konstruktiven Bemühungen!

Ich habe mittlerweile nochmals das komplette System in eine frisch formatierte Partition installiert.
Die Installation der Firmware erfolgte wiederum mehrfach über ein pkg_add http://damien.bergamini.free.fr/iwifw/OpenBSD/iwi-firmware-3.0.tgz.

Das die Dateien kaputt sind würde ich ausschliessen.
Da sie, wenn auch unter anderem Namen auch bei anderen Betriebssystemen verwendet werden.
Ein cmp mit den Firmware-Dateien, die unter Debian einwandfrei funktionieren,
liefert für die drei Dateien jeweils den Return Code 0.

Ich habe leider keine Umgebung, bei der ich mit einer statischen Adresse testen könnte,
sondern beziehe die IP-Adresse über DHCP.
Seit der Neuinstallation sind die Fehlermeldungen verschwunden.
Allerdings treten die Abbrüche jeweils nach ca. 5 Minuten immer noch auf.
Und zwar ohne Meldungen im Kernelbuffer (dmesg) oder irgendwelchen Logdateien.
Der Abbruch äußert sich darin, dass einfach keine Daten rein und rausgehen.

In machen Fällen reicht ein ifconfig iwi0 down und ifconfig iwi0 up,
meist muss ich noch ein dhclient iwi0 ausführen, wobei die zuvor erhaltene Adresse wieder zugewiesen wird.
Da es mit Debian geht, würde ich Umgebungseffekte ausschließen.

Mit ktrace habe ich bei Programmen wie ssh und wget nur gesehen,
dass jeweils schlagartig das Datensenden bzw. -empfangen abbrach.

Ich habe kein Ahnung, ob etwas mit dem Kerneldebugger zu eruieren wäre,
zumindest fehlt mir damit die praktische Erfahrung.
 
Zuletzt bearbeitet von einem Moderator:
ich weis nicht ob das noch aktuell ist, und ob es jemanden hilft, aber für die Akten:

Ich habe auch einen Fehler mit der iwi0 karte - das aber eben erst festgestellt:

Ohne Fehlermeldung bricht die Verbindung hab, ein ifconfig iw0 down und up bringen sie dann meisten wieder hoch ...

ABER

Das ganze passiert nur wenn ein 2. Notebook, mit ralink-chipsatz-usb-wlan-netzwerkkarte und Windows 2000 im Betrieb ist, aber nicht sofort, sondern nach einiger Zeit oo
 
Ich habe die Platte meines abgefackelten Notebook in's Notebook meines Vaters geschoben. Da ist auch eine iwi drin, die auch gelgentlich meldet die Firmware würde in mode 4 hängen (oder so ähnlich). Ist also ein generelles Problem.
 
Das ganze passiert nur wenn ein 2. Notebook, mit ralink-chipsatz-usb-wlan-netzwerkkarte und Windows 2000 im Betrieb ist, aber nicht sofort, sondern nach einiger Zeit oo
Das Problem habe ich im Hotel bemerkt.
Es ist sicher, dass andere Rechner mit Windows auch zeitgleich den Access Point nutzten, wobei ich nicht mehr nachvollziehen kann,
ob auch ein Gerät mit obiger Kombination dabei war.
Allerdings tratt das Problem auch auf, wenn ich der alleinige Nutzer eines anderen Access Points war.
 
Zurück
Oben