Olegil avautuu

Saku-foorumi » Uusi sukupolvi: AmigaOS 4 » Yleinen keskustelu » Viestit 2004 » Viestit 10/2004 asti » Olegil avautuu « Edellinen Seuraava »

Kirjoittaja Viesti
 

Janne
Torstaina, 3. kesäkuuta, 2004 - klo 13.42:   
Pieni kurkistus kulisseihin. :) olegil AW.netissä aiheesta AmigaOS 4 Pre-CD ja Linux AmigaOnella.

"@DrBombcrater

If it makes you feel any better I've already had a fall-out with Hyperion over the decision. So you are not alone."

"@Rogue

Uhm, I'm not trying to be offensive NOW. I didn't the at the time we DID have an argument (which ended with me shutting down the a1g3dev-list, remember?) either, but NOW I most certainly did not want to offend. Sorry "

"@Coder

Bah, I don't want special treatment. Giving a beta to me is pointless. I'm not actually waiting for MY machine to get OS4, I am waiting for the COMMUNITY to get OS4.

MY machine is happily sleeping under my desk and hasn't been powered on for half a year. Linux on the AmigaOne is too buggy for comfort. And any industrial customers Eyetech might have can quote me on that!!!"

 

hooligan/dcs
Torstaina, 3. kesäkuuta, 2004 - klo 13.48:   
Aamun tapahtumat :)


Posted by hooligan/dcs (Registered user) on 03-Jun-2004 08:38:52
In Reply to Comment 5 (DaveP):
@DaveP
In that thread you gave, Ole Egil complains about Linux being unusable on A1. Whats the deal here.. I was under impression that everything worked/works like a charm?



Posted by Peter Gordon (212.104.156.42) on 03-Jun-2004 08:42:39
In Reply to Comment 8 (hooligan/dcs):
He said buggy. He also has a really old SE board, which makes things worse for him. Debian ran fine on my XE-G4. I hated it, but not because it didn't work.



In Reply to Comment 9 (Peter Gordon):
Ah that explains it. Pretty much the same issue as with non-april Peg1's.


Posted by DaveP (213.36.38.164) on 03-Jun-2004 08:46:01
In Reply to Comment 9 (Peter Gordon):
Hooligan/dcs

Without knowing the specifics of what he is referring to Im just putting it down to the fact he uses an SE for now, its been solid for me since the beginning, except when the hard drive failed but that was sod all to do with debian.

Still to deny there are bugs in software would be to deny reality, Im just hoping he will elaborate on what he means. If its the UDMA driver issue then fair enough, if its the comparitavly shoddy condition of linuxppc versus the x86 distributions I can only agree with him...


source:
http://www.ann.lu/...?view=1086247732

[Edit: Linkki. --Moderaattori]

 

miksuh
Torstaina, 3. kesäkuuta, 2004 - klo 16.51:   
Ole Egilin Amigaone tais olla niitä aivan ensimmäisiä kappaleita, ensimmäisten 10 joukossa tjsp.

Ole Egilin oma kommentti myöhemmin tossa threadissa:

"Well, I consider myself to be a "power user" when it comes to Linux. I just generally didn't get the stability I needed.

Ok, ok. It's not unuseable, it's just that "very good" wasn't good enough here ;-)"

 

Janne
Maanantaina, 5. heinäkuuta, 2004 - klo 9.50:   
Lisää DMA:sta täällä:

http://amigaworld.net/modules/newbb/viewtopic.php?topic_id=5558&forum=13&31

 

KimmoK
Maanantaina, 5. heinäkuuta, 2004 - klo 10.29:   
Kauheastipa taas on fanaattisia Linux faneja AmigaOnen ympärillä. Eipä vois vähempää kiinnostaa. Samaa jaskaa jauhetaan uudestaan ja uudestaan.

 

Joanna
Maanantaina, 5. heinäkuuta, 2004 - klo 11.13:   
Paljon selityksiä, vähän valmista. Luulisi tuolla määrällä soopaa jo syntyneen julkisuuteen kelpaavat Linux-ajurit joista sitten itse kukin näkisi mitä pitää tehdä että se toimii kunnolla tuossa raudassa.

