(gelöst) 16bit-PCMCIA und kernel > 3.6.36

[guennid]

Zwei Eigenbaukernel, 2.6.36.2 und 2.6.39.4
config des höheren Kernels generiert aus der des niedrigeren. Treiber (3c574_cs) für die PCMCIA-Netzwerkkarte in beiden Kernen als Modul eingepflegt. Beim 36er wird das Modul beim Starten automatisch geladen, die Netzverbindung funktioniert bisher ohne bemerkte Fehler. Beim 39er wird das Modul beim Starten nicht geladen. modconf bezeichnet den Treiber bei beiden Versionen als buggy. Was kann ich tun (außer der Auswechslung der PCMCIA-Karte)?

Grüße, Günther

[Gunman1982]

Kannst du vielleicht die Ausgabe von modprobe -v 3c574_cs posten mit dem neuen Kernel? Braucht keine proprietären firmware blob oder?

[guennid]

Das wird umständlich, denn das Maschinchen ist mein Router, und wenn ich den neustarte, habe ich je nach Kern weder lan noch I-Netz. Ich werd's machen, verspreche mir aber wenig davon.

Hier noch ein Phänomen. Wenn ich die Karte neu einsteckte, meldet udev(?), dass irgendwas den Kartenspeicher nicht "mappen" konnte ("... map card memory") und das kommt dann auch, wenn ich eine andere Karte (pcnet_cs) einstecke.

Was bedeutet eigentlich dieses "mappen"? dict.cc hilft mir da nicht wirklich weiter.

Grüße, Günther

[edit]: Es lohnt nicht, die Meldung irgendwie hierher zu transportieren. modprobe meldet lediglich den Vollzug des Befehls, keine weiteren Angaben.

[Gunman1982]

Was bedeutet eigentlich dieses "mappen"? dict.cc hilft mir da nicht wirklich weiter.

Das Speicheradressen auf nen Kartenspeicher zeigen. Adresse x01000 zeigt dann auf kartenspeicher-adresse x0000. Heisst also in dem Fall hier sowas wie, kann nicht auf internen Speicher der Karte zugreifen.

[guennid]

Heisst also in dem Fall hier sowas wie, kann nicht auf internen Speicher der Karte zugreifen.

Das war mir schon irgendwie klar. Aber dieser Begriff, "to map" wird ja dauernd von (IT-) Gott und der Welt verwendet. Ist wohl wieder so'n Begriff, der alles und ergo nichts bezeichnet. Aber die Diskussion sollten wir hier nicht führen.
Schau mal nach oben, mein edit und dein letzter Beitrag haben sich überschnitten.

Grüße, Günther

[Gunman1982]

Aber dieser Begriff, "to map" wird ja dauernd von (IT-) Gott und der Welt verwendet. Ist wohl wieder so'n Begriff, der alles und ergo nichts bezeichnet.

Öh naja, bezechnet schon recht eindeutig etwas: http://de.wikipedia.org/wiki/Memory_mapping

Aber die Diskussion sollten wir hier nicht führen.
Schau mal nach oben, mein edit und dein letzter Beitrag haben sich überschnitten.

Naja ohne weitere Anhaltspunkte bin ich auch mit meinem Latein am Ende, hab die Karte nicht hier und auch kein 2.6.39 laufen da mein alter Testrechner ab allen Kernel >2.6.27 panisch wird. Naja, ich schätze dmesg und /var/log hast du konsultiert? Vor dem modprobe brav ein modprobe -r gemacht? Vielleicht 3.0/1/2er Kernel probieren? Oder in den mailinglists/bugtrackers schaun ob 3c574_cs auftaucht.

[guennid]

So, habe mal eben die Kompilation eines 3.3.4er probiert. Das Modul wird geladen, aber ifconfig zeigt nur lo. im Übrigen: same procedure. In der messages steht das hier. Ich denke, es liegt an den neueren Kernen. Fehlt ein Modul, ist eins zuviel da?

Muss in /etc/pcmcia/config.opts was getan werden?

