x86 kernelmodul használata amd64-es rendszeren

Ubuntu Linux

Sziasztok!

Olyan problémám van, hogy a webkamerámat nem tudtam sehogysem működésre bírni.
http://www.sonix.com.tw/sonix/product.do?p=sn9c201
Tegnapelőtt azonban kiadtak egy zártforrású kernelmodult hozzá, x86 architektúrára.
http://www.linux-projects.org/modules/mydownloads/
Nekem azonban amd64-es ubuntu feistym.
Próbálkoztam dpkg --forche-architecture -val, működött is, csak a modprobe-nál a következőt írja ki:

FATAL: Error inserting sn9c20x (/lib/modules/2.6.20-16-generic/kernel/drivers/media/video/sn9c102/sn9c20x.ko): Invalid module format

PLS HELP

  • 1163 megtekintés

( uid_4672 | 2007. 08. 01., sze – 09:59 )

benne van az FAQ-ban, hogy closed-source, x86-ra van fordítva, az x86-64-es használatot el lehet felejteni.

( bastya_elvtars | 2007. 08. 01., sze – 13:05 )

Gondolom, 4+ giga RAM van a gépedben, vagy más miatt volt muszáj amd64-es rendszert fölrakni.
It doesn't matter if you like my song as long as you can hear me sing

Ha 20%-kal gyorsabb (wines) DivX-enkódolásért cserében ilyenekkel akar szopni, hogy a hardvereit nem tudja pl. használni, lelke rajta. Egyébként a 64 bites Ubuntu desktop lassabb, mint a 32 bites, a HUP-on is volt cikk erről.
It doesn't matter if you like my song as long as you can hear me sing

( skateman | 2007. 08. 01., sze – 15:41 )

Most mié kell szemétkedni? :D
Mit tudtam én h mi a különbség az amd64 meg x86 között, amikor felraktam az ubuntut :)
Ezek szerint nincs gond, ha x86-os fut Turion64 procival?

--SkatemanJoe--

amd64-es platformon vannak még gondok (értsd: az amd64 még nem ért meg a desktopra). Ilyenek pl. a flash (nspluginwrapper-rel meneget), java plugin (még solarisra sincs 64 bites java plugin), egy csomó closed source program (kell cipelni a 32-bites libeket, hogy fussanak)-

32-bites disztró rendesen fut 64 bites procin, sokszor gyorsabb a 32 bites kód mint a 64 bites. És 32 bites pointerekkel memóriát is kevesebbet használ egy program.

És 32 bites pointerekkel memóriát is kevesebbet használ egy program.

És ezt így hogy? Mondjuk a pointerek tarolasa a memoriaban valoban fele annyi helyet igenyel 32 biten, de azert a memoriaigenyes programok nagy valoszinuseggel nem a qvasok pointer tarolasara igenyelnek annyi memoriat.

"És ezt így hogy?"

édes fiam, ha okoskodni akarsz, akkor menj a flame kategóriába.
Minden program használ pointereket, továbbá az sem elhanyagolható, hogy néha a 64 bites fordító 64 bitre alignol.
pl:

struct korte {
int a;
int c;
};

erre azt mondja a gcc nálam, hogy 8 byte. Viszont erre:

struct alma {
int a;
long b;
int c;
};

már azt mondja, hogy 24 byte.

És ez nem pointerekről szól.

édes fiam, ha okoskodni akarsz, akkor menj a flame kategóriába.

Hat nekem ez tunik az elso flame gyanus mondatnak ebben a threadben. Raadasul ha az edes fiad lennek valoszinu mar nem elnel. Hogy a vegelgyengules vitt volna el vagy mas, azt most hagyjuk...

Minden program használ pointereket, továbbá az sem elhanyagolható, hogy néha a 64 bites fordító 64 bitre alignol.

Mivel a fenti megszolitas utan feljogositva erzem magam -

Kedves Apu!

Egyreszt talan jarj utana egy atlagos c/c++-ban megirt program adatainak hany szazaleka pointer. Enelkul ez az erv a blabla kategoriaba sorolando.
Masreszt a fordito annyira alignol amennyire mondod neki hogy alignoljon. Sok adatot memoriaban tarolo programot nyilvan optimalizalunk ilyesmire is.
Harmadreszt illett volna nem architektura fuggo meretu integereket hozni peldanak es/vagy nem egy szem platformon egy szem forditoval megnezni.