Itseäni ei Linuxi (tai muut Unix sukuiset) jaksa paljon kiinnostaa mutta ymmärrän niiden markkinoinnillisen merkityksen ja välttämättömyyden raudan tulevaisuudelle. Vaikka AmigaOS4 olisi valmistuessaan kuinka hieno, ei sillä nykyhintaisen Aonen kanssa ole realistisia markkinoita nykyisten Aktiivi.Amigistien ulkopuolella, ja (lienen maininnut aiemminkin) niiden varaan ei esim MAI voi laskea piirin valmistusta. He tarvitsemat ehdottomasti jonkin mainstream-käyttiksen että piiriä kannattaa tehdä/kehittää.

 

KimmoK
Maanantaina, 5. heinäkuuta, 2004 - klo 12.40:   
@Joanna

Oikea kiinnostus PPC Linuxiin (etenkin A1:lle) lienee niin pientä että kukaan kernelikoodari ei viitsi sormeaan nostaa asian eteenpäin viemiseksi. Miksi pitäisikään, turhaahan se on. AmigaOnea ei kenenkään kannata Linux raudaksi kuitenkaan hankkia (turhaa maksaa AOS lisenssistä) ja Teronia tuskin mistään edes saa.

MAI:n olisi pitänyt homma hoitaa, ei osanneet/ymmärtäneet, ja sitten niiltä tais karata jokin asiaan liittyvä ohjelmoija/-tiimi eikä heiltä sen takia kunnon Linux tukea heru vieläkään. Pegasos2 oli varmaan viimeinen niitti kaikelle AOS:n ulkopuoliselle ArtisiaS/Teron businekselle.

"He tarvitsemat ehdottomasti jonkin mainstream-käyttiksen että piiriä kannattaa tehdä/kehittää."

Niin, siis jos he aikovat desktoppi markkinoille myydä sitä Teronia.

Ainakaan minä en tiedä kuinka suuri menestys Teroneilla on ollut PPC evaluaatioemona ja ArtisiaS:llä sulautetun puolen northbridgenä.

(näkyy muuten TurboLinux olevan mukana muissakin noissa PPC evaluaatio emoissa, taisi IBM:nkin mukana moisen saada...)

 

itix
Maanantaina, 5. heinäkuuta, 2004 - klo 16.10:   
Linuxin DMA-ajurit on tarpeen jos haluaa ajaa MOL:ia.

 

KimmoK
Maanantaina, 5. heinäkuuta, 2004 - klo 17.47:   
@itix

Sekään ei liene riittävä syy saada porukkaa innostumaan A1:n tukemisesta muissa kuin AOS4:ssa.


Toisaalta sitten jos (eiku KUN) AOS4:lla voidaan messuilla demota toimivaa ja luotettavaa IDE DMA:ta, voi toki tulla uutta intoa värkätä sen Linux DMA:nkin kanssa. Uskon puute voi jollain olla riittävä syy olla pistämästä "rikkaa ristiin" PPC linuxin tweakkaamiseksi A1:llä 100% toimivaksi.

 

Joanna
Maanantaina, 5. heinäkuuta, 2004 - klo 18.08:   
KimmoK: Katsotaan. Sen näkee mitä tapahtuu sitten kun OS4 on vakiintunut käyttökuntoon.

Tosin minun nähdäkseni ajuri-patchien porttauksen esteeksi voi tulla se ettei Hyperion (tahi Mai) halua niitä muutoksia Opensourceeen ettei potentiaaliset asiakkaat pääse näkemää mitä kaikkea ja miten paljon pitää säätää.

 

itix
Maanantaina, 5. heinäkuuta, 2004 - klo 18.17:   
Jos oikein ymmärrän Benjamin Herrenschmidtiä niin DMA:n ei pitäisi olla ongelma Linuxissa.

Mutta enpä usko että kukaan jaksaa enää värkätä sen kanssa. Jos kerran A1/Linux-developereilla ei riittänyt motivaatio aikaisemmin niin miksi löytyisi myöhemminkään. Varsinkin kun Micro-A1 ja A1-XC ovat tulossa...