Und so sieht messages bei dem 36er Kern aus, der funktioniert.

Grüße, Günther

[Gunman1982]

Könntest dir mal die debian std config nehmen und mit der bauen um zu schaun ob das vielleicht anner fehlenden option in der conf hapert.

[guennid]

Ja, ging mir auch schon durch den Kopf! Wie heißt das Kommando für make-kpkg, wenn eine initrd mitgebaut werden muss?
Aber ca. 50 Mb-Kern auf dem Maschinchen, mit allem sound-Geraffel und, und ... da dreht sich mir der Magen rum. Außerdem würde ich alles Neue eh durchwinken, weil ich wohl eh nicht weiß, was es soll.

Grüße, Günther

[Gunman1982]

Ja, ging mir auch schon durch den Kopf! Wie heißt das Kommando für make-kpkg, wenn eine initrd mitgebaut werden muss?

öh kann ich dir grad auch nicht sagen

Aber ca. 50 Mb-Kern auf dem Maschinchen, mit allem sound-Geraffel und, und ... da dreht sich mir der Magen rum. Außerdem würde ich alles Neue eh durchwinken, weil ich wohl eh nicht weiß, was es soll.

Grüße, Günther

Naja das liesse sich ja zur Not noch bei menuconfig recht einfach ausknipsen, sollte aber eh als modul gebaut werden also wäre es ja nicht soooo schlimm oder?

Ich hab grad nochmal die beiden logs durchgeschaut, der einzige Unterschied scheint sich hier zu ergeben:
2.6.36.2:

Code: Alles auswählen

May 23 17:05:01 router kernel: pcmcia_socket pcmcia_socket1: cs: memory probe 0x0c0000-0x0e3fff: excluding 0xc8000-0xcbfff 0xce000-0xcffff excluding 0xcc000-0xcdfff 0xd2000-0xd3fff

3.3.4:

Code: Alles auswählen

May 23 08:14:16 router kernel: pcmcia_socket pcmcia_socket1: cs: memory probe 0x0c0000-0x0e3fff: excluding 0xc4000-0xc5fff excluding 0xc8000-0xc9fff 0xc6000-0xc7fff

Ich hatte irgendwo beim Suchen gelesen das du über die opts die exluding ranges übergeben kannst. Vielleicht das vor dem Neubauen testen?

[Cae]

Ja, ging mir auch schon durch den Kopf! Wie heißt das Kommando für make-kpkg, wenn eine initrd mitgebaut werden muss?

Code: Alles auswählen

make-kpkg --initrd --append-to-version=-foo -j 8 kernel_image kernel_headers

steht dafür in meiner History und wahrscheinlich auch in der Manpage. -j sind die Threads und --append-to-version wird an den Namen angehängt, zur Unterscheidung zu normalen Kerneln.

Gruß Cae

[guennid]

Ich mach das viel einfacher:

Code: Alles auswählen

make-kpkg revision=dingsbums linux-image

fertig. revision= ist auch noch optional. Welche threads? Was will ich mit den headers?

Gehe ich recht in der Annahme, dass NUR --initrd für den Bau der initrd zuständig ist?

Grüße, Günther

[Gunman1982]

fertig. revision= ist auch noch optional. Welche threads?

Mehrere threads beschleunigen das backen auf nem Multicore Rechner.

Was will ich mit den headers?

Extra Packet wenn du nicht das ganze src Verzechnis auf dem Rechner lassen willst und irgendwann nochmal nachträglich ein Kernel-Modul kompilieren musst.

[towo]

Und auf make-kpkg kann man auch verzichchten, aktuelle Kernel kennen schließlich das target deb-pkg, somit baut

make -jN deb-pkg

ganz tolle debs des Kernels.

[guennid]

Viele Wege führen nach Rom, zugegeben, aber bei mir regt sich der Verdacht, ob nicht einige redundant/Spielwiese sind. Konkret: Wo ist der Vorteil von

Code: Alles auswählen

make -jN deb-pkg

gegenüber

Code: Alles auswählen

make-kpkg ...

