Journal Support matériel parfait sous OpenBSD

Posté par  .
Étiquettes : aucune
0
5
nov.
2006
Bonjour !

Suite à la sortie d'OpenBSD 4.0 ( http://linuxfr.org/2006/11/02/21566.html et http://linuxfr.org/~lapinflemard/23026.html ), j'ai mis à jour mon portable (Dell D410, un petit bijou de technologie ultraportable avec une autonomie démente), et j'ai décidé de tester le support de l'ACPI récemment ajouté, mais non activé par défaut ( http://undeadly.org/cgi?action=article&sid=2006101219152(...) )

Pour cela, il fallait tout d'abord mettre à jour vers le snapshot binaire le plus récent, puis récupérer les sources -CURRENT, et recompiler le noyau en activant l'option ACPI_ENABLE dans le fichier de configuration GENERIC. Au début, ca fait un peu peur, mais en suivant la faq ( http://www.openbsd.org/faq/faq5.html ) c'est aussi facile que sous linux, et même plus rapide.

Maintenant, tout marche à merveille : le niveau de charge de batterie, le statut en charge / décharge, la température du processeur, les evénements lorsque j'appuie sur le bouton power, le suspend lorsque je ferme l'écran, tout ça s'ajoute à ce qui était déjà supporté comme le chipset wifi iwi2200, le chipset son, la variation de fréquence processeur à la volée avec le speedstep, le chipset graphique i915GM, j'arrive même à faire tourner composite (mais sans accélération graphique, pas de DRI sous OpenBSD) et c'est relativement fluide.

Pour le plaisir, un morceau du dmesg :

cpu0: Intel(R) Pentium(R) M processor 2.00GHz ("GenuineIntel" 686-class) 2 GHz
cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,TM,SBF,EST,TM2
cpu0: Enhanced SpeedStep 2000 MHz (1356 mV): speeds: 2000, 1600, 1333, 1067, 800 MHz
real mem = 2138472448 (2088352K)
avail mem = 1942503424 (1896976K)
using 4256 buffers containing 107048960 bytes (104540K) of memory
mainbus0 (root)
bios0 at mainbus0: AT/286+(00) BIOS, date 09/28/05, BIOS32 rev. 0 @ 0xffe90, SMBIOS rev. 2.3 @ 0xf7810 (60 entries)
bios0: Dell Inc. Latitude D410
pcibios0 at bios0: rev 2.1 @ 0xf0000/0x10000
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfb2d0/176 (9 entries)
pcibios0: PCI Interrupt Router at 000:31:0 ("Intel 82371 ISA and IDE" rev 0x00)
pcibios0: PCI bus #3 is the last bus
bios0: ROM list: 0xc0000/0xf800! 0xcf800/0x800
acpi0 at mainbus0: rev 0
acpi0: tables DSDT FACP APIC ASF! MCFG SSDT SSDT SSDT
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpiac0 at acpi0: AC unit online
acpibat0 at acpi0: BAT0: model: DELL X53086 serial: 30511 type: LION oem: Sony
acpibat1 at acpi0: BAT1: not present
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: PBTN
acpibtn2 at acpi0: SBTN
acpicpu0 at acpi0: CPU0: 2000, 1600, 1333, 1067, 800 MHz
acpitz0 at acpi0, critical temperature: 100 degC

Et le résultat de sysctl hw :

hw.machine=i386
hw.model=Intel(R) Pentium(R) M processor 2.00GHz ("GenuineIntel" 686-class)
hw.ncpu=1
hw.byteorder=1234
hw.physmem=2138472448
hw.usermem=2137903104
hw.pagesize=4096
hw.disknames=wd0
hw.diskcount=1
hw.sensors.0=acpiac0, power supply, On
hw.sensors.1=acpibat0, last full capacity, 4.65 Ah
hw.sensors.2=acpibat0, warning capacity, 0.48 Ah
hw.sensors.3=acpibat0, low capacity, 0.14 Ah
hw.sensors.4=acpibat0, voltage, 11.10 V DC, OK
hw.sensors.5=acpibat0, state, 0 raw, OK
hw.sensors.6=acpibat0, rate, 1 raw
hw.sensors.7=acpibat0, remaining capacity, 4.80 Ah
hw.sensors.8=acpibat0, current voltage, 12.61 V DC, OK
hw.sensors.9=acpibat1, last full capacity, 0.00 Wh
hw.sensors.10=acpibat1, warning capacity, 0.00 Wh
hw.sensors.11=acpibat1, low capacity, 0.00 Wh
hw.sensors.12=acpibat1, voltage, 0.00 V DC, OK
hw.sensors.13=acpibat1, state, 0 raw, OK
hw.sensors.14=acpibat1, rate, 0 raw
hw.sensors.15=acpibat1, remaining capacity, 0.00 Wh
hw.sensors.16=acpibat1, current voltage, 0.00 V DC, OK
hw.sensors.17=acpitz0, zone temperature, 47.55 degC
hw.cpuspeed=800
hw.setperf=0
hw.vendor=Dell Inc.
hw.product=Latitude D410
hw.serialno=JFBN82J
hw.uuid=44454c4c-4600-1042-804e-cac04f38324a


Pour conclure, le DELL D410 est vraiment un super petit portable (12", 2Go de RAM, centrino), très bien supporté sous OpenBSD sans avoir besoin de blobs propriétaires :)
Bon, évidemment, toutes ces choses sont déjà supportées sous Linux depuis 2-3 ans, mais je trouve très positif que le support matériel s'améliore toujours dans les autres OS libres, la diversité et le choix ça a du bon :)

N'hésitez pas à poser des questions si vous voulez essayer ce BSD en tant que station de travail multimédia, vous n'en serez pas décu !

Ps: j'ai fait ce journal pour avoir un peu plus de "visibilité" qu'un commentaire succint sur une dépêche/journal qui date d'une semaine, désolé si des gens trouvent qu'on parle trop d'autres choses que linux sur linuxfr.. :)
  • # grille d'aération sous le portable...

    Posté par  (site web personnel) . Évalué à 6.

    Je viens de regarder un peu à quoi ressemble cet ordinateur portable, et ce que je retiens, c'est qu'il fait partie de la famille "portable avec une grille d'aération sous le capot".

    Les ordinateurs portables étant dans la majeure partie des cas posés sur une table, à quoi cela sert il de mettre une grille d'aération qui va se trouver d'office obstruée ? Et cela ne peut il pas causer des problèmes de refroidissement de l'engin ?
    • [^] # Re: grille d'aération sous le portable...

      Posté par  . Évalué à 4.

      C'est une bonne question, dans tout les cas l'air chaud sort sur le coté gauche du portable, la grille cache un ventilateur aspirant l'air ambiant par le dessous...
      Mais il ne chauffe pas énormément.
      • [^] # Re: grille d'aération sous le portable...

        Posté par  (site web personnel) . Évalué à 4.

        effet de sol !

        (je dis ca pour rire.) Cependant, l'ordinateur est a qques mm de la table grace aux picots de maintien.

        Je suis sur que capter de l'air par le bas et bénéficiant ainsi de l'effet de sol (ou du moins d'un flux laminaire d'air.

        Après, ca depend ou c'est sous l'ordi. Si c'est au milieu, c'est bien :) ca chauffe pas les genous ;)
  • # Pas de blob propriétaire avec un wifi intel 2200 ?

    Posté par  . Évalué à 3.

    Bonjour,

    Merci pour le test. Je suis en train de télécharger Openbas pour essai.
    Mais je suis surpris par le fait qu'il y ait le support des chipset wireless d'intel sans blob propriétaire :

    Cf : http://kerneltrap.org/node/4202

    Cordialement
    • [^] # Re: Pas de blob propriétaire avec un wifi intel 2200 ?

      Posté par  . Évalué à 2.

      C'est quoi un Openbas ?
    • [^] # Re: Pas de blob propriétaire avec un wifi intel 2200 ?

      Posté par  . Évalué à 5.

      Ces drivers wifi d'OpenBSD sont developpés en faisant du reverse-engeneering sur les drivers binaires linux, en particulier grace à l'excellent travail de Damien Bergamini : http://damien.bergamini.free.fr/ipw/iwi-openbsd.html

      Cf http://kerneltrap.org/node/6650/ pour l'exemple du driver wpi pour les chipsets 3945ABG.

      Certains chipsets ont cependant encore besoin d'un firmware, qui est lui non libre.
    • [^] # Re: Pas de blob propriétaire avec un wifi intel 2200 ?

      Posté par  . Évalué à 2.

      Avec Intel, c'est des fois "libre", et des fois moins libre.

      Les chipsets IPW2100 & IPW2200 (respectivement pour les Centrino à base de Pentium M et de Core Duo) ont un driver libre, accompagné comme la plupart des chips d'autres marques, d'un firmware proprio. (faut que tout le monde arrête d'appeler "blob" tout et n'importe quoi : à la base, c'est une notion de BDD...).

      Par contre, les chips IPW3945 (pour les Core 2 Duo) ont un dirver libre ayant besoin d'un daemon proprio (sous linux) qui tourne en user space, + un firmware proprio. Et là c'est beaucoup moins top. Comme indiqué plus haut, pour OpenBSD, le driver est entièrement libre et sans démon grâce au travail de reverse engeneering de Damien Bergamini.

      Ca pourrait être intégré à Linux, mais je pense qu'il y a des tensions de parts et d'autres : d'un coté c'est Intel qui maintient les drivers libres Intel (intégrés au noyau); ça leur ferait peut-être pas plaisir que quelqu'un se ramène avec une version libérée tout en demandant à ce qu'ils maintiennent les autres drivers déjà libres (bon, d'un côté, on a aucune obligation de faire plaisir à Intel, c'est clair; ni Intel n'a d'obligation de continuer à maintenir ses drivers). Mais bon d'un coté, il me semble que les devs du kernel sont en train de virer la pile ieee80211 softmac de Intel (utilisée par quelques chips softmac, dont ceux des Centrino) pour celle de DeviceScape, donc ça a l'air bien parti pour la bataille...
      • [^] # Re: Pas de blob propriétaire avec un wifi intel 2200 ?

        Posté par  . Évalué à 2.

        >Par contre, les chips IPW3945 (pour les Core 2 Duo)

        Plus précisément, la plate-forme Napa introduite début 2006, pour les Core 1 Duo (Yonah) et jusqu'ici les Core 2 Duo. La prochaine, Santa-Rosa, implique un changement de carte; espérons qu'Intel ne fournisse pas de démon binaire en cadeau avec son ipw4965...
      • [^] # Re: Pas de blob propriétaire avec un wifi intel 2200 ?

        Posté par  . Évalué à 8.

        Je me permets une petite remarque concernant l'emploi du terme blob.

        Si mes souvenirs sont bons, blob signifie "binary large object", et c'est plus qu'une notion de BDD mais un type de données.

        Hors dans le cas des drivers proprio c'est bien de cela qu'il s'agit: un objet binaire, dont on ne connait le fonctionnement interne. Celui-ci tourne souvent en mode noyau, donc avec accès complet au système.

        Comme les joyeux développeurs d'OpenBSD se servent du terme de manière cohérente dans un sens précis, et que cet usage est répandu, je ne vois pas de raison de s'en priver.

        Accessoirement l'usage de ce terme permet de faire des dessins avec un gros méchant pas beau et gluant.
        • [^] # Re: Pas de blob propriétaire avec un wifi intel 2200 ?

          Posté par  . Évalué à 4.

          Oui, sauf que on appelle blob un firmware, un driver proprio, ou un programme proprio, sans faire la distinction.
          En l'occurence, dans notre cas, on ne parle pas du tout de driver binaire : quand les gens parlent des "blobs" d'Intel, ici, c'est soit le firmware (qui tourne sur la carte wifi), soit un démon proprio (qui tourne donc en espace utilisateur, pas en noyau). Ce n'est pas le cas que tu décris (c'est pour ça d'ailleurs que je trouve que blob porte à confusion : je n'ai pas l'impression qu'on parle du même blob).
  • # comique ?

    Posté par  . Évalué à 2.

    Pour cela, il fallait tout d'abord mettre à jour vers le snapshot binaire le plus récent, puis récupérer les sources -CURRENT, et recompiler le noyau en activant l'option ACPI_ENABLE dans le fichier de configuration GENERIC. Au début, ca fait un peu peur, mais en suivant la faq ( http://www.openbsd.org/faq/faq5.html ) c'est aussi facile que sous linux, et même plus rapide.


    On n'est vraiment pas près pour le bureau, vu la faq et sa longueur. Je vais finir par croire que mon iBook entièrement supporté sauf Airport, clavier mac_fr et micro par défaut par ubuntu, ça tient du miracle.

    Enfin, si tu trouves que c'est aussi facile, comme tu dis, tant mieux pour toi :¬).

    Au passage, que signifie une autonomie démente ? En lecture en plein écran et en boucle de DVD et en navigation internet comme exemple d'utilisation. Et puis son temps de recharge aussi, ce serait bien, parce que démente est une description un peu courte, tu le reconnaitras ;¬D…
    • [^] # Re: comique ?

      Posté par  . Évalué à 3.

      Ca veut dire quoi ca ? Si la doc est complète et bien écrite, c'est que le système est compliqué ? Sincèrement, si on a un peu de bouteille en Linux, on est pas perdu sous *BSD.
      De plus, OpenBSD s'en tamponne pas mal d'être "près pour le bureau" : http://www.monkey.org/openbsd/archive/misc/0207/msg01799.htm(...)

      Oui, ca peut paraître "élitiste à mort" mais c'est un point de vue qui me plaît bien :)

      Et niveau autonomie, j'ai déja regardé 2 films a la suite dans le train, et la batterie m'affichait encore une bonne heure disponible... en faisant que du code/terminal/compilation, les 2 batteries doivent permettre d'atteindre les 9h je pense.
    • [^] # Re: comique ?

      Posté par  (site web personnel) . Évalué à 3.

      D'un autre côté sous Linux pour des trucs super courants faut aussi mettre un peu les mains dans le cambouis dans un premier temps. Et la base de développeurs et d'utilisateurs est pas la même...
      Moi au contraire ça m'impressionne : j'ai l'impression que le support matériel des BSD est meilleur que celui de Linux ! En tout cas pour la carte TV et les deux cartes wifi en PCI que j'ai pu toucher, c'était clairement le cas.
      • [^] # Re: comique ?

        Posté par  . Évalué à 2.

        Je suis du même avis, comme par exemple l'utilisation des chipset raid integrés (Promise et consort) :

        Sous Freebsd : il voit qu'un raid est configuré, il le gère directement, rien a faire, aux yeux de l'utilisateur, aucune manip à faire. (comme si c'etait du bon raid 100% hardware :D )

        Sous Linux : il voit deux disques durs, il faut lancer un dmraid pour qu'il mappe le raid. Si le système est sur le raid de la carte mère, il faut en plus intégrer dmraid dans l'initrd ... en bref tout sauf evident, (et surtout j'ai toujours pas compris pourquoi le boulot fait par dmraid n'est pas fait pas le noyau :/ ). Et surtout trés peu de distribution le supporte nativement (a vous de créer le bon intrd et compagnie) ...
        • [^] # Re: comique ?

          Posté par  (site web personnel) . Évalué à 4.

          Bienvenue dans la qualité BSD. :)

          Sur mon portable, depuis le support cpufreq et acpi dans FreeBSD je me suis empressé de virer Linux, sous linux, plein de modules pour l'acpi, et un peu de conf, sous FreeBSD, je charge deux modules au démarrage, le process qui va bien pour le cpufreq, et c'est tout !!! Simple et efficace, la gamme de variation de fréquence proposée pour mon CPU (pentium-m) est plus importante que celle détectée par dernière version de linux que j'ai pu tester.

          Je n'ai jamais aussi peu entendu le ventillo de cette machine y compris sous le Windows installé par le constructeur. Ma batterie est elle aussi très bien gérée.

          Je testerai bien OpenBSD dessus maintenant que le support ACPI existe.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.