Wo geht man auf die Suche nach unbekannten Gerätretreibern?

[kurzschluss]

Es ist mir jetzt schon ein paarmal passiert, dass ich eine Linux Distribution installiere und ein Gerät, das ich namentlich kenne, erscheint als unknown device.

Vor kurzem nervte mich so ein ATL1 Gigabit Ethernet Controller damit, derzeit gehe ich wieder auf die Suche nach einem Treiber für einen MARVELL MV 6121 SATA Controller.

Bei meiner letzten Anfrage nach dem atl1 sagte man mir: Installier doch einfach den oder den Kernel, da ist das schon drin. Toll. Woher wissen die das?

Ich würde gern einmal wissen, wo ihr sucht, wenn ihr ganz allgemein so ein Problem habt. Das googlen führt nämlich meist nur auf irgendweche Links mit Motherboards, die das Teil verbaut haben.

Okay, und falls jemand zufällig eine URL mit einem Source für meinen marvell Controller kennt, wäre das natürlich jetzt auch nicht soooo schlecht ...

[rockpommel]

Hi
Um dir effektiv helfen zu können, wäre es ganz gut, ein paar Daten zu kennen,
z.B. welche Distribution, Board usw.

Beim googlen habe ich folgendes gefunden:

http://en.opensuse.org/Hardware

gib hier mal marvel ein und du wirst sehen, dass er einiges findet.

Sicher ist, dass opensuse offensichtlich schon sehr viele Probleme mit Marvel kennt und dass eine Installation nicht ganz einfach ist.

Poste doch mal deine Daten!!!!!!!!!!!

Gruß rockpommel

[kurzschluss]

Keine Suse. Debian etch 40r1 und gentoo zum Beispiel. Beide kennen weder atl1.ko noch den wie immer lautenden Marvell Treiber.

Die Unterstützung der Boardhersteller ist poor. Nehmen wir zB. Asus. Da gibt es atl1 Treibersources, die lassen sich aber nicht kompilieren. MSI ist auch nicht der Hit bei der Treiberunterstützung für Linux. Die Chiphersteller selbst sind auch nicht das Sahnehäubchen. Marvell stellt ganze Modellreihen von irgendwelchen Chips für Festplatten her. Aber geh mal auf deren Webseite, und gib Drivers unter Linux an. Da kannst du zwar 1000 Unix-Varianten auswählen, aber außer einem YUKON Treiber kommt nix.

Okay, OpenSuse ist Vorreiter bei der Unterstützung solcher Hardware. Die 10.3 scheint sowohl den Marvell zu kennen als auch die atl1.

Nur hilft mir das bei einer debian oder gentoo nicht wirklich weiter.

Das sollten auch alles nur Beispiele sein.

Ich möchte generell wissen, wo ich effizient auf Treibersuche gehen kann, wenn ich - welche Distribution auch immer - habe, und für meinen neuen, dort verbauten SATA, Sound, Ethernet-Treiber gibt es nichts außer der Möglichkeit, den Namen der verbauten Hardware festzustellen.

Das ist heute Marvell, und in einem halben Jahr irgendeine andere Hardwareklitsche, die irgendwas Hübsches in Chipform auf meinem Motherboard verbaut hat ...

Wo geht man dann suchen? (Der Marvell MV 6121 oder ATTANSIC ATL1 waren halt nur gute Beispiele)


Sorry wenn diese Frageintention nicht sofort rüberkam ....

[MiGo]

Wo geht man dann suchen? (Der Marvell MV 6121 oder ATTANSIC ATL1 waren halt nur gute Beispiele)
Es hilft schon mal sehr, wenn du nicht nach der Hardware selbst sondern nach den verbauten Chipsätzen suchst - selbige siehst du unter Linux z.B. mit "lspci".

[fubar]

Bei meiner letzten Anfrage nach dem atl1 sagte man mir: Installier doch einfach den oder den Kernel, da ist das schon drin. Toll. Woher wissen die das?


Da kann ich echt nur zustimmen. Mir fehlt da auch die Intelligenz zur Autodidaktik. Nichts desto Trotz, konnte ich durch die Suchfunktion, der Mailingliste von www.kernel.org, immer wieder hilfreiche Informationen beziehen.

Gruss Peter

[kurzschluss]