Ja toisaalta jos Eyetechillä olisi oikeasti tarkoitus saada toimiva Linux AmigaOneen olisivat he varmasti palkanneet jonkun sitä myös tekemään. Mikään ei ole ilmaista, ei edes Linux...

 

KimmoK
Maanantaina, 5. heinäkuuta, 2004 - klo 20.49:   
@itix

Se miniA1 piti käyttämän samaa ArtisiaS:ää. (mutta enpä tiiä enään... merkillisen hiljaista on ... ja Garry vihjailee siitä uudesta mobiilista piirisarjasta ... mini emossahan sen Radeon7000 toimis varmaan kyllin hyvin vaikkkapa 66Mhz PCI:llä...)

Ja sama DMA ilmiö voi olla A1-XC:ssäkin jos se pohjautuu ArtisiaP piiriin ja jos AOS4:ssa DMA näyttää pelittävän. Ovvat niin jääräpäitä etteivät ehkä muuta toteutusperiaatetta.

Jos AOS4:n DMA ei sittenkään toimis ArtisiaS:llä niin miniA1:n varmaan tulisi vähintäänkin April vastine ja sama A1-CX:lle (no siihen varmaan jo sais Artisia piirillekin HW cache coherencyn korjauksen). Tai sitten projektit kuopataan tyyliin AMigaOne1200


Sitähän tässä ei käsitä että miksi halutaan ehdoin tahdoin tärvätä A1 raudan lisämarkkinat tuolla huonolla Linux tuella.

 

itix
Maanantaina, 5. heinäkuuta, 2004 - klo 21.31:   
Kyllähän se DMA OS4:ssa toimii eikä se näin jälkeenpäin vaikuta mitenkään kovin monimutkaiselta operaatiolta.

Kiva myös todeta että Ben Hermans oli aikoinaan ajan tasalla: kommentti.

 

KimmoK
Tiistaina, 6. heinäkuuta, 2004 - klo 9.19:   
Peter Gordon @ ann:
183
All I claim is that DMA works on the AmigaOne, with DMA enabled OS4 drivers. I know this for a 100% fact because I have exactly those drivers on my system, and DMA works. Nothing more, nothing less. I would give further information, but the NDA unfortunately forbids me from letting you know anything which is not already public knowledge.
193
Yes. And the reason i'm claiming it works in OS4, is because it DOES work in OS4. It really does. I don't really know what else to tell you. The computer I'm using right now to tell you this is an AmigaOne with OS4, using DMA enabled IDE drivers.

@itix
"eikä se näin jälkeenpäin vaikuta mitenkään kovin monimutkaiselta operaatiolta"

Vitsinä tuon ehkä murjaisit... tai sitten se on yksinkertaista silloin kun sinulla on valta ja mahdollisuus koodata OS miten huvittaa. Mutta hemmetin riskaabelia/hankalaa jos pitää puukottaa koodia joka on jo kertaalleen Torvaldsin ja kumppaneiden siunaamaa ja täydeliseksi toteamaa.

Hermanin kommentista. Niin, tällä hetkellähän homma näyttää menevän kuten Ben selittää. Tulematta on kuitenkin se työn alla ollut kunnollinen Linux tuki.

"This behavior reduces latency"
Tuohan nähdään aika hyvin sitten kun päästään ajamaan benchmarkia vuoden 1999/2000 x86 koneita ja Peg1stä vastaan.
Uskotaan sitten kun nähdään, jos nähdään.

 

itix
Tiistaina, 6. heinäkuuta, 2004 - klo 10.38:   
"Yes. And the reason i'm claiming it works in OS4, is because it DOES work in OS4. It really does."

Niin, toimiihan se classic Amigassakin.

"Vitsinä tuon ehkä murjaisit..."

Nyt tuo on helppo korjata kun ongelma on tunnistettu. Periaate näyttäisi olevan yksinkertainen. Flushataan cachet ja merkitään DMA:n käyttämä muistialue non-cacheableksi.

"tai sitten se on yksinkertaista silloin kun sinulla on valta ja mahdollisuus koodata OS miten huvittaa."

Linuxin lähdekoodi on saatavilla. Sitä saa kuka tahansa muokata niin kuin huvittaa.

