Bonjour à tous. Joyeux noël (et bientôt bonne année 2009) ! :-D

J'ai reçu un vaio vgn-z11mn il y a peu. J'ai vite viré vista puis réinstallé windows xp downgrade et fedora 10. J'utilise le noyau PAE vu que j'ai 4GB de ram avec et tout fonctionne si ce n'est la gestion graphique... (donc ça fonctionne pas tant bien au final)

L'ordinateur portable possède un switch software permettant d'utiliser soit une carte graphique intégrée Intel GM45 (pour la durée, l'autonomie sur batterie), soit une carte Nvidia 9300GS (pour pouvoir faire quelques petites choses plus intéressantes, mais au coût de l'autonomie réduite).

Pour les infos :
http://www.nvnews.net/vbulletin/showthread.php?t=120810
http://vaio-online.sony.com/prod_info/series1/z/interview_Z/index_05.html

A savoir :
Le switch est logiciel et non hardware. Et malheureusement, seul Vista a la fonction intégrée pour l'utiliser en plein utilisation. Reste que cela ne me dérangerait pas de pouvoir l'utiliser avec une contrainte de reboot.
Actuellement, j'arrive à faire fonctionner la bête en démarrant d'abord sous windows xp, puis en redémarrant - à ce moment, le switch s'allume pour le choix sélectionné - et en démarrant alors sur fedora 10. Reste que je dois par la suite configurer correctement X pour utiliser le bon driver... mais ce n'est pas si grave, j'ai créé deux fichiers xorg.conf différents pour l'occasion.

Mon problème, c'est de rendre la première partie automatisée. J'aimerais pouvoir activer le switch sans avoir à faire tout le processus win start - reboot - linux start à chaque fois.

Vu que les drivers nvidia sont actuellement loin de fournir cela (en tout cas pas les versions de nvidia), et que ce n'est pas prévu pour les drivers nouveau avant bien longtemps, j'aimerais au moins automatiser le processus de "passage" par windows.
Avez-vous des idées spécifiques ?

Actuellement, mon idée est :