Gehen wir doch einmal der Reihe nach. Jetzt habe ich meinen Chipsatz, weiss auch wie mein Gerät heisst, und sagen wir mal auf meiner etch schlummert jetzt ein Kernel 2.6.18-5. Und das Netzwerk-Gerät oder das Marvell Teil ist immer noch der etch unbekannt.

Was soll ich jetzt bitte auf kernel.org? Mir die patchfiles für den Source so lange runterladen, bis ich beim letzten angelangt bin in der Hoffnung, es hat vielleicht schon einer eine Treiberunterstützung eingebaut? Selbst wenn das der Fall ist, wie hilft mir das denn weiter? Soll ich dann so lange irgendwelche modprobes auf Verdacht aufrufen, bis mein Gerät nicht mehr unbekannt ist (und wieso erinnert mich das jetzt irgendwie an Windows...) ?

Das kann es doch irgendwie auch nicht sein.

Ich verstehe nicht, wieso die Frage so kompliziert sein soll.

Jetzt sagt mir mein lspci, welche via Host Bridge ich habe,
und ich kenne jetzt alle Geräte, chipsets etc. Das war ja auch nicht das Problem. Ich weiss ja, da ist ein Marvell 6121 drin ...

Und was jetzt? Was hilft mir das, um an meinen Marvell oder Attansic Treiber zu kommen? Wo gehe ich jetzt suchen (was die Eingangsfrage war) ?

[almoeli]

Hallo,

willkommen in der Welt der freien Software. Dort gibt halt nur die Software bzw. Treiber, die irgend jemand mal programmiert hat, weil sich die Firmen ja meistens nicht darum kümmern.
Deshalb gibt es für Linux auch nur die Treiber, die irgend jemand aus der Community mal gebraucht hat und sich die Mühe gemacht hat den zu programmieren. Ist der Treiber gut und stabil, schafft er es in den Kernel.
Wenn nicht, so bleibt meistens als externes Projekt irgendwo im weiten Internet und evtl. über Google oder diverse Foren zu finden.

Also Schlussfolgerung:

1. Nur weil du weißt wie genau deine Hardware heißt, gibt es nicht zwangsweise einen Treiber dafür.

2. Neuere Kernel könnten einen Treiber enthalten als der gerade verwendete. Dazu Kernel von Kernel.org runterladen und in den Quellen nach Spuren deiner Hardware suchen (grep und ein paar Programmiererkenntnisse vorausgesetzt). Ist ein Treiber drin, dann den neueren Kernel einsetzen.

2. Es könnte einen Treiber geben, der aber nicht im Kernel enthalten ist. Dann hilft nur suchen und mit viel Aufwand den externen Treiber für deinen Kernel übersetzen (oft sind die Treiber auch nur für bestimmte Kernel verfügbar.).

Die Hardware-Datenbank von SuSe ist aber schon mal ein guter Startpunkt um zu sehen, ob es evtl. überhaupt einen Treiber für die Hardware gibt.

Gruß

almoeli

[tictactux]

Hi Kurzschluss,

Und was jetzt? Was hilft mir das, um an meinen Marvell oder Attansic Treiber zu kommen? Wo gehe ich jetzt suchen (was die Eingangsfrage war) ?
Um konkret bei Deinem Debian Etch zu bleiben:
- um herauszufinden ob die von Debian verwendeten (recht betagten) Default-Kernel eine spezielle Hardware unterstützen, würde ich das Paket linux-doc-x.y.z zu dem vorhandene Kernel installieren (falls nicht schon die Kernelquellen installiert sind).
Aktuell hieße das Paket linux-doc-2.6.18 für Debian Etch.
- bei installierten Kernelquellen wäre obiges unter /usr/src/linux-source-2.6.18(-x) zu finden.
Dort findest Du für die meisten unterstützten Geräte die letztendlich aktuellste Dokumentation- und falls da keine ist, blieben die Verzeichnisse im Kernel-source, die oft auch Dokumentation enthalten.

Falls der verwendete Kernel zu alt ist für die Hardware, könntest Du z.B. versuchen einen Kernel aus den Backports zu verwenden (aktuell 2.6.20-xx).
Dazu wäre in /etc/apt/sources.list z.B.

deb http://www.backports.org/debian etch-backports main contrib non-free
einzutragen, um den Kernel dann mit den üblichen Paketmanagern verfügbar zu haben.
HTH
Wolfgang

[rockpommel]

