Artician DMA & bugit & AOS4

Kirjoittaja Viesti   KimmoK Perjantaina, 5. maaliskuuta, 2004 - klo 14.58:    Näyttäisi vaihteeksi siltä että A1:n DMA:t saadaan toiminaan AmigaOS4:ssa. http://amigaworld.net/... Toimivia: - äänikortin DMA - ethernet piirin DMA IDE DMA: - We first want to iron out all and any issues with respect to the ATA(PI) support in the ide.device before activitating the DMA transfers. Don't forget that OS 4 is intended to support CD-Rom, CD-R, CR-RW, CD-MRW, DVD-ROM, DVD-RAM, DVD-W etc. etc. ... - Actually that's exactly what we did: we produced a IDE driver using DMA and it worked fine. It was however not integrated into the framework of a device driver yet. - FWIW, the DMA driver seems to work just fine, but like I said it's not required for a prelininary pre-release version. - Actually we have, and actually it works. As Ben pointed out, it's currently a standalone program that simply transfers stuff via DMA. That doesn't qualify as a driver yet, - as I said, there is already a testbed implementation that seems to work - The Prerelease will not have DMA, but as I already suggested, there is already a testbed implementation. Linkin takaa löytyy keskustelu rivien väliin, jos jokua haluaa syynätä tarkemmin. Ihan lupaavalta näyttää DMA:n kehitys AmigaOS4:n osalta...   Joanna Perjantaina, 5. maaliskuuta, 2004 - klo 15.52:    KimmoK: Onko siellä ollut mitään mainintaa USB:n tai sisäisten äänien DMA:sta, ymmärsin ettei jälkimmäistä ainakaan aiota tukea OS4:ssä. Siitä olen samaa mieltä että ennako -Pre-releasen saaminen ulos ajaa Ide-DMA:n edelle, sen ehtii lisäämään sitten kun se on irrallisena testattu ja se varmasti toimii 100%.   itix Perjantaina, 5. maaliskuuta, 2004 - klo 15.57:    "Toimivia: - äänikortin DMA - ethernet piirin DMA" No itse asiassa noihinhan DMA-pulmilla ei ole koskaan ollutkaan mitään merkittävää vaikutusta. En oikein usko että noihin olisi mitenkään mielekästä laittaa cache flushia yms. ennen DMA-siirtoa tai sen jälkeen. A1:n Linuxissa tuo DMA (paitsi IDE) on ollut käytössä ja iät ja ajat. Ja MAI:n YDL-patchi näyttäisi toimivan aika hyvin joten OS4:sen IDE DMA-tilanne on näyttänyt jo pitkään varsin kohtuulliselta.   Pekka Nissinen Perjantaina, 5. maaliskuuta, 2004 - klo 16.00:    Tietääkseni missään vaiheessa ei ole ollut siitä epäilystä etteikö DMA toimisi OS4:ssa. Sitähän nuo Hyperionin poijat ovat hokeneet jo vuoden päivät...   itix Perjantaina, 5. maaliskuuta, 2004 - klo 16.02:    "Onko siellä ollut mitään mainintaa USB:n tai sisäisten äänien DMA:sta, ymmärsin ettei jälkimmäistä ainakaan aiota tukea OS4:ssä." On-board audio ei toimi muista syistä. Sen sijaan floppy toimii mutta OS4 prerelease ei sisällä sille ajuria (näillä näkymin).   itix Perjantaina, 5. maaliskuuta, 2004 - klo 16.17:    Tarkennuksena vielä että A1 Liten integroitu audio toimii.   KimmoK Perjantaina, 5. maaliskuuta, 2004 - klo 16.51:    @Pekka Ennen kuin sitä on oikeasti AOS4:ssa testattu niin mielestäni homma ei ole ollut 100% varma. Ei vieläkään ehkä oo. @itix Minä en ollut ihan varma pystyikö DMA:ta käyttämään vielä millekään laitteelle... Ja satunnaisen seurailijan silmissä (ja BillBuckin mukaan) Artisian ongelmat on näyttäneet korostuvan silloin jos/kun on useammanlaista DMA säpinää meneillään. Emon audiosta: Onko kyseessä rautabugi? Ymmärsin aikaisemmin niin että integroitu audio vois joskus toimiakin, myös A1XE:ssä. (henk koht sillä ei ole merkitystä, tosin) En ollut kuullutkaan YDL:n päivityksestä. Saako sillä siis IDE DMA:n stabiiliksi linuxissa. Onko infoa tuosta saatavilla netistä?   hooligan/dcs Perjantaina, 5. maaliskuuta, 2004 - klo 17.06:    DMA toimii mutta sitä ei ole mukana pre-releasessa. Kysymys kuuluu miksi, jos se kerran toimii?   itix Perjantaina, 5. maaliskuuta, 2004 - klo 17.15:    "Ja satunnaisen seurailijan silmissä (ja BillBuckin mukaan) Artisian ongelmat on näyttäneet korostuvan silloin jos/kun on useammanlaista DMA säpinää meneillään." Mitä enemmän DMA-siirtoja on meneillään sitä enemmän on kuormitusta ja sitä kautta DMA-ongelma esiintyy paljon helpommin. Yleensäkin tuo näyttäisi tapahtuvan lähinnä silloin kun data tulee DMA:ta pitkin sisään ja sitten DMA:ta pitkin ulos. Omassa DMA-fixaamattomassa Pegasoksessa on syntynyt puolen tusinaa rikkinäistä netistä otettua LHA-pakettia ja vain yksi "käytännön" tilanteessa syntynyt viallinen tiedosto (GCC kirjoitti exeksi pelkkää roskaa). Ja vielä kun Olegil sanoi ANN:ssa että ongelma käy sitä harvinaisemmaksi mitä nopeempi kone on niin probleemalla on jotain tekemistä kuormituksen kanssa. "Onko kyseessä rautabugi? Ymmärsin aikaisemmin niin että integroitu audio vois joskus toimiakin, myös A1XE:ssä. (henk koht sillä ei ole merkitystä, tosin)" Se on rautabugi. En tiedä tarkemmin mutta Eyetech aikoo nyt jättää äänipiirin kokonaan pois. Ehkä joku pellepeloton keksii mtien sen saa toimimaan mutta virallisesti XE:n AC97:aa ei enää tueta. "En ollut kuullutkaan YDL:n päivityksestä. Saako sillä siis IDE DMA:n stabiiliksi linuxissa. Onko infoa tuosta saatavilla netistä?" MAI:n FTP-palvelimella oli YDL:n DMA-fixi joitakin kuukausia sitten. Sen perusteella YDL näyttäisi flushaavan CPU:n cachet ennen datan kirjoitusta ja vastaavasti se flushaa cachet kun dataa on luettu. Idea näyttäisi olevan sama kuin AmigaOS:n Pre/PostDMA() funktioissa eli noilla jutuille DMA:n saa varmasti toimimaan 99% luotettavasti. Mutta vaikea sanoa tarkemmin varsinkaan kun tuota lähdekoodia ei ole enää tuolla.   jontsa Perjantaina, 5. maaliskuuta, 2004 - klo 18.01:    Hooligan: Haluavat ehkä ensin lisätä kaikki suunnitellut featuret ajuriin ja testata perusteellisesti ennenkuin dma otetaan käyttöön. Mietippä jos ide ajurissa olisi joku ongelma... joka ikinen pahanilmanlintu huutaisi yhteen ääneen "SE ON DMA BUGI"   ahi Perjantaina, 5. maaliskuuta, 2004 - klo 18.47:    ArtiCia   hooligan/dcs Perjantaina, 5. maaliskuuta, 2004 - klo 19.09:    @Jontsa No mut sit vois sanoo takas että eipä ole kun beta-ajuri   jamie Lauantaina, 6. maaliskuuta, 2004 - klo 9.44:    hooligan: DMA:n toimimattomuudesta "It's not a bug, it's a feature!"   miksuh Lauantaina, 6. maaliskuuta, 2004 - klo 11.49:    Joanna: Eikös ainakin A1 Litessä ole tarkotus tukea emolevyn äänipiirejä. noin olen ymmärtänyt. USB:n kohdalla en ole ainakaan nähnyt mitään mainintaa ettei ne olisi käytettävissä.   Janne Sunnuntaina, 7. maaliskuuta, 2004 - klo 10.30:    Aikooko Eyetech vaihtaa ilman toimivia ääniä äänellisinä myydyt koneen toimiviin kuten Genesi vaihtoi April-koneet ilmaiseksi? Onko joku nähnyt kommenttia tästä?   KimmoK Maanantaina, 8. maaliskuuta, 2004 - klo 11.52:    @Janne Vai vaihtaako he kaikki äänipiirilliset äänipiirittömiin (jotta käyttäjät päisisivät eroon kuolleen raudan painolastista).   KimmoK Maanantaina, 8. maaliskuuta, 2004 - klo 13.19:    Rogue jatkoi: "Quote: I'm asking for a clear, precise answer to the question "Does OS4 work correctly on the A1 in DMA mode when the DMA controller and CPU are fully loaded?". I am not "dodging the issue". I told you that we have a testbed implementation of a DMA IDE driver. I said that this seems to work just fine. I don't even have that program, and I don't work on the IDE driver. No, we haven't done any stress tests. I never claimed that, and you never asked that until now. My take is that if there is any problem then these will be made public. IF there are. DMA works, that is what I am sure about. That is a general statement. I am sure that it works because both the sound driver(s) and the ethernet driver(s) already make use of it. Whether there will be any problems with IDE is an entirely different topic, one that I haven't answered yet and will ONLY reply to when I actually know the answer. What I am definitely not going to do is delay any work on OS 4 just to prove someone wrong or right. I've already explained in an earlier posting why this is the case. " Eli stressitestit IDE DMA:lle on tekemättä. No siitä tulee stressiä sen verran että itse en uskaltaisi vielä A1:stä laittaa.   TSK Tiistaina, 9. maaliskuuta, 2004 - klo 12.43:    Täällä mielenkiintoista asiaa aiheesta.   KimmoK Perjantaina, 2. huhtikuuta, 2004 - klo 23.12:    Hmmm... Kohta alkaa olla tämä bugisavotta lopussa, ehkä: bugitonta filesiirtoa Mutta ei nuolaista ennen kuin tipahtaa.   itix Lauantaina, 3. huhtikuuta, 2004 - klo 1.30:    Näyttää jo paremmalta.   Joanna Lauantaina, 3. huhtikuuta, 2004 - klo 2.10:    KimmoK: Kannattaisi testata muuten isommalla fileellä kuin mitä DaveP on tehnyt.. tuollainen nysä mahtuu missä tahansa nykysysteemissä cachemuistiin Mutta ei se sitä tarkoita etteikö se toimisi, sitten käytännössä paljonko se vaikutta nopeuksiin tosielämän testeissä. Ainakaan tällähetkellä tuota ajuria ei oikein optimaalisena voi pitää tuon siirtonopeuden perusteella, mutta on se silti parempi jo kuin ne aikaisemmat CPU-siirtoiset.   Piru Lauantaina, 3. huhtikuuta, 2004 - klo 5.15:    Työtä edessä vielä, sanoisin. peg2 siirtää vähintään 50-60 MB/s, levystä riippuen. Eli rajoittavana tekijänä on levyn siirtonopeus (average sustained transfer rate), ei väylän. Siinä mielessä tuo on väärä testi, että se mittaa levyn maksimisiirtonopeutta (ellei väylä rajoita ensin, toimivassa raudassa levy nappaa ensin kiinni). Kiinnostavampaa olisi nähdä itse väylän siirtonopeus, eli levyn cachesta luettuna saatava nopeus (Maximum External Transfer Rate). Tässä peg2 siirtää Seagate 7200.7 levylläni noin 90MB/s (peak maksimina dokumentaatio mainitsee 100MB/s). peg2 siis pystyisi vähintään tuohon 90MB/s nopeuteen myös todellisessa levyltä lukemisessa (sustained data rate), olettaen että itse levyt tähän kykenisivät. Seagate 7200.7 dokumentaatiossa mainitaan 58 MB/s.   KimmoK Lauantaina, 3. huhtikuuta, 2004 - klo 6.02:    @Joanna Luulis että DaveP ei ole niin tyhmä että lukisi dataa cachesta. Mutta niinkuin siellä threadissakin sanoin, ei shamppakaljaa ennekuin on testattu enemmän. @Piru "Kiinnostavampaa olisi nähdä itse väylän siirtonopeus" Moiseen kait kelpaisi esim 512kt-1024kt lukeminen siten että käyttiksen cachet on disabloitu. Luulisi että A1 pystyy samaan tai piirun verran parempaan kuin peg1April2, mutta himpun verran peg1:stä suuremmalla CPU kuormalla/haitalla koska L2 cacheja joudutaan (ymmärtääkseni) lataileen A1:ssä uudestaan. Eniten se kait harmittaa jos esim animaatio/multimedia alkaa tökkimään nuiden cachejuttujen takia. Muistuu mieleen kuinka kavereiden A1200/030 ja A4000/030 pyöritti animaatiota jouhevammin kuin minun A4000/040.   Joanna Lauantaina, 3. huhtikuuta, 2004 - klo 9.23:    Kimmok: Ei ehkä hän, mutta en ollut ihan 100% varma oliko se hänen koneensa jolla tuota oli testattu. Siis Hyperion on ennenkin mokannut tuonkokoisia juttuja (mm. puhuttaessa Articia S:n Ram-nopeudesta) joten ei se olisi mitenkään täysin poissuljettua. Tuo koneteho on ongelmallinen ja monimutkainen kysymys. Ainakin jos (kuten olettaisin) AmigaOnessa tulee Audion/näyttökorttien toimintaan samaa säätämistä kuin Pegasos 1:ssä. Samaten on mielenkiintoista nähdä mitä tapahtuu kun nitä DMA:ta on useampia (esim audio-samplaus samaan aikaan USB ja Ide hakujen kanssa) koska ilmeisesti kaikkien ajureiden pitää sisältää samanlaiset CPU-Cachen tyhjennys-rutiinit.   miksuh Lauantaina, 3. huhtikuuta, 2004 - klo 12.35:    "The IDE driver is still very unoptimised. Performance is between 20-30 MB/s on average. The benchmark program is 68K being emulated however." Hyvä alku kuitenkin   miksuh Lauantaina, 3. huhtikuuta, 2004 - klo 12.37:    Hmm a1ide.device, no nyt on ainakin huomattavasti loogisempi nimi tolla. Ei enää mitään outoa scsi.deviceä ide-leveille jne   itix Lauantaina, 3. huhtikuuta, 2004 - klo 14.16:    Olisi kyllä kiva tietää miksi tuo kyseinen kokoonpano antaa siirtonopeudeksi vain 16MB/s. Se on puolet siitä mitä SysSpeed näyttää täällä ja 2/5 SCSISpeedin tuloksesta. Jos testissä on käytetty jotain vanhaa 80MB kiintolevyä tms. niin kannattaisi mainita.   JPQ Lauantaina, 3. huhtikuuta, 2004 - klo 14.17:    miksuh: joo mutta toisaalta siksi se scsi.device kuvaavampi kun rajapinta oli muistanko väärin scsimainen joka toteuttaa hommat sitten IDEnä vai oliko jopa se rauta tasolla tuollain???? muistaisi vain   Pekka Nissinen Lauantaina, 3. huhtikuuta, 2004 - klo 16.38:    @Piru Ihan uteliaisuuttani kyselen, mitenkäs tuo peg1 suoriutuu noista samoista mittauksista? Itsellä tuo A1XE antaa hdparm:lla ~40MB/sec, mutta en tiedä ovatko sen antamat luvut edes vertailukelpoisia...   KimmoK Sunnuntaina, 4. huhtikuuta, 2004 - klo 0.57:    @itix Ja millä se sinä testasitkaan? (huomasit varmaan että tuolla AW:ssä oli testattu 68k testisoftalla, NON-JIT 68k emussa) ANN:stä pikaisesti selattuna porukalla vaihtelee aika paljon nuo nopeudet. Mutta niinkuin Piru tuumasi, töitä varmasti on vielä optimoinnissa vaikka tuossa olisikin ollut hidas levy. @Pekka Linuxissa? UDMA:lla?   Piru Sunnuntaina, 4. huhtikuuta, 2004 - klo 3.27:    Pekka: En voi testata juuri nyt, ei ole pega ykkösessä näppäimistöä (se ajaa debiania tällä hetkellä 2.6.4 kernelillä). Selkeästi hitaampi kuin Peg2 kuitenkin (Artician vuoksi). Tulokset eivät ole vertailukelpoisia. Kiinnostavampi tulos saadaan SCSIBench ohjelmalla, Transfer Size "256 k" ja Transfer Type "Same Sector". Tällöin mitataan IDE-väylän nopeutta, eikä kyseisen levyn pitemmän aikavälin siirtonopeutta. Peg2 G4 + Seagate Barracuda 7200.7 antaa tulokseksi noin 90MB/s.   Janne Sunnuntaina, 4. huhtikuuta, 2004 - klo 9.32:    Itse olen ollut aina sitä mieltä että jollain tavalla A1:n dma saadaan toimimaan luotettavasti. Ongelma on se, että asiassa on kestänyt näin kauan mikä kielii että ongelmaa ei oikein ymmärretä tai osata täysin vielä kiertää... Lienee siis vakava kuten bplan totesi ja bbrv liioitteli. Katsotaan milloin ratkaisu tulee ja onko sillä suorituskykyvaikutusta. Olisin yllättynyt jos ongelmaa ei saada korjattua. Tippuivat muuten Alan Redhousen pisteet kun mies rupesi oma-aloitteisesti ja ihan turhaan fudaamaan pegasosta amigbg-puhelinpuheessaan. Syvällä mennään...   itix Sunnuntaina, 4. huhtikuuta, 2004 - klo 12.21:    @KimmoK: "Ja millä se sinä testasitkaan? (huomasit varmaan että tuolla AW:ssä oli testattu 68k testisoftalla, NON-JIT 68k emussa)" Samalla testiohjelmalla mitä AW:n screenshotissa oli käytetty. MorphOS:n JIT tietysti auttaa hiukan mutta merkitys ei ole suuri (silmukka on lyhyt ja kutsuu vain käyttisrutiineja). Joku oli testannut Peg2/G4:lla ilman JIT:iä ja tulos oli ollut jopa parempi.   itix Sunnuntaina, 4. huhtikuuta, 2004 - klo 12.46:    Näyttäisi myös että Peg2 on nopeampi. Paras Peg1 tulos on ollut ~40MB/s kun paras Peg2 tulos on ollut ~60MB (SCSIspeedillä mitattuna). ANN   Joanna Sunnuntaina, 4. huhtikuuta, 2004 - klo 12.53:    itix: Ei ole suuri ihme että Pegasos 1 ja 2 välillä olisi ide-siirtonopeudessa eroja, siihen vaikuttaa moni asia, kuten PCI:n toteutus, SDrammi-kontrolleri yms..   Pekka Nissinen Sunnuntaina, 4. huhtikuuta, 2004 - klo 14.13:    @KimmoK Juu, Linuxissa UDMA:lla. Tuohon testiin vaikuttaa aika paljon tuo käytettävä levy. Kun kokeilin tuota samaa testiä 1.5 vuotta vanhalla Maxtorin 80GB D540X -levyllä niin sillä irtoaa ~35MB/sec ja tällä uudemmalla DiamondMax +9:llä tuo ~40MB/sec. @Piru & Muut Löytyisikös tuonne Linukan puolelle mitään SCSIspeed:iä vastaavaa softaa? Tuosta SCSIbench:istä löysin sorsat, mutta se ei näytä kääntyvän suoraan PPC:lle, x86:lle kylläkin...   Marq Sunnuntaina, 4. huhtikuuta, 2004 - klo 17.05:    Pekka: hdparm -t kertoo suuntaa-antavaa tietoa levyn nopeudesta.   Pekka Nissinen Sunnuntaina, 4. huhtikuuta, 2004 - klo 17.34:    @Marq Juu, tiedän. Sillähän minä nuo "mittaukset" teinkin! Kysymys olinkin siitä, että löytyisikö jotain tuota SCSIspeed:iä vastaavaa Linukalle. Nuo hdparm:in tulokset kun eivät ole oikein vertailukelpoisia, kuten Piru jo tuossa aikaisemmin sanoikin: "Tulokset eivät ole vertailukelpoisia. Kiinnostavampi tulos saadaan SCSIBench ohjelmalla, Transfer Size "256 k" ja Transfer Type "Same Sector". Tällöin mitataan IDE-väylän nopeutta, eikä kyseisen levyn pitemmän aikavälin siirtonopeutta."   - Sunnuntaina, 4. huhtikuuta, 2004 - klo 19.36:    @Pekka Nissinen bonnie++ on aika hyvä tollaiseen testaamiseen. Löytyy debianin apt-get paketeista.   KimmoK Sunnuntaina, 4. huhtikuuta, 2004 - klo 20.48:    sanat män suusta. Bonnie on aika hyvä... testattiin muinoin AmigaDE:tä sillä. Pistää raudan lujille... mutta niinhän se pitääkin.   KimmoK Maanantaina, 5. huhtikuuta, 2004 - klo 15.06:    Tässä selitys sille miksi IDE ajurin olemassa olo ei riitä siihen että DMA toimisi Artician kanssa: ANN: "Gary Colville (81.86.241.100) on 05-Apr-2004 11:44:26In Reply to Comment 183 (Nate Downes): DMA cache coherency is usually handled at a level above the actual driver code, so you don't need 'custom' drivers - and this is the case with the Linux IDE system. The ArticiaS 'fix' is implemented in the IDE DMA layer and affects all the IDE drivers, so the 686B driver remains unchanged." Selittää erittäin paljon.   Pekka Nissinen Tiistaina, 6. huhtikuuta, 2004 - klo 13.57:    @KimmoK Kun sinulla kerran on tuosta Bonnie++:sta aiempaa kokemusta, millaisia parametrejä ehdottaisit testiä varten? Pistä vaikka mailia niin lähetän sulle sitten testin tulokset, jos siis kiinnostaa...?   KimmoK Tiistaina, 6. huhtikuuta, 2004 - klo 14.38:    @Pekka Konsultoin asiaa gurummalta kaverilta ... on jonkin verran aikaa kun moiset kokeilut oli meneillään.... Esim. AmigaDE:tä varten sitä piti "puukottaa" jotta se toimi. Ja kaikki aivan testit ei olleet käytössä. Selvinpänä SMP:tä käyttävä testi.   KimmoK Tiistaina, 6. huhtikuuta, 2004 - klo 14.39:    ... siis ... palaan asiaan...   - Tiistaina, 6. huhtikuuta, 2004 - klo 15.34:    @Pekka Nissinen Jos haluat muitten plattisten kanssa vertailu kelpoisia tuloksia niin aja testi ilman mitään parametrejä. Silloin testi suoritetaan 2x keskusmuistin kokoisella fileellä/fileillä. Silloin ei enään käyttiksen levy välimuistit sun muut pääse parantamaan tulosta vaan saat väylän todellista suorituskykyä kuvaavat tulokset.   Piru Tiistaina, 6. huhtikuuta, 2004 - klo 17.11:    -: Mikäli testi lukee/kirjoittaa tämän koko tiedoston, näin et saa väylän nopeutta vaan levyn pitemmän aikavälin siirtonopeuden, joka on lähes aina alhaisempi kuin väylän nopeus (esim 58MB/s vs. 90MB/sec).   - Tiistaina, 6. huhtikuuta, 2004 - klo 18.12:    @Piru Bonnien kotisivulta lainattuna... "The main program tests database type access to a single file (or a set of files if you wish to test more than 1G of storage), and it tests creation, reading, and deleting of small files which can simulate the usage of programs such as Squid, INN, or Maildir format email." Eli ison fileen tarkoitus on että koko filetto ei mahdu välimuistiin. Tarkoitus ei ole lukea koko filettä. Lisää infoa ja sorsat osoitteesta. http://www.coker.com.au/bonnie++/ Muistaakseni aikalailla ANSI C:tä joten pitäisi kääntyä lähes mille tahansa alustalle.   Piru Tiistaina, 6. huhtikuuta, 2004 - klo 19.05:    -: "Eli ison fileen tarkoitus on että koko filetto ei mahdu välimuistiin. Tarkoitus ei ole lukea koko filettä." Njoo, mutta ei se siltikään väylän nopeutta testaa. Lähinnä tuo taitaa testata levyjärjestelmää kokonaisuudessaan, mukaanlukien filesysteemi. Ja tuo ei tod ole ANSI C:tä, vaan C++:aa ja haluaa mm. fork():n.   KimmoK Keskiviikkona, 7. huhtikuuta, 2004 - klo 17.42:    @Pekka pala infoa: Ranella oli muinoin perus Bonnie käytössä. Ei mitään ihme parametrejä ja "forkki piti tappa pois". Bonnie++:lle ei parmetrejä ollu tiiossa. (olipa auttava vastaus eikös jees) (on muuten hemmetin hienoa että se AmigaDE SDK kytketään ethernet kortin mac osoitteeseen ... eipä turhan helpolla kokeilla enään uudestaan ... puhumattakaan AmigaDE:n Linux epäyhteensopivuuksista)   KimmoK Tiistaina, 13. huhtikuuta, 2004 - klo 9.24:    Onkos kuulunut uutta IDE DMA:n testeistä? Mitä testejä on viimeaikoina tehty AOS4:n IDE DMA:n testaamiseksi? (kai nyt jotain voi vihjata ilman että NDA lyö sormille....)   Jope Tiistaina, 13. huhtikuuta, 2004 - klo 17.53:    Kimmo, aika monen kortin mac-osoitteen voi määritellä itse.