?

Nochmal die Frage von oben: Wie baut man einen Kern mit initrd?

Code: Alles auswählen

make-kpkg --initrd --revision=dingsbums linux-image

lief fehlerfrei durch, aber bei der Installation wurde mitnichten ein initrd.img erzeugt.

Grüße, Günther

[TRex]

Viele Wege führen nach Rom, zugegeben, aber bei mir regt sich der Verdacht, ob nicht einige redundant/Spielwiese sind. Konkret: Wo ist der Vorteil von

Code: Alles auswählen

make -jN deb-pkg

gegenüber

Code: Alles auswählen

make-kpkg ...

?

make-kpkg == extra-Paket. make deb-pkg == builtin eingebaut

[guennid]

make deb-pkg == builtin

sagt mir nichts.

Aber wichtiger: Wie baue ich mit make-kpkg einen kernel mit initrd und wie installiere ich ihn? Ich habe die config des sqeeze-Standard-Kerns genommen, außer der Abwahl von sound und multimedia nichts verändert. Beim Installieren des debs wurde kein initrd.img unter /boot erzeugt. Ich habe in neun Jahren Debian schon etliche Kerne, aber noch nie einen mit initrd.img gebaut.

Das Kompilieren hat ca. 3 1/2 Stunden gedauert (bei dem bisschen, das ich wirklich brauche, geht das in einer halben Stunde). Das möchte ich mir nicht unbedingt öfter antun, zumal ich eigentlich nur prüfen will, ob bei dieser Ausgangsbasis (config des sqeeze-Standard-Kerns) der pcmcia-Kram mit Kernen > 2.6.36 funktioniert.

Grüße, Günther

[TRex]

Ich habs umeditiert auf deutsch..

[Gunman1982]

Ja ubuntu is the devil aber ich bin faul und will mich jetzt nich auch noch durch ~75000 google treffer klicken:
http://forum.ubuntuusers.de/post/2531680/

[guennid]

@Gunman1982

ich [...] will mich jetzt nicht auch noch durch ~75000 google treffer klicken:

Heißt das jetzt, dass das eigentlich mein Job gewesen wäre? Zur Erinnerung: Eigentlich will ich nur 16 bit-PCMCIA-Karten mit einem aktuelleren Kern als 2.6.36 zum Laufen bringen. Eine initrd benötige ich einmalig lediglich, weil ich, deinem Vorschlag folgend, die config des Standard-Kernels zu Testzwecken beim Kernelbauen benutzen will, um den Fehler in meinen eigenen configs zu entdecken.

Unter dem Ballastwust des verlinkten Threads meine ich folgendes erkannt zu haben:
Ich erstelle einen neuen Kern, so wie o.a. also:

Code: Alles auswählen

make-kpkg --initrd --revision=dingsbums linux-image

und installiere ihn (z.B. via dpkg -i). Dieser Kern bootet noch nicht, deswegen boote ich mit einem anderen, funktionierenden Kern und erstelle anschließend mit

Code: Alles auswählen

update-initramfs -ck [kernel-Versions-Nummer]dingsbums

die initrd.img für den neu gebauten? Anschließend sollte der neue Kern booten. Habe ich das richtig verstanden?
Und wie kommt es, dass man den Standard-Kern als deb installieren kann und initrd.img dabei automatisch miteingerichtet wird, bei meiner Vorgehensweise aber nicht?

@TRex
Die Übersetzung war nicht das Problem. Soviel Englisch kann ich. Eingebaut wo hinein? Wird der nicht nur kompiliert, sondern auch installiert? Macht der die update-initramfs-Geschichte überflüssig (sofern mit initrd kompiliert), von der gunman spricht? Verhält das deb(?) sich also wie das deb eines Standard-Kerns aus den debian-Repos? Oder wie, oder was? Auch der deutsche Brocken macht mich da eigentlich nicht schlauer.

[Gunman1982]

@Gunman1982

ich [...] will mich jetzt nicht auch noch durch ~75000 google treffer klicken:

Heißt das jetzt, dass das eigentlich mein Job gewesen wäre? Zur Erinnerung: Eigentlich will ich nur 16 bit-PCMCIA-Karten mit einem aktuelleren Kern als 2.6.36 zum Laufen bringen. Eine initrd benötige ich einmalig lediglich, weil ich, deinem Vorschlag folgend, die config des Standard-Kernels zu Testzwecken beim Kernelbauen benutzen will, um den Fehler in meinen eigenen configs zu entdecken.

War primär bezüglich des Ubuntu links gemeint, mit einem gewissen Augenzwinkern.
Es stimmt allerdings das es mich verwundert das ich so leicht eine mögliche Antwort auf deine Frage wie man einen initrd erstellen könnte gefunden hab. Und wie es scheint sinds ja auch nicht wenige mögliche Antworten bei ~75000 Treffern.
Und JA ich gehe davon aus das wenn jemand ein Problem hat dieser wenigstens zeitgleich eine Suchmaschiene seiner Wahl benutzt um eine Lösung zu finden und nicht die Frage im Forum stellt OHNE auch nur mal kurz in die man page zu schaun ob vielleicht beim make-kpkg drin steht das --initrd ohne händische Arbeit nichts macht.

Übrigens, wenn dir der Vorschlag nicht gefällt einen aktuellen Kernel zu testen oder es dir zu viel Arbeit bereitet steht es dir natürlich frei diesem nicht zu folgen. Ich stehe nicht mit einer Waffe hinter dir und zwinge dich zu irgendwas.

Unter dem Ballastwust des verlinkten Threads meine ich folgendes erkannt zu haben:
Ich boote mit einem funktionierenden Kern und erstelle anschließend mit

Code: Alles auswählen

update-initramfs -ck [kernel-Version]

die initrd.img für den neu gebauten? Habe ich das richtig verstanden?

Ich weiss ja nicht was dein bevorzugter Browser macht aber bei dem Link springt dieser bei mir auf den LETZTEN Eintrag in dem Thread. Wenn dir ein Beitrag bereits zu viel Ballast ist, naja ...
Ich kann das natürlich nochmal zusammen fassen:

Code: Alles auswählen

update-initramfs -ck VERSION
update-grub

VERSION= das was hinter deinem kernel bzw vmlinuz- steht .... also vmlinuz-VERSION

[guennid]

Bootloader ist lilo. Aber bitte jetzt nicht darüber diskutieren, der hat mit der Sache nichts zu tun und den weiß ich zu handlen.

So, 2.6.37.2er Kern mit initrd auf Basis der config des 2.6.32.5er Standard-Kerns gebaut und läuft - ohne PCMCIA-NICs.

Damit weiß ich jetzt wenigstens, dass das ganze initrd-Gerödel überflüssig war.

Ich stelle jetzt mal die config für meinen aktuellsten Eigenbau, den 3.3.4er Kern, gebaut auf der Basis des voll funktionierenden 2.6.36.2er Eigenbau-Kerns ohne initrd nach nopaste. Vielleicht findet da ja jemand den Fehler, warum meine 16bit-PCMCIA-NIC trotz geladenem Treiber 3c574_cs unter dem 3.3.4er Kern mit der weiter o.a. Fehlermeldung nicht läuft.
Es dürfte auch nicht am 3c574_cs liegen, denn die zweite PCMCIA-NIC mit xirc2ps_cs (einkompiliert und geladen) funktioniert genauso wenig

Grüße, Günther

[Gunman1982]

Bootloader ist lilo. Aber bitte jetzt nicht darüber diskutieren, der hat mit der Sache nichts zu tun und den weiß ich zu handlen.

So, 2.6.37.2er Kern mit initrd auf Basis der config des 2.6.32.5er Standard-Kerns gebaut und läuft - ohne PCMCIA-NICs.

Damit weiß ich jetzt wenigstens, dass das ganze initrd-Gerödel überflüssig war.

Könntest dir mal die debian std config nehmen und mit der bauen um zu schaun ob das vielleicht anner fehlenden option in der conf hapert.