Hi
Deine Frage nach der grundsätzlichen Suche kann ich nicht beantworten.
Nur kann ich sagen, dass das googeln mich immer weiter gebracht hat. Manchmal dauert es eben länger.
Leider bin ich nicht so gut der englischen Sprache mächtig, auch stehe ich was Linux betrifft, erst am Anfang.
Jedoch glaube ich, dass ich einen interessanten Bericht zu deinem Problem gefunden habe. Vielleicht hilft er ja weiter!
/
Enter your search termsSubmit search formWeblkml.org
Date Fri, 03 Aug 2007 12:09:40 -0400
From Jeff Garzik <>
Subject libata git tree, mbox queue status and contents
Digg This

This is a quick guide to current libata work that is queued or in
progress in some way, shape or form.

First, a guide to the branches currently in use in
git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git

ALL

Everything that is exported for testing (and akpm's -mm tree).
Currently consists of upstream-fixes + upstream + sil680-mmio branches.


master

Vanilla upstream linux-2.6.git tree.


mv-ahci-pata

Marvell 6121/6141 PATA support. Needs fixing in the 'PATA controller
command' area before it is usable, and can go upstream.


mv-ncq

sata_mv NCQ support. Code is complete and /should/ be working, but it
does nothing but timeout and fallback to non-NCQ here. Needs debugging
before can go upstream.


new-eh

Convert sata_qstor and sata_sx4 to new EH. Each needs
testing/verification before it can go upstream.


pmask

Add proto_mask to LLDDs, alongside pio_mask, udma_mask, etc.


sii-lbt

Enable Large Block Transfer mode on sata_sil. Verified to work locally,
but some bug reports on the 'net need to be tracked down before this can
go upstream.


sil680-mmio

BenH's MMIO patch for pata_sil680. Some MMIO/flushing type issues were
raised on the list, a solution was reached. That solution must be coded
before this can go upstream.


upstream

Everything queued for 2.6.24. Includes everything in upstream-fixes.


upstream-fixes

Everything queued for 2.6.23-rc. This tends to go upstream rapidly.




mbox queue, prefixed by author:

* Kristen: ALPM patches. We definitely want them, as they save a ton of
power.

* Tony Vroon: LED trigger.... hmmm
* Alan: IORDY handling -- upstream whenever Alan is happy

* Tejun: improved probe info printout. Want to test and review in
depth, but probably OK

* Alan: ACPI checks for 80wire cable -- upstream whenever Alan is happy

* Tejun: Port Multiplier Support -- I still need to review in depth,
but would like go ahead and push ata_link in

* NVIDIA: sata_nv SW NCQ: need to review WRT FIS state machine, though I
saw some flaws in there. OK if that is OK.

* Albert: irq_on/off. Really need to give this some thought. Not sure
I like where this model is going. Polling and twiddling irq on/off
should be kept to a minimum, because it's sorta an admission that the
host state machine has broken down, and we need to bandaid. Its a
bandaid not a root-cause solution.

* Albert: minor PIO fixes. Need to review in depth.

* Kristen: AN: it seems that things got stuck once Al Viro voiced an
objection?

* Ben Collins: cleanup HPA support. Need to review and see what's
needed today, from this patch.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
ISP Services
Valid XHTML 1.0! \

gefunden habe ich dies hier:

http://robilad.livejournal.com/16780.html
und
http://lkml.org/lkml/2007/8/3/183

Viele Grüße

rockpommel

[kurzschluss]

Hi Kurzschluss,

Um konkret bei Deinem Debian Etch zu bleiben:

Falls der verwendete Kernel zu alt ist für die Hardware, könntest Du z.B. versuchen einen Kernel aus den Backports zu verwenden (aktuell 2.6.20-xx).
Dazu wäre in /etc/apt/sources.list z.B.

deb http://www.backports.org/debian etch-backports main contrib non-free
einzutragen, um den Kernel dann mit den üblichen Paketmanagern verfügbar zu haben.
HTH
Wolfgang

Das mit den backports war mir neu, das kannte ich noch nicht. Sind die dann vom Typ "stable" ? Die Doku und sources hatte ich schon heruntergeladen. Aber da steht halt nichts drin, weil die Geräte von diesem Kernel nicht unterstützt werden.

[tictactux]

wie auf der Eingangsseite http://www.backports.org/ erwähnt, handelt es sich dabei um Pakete aus Testing und unstable, die für Stable compiliert wurden.