| Thread Previous • Date Previous • Date Next • Thread Next |
Ahoj On 6.7.2011 13:31, Jirka Michalec wrote:
Konečně se mi též podařilo nabootovat na reálném HW a testovat tam.
Super :-)
Z celkem pěti karet, které mám k dispozici, byly 4 detekovány a přiřazeny ke správnému driveru, jedna nikoliv (zřejmě používá jiné vendor ID a device ID, bohužel toto už ve výpisu do kernel console není, ale čekám, že až tyto informace do výpisu přidám, zbývající kartu rychle zprovozním).Ve zdrojáku 8139too.c (viz např. http://lxr.free-electrons.com/source/drivers/net/8139too.c ) jsou i další vendor/device id od jiných výrobců, možná by stálo za to je přihodit do match file.
Všechny detekované karty vykazují naprosto stejné chování (alespoň v rámci testovaných funkcionalit): po startu funguje přijímání i odesílání packetů (broadcast i unicast), nefunguje změna MAC adresy (přijímají stále na původní) a po změně bcast modu přestane přijímat úplně (změny ostatních jsem zatím nezkoušel), v QEMU vše zmíněné funguje správně.Nemožnost změny MAC bychom asi přežili (možná to někde bude prostě hardwareově zakázáno, nedivil bych se), nicméně ty módy to chce opravit.
V QEMU jsem stále nedokázal zprovoznit periodický polling, on_demand funguje správně, stejně jako přijímání pomocí přerušení.Koukal jsi se do zdrojáků qemu, jestli to tam vůbec je implementováno? Třeba na NE2000 lze změnit MAC adresu dvěma způsoby (přímý zápis do registrů pro MAC nebo remote DMA transfer), nicméně funguje jenom ten druhý. Ovšem
Rýpavý dotaz: zkoušel jsi už, jak funguje autonegotation? To jsme neměli možnost testovat na qemu...Dále budu pracovat na odstraňování chyb a uváděním všech karet do správně fungujícího stavu.
Fajn, taky souhlasím a jestli jsme se na podobném způsobu už dříve dohodli, tak tím lépe. Jde tam o to, že se volá as_get_mappable_page() (které zjistí nějakou nepoužívanou stránku virtuální paměti) a následně s async_share_in_start() s touto pamětí. Pokud se mezi tím ta paměť použije (namapuje) jinde, tak async_share_in_start() vrátí ENOMEM.A mám taky jednu otázku ohledně designu: ve funkcích ohledně alokování packetů je race, který způsobuje, že občas se prostě nepodaří naalokovat packet, ačkoliv možné to je (ještě nedošla paměť). Zamykat by to ani nešlo a v podstatě to není problém - otázkou ale je, jestli to má řešit knihovna (cyklit, dokud se nepodaří naalokovat), uživatel (dostane chybu, že se nepodařilo alokovat, ať si dělá co chce) nebo jestli to zkusit třeba 8x v cyklu naalokovat a když se to nepodaří ani jednou, tak teprve tehdy vrátit chybu. Já bych byl pro to poslední řešení, co vy na to?Můžeš se trochu více rozepsat o tom, kde ta race je, příp. ve kterých funkcích se projevuje (jde-li o race na straně packet serveru či driveru)? Jedna race je v dma_allocate_anonymous (při volání ze dvou vláken mohou obě najít stejnou volnou virtuální adresu, avšak vytvoření mapování se povede jen jednomu) - o tom jsem už mluvil na jedné ze schůzek, když jsme DMA řešili, a shodli jsme se, že finální řešení bude v případě neúspěchu několikrát zopakovat postup a vrátit neúspěch až poté (ale zdá se mi, že to zapadlo). V tomto případě by šlo i zamykat, ale jen globálním zámkem v celé DMA knihovně (což ale nepomůže při současném volání jiných funkcí alokujících paměť mimo DMA knihovnu), rozumnější mi opravdu přijde zkusit několik pokusů. Na druhou stranu je otázkou, zda-li má opravdu tato funkce myslet na možnost více vláken volajícího nebo si to má volající zajistit sám. Co se alokace packetu týče - IMO typycká aplikace (driver) poběží v několika vláknech a tudíž by tyto funkce měly s více vlákny počítat a snažit se to rozumně řešit. Poslední zmiňované řešení se mi též líbí nejvíce, v takovém případě by bylo dobré odlišit návratový kód "opravdu není paměť" od "nastal race, příště se to možná podaří" - otázkou ale je, jestli je toto schopen framework rozlišit, např. dma_allocate vrací v případě neúspěchu ENOMEM nehledě na důvod.
Radim
| Thread Previous • Date Previous • Date Next • Thread Next |