De bisztos csak okoskodom, Apu.

Mely tisztelettel, es hodolattal:

"Edes fiad"

P.S.: En is megmondhatom Te hova menj?

nem kell felkapni a vizet, de tényleg elég sok ellentmondás van abban, amit mondtál.

"Egyreszt talan jarj utana egy atlagos c/c++-ban megirt program adatainak hany szazaleka pointer. Enelkul ez az erv a blabla kategoriaba sorolando."

Nagyon sok pointert használ. Erről szól a C++, látom sokat nem programoztál C++-ban. Amúgy meg épp azt próbáltam ecsetelni, hogy nem csak a pointerek miatt lesz nagyobb egy 64-bites kód.

"Masreszt a fordito annyira alignol amennyire mondod neki hogy alignoljon."
Talán te nézz utána annak, hogy hány átlagos program mondja meg a fordítónak, hogy mennyire alignoljon. Általában az ilyesmibe nem jó beleszólni, csak ha ez indokolt. Akik a fordítót írták, azok nem hátulgombolósban járó programozók.

"Harmadreszt illett volna nem architektura fuggo meretu integereket hozni peldanak es/vagy nem egy szem platformon egy szem forditoval megnezni."

lol, ez no comment. x86-64 vs x86 threadben szerinted miért különös amd64-es példát felhozni? és történetesen amd64-es gépem van.

p.s.: ez egy szabad ország

nem kell felkapni a vizet,

Ostoba es otromba modon szoltal valakihez "kisfiam"-mal akinek fogalmad nincs a korarol. Mondjuk ebbol nagyjabol mar sejtem, hogy ez a relacio nagyjabol forditva lehet igaz.

de tényleg elég sok ellentmondás van abban, amit mondtál.

Es ez mar elegseges indok hogy egy nyegle kamasz modjara viselkedj?!

Nagyon sok pointert használ. Erről szól a C++

Ezt beszerd meg mondjuk Stroustrouppal, hagy legyen neki is par vidam perce. Ha ugy gondolod hogy ezek a nyelvek a pointerekrol szolnak, ketsegbeejto mennyire nem erzed oket. Ha C++-ban tul sokat kell valodi pointert hasznalnod, nem lehetsz nagy stl magus... ( az iterator NEM pointer )

látom sokat nem programoztál C++-ban

Hat 16-18 ev C/C++ (adj meg hozza ugy 5 ev assembly-t) es millio folotti kodsor valoban eltorpulhet a Te minden bizonnyal nagysagrendekkel nagyobb tapasztalatod mellett (es mar megint anelkul felteteleztel valamit rolam, hogy halvany lila dunsztod is lehetett volna a valosagrol)

Amúgy meg épp azt próbáltam ecsetelni, hogy nem csak a pointerek miatt lesz nagyobb egy 64-bites kód.

Amire en valaszoltam is, hogy miert nincs igazad.

Talán te nézz utána annak, hogy hány átlagos program mondja meg a fordítónak, hogy mennyire alignoljon

Nagyjabol az osszes ami torodik azzal hogy ne csak rammal telepakolt rendszereken fusson (pl aminek beagyazott rendszereken is futnia kell)

Általában az ilyesmibe nem jó beleszólni, csak ha ez indokolt. Akik a fordítót írták, azok nem hátulgombolósban járó programozók.

Altalaban nem jo ha egy programozo hasznalja az agyat mert a vegen meg nem tudnak a ram gyartok kinek memoriat eladni. Amugy meg az eonokban merheto c/c++ tapasztalatoddal tudhatod hogy alapvetoen egy strukturaban levo tagok sorrendjenek meghatarozasaval is befolyasolhatod hogy az alignment miatt mennyi memoria pazarlodik el. egy egy vagy 2 bajtos valtozonal meg nyugodtan igazithatsz egy vagy 2 byte-os cimre manualisan is akar, nem lesz tole semmi lassabb. De en ehez biztos hatulgombolos vagyok. Ja amugy esetleg ha erdekel a tema gondold vegig a memoria es a proci kozott hany byte mozog egyszerre. mem->L2->L1->CPU. Hiaba huzol be egy byte-ot a rambol, a proci amd64 eseteben 64 byte-ot fog berantani a cache-be. (ez az ugynevezett cache line size) Szoval abban valoban egyetertunk hogy hatulgombolos programozo nem biztos hogy jo ha babral az alignmentel, de aki tudja mit miert csinal az sokkal jobban el tudja donteni adott esetben mi lesz a jo mint a compiler. (jo, nem art kis gyakorlat hozza assembly-ben)
Amugy meg a compiler sem hulye, nezd meg a kovetkezo peldat: 