Ymmärtääkseni Linux tukee myös arkkitehtuureja joista puuttuu cache coherency kovolta.

"Hermanin kommentista. Niin, tällä hetkellähän homma näyttää menevän kuten Ben selittää."

No ei sinne päinkään.

 

KimmoK
Tiistaina, 6. heinäkuuta, 2004 - klo 12.34:   
@itix
"Nyt tuo on helppo korjata kun ongelma on tunnistettu. Periaate näyttäisi olevan yksinkertainen. Flushataan cachet ja merkitään DMA:n käyttämä muistialue non-cacheableksi."

Jotain sinnepäin.

"Ymmärtääkseni Linux tukee myös arkkitehtuureja joista puuttuu cache coherency kovolta. "

Juu. Siis tuo toiminne mitä edellä mainitsit löytynee kernelistä.

Mutta semmonen palautui mieleen tässä viimeisen 24 tunnin aikana että se ei välttämättä riitä.

Jos siis ArtisiaS mahdollistaa/sallii usean samanaikaisen DMA siirron (tjsp) northbridgen läpi saman aikaisesti poiketen x86 northbridge toteutuksista / PCI standardista, homma voi olla monimutkaisempi kuin mitä esim. Linux tukee.

"No ei sinne päinkään."

Miksei?


"This "so called "problem is the direct result of the Articia S's ability to handle memory access by the CPU and PCI bus. "
Tuosta ei ehkä saa täyttä selkoa mitä tuo tarkoittaa, mutta... ilmeisesti samaa minkä ben selittää tuossa myöhemmin ... *

"This behavior reduces latency "
Tuotahan me ei tiedetä ennen kuin se ollaan testattu. Sen merkitys voi olla yhtä "suuri" kuin käyttiksen taskinvaihdon nopeus.
Teoriassa tuo rinnakkaisuus pienentää latenssia. Mm. siksi esim P4:n tehtiin HT.

"but is unknown in the Wintel world "
Empä tiiä. En ole tutkinut nuita niin tarkkaan. MAI kyllä kehuu patentoineensa vaikka mitä mutta....

"which is why the Linux drivers don't cater for it. "
Ainakin tuo on totta. :-)

* "In the Wintel world either the CPU or the PCI busmaster is allowed to write to memory, not both at the same time. "
Tämähän on juuri se PCI standardin vastainen toimintatapa josta siniset fanaatit + x86 fanaatit on valittaneet.
Ja samaisesta syystä koko härdelli onkin vain FEATURE kunhan se saadaan toimimaan. Muutoin voitaneen todeta sen olevan rikki.
Tuon tapaista olen ymmärtänyt myös joitain MAI:n speksejä luettuani.
Onkos linkkiä jossa selitettäisiin miksi tilanne ois jokin toinen?

"MAI has been reworking the Linux drivers to cope with this and "
Tämäkin on totta. (sittemmin ne koodarit vissiin nosti kytkintä tjsp)

"Hyperion has been aware of this feature for quite some time and has taken it into account when doing DMA capable drivers for the AmigaOne hardware."
Kirjoituksen aikoihin ei oo varmaan muuta kuin suunnitelmat IDE DMA:sta olleet valmiina. Muuten ok.
Kuulostaahan ne aika toimivilta nyt kun Betatestaajat niitä on testailleet A1:llä.

"It is nice to see Genesi finally putting their cards on the table after close to a easy of rumor mongering so their ignorance can be exposed."

Tuohon voin kommentoida sen verran että Hyperion tuppaa puhumaan aidasta ja Genesi aidan seipäästä (tjsp).

 

KimmoK
Tiistaina, 6. heinäkuuta, 2004 - klo 12.48:   
@itix
""tai sitten se on yksinkertaista silloin kun sinulla on valta ja mahdollisuus koodata OS miten huvittaa.""
"Linuxin lähdekoodi on saatavilla. Sitä saa kuka tahansa muokata niin kuin huvittaa."

Juu, en oli niin tyhmä. Ei vaikuta siihen mitä tarkoitin.

On varmasti helpompi nyhjästä tyhjästä muutaman tuhannen koodirivin kerneliin sellainen DMA tuki mitä haluaa kuin että opiskella 10 miljoonia koodirivejä Linux koodeja.

