Murakami et le ONE PoWeR WEEK de cette semaine nous ont révélé des informations intéressantes concernant le développement d’AmigaOS 4.0.
En fait, ces informations sont passées sur la mailing-list AmigaOne francophone et ont été données par Stéphane ‘sg2’ Guillard.
Voici ce qu’il y dit :
Nous venons de corriger un bug dans UBoot, qui empêchait les cartes combo (embarquant un bridge PCI vers PCI) de fonctionner. Je suis à l’origine de la détection du problème, mais c’est hjf qui a trouvé la solution. Vous pouvez voir [ici] le pciscan de mon XE avec une carte SATA/USB/firewire, avec le disque SATA en cours de Scsibench ! L’UBoot correspondant sera prochainement mis à disposition de tous.
En termes de pilotes :
- Tous les pilotes IDE/SATA/SCSI OS4 sont utilisables avec ces cartes si elles portent les chips supportés par les pilotes. Dans mon cas, ma carte porte un chip SATA sii3112, donc pas de problème.
- La fonction USB nécessite un nouveau pilote. OS4 est livré avec un pilote au standard UHCI qui correspond à la fonction USB du VIA686b de la carte mère des A1, or les cartes multifonctions implémentent généralement le standard OHCI. Pas de problème, on a maintenant un pilote OHCI, qui est en cours de betatest, et qui sera aussi livré bientôt. Pour votre information, bien que cela ne se voie pas sur la capture d’écran ci-dessus, la souris est contrôlée par la fonction USB de la carte combo avec ce nouveau pilote !
- Pour le firewire, il faut un pilote dérivé de OHCI donc espoir.
Pour info, j’ai été pris par des tonnes d’autres choses :
- L’écriture du pilote SCSI, maintenant quasi-terminée, et qui marche très bien (avec les cartes PCI à base de chip LSI/NCR/SYM 53c8xx).
- La correction du bug d’UBoot cité en haut de ce communiqué.
- La correction d’un bug dans le kernel, concernant le cache des G3, qui est à l’origine de pas mal de comportements bizarres observés avec les drivers DMA (drag&drop vers disque dur trashé, etc).
Source : ONE PoWeR WEEK n°12
14 Commentaires
Passer au formulaire de commentaire
Auteur
Merci à Murakami pour cette information que je n’aurais jamais trouvé sans le OPW, n’étant pas sur la ml AmigaOne Francophone (forcément, je n’ai toujours pas d’AOne).
—
/me se devait de le dire.
je viens de voir le grab… euh… ca rame ce disque dur… et pourtant c’est pas un “vieux” vu la capacité… et la norme (SATA)… quid ?
d’où il indique la vitesse ? je ne vois rien qui y ressemble.
A part ce 41479 sans unités de mesure. ça pourrait bien être des patates que ce serait pareil :-/
oui c’est bien ce chiffre là qui est le débit du disque SATA de 120Go…c’est lu par blocs de 128 k octets et toujours le même secteur (donc a tourne avec la mémoire cache du disque exclusivement) Sur un bus qui peut transférer 150Mo/seconde, je trouvecela un peu faible…. même si il y a le goulot d’étranglement ‘PCI’. d’où mon interrogation…. ici sur l’IDE ca tourne entre 75000 et 95000 selon le disque…. d’où mon grand étonnement…..
C’est super utile de faire un benchmark de bus sachant qu’auccun périphérique ne pourra en atteindre la limite.
Fantasmer sur la relecture d’un unique bloc en boucle, voila bien une occupation inutile, à l’image de tes commentaires.
L’OHCI (USB 1.1) et l’OHCI 1394 (Firewire) n’ont rien avoir. Il s’agit de deux spec compltement différrentes. De plus, il ne suffit pas d’avoir un pilote pour le Firewire, mais la pile qui va avec.
Bye
OHCI
Short for Open Host Controller Interface, OHCI was developed by Compaq and is a standard that allows a computer host to interface with Firewire and USB 1.0 and 1.1 devices.
Désolé Crisot, mais je trouve quand meme intéressant de remarquer que le transfert avec ce test débile n’est pas encore “au top”… une bien meilleure réponse aurait été de soulever que “probablement le pilote (ou je ne sais quoi) n’est pas finalisé et/ou tourne peut être encore en mode debug” ça aurait été bien moins puéril et au combien plus approprié que ta réponse à l’emporte pièce qui finalement (à mon avis) ne donne en aucun cas une image favorable de ton “camp”.
Le mieux aurait quand même été de poser la question au développeur ou que celui-ci réponde ici (ou que quelqu’un rapporte sa réponse)…
Personnellement je ne suis pas vraiment surpris de ce résultat en effet il s’agit quand même d’une carte “bridge” monté sur un port pci et tout le monde sait que ce port ne date pas d’hier.
De toute façon comme le souligne Crisot ce test ne démontre rien, ne sert à rien, est inutile, caduque, nul et non avenu, une pure perte de temps, car aucun périphérique n’est capable d’atteindre le taux de transfert max…
Seulement il y en a toujours qui viennent rajouter leur grain de sel pour dire que ça rame….
Mais pourquoi s’embéter à optimiser des pilotes puisque les périphériques capables d’exploiter une telle bande passante sont de la science fiction ?
Il y a des choses plus importantes à mon humble avis.
Oui il y a des choses plus importantes comme garantir l’intégrité des données. Maintenant que ceci semble enfin être fait (pour la nième fois ?), on peut s’intéresser à optimiser les transferts. 🙂
Mon “camp” à des pilotes pour 2 controleurs PATA, 3 controleurs SATA, 1 controleur SCSI en cours, pour l’USB intégré à ces cartes, et espoir de FW1394, grace à des gens comme Stephane.
Nul besoin que je post ici pour avoir une image favorable de mon “camp”.
@Crisot: Je ne sais pas ce que tu cherche à dire.. je n’ai pas critiquer le travail de Stéphane (bien au contraire) je trouve juste dommage de répondre ainsi… Alors qu’un bête “bin comme tu dis le bus doit limiter et de toute façon cette vitesse théorique mesurée de manière caduque n’est pas représentative du driver(/bidule) lorsqu’il sera définitif…”
Enfin moi je dis ça.. je dis rien…
d’un autre côté, avoir des cartes sata qui n’arrivent pas à dépasser les perfs d’un controleur ata100, quel intérêt?
Pour info, il existe pas mal de disques durs sur le marché qui dépassent les 50Mo/seconde…. et à mon avis le disque de la machine de sg2 doit en faire partie….