#include <iostream>
using namespace std;

struct SA
{
 char a;
 char b;
 char c;
 char d;
};

struct SB
{
 char a;
 intptr_t b;
 char c;
 char d;
};

int main( int argc, char **argv )
{
 cout << sizeof( SA ) << endl << sizeof( SB ) << endl;
 return 0;
}

az elso struktura bizony-bizony 4 byte meretu lesz alignment ide vagy oda. a masodiknal mar van ertelme az alignmentnek, ott 24 byte a struktura merete, amit szimplan azzal hoyg az uintptr_t tagot a struktura elejere viszem, sporolhatok 8 byte-ot. Es meg nem mondtam semmit a compilernek arrol, hogy hogyan alignoljon. Csak a hatulgombolos agyammal tudom hogyan fog igazitani es miert ugy, es ugy irom meg a kodot hogy nekem is jo legyen meg neki is. Mellesleg az igazan memoriazabalo programoknal nem a strukturalt adatok tarolasa veszi el a memoriafoglalas javat.

"Harmadreszt illett volna nem architektura fuggo meretu integereket hozni peldanak es/vagy nem egy szem platformon egy szem forditoval megnezni."

lol, ez no comment. x86-64 vs x86 threadben szerinted miért különös amd64-es példát felhozni? és történetesen amd64-es gépem van.

Most irjam jargonul hogy rotfl? szoval A vs B threadben te csak B-n nezted meg a dolgot. Teljesen rendben van. A ferrari azert jobb mint a mercedes mert a ferrari megy 200-zal. de azert lol. Hat te tudod, Apu.

és történetesen amd64-es gépem van.

Es tortenetesen azokon csak 64 bites linux futtathato. Azert ennel tobbet vartam volna toled, Apu!

micsa: Világosan lejött nekem, hogy nem flamelni akart.

std C++ gyakoriak pointerek a contanerekben, most nem vectorra kell gondolni.
(32 bittes rendszeren megnéztem, hogy gvim, átlagosan 33 bytokat allocált, feltételezem valami lista/fa féleség lehetnek főleg az allocált részek, tehát 1-2 ponter van bennük, nagyon sok kis blokkrol van szó )

DDR2 ram 64 bitteket tologat 32 bittes rendszeren is, Tehát 32 bittes pointer mellé bekerül még valmi a cachebe, ami feltételezhetőleg jol fog jönni. Egy jol megtervezett 32 bittes procival szemben nem jelent igazi előnyt 64bit, ha nem dolgozol nagy számokkal vagy nincs sok RAMod.

Szerintem a sebbeség külömbség (az a pár százalék) nagyábbol az eltérő pointerekől fakad.

"Ostoba es otromba modon szoltal valakihez "kisfiam"-mal akinek fogalmad nincs a korarol. Mondjuk ebbol nagyjabol mar sejtem, hogy ez a relacio nagyjabol forditva lehet igaz."

A kor nem egy érdem, hanem egy állapot.

"Ezt beszerd meg mondjuk Stroustrouppal, hagy legyen neki is par vidam perce. Ha ugy gondolod hogy ezek a nyelvek a pointerekrol szolnak, ketsegbeejto mennyire nem erzed oket. Ha C++-ban tul sokat kell valodi pointert hasznalnod, nem lehetsz nagy stl magus... ( az iterator NEM pointer )"

márpedig a dinamikus memória használata elkerülhetetlen, ebből következik a pointerek használata. Használhatsz stl-től kezdve bármit, keresési fát, gráfot, a pointereket nem kerülheted el.

"Hat 16-18 ev C/C++ (adj meg hozza ugy 5 ev assembly-t) es millio folotti kodsor valoban eltorpulhet a Te minden bizonnyal nagysagrendekkel nagyobb tapasztalatod mellett (es mar megint anelkul felteteleztel valamit rolam, hogy halvany lila dunsztod is lehetett volna a valosagrol)"

Én nem mondtam, hogy nekem sok tapasztalatom van. Azt viszont mondom hogy te sokat nem mutatsz ebből a 16-18 év tapasztalatból. Lehet hogy csak én nem látom.