Kuten kaverini sanoi: "tein yhden kernelipuukon, en tee enään".

Toinen kaverini uudelleen implementoi alle 30 000 koodirivillä about 5 000 000 koodirivin softan toiminteet. (säästyi varmaan muutama tuhat työtuntia ja lopputuloksen kompleksisuus oli pieni ja toimintavarmuus suuri)

Ja saakos virallisiin kernelin kehityshaaroihin kuka tahansa koodata mitä tahansa? Ei varmasti.

Eikö Linux (amiga ei pre-emptiivisesti moniaja) Torvaldsilla ole mitään sanavaltaa jos haluan koodata arveluttavan näköisen puukon mukaan virallisiin koodeihin?

Jos ei koodia saa sinne viralliseen kernelin kehitykseen mukaan niin hommassa ei liene pienintäkään järkeä. Jokaisesta kernelin iteraatiosta joutuisi erikseen tekemään MAI version.

Siis: se on VARMASTI on yksinkertaisenpaa silloin kun sinulla on valta ja mahdollisuus koodata OS miten huvittaa

 

Piru
Tiistaina, 6. heinäkuuta, 2004 - klo 15.26:   
"Ja saakos virallisiin kernelin kehityshaaroihin kuka tahansa koodata mitä tahansa? Ei varmasti."

Ja takuulla saa.

"Eikö Linux (amiga ei pre-emptiivisesti moniaja) Torvaldsilla ole mitään sanavaltaa jos haluan koodata arveluttavan näköisen puukon mukaan virallisiin koodeihin?"

Ei. Voit levittää tätä arveluttavaa versiotasi miten mielesi tekee, kenenkään estämättä.

"Jos ei koodia saa sinne viralliseen kernelin kehitykseen mukaan niin hommassa ei liene pienintäkään järkeä. Jokaisesta kernelin iteraatiosta joutuisi erikseen tekemään MAI version."

Miksi ei?

Käsittääkseni pegasos kernelipätsi ei ole virallisesssa Linux puussa, vaan Debianin kernelissä.

Esim. "-benh" puu on yleisesti tunnettu Mac versio kernelistä.

 

itix
Tiistaina, 6. heinäkuuta, 2004 - klo 16.12:   
> > No ei sinne päinkään.
>
> Miksei?

ANN alkaa päästä keskustelussa taas paremmalle tasolle:

Chris Hodges kommentoi

Toisekseen millä tavalla ArticiaS olisi muka nopeampi? Pienempi latenssi? Missä se latenssi tulee? Ainakaan DMA:n nopeuteen se ei vaikuta joten ArticiaS ei ole "tehokkaampi" kuin esimerkiksi Marvellin Discovery II.

Hermans:
"This behavior reduces latency but is unknown in the Wintel world which is why the Linux drivers don't cater for it."

Näyttää kyllä siltä että tämä sama "ominaisuus" on tuntematon myös PPC-maailmassa. Marvell ei tällaista näytä tuntevan eikä samaa ominaisuutta näytä olevan Maceissäkään.

No onhan ennenkin nähty "vallankumouksellista suunnittelua ja pioneerihenkeä" HW-suunnittelussa. ArticiaS on susi.

 

itix
Tiistaina, 6. heinäkuuta, 2004 - klo 16.15:   
"ArticiaS on susi."

Täytyy vielä mainita että onhan mullakin ArticiaS-kone eli kyllä sen kanssa elää. Syksyllä tulee vuosi Articiaa täyteen ja suhteellisen vähän on ollut mitään ongelmia.

 

Joanna
Tiistaina, 6. heinäkuuta, 2004 - klo 22.49:   
Termi *susi* on aika suhteellinen tällä alalla.. Kokemus on opettanut että pahemminkin rikki olevien piirien kanssa tulee toimeen niinkauan kuin piirin viat on dokumentoitu ja niiden kiertoon on selkeät ohjeet.

Hyvä esimerkki on vaikkapa Intellin StrataFlash.. Siis 'simppeli' tavallinen Flash.muistipiiri, isolta ja tunnetulta valmistajalta, eli pitäisi olla jokapäiväistä kauraa?... Helppoa, yksinkertaista ja standardia? *BLÄÄH*

