| Kirjoittaja | Viesti | ||
     Janne |
 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 |
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 |
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 |
http://amigaworld.net/modules/newbb/viewtopic.php?topic_id=5558&forum=13&31 | ||
| KimmoK |
| ||
| Joanna |
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 |
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 |
| ||
| KimmoK |
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 |
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 |
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 |
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 |
Kiva myös todeta että Ben Hermans oli aikoinaan ajan tasalla: kommentti. | ||
| KimmoK |
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 |
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 |
"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 |
""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 |
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 |
> > 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 |
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 |
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 |
>> "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 |
>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 |
" 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 |
>> "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 |
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 |
it's not a bug, it's a feature | ||
| KimmoK |
hammer @ ann Erot ArtisiaS:n jää pieneksi ... lähinnä se että cache coherency ei olekaan ArtisiaS:ssä niinkuin speksissä sanovat... | ||
| Janne |
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. |