"Amire en valaszoltam is, hogy miert nincs igazad."

persze.

"Nagyjabol az osszes ami torodik azzal hogy ne csak rammal telepakolt rendszereken fusson (pl aminek beagyazott rendszereken is futnia kell)"

Jaja. vajon miért használnak linux kernelt az access pointomon? Miért nem spórolták ki a pointereket? Esti tűnődésnek nem rossz. És ugyanúgy benne van a "Wirzenius wrote this portably, Torvalds fucked it up :-)" idézet a vsprintf.c-ben, de egyetlenegy pointert sem vettek ki amiatt, hogy embedded lesz a rendszer :P

Amúgy meg a linux arch könyvtárán kívül nem nagyon láttam alignmentre vonatkozó paramétert a gcc-nek (leglábbis én nem találtam).

"Altalaban nem jo ha egy programozo hasznalja az agyat mert a vegen meg nem tudnak a ram gyartok kinek memoriat eladni. Amugy meg az eonokban merheto c/c++ tapasztalatoddal tudhatod hogy alapvetoen egy strukturaban levo tagok sorrendjenek meghatarozasaval is befolyasolhatod hogy az alignment miatt mennyi memoria pazarlodik el. egy egy vagy 2 bajtos valtozonal meg nyugodtan igazithatsz egy vagy 2 byte-os cimre manualisan is akar, nem lesz tole semmi lassabb. De en ehez biztos hatulgombolos vagyok. Ja amugy esetleg ha erdekel a tema gondold vegig a memoria es a proci kozott hany byte mozog egyszerre. mem->L2->L1->CPU. Hiaba huzol be egy byte-ot a rambol, a proci amd64 eseteben 64 byte-ot fog berantani a cache-be. (ez az ugynevezett cache line size) Szoval abban valoban egyetertunk hogy hatulgombolos programozo nem biztos hogy jo ha babral az alignmentel, de aki tudja mit miert csinal az sokkal jobban el tudja donteni adott esetben mi lesz a jo mint a compiler. (jo, nem art kis gyakorlat hozza assembly-ben)"

erre csak ennyit tudok mondani: "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." (Code Complete, Page 594)

Nekem is van jó pár éves assembly tapasztalatom, de soha nem merném azt mondani, hogy az gyorsabb lesz mint ugyanaz C-ben megírva.

"lol, ez no comment. x86-64 vs x86 threadben szerinted miért különös amd64-es példát felhozni? és történetesen amd64-es gépem van."

"Most irjam jargonul hogy rotfl? szoval A vs B threadben te csak B-n nezted meg a dolgot. Teljesen rendben van. A ferrari azert jobb mint a mercedes mert a ferrari megy 200-zal. de azert lol. Hat te tudod, Apu."

megint lol.

"Es tortenetesen azokon csak 64 bites linux futtathato. Azert ennel tobbet vartam volna toled, Apu!"

Természetesen nem csak 64 bites linux futtatható kedves fiam, de rá vagyok kényszerítve, mert 64 bites release-t kell készítenem a gépemen, tudniillik a szerver, ahol ez a szoftver fut 4G+ memóriat tartalmaz. Értsd: nem elég a 4G address space.

p.s.: én nem sértegeni akarlak. csak indokold meg amit mondasz.

A kor nem egy érdem, hanem egy állapot.

Valahogy megsem en viszonyultam lekezeloen hozzad.

Nagyon sok pointert használ. Erről szól a C++

márpedig a dinamikus memória használata elkerülhetetlen, ebből következik a pointerek használata. Használhatsz stl-től kezdve bármit, keresési fát, gráfot, a pointereket nem kerülheted el.

csak nekem tunik fel hogy a ket fenti idezet nem ugyan azt jelenti? Kezdesz belezavarodni, Apu! Az hogy a pointerek nem kerulhetok el nem egyenlo azzal hogy a nyelv a pointerekrol szol. A kozlekedesi balesetek nem kerulhetok el (sot mitobb rendszeresen elofordulnak), ergo a kozlekedes a balesetekrol szol. Bela, van neked akvariumod? Nincs! Akkor te buzi vagy! Jo kis rendorlogika mint az egyszeri viccben.