Datalehti.. (70 sivuinen.. jota tuskin tavallisen käyttäjän kannattaa imuroida/lukea)
ftp://download.intel.com/design/flcomp/datashts/29066718.pdf


Errata! (josta pari opettavaa näytettä, 28 sivuinen PDF)
ftp://download.intel.com/design/flcomp/specupdt/29813019.pdf

"5. Operating Temperature Range
Problem: The operating temperature range for this device is 0 °C to +70 °C. with a –20 °C read only
operation.
Implication: Customers that use this part in applications that require full device operation below 0 °C should be aware of this erratum. Full operation of the device below 0 °C is not guaranteed and should not be attempted. The device will read down to –20 °C."

Eli .. laite joka on datalehdessä speksattu toimimaan -20 - 70C, ei kirjoita dataa oikein alle 0C lämpötilassa.

"18. Byte Mode (x8) Functionality
Problem: Reads from the array in Byte-mode do not return the correct data.
Implication: Customers should not attempt to operate the device in the x8 configuration as incorrect data will be read from the array.
Workaround: There is no known workaround for this issue."

Eli jos piiri on byte-wide modessa (eli 8 datalinjaa) se ei kirjoita dataa ollenkaan Flashille... Bytewide on kyllä Datalehden mukaan tuettu.

Jne jne.. Onneksi nuo sentään ON dokumentoitu ettei niistä tarvitse tapella vuodesta toiseen käyttäjien kesken. :-)

 

KimmoK
Keskiviikkona, 7. heinäkuuta, 2004 - klo 8.44:   
@Piru
>> "Ja saakos virallisiin kernelin kehityshaaroihin kuka tahansa koodata mitä tahansa? Ei varmasti."
>Ja takuulla saa.

Ööö. Olen kyllä kuullut että siellä on jonkinlainen valvonta siitä mitä otetaan kerneliin mukaan. Muutoin Linux ois kaatumatautinen.

>>"Eikö Linux (amiga ei pre-emptiivisesti moniaja) Torvaldsilla ole mitään sanavaltaa jos haluan koodata arveluttavan näköisen puukon mukaan virallisiin koodeihin?"
>Ei. Voit levittää tätä arveluttavaa versiotasi miten mielesi tekee, kenenkään estämättä.

Mutta kun linux kerneliin tulee uusia ominaisuuksia, esimerkiksi PPC970 hyperthreading niin tuleeko se sitten automaattisesti myös siihen arveluttavaan versiooni?

>>"Jos ei koodia saa sinne viralliseen kernelin kehitykseen mukaan niin hommassa ei liene pienintäkään järkeä. Jokaisesta kernelin iteraatiosta joutuisi erikseen tekemään MAI version."
>Miksi ei?

No siksi että: Jokaisesta uudesta kernelin iteraatiosta joutuisi itse erikseen tekemään MAI version, uudestaan ja uudestaan.

>Käsittääkseni pegasos kernelipätsi ei ole virallisesssa Linux puussa, vaan Debianin kernelissä.

Mielenkiintoista. Luulin toisin. Ja ihmettelen.
Tarkoittaa sitä että Genesillä pitäisi olla northbridgelleen oma Linux ylläpito niin pitkään kun sitä northbridgeä käytettään.

 

KimmoK
Keskiviikkona, 7. heinäkuuta, 2004 - klo 8.59:   
@itix
>Toisekseen millä tavalla ArticiaS olisi muka nopeampi?

Näyttöä ei ole. Kukaan ei ole julkisesti testannut toimivilla ajureilla. April luultavimmin poistaa MAI:n ajatteleman alkuperäisen toimintatavan.

>Pienempi latenssi? Missä se latenssi tulee?

Latenssi tulee aina muistiaccessien alussa.
P4:n hyerthreading mahdollistaa toisen säikeen toimintojen suorittamista silloin kuin muistiaccessin latenssi on pysäyttänyt edellisen säikeen. (tjsp, paras matsku aiheesta löytyy Sunin prossuista)