[1]. placer une option dans grub pour ce processus start->reboot.
Pour faire cela, il suffit de pouvoir spécifier une entrée windows (en plus de l'entrée windows déjà existante) et de lui passer des paramètres qui puissent être examinés au démarrage de windows par un programme exécuté en tâche de démarrage. Simple à imaginer, mais je suis un peu bloquer par ... tout.

[2]. le programme défini au démarrage de windows vérifiera les paramètres passés au démarrage et s'il trouve un paramètre spécifique forcera le redémarrage de l'ordinateur portable... et hop, on peut démarrer (automatiquement) sur linux fedora 10 fonctionnel !

Au pire, dès que l'information du choix a été passé à windows, si j'arrive à la récupérer avec n'importe quoi, je vois bien comment faire pour le reste. Mais peut-on passer des paramètres à windows qui soient récupérables via un programme après le démarrage de base ?

Actuellement, le grub.conf : 
... blabla de fedora

title Windows XP
    rootnoverify(hd0,1)
    chainloader +1
Partitions : hda1 pour la RECOVERY, hda2 pour Windows xp, hda3 pour le /boot, hda4 étendue contenant /, /home et swap.

Peut-on passer des paramètres spécifiques à windows ? si oui, lesquels ? et comment récupérer ces valeurs par la suite au démarrage de windows ?
Je pense que passer par Windows est une idée sangrenue et qui ne fonctionnera pas. Il faudrait plutôt aller voir du BIOS et de Fedora 10. Pour moi, l'idée est plus d'avoir deux entrée dans GRUB, une utilisant la carte Intel, l'autre utilisant la carte Nvidia.

Première chose à savoir, est ce que Fedora n'utilise bien qu'une carte tandis que l'autre est "éteinte" ? (une méthode : en utilisant le chipset Intel, tu lances Nvidia-config (pilotes proprio), pour voir comment la carte NVidia est déctecté) Parce que je confierais pas en un voyant.
Deuxième chose, comment le système voit les cartes, donc colle le résultat de la commande "lspci"

Après on vera :-D
Tout dépend du fonctionnement du switch.

Actuellement, il y a déjà une solution post-switch :
http://neotokyo.sytes.net/vgn-z11/Ubuntu8.10_vaio_vgn_z11.html

Dès que le switch sera possible sans passer par windows, bas ça sera ok.
lspci renvoie :
1. switch "stamina" : seulement la carte intel est fonctionnelle (tant mieux, c'est le but)
2. switch "speed" : semblerait que les deux cartes soient fonctionnelles chez moi.. mais au moins la nvidia fonctionne bien (compiz & co marchent)
3. switch null : si pas de passage par windows, le switch est éteint et les deux cartes sont visibles, mais rien ne fonctionne

Donc le passage par windows est pas joli du tout, mais nécessaire pour faire fonctionner le switch.
Le fait de passer par windows, au contraire, fonctionnera certainement vu que c'est ce que je dois faire manuellement actuellement. Et ça marche ! :-P
Y con esto esta listo para que nuestro Vaio vng-z11 arranque nuestras X bajo cualquier circunstancia. La unica pega es que para realizar la conmutacion de una tarjeta a otra hay que arrancar primero en Windows XP el modo que deseemos utilizar stamina o speed y reiniciar.
Espero que os sea de utilidad.

Si averiguais la manera de conmutar la tarjeta sin la necesidad de arrancar en Windows XP, por favor remitírmelo a freeshark@gmail.com
Un saludo y gracias.
Effectivement, s'il y a moyen de toucher au bios pour faire fonctionner le switch, je veux bien... sauf que c'est un bios réduit insydeh20 bios qui ne contient que très peu d'options et surtout aucune à propos du switch...
Les vaio sz avaient une option permettant le switch hardware, donc peut-être qu'il y a moyen d'utiliser le bios des sz à la place... mais je n'ai aucune idée de comment on modifie le bios - ça doit pas être sans danger 😐 - ni si le bios des sz fonctionnerait.

Note : j'ai réussi à faire planter systématiquement windows xp au démarrage pour le faire rebooter :
ajouter un os "virtuel" au boot.ini pointant sur une partition de linux ou autre... (mais pas une bonne) vu qu'il est paramétré pour redémarrer en cas d'erreur, bas vu qu'il charge une mauvaise partition, ça foire et il redémarre... sauf que windows n'a pas vraiment démarré et le switch ne s'allume malheureusement donc pas... et ça ne fonctionne pas. 🙁

Dommage, j'aurai au moins essayé. Il reste donc la solution du démarrage sur windows complet puis redémarrage que j'aimerai automatiser.
Et il semblerait que grub ne permette pas de passer des options spécifiques au chainloader... donc il faudra probablement passer par boot.ini de winxp. Ou alors existe-t-il un moyen d'exécuter des programmes avant le démarrage qui aient des accès en écriture à quelque part ? (pour y placer une valeur spécifique correspondant au choix dans grub)

Et quelqu'un sait-il comment ce switch fait pour savoir comment et quand il doit s'allumer ? il ne s'allume qu'au redémarrage après avoir été sous windows xp (ce qui est fort étrange, car ça veut dire qu'il doit se passer quelque chose à ce redémarrage et c'est ça qu'il faudrait comprendre).
La solution du double xorg.conf est celle utilisée par la plupart des gens ayant ce type de notebook. Regarde quant même de ce côté (attention c'est du ubuntu) http://forum.ubuntu-fr.org/viewtopic.php?id=101072 voir les posts de Veskit (surtout le #15 qui devrait t'intéresser).
Refuznik wrote:La solution du double xorg.conf est celle utilisée par la plupart des gens ayant ce type de notebook. Regarde quant même de ce côté (attention c'est du ubuntu) http://forum.ubuntu-fr.org/viewtopic.php?id=101072 voir les posts de Veskit (surtout le #15 qui devrait t'intéresser).
A vrai dire, ça ne concerne pas mon problème. Effectivement, si je voulais activer toutes les foncitonnalités des cartes graphiques lorsque celles-ci fonctionnent. Bas il me serait utile de gérer les diverses librairies doublons pour opengl. Dans mon cas, je vais me restreindre pour l'instant à utiliser le mode stamina uniquement pour faire des choses de base ne nécessitant pas d'accélération graphique ou très peu (pas de 3d en tout cas).

Le problème est que ce post est relatif aux sz qui possèdent : un switch hardware, un bios permettant de spécifier la carte à activer.
Je possède un vaio z (!= sz) : un switch software, un bios ultra-réduit insydeh20 ne possédant rien pour spécifier la carte à activer.

La partie qui m'intéresse est de faire fonctionner le switch. Pour le reste, j'arrive à le gérer plus ou moins bien. Mais pour faire fonctionner le switch, il me faut démarrer sur windows puis redémarrer actuellement. C'est long, fastidieux. J'aimerais automatiser cela. Au mieux, trouver comment windows fait pour indiquer quel switch doit être démarré et comment le bios fait pour le savoir au démarrage (j'imagine que c'est le bios qui active le switch).

A ce qu'il paraît (lu sur nvnews), le bios fait son choix relativement au nom de l'os de la machine.
Y a-t-il un moyen d'accéder au code source du bios ?
Pour le BIOS, généralement plus fermé tu meurs. Donc hormis si tu as envie de coder un nouveau BIOS, ne passe pas par là ^^

Je ne comprends pas trop comment fonctionne le switch. Ça fonctionne à partir d'un logiciel sous Windows qui permet de choisir soit une carte soit l'autre ou bien c'est un bouton qui potentiellement "relié" à un pilote ? En gros, est ce que t'as besoin que windows démarre en entier ou non et comment choisi la carte à utilisée ? Aussi, le "chainloader +1" t'amène au gestionnaire de boot de Vista ou celui de XP ?

Enfin, là, ça s'oriente soit vers de reverse-ingineering soit vers un scriptage du démarrage de Windows.
Le switch est un bouton, cependant il fonctionne via ... ça dépend en fait.

Actuellement, je n'a que windows xp et fedora 10 en dual boot. Cela m'est nécessaire pour fedora car vista désinitialise le switch au redémarrage tandis que ce n'est pas le cas de windows xp.

Pour l'instant, je ne sais pas jusqu'à quel point windows xp doit démarrer pour que ça fonctionne. Il semble plutôt que le bios utilise une information fournie par le système d'exploitation au redémarrage.

Comment le switch fonctionne :

[Vista]
Le bios gère peut-être le switch au démarrage, cependant, sous Vista, on peut modifier le switch pendant l'exécution de Vista en modifiant le switch (bouton).

[Windows XP]
Le bios gère le switch relativement au dernier os qui a fonctionné. Si c'était windows xp, le switch s'allume sur le mode sélectionné avant le nouveau démarrage. (Cependant, même si le switch n'est pas allumé, windows arrive à utiliser les cartes graphiques)
Si c'était linux, le switch ne s'allume pas.

Donc le bios doit regarder à quelque part quel était le dernier OS qui a démarré. Si c'est windows xp, il fait fonctionner le switch. Sinon... bas c'est pas le cas pour linux... 😐

[Linux]
Si Windows xp était le précédent os, ça fonctionne sur la carte choisie avant le démarrage.
Sinon, les deux cartes sont allumées (le switch est éteint) et rien ne fonctionne.
Dans tous les cas, lorsque linux s'éteint, il désinitialise le switch et au prochain démarrage, le switch sera éteint.

Finalement, ça dépend donc de l'os qui a fonctionné précédemment.

A propos du switch :
Le switch est un bouton qui peut être soit sur "stamina", soit sur "speed". Chaque côté possède un LED. Soit ils sont les deux éteints, soit stamina est allumé, soit speed est allumé. Lorsqu'on modifie l'état du switch pendant l'exécution, ça ne modifie pas le LED allumé à moins d'être sous windows Vista.
Donc le LED allumé indique la carte graphique utilisée. Sur XP, on aura beau changé, la carte utilisée ne changera pas. Sous linux non plus. Sous vista oui.
Par contre, si aucun LED n'est activé, linux n'arrive pas à faire fonctionner les cartes graphiques et les deux semblent disponibles (d'après lspci).

A voir :
http://www.nvnews.net/vbulletin/showpost.php?s=d983c74e9dfc85a80e19f7aca9368b48&p=1856567&postcount=13
Short story long, I think this is a combination of factors biting us - a poor system BIOS that is completely unconfigurable (I've never seen a BIOS with fewer options), that relies on detecting Windows versions to determine operation (this is something we may be able to leverage, though it's really an ugly hack). Plus the long-standing poor handling of multiple VGA adapters under linux, and probably some xorg and nvidia-drivers deficiencies in int10 initialization.

All that said, I've never looked at any of this code before, so I could be completely wrong in all of my assertions. My theory and hope though is, if Vista can initialize the card when booted in the same state we get it in Linux, then we should be able to do so too...

We could probably work around these problems temporarily with the bios-from-file hack, but BiosLocation has now been removed completely for being 'dangerous' (don't use it unless you need it, but don't remove it while it's still useful!), and various other sections have changed. I may look at implementing some analogue (maybe just mmap the bios dump and point BiosBase at it would work?) against the current code...

I have some register dumps from Windows when flicking the stamina/speed switch if they're at all usefull, but I've not been able to trace the ACPI calls involved since my Vista seems to hang after about 30 seconds when debug is enabled.
A mon avis, les solutions :

[1]. Démarrage windows, redémarrage automatique et passage sous linux automatisé (mais c'est très lourd et long)

[2]. Modifier le bios (mais je vois mal comment)

[3]. Forcer l'information du dernier OS fonctionnel à être Windows XP... mais où cela se trouve-t-il ?
En fait, j'ai plus l'impression que le problème c'est que Linux désinitialise le switch lorsqu'il s'éteint. Donc, je pense qu'il faudrait presque plus tracer les appels du noyau que d'aller voir chez Windows. Par exemple, si tu lances "tail -f /var/log/messages", et que tu modifies le switch, tu as quelque chose ?
Si je modifie le switch, rien ne se passe, que ce soit avec 
tail -f /var/log/messages
ou 
dmesg
.
Bon, alors refait les mêmes commandes après avoir démarré avec l'option "debug" à la fin de la ligne "kernel". Si t'as toujours rien, tu utilises l'artillerie lourde et tu mets "noapic acpi=off irqpoll" comme options (c'est pas dangereux, mais je pense que c'est peut-être une connerie de mettre irqpoll et nopic en même temps), et tu regardes si Linux désinitialise le switch à l'arrêt.
Yes, tu as trouvé l'os ! :-D

L'option "debug" ne me fournit rien. Lorsque je modifie le switch à l'exécution, ça ne fait rien, quelles que soient les options (debug, noacpi, noapic, acpi=off, irqpoll ...).

Par contre, si j'active le switch en passant par windows xp, puis que je redémarre sur linux en passant les options du noyau noacpi, noapic, acpi=off et irqpoll, rien de nouveau, si ce n'est qu'au redémarrage, linux n'a pas désinitialisé le switch qui est toujours allumé ! :-D
En fait, il me suffit d'utiliser l'option acpi=off pour que le switch ne soit pas désinitialisé.

Par contre, si je modifie la position du switch, au démarrage, le LED n'a pas changé. Et au final, la carte graphique n'a pas été modifiée (si j'étais sur nvidia, ça reste nvidia).
Donc ça permet de pouvoir passer indéfiniment sur linux sur la carte définie au redémarrage après win xp, mais il faut repasser sur windows pour changer la carte choisie... :-?

Au moins tu as vu juste. C'est l'ACPI qui cause la désinitialisation du switch. Mais est-ce embêtant d'utiliser acpi=off de manière courrante ? Que cela implique-t-il ?

Dans tous les cas, c'est toujours trop contraignant, il faudrait au moins pouvoir modifier la carte graphique au démarrage sans passer par windows xp.
Merci déjà, c'est un bon pas en avant. 🙂

Edit : si je force la fermeture via le bouton on/off, bas au redémarrage, le switch reste ok, mais il ne se modifie pas.
En même temps, c'était un peu prévisible que ce soit l'ACPI. Par contre, en mettant "acpi=off", tu perds tout ce qui est gestion de l'énergie, pas très cool sur un portable. De manière a avoir un effet un peu moins global sur le système, teste avec "pci=noacpi" ou "pnpacpi=off" à la place de "acpi=off"

Je pense plus ou moins avoir trouvé une solution grâce au site Less Watt (merci Intel). À partir cette page (tout à la fin), sans option relative à l'acpi au boot, tu effectues les 3 premières étapes de "How to Build a custom DSDT into the kernel" et tu colles ici le fichier "DSDT.dsl".
OK, pour les tests d'options, je ferait ça demain (ou plutôt aujourd'hui ...).
Pour le fichier DSDT.dsl, vu sa taille, je l'ai uploadé sur un serveur :

http://projects.wox-xion.ch/intern/vaio-z11/acpi/DSDT-02.01.2009_01.dsl

Edit : j'avoue ne pas comprendre ce qui est contenu dans ce fichier (va falloir que je lise les docs du site que tu as proposé), mais les passages tel que : 
Name (_HID, EisaId ("PNP0A08"))
            Name (_CID, 0x030AD041)
            Name (_ADR, Zero)
            Method (_INI, 0, NotSerialized)
            {
                Store (One, GPO9)
                Store (0x07D0, OSYS)
                If (CondRefOf (_OSI, Local0))
                {
                    If (_OSI ("Linux"))
                    {
                        Store (0x03E8, OSYS)
                    }

                    If (_OSI ("Windows 2001"))
                    {
                        Store (0x07D1, OSYS)
                    }

                    If (_OSI ("Windows 2001 SP1"))
                    {
                        Store (0x07D1, OSYS)
                    }

                    If (_OSI ("Windows 2001 SP2"))
                    {
                        Store (0x07D2, OSYS)
                    }

                    If (_OSI ("Windows 2006"))
                    {
                        Store (0x07D6, OSYS)
                    }
                }

                HGWH (0x05)
            }
Je les aime bien. Ou plutôt, ça ressemble à des choses qui peuvent intéresser vu le contexte. 🙂

Edit 2 : ça vaut la peine que je fasse la manip pour chaque situation ? (switch nvidia, switch intel, switch off) pour faire un diff des versions et peut-être voir les données qui changent ? (todo, but tomorrow)
Resalut.
Pour information supplémentaire donc...
Ni pnpacpi=off ni pci=noacpi ne fonctionnent : le switch est quand même désinitialisé.

Ajout : j'ai refait la manipulation DSDT pour chaque cas (NVIDIA, INTEL et NOTHING) en vérifiant si ça se modifiait après un démarrage avec windows (1st ou 2nd).
Quelques exemples :
- nvidia (2nd) : http://projects.wox-xion.ch/intern/vaio-z11/acpi/nvidia/DSDT-02.01.2009_02.dsl (voir post précédent pour 1st)
- intel (1st) : http://projects.wox-xion.ch/intern/vaio-z11/acpi/intel/DSDT-02.01.2009_01.dsl
- nothing (1st) : http://projects.wox-xion.ch/intern/vaio-z11/acpi/nothing/DSDT-02.01.2009_01.dsl
- nothing (2nd) : http://projects.wox-xion.ch/intern/vaio-z11/acpi/nothing/DSDT-02.01.2009_02.dsl

Si on fait un diff, on remarque que - mis à part le header commenté où est inscrit la date - les seuls changements sont entre la version NVIDIA et celles INTEL/NOTHING.
Si on redémarre avec windows, ça ne change rien (nvidia 1 et nvidia 2 sont les mêmes à la date près).
Le diff (nvidia - intel) : 
5c5
<  * Disassembly of DSDT.cat, Fri Jan  2 17:23:07 2009
---
>  * Disassembly of DSDT.cat, Fri Jan  2 17:35:02 2009
140c140
<     OperationRegion (MBOX, SystemMemory, 0xBBCBEC18, 0x000002BC)
---
>     OperationRegion (MBOX, SystemMemory, 0xBFEBEC18, 0x000002BC)
557c557
<     OperationRegion (NVST, SystemMemory, 0xBBCBEED4, 0x000000D8)
---
>     OperationRegion (NVST, SystemMemory, 0xBFEBEED4, 0x000000D8)
Les versions INTEL et NOTHING (aucun led) sont identiques (à la date près).
Bon, puisque ni pnpacpi=off ni pci=noacpi ne fonctionne, utilise acpi=ht, celui là devrait fonctionner.

Pour le fichier DSDT, ça peut être intéressant quand j'aurais trouvé l'équivalent d'un manuel :-D Le diff par contre donne des informations un peu mystérieuse ; peut-être l'activation de la mémoire de carte Nvidia où quelque chose dans le genre ...

Par contre, dans le même genre de diff, pourrais tu également le faire avec les commandes dmidecode et lspci -vv.
Pour acpi=ht, ça fonctionne : le switch n'est pas désinitialisé, mais je ne peux pas le modifier (si je le modifie, le led ne change pas, même après reboot).

Pour lspci -vv et dmidecode, voici les résultats respectifs :
- nvidia :
http://projects.wox-xion.ch/intern/vaio-z11/acpi/nvidia/lspcivv-02.01.2009_01
http://projects.wox-xion.ch/intern/vaio-z11/acpi/nvidia/dmidecode-02.01.2009_01
- intel :
http://projects.wox-xion.ch/intern/vaio-z11/acpi/intel/lspcivv-02.01.2009_01
http://projects.wox-xion.ch/intern/vaio-z11/acpi/intel/dmidecode-02.01.2009_01
- nothing :
http://projects.wox-xion.ch/intern/vaio-z11/acpi/nothing/lspcivv-02.01.2009_01
http://projects.wox-xion.ch/intern/vaio-z11/acpi/nothing/dmidecode-02.01.2009_01

Et le diff est plus verbeux :
# diff nvidia intel 
diff nvidia/lspcivv-02.01.2009_01 intel/lspcivv-02.01.2009_01
6a7
>     Kernel driver in use: agpgart-intel
8c9,10
< 00:01.0 PCI bridge: Intel Corporation Cantiga PCI Express Graphics Port (rev 07) (prog-if 00 [Normal decode])
---
> 00:02.0 VGA compatible controller: Intel Corporation Cantiga Integrated Graphics Controller (rev 07) (prog-if 00 [VGA controller])
>     Subsystem: Sony Corporation Device 9025
10c12
<     Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
---
>     Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
12,22c14,17
<     Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
<     I/O behind bridge: 00007000-00007fff
<     Memory behind bridge: d2000000-d4ffffff
<     Prefetchable memory behind bridge: 00000000c0000000-00000000cfffffff
<     Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
<     BridgeCtl: Parity- SERR- NoISA- VGA+ MAbort- >Reset- FastB2B-
<         PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
<     Capabilities: [88] Subsystem: Sony Corporation Device 9025
<     Capabilities: [80] Power Management version 3
<         Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
<         Status: D0 PME-Enable- DSel=0 DScale=0 PME-
---
>     Interrupt: pin A routed to IRQ 16
>     Region 0: Memory at d4400000 (64-bit, non-prefetchable) [size=4M]
>     Region 2: Memory at c0000000 (64-bit, prefetchable) [size=256M]
>     Region 4: I/O ports at 7130 [size=8]
25,48c20,32
<     Capabilities: [a0] Express (v1) Root Port (Slot+), MSI 00
<         DevCap:    MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
<             ExtTag- RBE+ FLReset-
<         DevCtl:    Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+
<             RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
<             MaxPayload 128 bytes, MaxReadReq 128 bytes
<         DevSta:    CorrErr+ UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
<         LnkCap:    Port #2, Speed 2.5GT/s, Width x16, ASPM L0s L1, Latency L0 <256ns, L1 <4us
<             ClockPM- Suprise- LLActRep- BwNot-
<         LnkCtl:    ASPM L0s L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk+
<             ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
<         LnkSta:    Speed 2.5GT/s, Width x16, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
<         SltCap:    AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surpise-
<             Slot #  1, PowerLimit 75.000000; Interlock- NoCompl+
<         SltCtl:    Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
<             Control: AttnInd Off, PwrInd On, Power- Interlock-
<         SltSta:    Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock-
<             Changed: MRL- PresDet+ LinkState-
<         RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible-
<         RootCap: CRSVisible-
<         RootSta: PME ReqID 0000, PMEStatus- PMEPending-
<     Capabilities: [100] Virtual Channel <?>
<     Capabilities: [140] Root Complex Link <?>
<     Kernel driver in use: pcieport-driver
---
>     Capabilities: [d0] Power Management version 3
>         Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
>         Status: D0 PME-Enable- DSel=0 DScale=0 PME-
> 
> 00:02.1 Display controller: Intel Corporation Cantiga Integrated Graphics Controller (rev 07)
>     Subsystem: Sony Corporation Device 9025
>     Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
>     Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
>     Latency: 0
>     Region 0: Memory at d7800000 (64-bit, non-prefetchable) [size=1M]
>     Capabilities: [d0] Power Management version 3
>         Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
>         Status: D0 PME-Enable- DSel=0 DScale=0 PME-
56,58c40,42
<     Region 0: Memory at de200000 (32-bit, non-prefetchable) [size=128K]
<     Region 1: Memory at de224000 (32-bit, non-prefetchable) [size=4K]
<     Region 2: I/O ports at 8100 [size=32]
---
>     Region 0: Memory at daa00000 (32-bit, non-prefetchable) [size=128K]
>     Region 1: Memory at daa24000 (32-bit, non-prefetchable) [size=4K]
>     Region 2: I/O ports at 7100 [size=32]
74c58
<     Region 4: I/O ports at 80e0 [size=32]
---
>     Region 4: I/O ports at 70e0 [size=32]
84c68
<     Region 4: I/O ports at 80c0 [size=32]
---
>     Region 4: I/O ports at 70c0 [size=32]
94c78
<     Region 4: I/O ports at 80a0 [size=32]
---
>     Region 4: I/O ports at 70a0 [size=32]
104c88
<     Region 0: Memory at de225c00 (32-bit, non-prefetchable) [size=1K]
---
>     Region 0: Memory at daa25c00 (32-bit, non-prefetchable) [size=1K]
118c102
<     Region 0: Memory at de220000 (64-bit, non-prefetchable) [size=16K]
---
>     Region 0: Memory at daa20000 (64-bit, non-prefetchable) [size=16K]
147,148c131,132
<     Memory behind bridge: dd200000-de1fffff
<     Prefetchable memory behind bridge: 00000000d8100000-00000000d90fffff
---
>     Memory behind bridge: d9a00000-da9fffff
>     Prefetchable memory behind bridge: 00000000d4800000-00000000d57fffff
189,190c173,174
<     Memory behind bridge: dc100000-dd1fffff
<     Prefetchable memory behind bridge: 00000000d9100000-00000000da0fffff
---
>     Memory behind bridge: d8900000-d99fffff
>     Prefetchable memory behind bridge: 00000000d5800000-00000000d67fffff
231,232c215,216
<     Memory behind bridge: db100000-dc0fffff
<     Prefetchable memory behind bridge: 00000000da100000-00000000db0fffff
---
>     Memory behind bridge: d7900000-d88fffff
>     Prefetchable memory behind bridge: 00000000d6800000-00000000d77fffff
273c257
<     Region 4: I/O ports at 8080 [size=32]
---
>     Region 4: I/O ports at 7080 [size=32]
283c267
<     Region 4: I/O ports at 8060 [size=32]
---
>     Region 4: I/O ports at 7060 [size=32]
293c277
<     Region 4: I/O ports at 8040 [size=32]
---
>     Region 4: I/O ports at 7040 [size=32]
303c287
<     Region 0: Memory at de225800 (32-bit, non-prefetchable) [size=1K]
---
>     Region 0: Memory at daa25800 (32-bit, non-prefetchable) [size=1K]
317c301
<     Memory behind bridge: d6000000-d80fffff
---
>     Memory behind bridge: d2000000-d40fffff
337,342c321,326
<     Region 0: I/O ports at 8128 [size=8]
<     Region 1: I/O ports at 8134 [size=4]
<     Region 2: I/O ports at 8120 [size=8]
<     Region 3: I/O ports at 8130 [size=4]
<     Region 4: I/O ports at 8020 [size=32]
<     Region 5: Memory at de225000 (32-bit, non-prefetchable) [size=2K]
---
>     Region 0: I/O ports at 7128 [size=8]
>     Region 1: I/O ports at 713c [size=4]
>     Region 2: I/O ports at 7120 [size=8]
>     Region 3: I/O ports at 7138 [size=4]
>     Region 4: I/O ports at 7020 [size=32]
>     Region 5: Memory at daa25000 (32-bit, non-prefetchable) [size=2K]
357,358c341,342
<     Region 0: Memory at de226000 (64-bit, non-prefetchable) [size=256]
<     Region 4: I/O ports at 8000 [size=32]
---
>     Region 0: Memory at daa26000 (64-bit, non-prefetchable) [size=256]
>     Region 4: I/O ports at 7000 [size=32]
362,400d345
< 01:00.0 VGA compatible controller: nVidia Corporation Device 06e5 (rev a1) (prog-if 00 [VGA controller])
<     Subsystem: Sony Corporation Device 9025
<     Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
<     Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
<     Latency: 0
<     Interrupt: pin A routed to IRQ 16
<     Region 0: Memory at d4000000 (32-bit, non-prefetchable) [size=16M]
<     Region 1: Memory at c0000000 (64-bit, prefetchable) [size=256M]
<     Region 3: Memory at d2000000 (64-bit, non-prefetchable) [size=32M]
<     Region 5: I/O ports at 7000 [size=128]
<     Capabilities: [60] Power Management version 3
<         Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
<         Status: D0 PME-Enable- DSel=0 DScale=0 PME-
<     Capabilities: [68] Message Signalled Interrupts: Mask- 64bit+ Count=1/1 Enable-
<         Address: 0000000000000000  Data: 0000
<     Capabilities: [78] Express (v2) Endpoint, MSI 00
<         DevCap:    MaxPayload 128 bytes, PhantFunc 0, Latency L0s <256ns, L1 <4us
<             ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
<         DevCtl:    Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
<             RlxdOrd+ ExtTag+ PhantFunc- AuxPwr- NoSnoop+
<             MaxPayload 128 bytes, MaxReadReq 512 bytes
<         DevSta:    CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
<         LnkCap:    Port #0, Speed 5GT/s, Width x16, ASPM L0s L1, Latency L0 <256ns, L1 <1us
<             ClockPM- Suprise- LLActRep- BwNot-
<         LnkCtl:    ASPM L0s L1 Enabled; RCB 128 bytes Disabled- Retrain- CommClk+
<             ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
<         LnkSta:    Speed 2.5GT/s, Width x16, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
<         DevCap2: Completion Timeout: Not Supported, TimeoutDis+
<         DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-
<         LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-, Selectable De-emphasis: -6dB
<              Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
<              Compliance De-emphasis: -6dB
<         LnkSta2: Current De-emphasis Level: -6dB
<     Capabilities: [100] Virtual Channel <?>
<     Capabilities: [128] Power Budgeting <?>
<     Capabilities: [600] Vendor Specific Information <?>
<     Kernel driver in use: nvidia
<     Kernel modules: nvidiafb, nvidia
< 
407c352
<     Region 0: Memory at dc100000 (64-bit, non-prefetchable) [size=8K]
---
>     Region 0: Memory at d8900000 (64-bit, non-prefetchable) [size=8K]
442c387
<     Region 0: Memory at d8000000 (32-bit, non-prefetchable) [size=4K]
---
>     Region 0: Memory at d4000000 (32-bit, non-prefetchable) [size=4K]
444,445c389,390
<     Memory window 0: e0000000-e3fff000 (prefetchable)
<     Memory window 1: e4000000-e7fff000
---
>     Memory window 0: dc000000-dffff000 (prefetchable)
>     Memory window 1: e0000000-e3fff000
459c404
<     Region 0: Memory at d8001000 (32-bit, non-prefetchable) [size=2K]
---
>     Region 0: Memory at d4001000 (32-bit, non-prefetchable) [size=2K]
472c417
<     Region 0: Memory at d8001900 (32-bit, non-prefetchable) [size=256]
---
>     Region 0: Memory at d4001900 (32-bit, non-prefetchable) [size=256]
485c430
<     Region 0: Memory at d8001800 (32-bit, non-prefetchable) [size=256]
---
>     Region 0: Memory at d4001800 (32-bit, non-prefetchable) [size=256]
# diff intel nothing 
diff intel/lspcivv-02.01.2009_01 nothing/lspcivv-02.01.2009_01
9,10c9
< 00:02.0 VGA compatible controller: Intel Corporation Cantiga Integrated Graphics Controller (rev 07) (prog-if 00 [VGA controller])
<     Subsystem: Sony Corporation Device 9025
---
> 00:01.0 PCI bridge: Intel Corporation Cantiga PCI Express Graphics Port (rev 07) (prog-if 00 [Normal decode])
12c11
<     Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
---
>     Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
14,17c13,23
<     Interrupt: pin A routed to IRQ 16
<     Region 0: Memory at d4400000 (64-bit, non-prefetchable) [size=4M]
<     Region 2: Memory at c0000000 (64-bit, prefetchable) [size=256M]
<     Region 4: I/O ports at 7130 [size=8]
---
>     Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
>     I/O behind bridge: 00007000-00007fff
>     Memory behind bridge: e2000000-e4ffffff
>     Prefetchable memory behind bridge: 00000000c0000000-00000000cfffffff
>     Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
>     BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
>         PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
>     Capabilities: [88] Subsystem: Sony Corporation Device 9025
>     Capabilities: [80] Power Management version 3
>         Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
>         Status: D0 PME-Enable- DSel=0 DScale=0 PME-
20,22c26,49
<     Capabilities: [d0] Power Management version 3
<         Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
<         Status: D0 PME-Enable- DSel=0 DScale=0 PME-
---
>     Capabilities: [a0] Express (v1) Root Port (Slot+), MSI 00
>         DevCap:    MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
>             ExtTag- RBE+ FLReset-
>         DevCtl:    Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+
>             RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
>             MaxPayload 128 bytes, MaxReadReq 128 bytes
>         DevSta:    CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
>         LnkCap:    Port #2, Speed 2.5GT/s, Width x16, ASPM L0s L1, Latency L0 <256ns, L1 <4us
>             ClockPM- Suprise- LLActRep- BwNot-
>         LnkCtl:    ASPM L0s L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk+
>             ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
>         LnkSta:    Speed 2.5GT/s, Width x16, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
>         SltCap:    AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surpise-
>             Slot #  1, PowerLimit 75.000000; Interlock- NoCompl+
>         SltCtl:    Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
>             Control: AttnInd Off, PwrInd On, Power- Interlock-
>         SltSta:    Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock-
>             Changed: MRL- PresDet+ LinkState-
>         RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible-
>         RootCap: CRSVisible-
>         RootSta: PME ReqID 0000, PMEStatus- PMEPending-
>     Capabilities: [100] Virtual Channel <?>
>     Capabilities: [140] Root Complex Link <?>
>     Kernel driver in use: pcieport-driver
24c51
< 00:02.1 Display controller: Intel Corporation Cantiga Integrated Graphics Controller (rev 07)
---
> 00:02.0 VGA compatible controller: Intel Corporation Cantiga Integrated Graphics Controller (rev 07) (prog-if 00 [VGA controller])
29c56,61
<     Region 0: Memory at d7800000 (64-bit, non-prefetchable) [size=1M]
---
>     Interrupt: pin A routed to IRQ 10
>     Region 0: Memory at e8400000 (64-bit, non-prefetchable) [size=4M]
>     Region 2: Memory at d0000000 (64-bit, prefetchable) [size=256M]
>     Region 4: I/O ports at 8130 [size=8]
>     Capabilities: [90] Message Signalled Interrupts: Mask- 64bit- Count=1/1 Enable-
>         Address: 00000000  Data: 0000
40,42c72,74
<     Region 0: Memory at daa00000 (32-bit, non-prefetchable) [size=128K]
<     Region 1: Memory at daa24000 (32-bit, non-prefetchable) [size=4K]
<     Region 2: I/O ports at 7100 [size=32]
---
>     Region 0: Memory at ee900000 (32-bit, non-prefetchable) [size=128K]
>     Region 1: Memory at ee924000 (32-bit, non-prefetchable) [size=4K]
>     Region 2: I/O ports at 8100 [size=32]
58c90
<     Region 4: I/O ports at 70e0 [size=32]
---
>     Region 4: I/O ports at 80e0 [size=32]
68c100
<     Region 4: I/O ports at 70c0 [size=32]
---
>     Region 4: I/O ports at 80c0 [size=32]
78c110
<     Region 4: I/O ports at 70a0 [size=32]
---
>     Region 4: I/O ports at 80a0 [size=32]
88c120
<     Region 0: Memory at daa25c00 (32-bit, non-prefetchable) [size=1K]
---
>     Region 0: Memory at ee925c00 (32-bit, non-prefetchable) [size=1K]
102c134
<     Region 0: Memory at daa20000 (64-bit, non-prefetchable) [size=16K]
---
>     Region 0: Memory at ee920000 (64-bit, non-prefetchable) [size=16K]
131,132c163,164
<     Memory behind bridge: d9a00000-da9fffff
<     Prefetchable memory behind bridge: 00000000d4800000-00000000d57fffff
---
>     Memory behind bridge: ed900000-ee8fffff
>     Prefetchable memory behind bridge: 00000000e8800000-00000000e97fffff
173,174c205,206
<     Memory behind bridge: d8900000-d99fffff
<     Prefetchable memory behind bridge: 00000000d5800000-00000000d67fffff
---
>     Memory behind bridge: ec800000-ed8fffff
>     Prefetchable memory behind bridge: 00000000e9800000-00000000ea7fffff
215,216c247,248
<     Memory behind bridge: d7900000-d88fffff
<     Prefetchable memory behind bridge: 00000000d6800000-00000000d77fffff
---
>     Memory behind bridge: eb800000-ec7fffff
>     Prefetchable memory behind bridge: 00000000ea800000-00000000eb7fffff
257c289
<     Region 4: I/O ports at 7080 [size=32]
---
>     Region 4: I/O ports at 8080 [size=32]
267c299
<     Region 4: I/O ports at 7060 [size=32]
---
>     Region 4: I/O ports at 8060 [size=32]
277c309
<     Region 4: I/O ports at 7040 [size=32]
---
>     Region 4: I/O ports at 8040 [size=32]
287c319
<     Region 0: Memory at daa25800 (32-bit, non-prefetchable) [size=1K]
---
>     Region 0: Memory at ee925800 (32-bit, non-prefetchable) [size=1K]
301,302c333,334
<     Memory behind bridge: d2000000-d40fffff
<     Prefetchable memory behind bridge: 00000000d0000000-00000000d1ffffff
---
>     Memory behind bridge: e6000000-e80fffff
>     Prefetchable memory behind bridge: 00000000e0000000-00000000e1ffffff
321,326c353,358
<     Region 0: I/O ports at 7128 [size=8]
<     Region 1: I/O ports at 713c [size=4]
<     Region 2: I/O ports at 7120 [size=8]
<     Region 3: I/O ports at 7138 [size=4]
<     Region 4: I/O ports at 7020 [size=32]
<     Region 5: Memory at daa25000 (32-bit, non-prefetchable) [size=2K]
---
>     Region 0: I/O ports at 8128 [size=8]
>     Region 1: I/O ports at 813c [size=4]
>     Region 2: I/O ports at 8120 [size=8]
>     Region 3: I/O ports at 8138 [size=4]
>     Region 4: I/O ports at 8020 [size=32]
>     Region 5: Memory at ee925000 (32-bit, non-prefetchable) [size=2K]
341,342c373,374
<     Region 0: Memory at daa26000 (64-bit, non-prefetchable) [size=256]
<     Region 4: I/O ports at 7000 [size=32]
---
>     Region 0: Memory at ee926000 (64-bit, non-prefetchable) [size=256]
>     Region 4: I/O ports at 8000 [size=32]
345a378,417
> 01:00.0 VGA compatible controller: nVidia Corporation Device 06e5 (rev a1) (prog-if 00 [VGA controller])
>     Subsystem: Sony Corporation Device 9025
>     Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
>     Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
>     Latency: 0
>     Interrupt: pin A routed to IRQ 16
>     Region 0: Memory at e4000000 (32-bit, non-prefetchable) [size=16M]
>     Region 1: Memory at c0000000 (64-bit, prefetchable) [size=256M]
>     Region 3: Memory at e2000000 (64-bit, non-prefetchable) [size=32M]
>     Region 5: I/O ports at 7000 [size=128]
>     Expansion ROM at <ignored> [disabled]
>     Capabilities: [60] Power Management version 3
>         Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
>         Status: D0 PME-Enable- DSel=0 DScale=0 PME-
>     Capabilities: [68] Message Signalled Interrupts: Mask- 64bit+ Count=1/1 Enable-
>         Address: 0000000000000000  Data: 0000
>     Capabilities: [78] Express (v2) Endpoint, MSI 00
>         DevCap:    MaxPayload 128 bytes, PhantFunc 0, Latency L0s <512ns, L1 <4us
>             ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
>         DevCtl:    Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
>             RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
>             MaxPayload 128 bytes, MaxReadReq 512 bytes
>         DevSta:    CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
>         LnkCap:    Port #0, Speed 5GT/s, Width x16, ASPM L0s L1, Latency L0 <512ns, L1 <1us
>             ClockPM- Suprise- LLActRep- BwNot-
>         LnkCtl:    ASPM L0s L1 Enabled; RCB 128 bytes Disabled- Retrain- CommClk+
>             ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
>         LnkSta:    Speed 2.5GT/s, Width x16, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
>         DevCap2: Completion Timeout: Not Supported, TimeoutDis+
>         DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-
>         LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-, Selectable De-emphasis: -6dB
>              Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
>              Compliance De-emphasis: -6dB
>         LnkSta2: Current De-emphasis Level: -6dB
>     Capabilities: [100] Virtual Channel <?>
>     Capabilities: [128] Power Budgeting <?>
>     Capabilities: [600] Vendor Specific Information <?>
>     Kernel driver in use: nvidia
>     Kernel modules: nvidiafb, nvidia
> 
352c424
<     Region 0: Memory at d8900000 (64-bit, non-prefetchable) [size=8K]
---
>     Region 0: Memory at ec800000 (64-bit, non-prefetchable) [size=8K]
387c459
<     Region 0: Memory at d4000000 (32-bit, non-prefetchable) [size=4K]
---
>     Region 0: Memory at e8000000 (32-bit, non-prefetchable) [size=4K]
389,390c461,462
<     Memory window 0: dc000000-dffff000 (prefetchable)
<     Memory window 1: e0000000-e3fff000
---
>     Memory window 0: f0000000-f3fff000 (prefetchable)
>     Memory window 1: f4000000-f7fff000
404c476
<     Region 0: Memory at d4001000 (32-bit, non-prefetchable) [size=2K]
---
>     Region 0: Memory at e8001000 (32-bit, non-prefetchable) [size=2K]
417c489
<     Region 0: Memory at d4001900 (32-bit, non-prefetchable) [size=256]
---
>     Region 0: Memory at e8001900 (32-bit, non-prefetchable) [size=256]
430c502
<     Region 0: Memory at d4001800 (32-bit, non-prefetchable) [size=256]
---
>     Region 0: Memory at e8001800 (32-bit, non-prefetchable) [size=256]
Hum, il y a quelque chose qui m'intrigue. Si tu as installé Windows XP from scratch, tu n'avais donc aucun logiciel qui pourrait gérer le switch, c'est à dire que soit XP gère nativement le switch (ce que je crois guère) soit ça passe exclusivement par le BIOS. Donc à savoir si sous Linux c'est le BIOS qui bloque le switch ou si c'est le noyau qui intercepte (avec l'ACPI).

Donc, d'après "How to build a custom DSDT into an initrd" du site que je t'ai donné, est ce que tu pourrais tester de mettre un DSDT où tu changerais dans la partie que tu montres dans le message #13 le code héxadécimal de Linux en le passant de "Store (0x03E8, OSYS)" à "Store (0x07D2, OSYS)" et démarré avec ?
Ok, il paraît logique d'essayer. Par contre je n'ai jamais recompilé de kernel.
Est-ce que le tutorial http://doc.fedora-fr.org/wiki/Recompilation_du_noyau_Fedora suffit ?

Quelle différence entre construire le noyau de A à Z ou seulement construire le initrd ?
(http://doc.fedora-fr.org/wiki/Recompilation_du_noyau_Fedora#Etape_10_:_G.C3.A9n.C3.A9ration_du_RAM_Disk)

Pour construire le initrd, je dois faire tout ce qui précède de toute façon, non ?
Bon, j'ai plus ou moins réussi à recompiler le noyau avec les options pour le fichier DSDT.hex. (j'ai tout recompilé)
Cependant, je devais bien me résoudre à utiliser un des deux DSDT que j'ai (celui nvidia ou celui intel). J'ai choisi celui NVIDIA.

... la compilation du noyau est assez longue, mais ça passe. Au redémarrage par contre, surprise ! Le switch est on sur Nvidia. Quoi que je fasse, il reste sur nvidia tant que j'utilise le noyau que j'ai compilé avec le DSDT.hex pour nvidia. Je vais encore tester pour voir si c'est vraiment absolu et je vais tenter une recompilation avec le DSDT.hex pour la carte intel... qui sait, ça pourrait ne faire que fonctionner la carte intel. Auquel cas j'aurai juste à préciser le noyau choisi selon ... la carte à utiliser. (mais risque d'y avoir besoin d'un reboot linux) :-?

En passant, le kmod-nvidia n'est pas fait pour le noyau que j'ai recompilé et donc ça ne fonctionne pas tant. On fait comment pour que les éléments du kmod-nvidia soient chargés aussi pour le noyau personnalisé ?

Edit : mince, je ne suis pas tant sûr d'avoir pris le dsdt pour nvidia... plutôt celui pour intel... arghk.. je vais test les divers cas de toute façon. 😉

Ajout : c'est bien le dsdt d'intel... et ça a amené à des éléments nouveaux :
- en mode NOTHING, la carte intel est désormais fonctionnelle bien que les deux cartes soient visibles via lspci (par contre la carte nvidia est out)
- le switch ne se règle pas au boot !

En fait, la modification dans le DSDT.hex a permis de forcer la non-désinitialisation que fait linux (étrangement). Par contre, le résultat est donc le même que si j'utilisais l'option acpi=ht : le switch reste activé sur ce sur quoi il était activé... et je suis obligé de passé par windows pour modifier l'état du switch en redémarrant.
Ce qui voudrait dire que windows fait plus que juste informer l'os. (mais c'est déjà un bon début 😉 )

Et j'ai aussi trouvé un groupe réalisé autour du problème (mais sans solution pour l'instant) : https://launchpad.net/~z-series
xion.luhnis wrote:Ok, il paraît logique d'essayer. Par contre je n'ai jamais recompilé de kernel.
Est-ce que le tutorial http://doc.fedora-fr.org/wiki/Recompilation_du_noyau_Fedora suffit ?

Quelle différence entre construire le noyau de A à Z ou seulement construire le initrd ?
(http://doc.fedora-fr.org/wiki/Recompilation_du_noyau_Fedora#Etape_10_:_G.C3.A9n.C3.A9ration_du_RAM_Disk)

Pour construire le initrd, je dois faire tout ce qui précède de toute façon, non ?
Justement l'avantage de ne pas compiler, c'est que ça prend beaucoup moins de temps, surtout si on doit le refaire plusieurs fois 🙂

Bon, j'ai plus ou moins réussi à recompiler le noyau avec les options pour le fichier DSDT.hex. (j'ai tout recompilé)
Cependant, je devais bien me résoudre à utiliser un des deux DSDT que j'ai (celui nvidia ou celui intel). J'ai choisi celui NVIDIA.

... la compilation du noyau est assez longue, mais ça passe. Au redémarrage par contre, surprise ! Le switch est on sur Nvidia. Quoi que je fasse, il reste sur nvidia tant que j'utilise le noyau que j'ai compilé avec le DSDT.hex pour nvidia. Je vais encore tester pour voir si c'est vraiment absolu et je vais tenter une recompilation avec le DSDT.hex pour la carte intel... qui sait, ça pourrait ne faire que fonctionner la carte intel. Auquel cas j'aurai juste à préciser le noyau choisi selon ... la carte à utiliser. (mais risque d'y avoir besoin d'un reboot linux) hmm
C'est à quoi je veux arriver 🙂 Et ce serait déjà un exploit d'y arriver.
Ajout : c'est bien le dsdt d'intel... et ça a amené à des éléments nouveaux :
- en mode NOTHING, la carte intel est désormais fonctionnelle bien que les deux cartes soient visibles via lspci (par contre la carte nvidia est out)
- le switch ne se règle pas au boot !

En fait, la modification dans le DSDT.hex a permis de forcer la non-désinitialisation que fait linux (étrangement). Par contre, le résultat est donc le même que si j'utilisais l'option acpi=ht : le switch reste activé sur ce sur quoi il était activé... et je suis obligé de passé par windows pour modifier l'état du switch en redémarrant.
Ce qui voudrait dire que windows fait plus que juste informer l'os. (mais c'est déjà un bon début wink )
Intéressant ça 🙂 Si je comprend bien ça donne une gestion de l'ACPI différente, spécifique à Windows, qui doit répondre de manière générique aux demandes du BIOS. C'est vraiment du tatonnement, donc il faudrait voir si utiliser le code héxadécimal de "Windows Xp (2001)" ou "Windows Vista (2006)" change quelques choses au comportement de l'ordinateur.

Sinon, en faisant pas mal de recherche, j'ai vu qu'il y avait plein de fichier dans /proc qui était directement relié au BIOS (comme ioports, interrupts). Il faudrait voir si l'un de ces fichiers ne réagit pas lors de la modification du switch.

P.S.: Oh, élément intéressant ! En cherchant la valeur OSYS dans le fichier DSL, on voit qu'il y a pas mal de modification pour Vista (0x07D6). C'est à approfondir.