Jaja. vajon miért használnak linux kernelt az access pointomon? Miért nem spórolták ki a pointereket? Esti tűnődésnek nem rossz. És ugyanúgy benne van a "Wirzenius wrote this portably, Torvalds fucked it up :-)" idézet a vsprintf.c-ben, de egyetlenegy pointert sem vettek ki amiatt, hogy embedded lesz a rendszer :P

Te olyan szinten nem erted mirol beszeltem, hogy tenyleg kar pazarolni az idot rad. Nincs bajom a pointerekkel, azzal van bajom hogy keptelen vagy felfogni hogy alignment ide alignment oda, lehet ugy explicit megadott packing nelkul is osszerakni strukturat hogy az alignment miatt ne vesszen el egy szekerdereknyi memoria. Es ugye azt sem birod (vagy akarod) megerteni hogy normalis tervezes eseten egy c(++) program adatterulete nem pointerekre mutato pointerekre mutato pointerekkel van tele hanem valodi, ertelmes adatokkal.

erre csak ennyit tudok mondani: "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." (Code Complete, Page 594)

Van 16 mega ram ezen a szaron. Ebbe kell beleferjunk, nincs apellata. (Egykori fonokom, nemtom hanyadik oldalon)

---------------

megint lol.

lololol, eggyel tobb lolt irtam le, most akkor en gyoztem? Tudok en ovodas stilusban is ha muszaj...

Természetesen nem csak 64 bites linux futtatható kedves fiam, de rá vagyok kényszerítve, mert 64 bites release-t kell készítenem a gépemen, tudniillik a szerver, ahol ez a szoftver fut 4G+ memóriat tartalmaz. Értsd: nem elég a 4G address space.

Es biztos minden gep a kornyezeteben 4G+ es 64 bit, nem tudtad volna megnezni 32 biten mekkorak azok a strukturak. 32 bites knoppix se bootol be rajta tutira.

p.s.: én nem sértegeni akarlak. csak indokold meg amit mondasz.

1. Bizonyara pusztan a masik ember iranti tisztelet birt ra a kisfiamozasra.
2. En indokoltam, de te ugy tunik write-only modban vagy sajna. Komolyan, mint ha loval imadkozna az ember olyan neked indokolni barmit is. Es itt fejeztem be, innentol ignore-ban vagy, indokoljon neked a tovabbiakban az iteletvegrehajto...

"Nagyon sok pointert használ. Erről szól a C++"

"márpedig a dinamikus memória használata elkerülhetetlen, ebből következik a pointerek használata. Használhatsz stl-től kezdve bármit, keresési fát, gráfot, a pointereket nem kerülheted el."

márpedig ugyanazt jelenti ez a két mondat.

"Van 16 mega ram ezen a szaron. Ebbe kell beleferjunk, nincs apellata. (Egykori fonokom, nemtom hanyadik oldalon)"

Az enyémen csak 8 mega ram van :( De sikerült belepasszírozni még egy telnet szervert :)

p.s.: így igaz, ignore_list.push_back(*pcompi)

semmi gond nincs, ha nem végzel bazinagy számokkal tudományos számolásokat :)
amugy meg x86-os modult x86_64 alá ne akarjál behúzni, mert még x86-oson belül is csak ugyanarra optimalizáltat szereti a kernel.

Nekem mindig igazam van, ha nem, akkor nincs igazam, szoval megint igazam van hogy nincs igazam.

debian 4.0 - linux-2.6.22.1-pancs1-wifi1 - 2.6.22.1 kernel madwifivel itt

Semmi baj nincs, és sokkal több programod lesz, sokkal kevesebbet kell szívni (igaz, Windows alatt 20%-al lassabban fog menni a DivX kódolása. :-P)
Egyébként nem akartalak bántani, azt hittem, "direkt" raktál 64 bites rendszert. Elnézést, ha sértő voltam.
It doesn't matter if you like my song as long as you can hear me sing

( skateman | 2007. 08. 01., sze – 16:10 )

Flash, Skype hónapok óta működik nálam rendesen, nem volt velük gond.
Ha lesz időm, átpakolom valahogy az Ubuntut x86-osra.

Windowst meg nem is használok, ami kell az fut wineval.
--SkatemanJoe--

( skateman | 2007. 08. 02., cs – 00:34 )

Fent van az x86-os verzió.
A modul műxik, csak a kamera képe fejjel lefelé van, ugyanis a kamera forgatható :P

--SkatemanJoe--