Jos artisia kykenee tekemään esim muistinkäsittelyssä saman taoaista toiminnetta kuin mitä P4 tekee, se voisi olla jotain uutta.

> Ainakaan DMA:n nopeuteen se ei vaikuta joten ArticiaS ei ole "tehokkaampi" kuin esimerkiksi Marvellin Discovery II.

Vaikka DMA siirto tapahtuisi täsmälleen samalla nopeudella, viiveet DMA accessien välissä voisivat olla pienemmät. Siitä voi olla merkitystä silloin kun DMA siirtoja on paljon (luultavasti olemattoman vähän hyötyä desktop käytössä).

(olen varma että Marvell pieksee ArtisiaS:ää jo muutenkin niin paljon että häviävän pienillä DMA viiveillä ei ole siinä pelissä pienintäkään merkitystä)

>"This behavior reduces latency but is unknown in the Wintel world which is why the Linux drivers don't cater for it."
>Näyttää kyllä siltä että tämä sama "ominaisuus" on tuntematon myös PPC-maailmassa. Marvell ei tällaista näytä tuntevan eikä samaa ominaisuutta näytä olevan Maceissäkään.

Etkö ole huomannut että maailma kehittyy.
Ei ollut hyperthreadingiakaan ensimmäisessä p4:ssa jne jne.

>No onhan ennenkin nähty "vallankumouksellista suunnittelua ja pioneerihenkeä" HW-suunnittelussa.

Mutta myös epäonnistuneita innovaatiota.

>ArticiaS on susi.

Ehkä siinä on ominaisuus josta on desktoppikoneessa enemmän haittaa kuin hyötyä.

Tai ehkä se on rikki.

Kyllä se selviää.

 

KimmoK
Keskiviikkona, 7. heinäkuuta, 2004 - klo 9.11:   
ann#295

" As the hardware DMA support is assumed for most systems, hardly anybody will care for such manual cache consistency in their drivers."

Siis sen lisäksi että Linuxin DMA:n yläkerta pistetään kuntoon ArtisiaS:lle, myös about joka ikinen DMA kykyinen laiteajuri voi tarvita muutoksia. Sama homma jokaiselle käyttikselle erikseen. Tämähän on tiedetty. Ja se on yksi syy miksi AOS4 on eri asemassa kuin Linux A1:llä. Ja selittää miksi Peg1:ssä on April1.

...

" Even if one would not call the ArticiaS bugged related to DMA, it is clearly a missing feature for transparent DMA operations. "

Niinpä. Siinä on uusi ominaisuus jonka yhteydessä ei ole älytty ottaa mukaan tai testata toimivaksi vanhan mallista DMA siirtoa.

...
" In order to invalidate a cache entry, a driver designer would have to invalidate a huge block of memory addresses (up to 256MB). This would probably be outside the addressing for a single device's I/O buffers and could seriously hamper performance across the board. .... ... Seems to me that, if someone wants DMA-enabled Linux on an A1, all they've got to do is rewrite the memory-management routines using page tables and throw out all the work done by BenH, an acknowledged kernel guru."

Että semmoinen helppo homma, ehkä. ;-)

 

Piru
Keskiviikkona, 7. heinäkuuta, 2004 - klo 13.31:   
@KimmoK
>> "Ja saakos virallisiin kernelin kehityshaaroihin kuka tahansa koodata mitä tahansa? Ei varmasti."
>>Ja takuulla saa.

>Ööö. Olen kyllä kuullut että siellä on jonkinlainen valvonta siitä mitä otetaan kerneliin mukaan. Muutoin Linux ois kaatumatautinen.

Edelleen: Kuka tahansa saa lisätä/poistaa/muuttaa linuxia miten tahansa. Jos muutekset eivät toimi, ongelma on yksin sinun (ja muiden jotka mahdollisesti käyttävät omaa versiotasi).

>>>"Eikö Linux (amiga ei pre-emptiivisesti moniaja) Torvaldsilla ole mitään sanavaltaa jos haluan koodata arveluttavan näköisen puukon mukaan virallisiin koodeihin?"
>>Ei. Voit levittää tätä arveluttavaa versiotasi miten mielesi tekee, kenenkään estämättä.