Nimm doch bitte die standard config für den entsprechenden kernel. Oder installier mal einen Kernel aus den repos ohne den selber zu bauen. Wenn ein kernel "Von der Stange" funktioniert weisst du das es an der config liegt. Wenn er nicht funktioniert blieben nur noch die Möglichkeiten zu testen ab welcher Kernel version die pcmcia Karte nicht mehr erkannt wird, nochmal einen blick auf die speicherbereiche zu werfen und zu schaun ob man die wie in einem meiner früheren posts angedeutet angeben kann oder n bugreport schreiben.

[guennid]

Nimm doch bitte die standard config für den entsprechenden kernel

Das tu' ich doch die ganze Zeit. Ich habe das Gefühl, dass wir irgendwie aneinander vorbei reden. Der Standard-Kernel für squeeze ist 2.6.32.5. Der ist selbstverständlich installiert und funktioniert auch. Und nachdem ich mit meinen Eigenbau-configs nur is 2.6.36 kam, war der letzte Versuch, ausgehend von der "standardconfig" (2.6.32), einen 2.6.37er Kern zu bauen. Wie kann man den sonst "die standard config" verwenden?

Oder installier mal einen Kernel aus den repos

Läuft gerade, ich probier's gerade mit 'nem 3.2.er backport-Kern. Da krieg ich jetzt diese Meldung:

Code: Alles auswählen

Benötigte Firmware-Dateien möglicherweise nicht vorhanden                   
 │                                                                             
 │ Auf diesem System läuft derzeit Linux 2.6.36.2 und Sie installieren         
 │ gerade Linux 3.2.0-0.bpo.2-486. In der neuen Version könnten einige         
 │ Treiber, die auf diesem System verwendet werden, zusätzliche                
 │ Firmware-Dateien benötigen:                                                 
 │                                                                             
 │ pcnet_cs: cis/tamarack.cis, cis/PE-200.cis, cis/NE2K.cis, cis/PE520.cis,    
 │ cis/LA-PCM.cis, cis/DP83903.cis, cis/PCMLM28.cis                            
 │ serial_cs: cis/RS-COM-2P.cis, cis/COMpad4.cis, cis/COMpad2.cis,             
 │ cis/MT5634ZLX.cis, cis/SW_555_SER.cis, cis/SW_7xx_SER.cis,                  
 │ cis/SW_8xx_SER.cis, cis/3CXEM556.cis, cis/3CCFEM556.cis,                    
 │ cis/DP83903.cis, cis/PCMLM28.cis

Abgesehen von pcnet_cs, den ich vielleicht mal brauchen könnte, aber momentan nicht, sehe ich nicht, dass ich betroffen wäre.

...blieben nur noch die Möglichkeiten zu testen ab welcher Kernel version die pcmcia Karte nicht mehr erkannt wird

Ja, da bin ich doch die ganze Zeit dran!

Grüße, Günther

[guennid]

Es sieht so aus, als hätte ich es.
Der Router ist ein Uralt-Schlepptopp: von ca. 1997 Toshiba Portégé 660CDT. Der sollte zwar damals als einer der ersten Schleppis 32bit-PCMCIA (auch Cardbus genannt) können, aber das hat hier (mit drei von den Teilen) wegen der entsprechenden Bios-Einstellung (Cardbus/16bit) nie funktioniert. Sobald eine 32bit-PCMCIA-NIC da dran hing, hängte sich die Maschine unter Last auf. Ich musste immer PCIC im Bios und dann im Linux-Kern i82365 für 16bit-PCMCIA wählen. Siehe hier Das hat bis Kernel 2.6.36 funktioniert. War da nicht was mit einer einschneidenden Veränderung ab Kernel 2.6.37?

Offenbar tut das Teil mit neueren Kernen jetzt mit yenta-socket. Die 16bit-Karten werden jetzt korrekt eingerichtet. Wenn ich Zeit habe, werde ich mal testen, ob 32bit-PCMCIA jetzt auch funktioniert.

Grüße, Günther