>Mutta kun linux kerneliin tulee uusia ominaisuuksia, esimerkiksi PPC970 hyperthreading niin tuleeko se sitten automaattisesti myös siihen arveluttavaan versiooni?

Ei automaattisesti, sinun tulee mergettää muutokset omaan puuhusi tai muokata pätsisi toimimaan uuden kernelirevision kanssa. Riippuen pätsin laajuudesta tämä on pieni / hieman suurempi urakka.

>>>"Jos ei koodia saa sinne viralliseen kernelin kehitykseen mukaan niin hommassa ei liene pienintäkään järkeä. Jokaisesta kernelin iteraatiosta joutuisi erikseen tekemään MAI version."
>>Miksi ei?

> No siksi että: Jokaisesta uudesta kernelin iteraatiosta joutuisi itse erikseen tekemään MAI version, uudestaan ja uudestaan.

Ja tämä on ongelma miksi? Muutosten mergeäminen ei ole mikään mahdoton ongelma, ja suurimmaksi osaksi automaattinen toiminne muutenkin.

>>Käsittääkseni pegasos kernelipätsi ei ole virallisesssa Linux puussa, vaan Debianin kernelissä.

>Mielenkiintoista. Luulin toisin. Ja ihmettelen.
>Tarkoittaa sitä että Genesillä pitäisi olla northbridgelleen oma Linux ylläpito niin pitkään kun sitä northbridgeä käytettään.

Toki. Tämä ei ole mikään ongelma.

Tässä esim 2.6.7 kernelin pätsi:
kernel-patch-powerpc-2.6.7-2.6.7

 

KimmoK
Torstaina, 8. heinäkuuta, 2004 - klo 17.02:   
ann jatkoa: http://www.ann.lu/comments2.cgi?show=1089269236&category=unmoderated&number=24#comment

Tämän huomattuani:
And then we discover quotes from ArticiaS documentation:
""The snoop cycle is used to probe the primary and secondary cache for updated data when the PCI accesses DRAM. This is done to maintain data coherency between the Floating Buffer, DRAM and both caches. The Articia S performs the Snoop cycle. When there is a snoop hit on a modified cache line in either level one or two cache, the contents are written back directly to the Floating Buffer. A PCI Bus master can subsequently later on fetch the data directly from the Floating Buffer. The Floating Buffer is flushed back to DRAM during a PCI write cycle. The corresponding line in level one or level two cache is thus invalidated. Snoops are hidden, meaning the CPU can continue its current data access without being interrupted while the Articia S simultaneously queries both caches.""

Tekee mieli äänestää: feature with bug

Lisäksi tämä "The corresponding line in level one or level two cache is thus invalidated." viittaa siihen että L3 välimuisti kusee aivan varmasti.

((((((Seköhän onkin todellinen syy miksi L3 välimuisti poistui A1 koneista.....)))))

feature with bugS

 

Jamie
Torstaina, 8. heinäkuuta, 2004 - klo 18.47:   
Niinhän se on, että:
it's not a bug, it's a feature :)

 

KimmoK
Torstaina, 8. heinäkuuta, 2004 - klo 19.53:   
Miltei identtiset floating bufferihommelit näkyy olevan x86 puolellakin.
hammer @ ann

Erot ArtisiaS:n jää pieneksi ... lähinnä se että cache coherency ei olekaan ArtisiaS:ssä niinkuin speksissä sanovat...

 

Janne
Maanantaina, 12. heinäkuuta, 2004 - klo 12.27:   
KimmoK: Tässäpä haaste kesäiltojesi ratoksi - saa Samface uskomaan tuo. :)

Mutta eiköhän se OS4 vähitään DMA:ta saada tukemaan. Ja kenties Linuxkin aikanaan - ellei sitten juuri käy niin että uusi Articia ilmestyy ja vanhat jätetään oman onnensa nojaan.

Lisää viestisi tähän
Viestisi:
Käyttäjätunnus: Postitus informaatiota:
Tämä on yksityinen keskustelupalsta. Vain rekisteröidyt käyttäjät ja moderaattorit voivat postittaa tänne.
Salasana:
valinnat: Aktivoi URL:t automaattisesti tässä viestissä
Toimenpide: