Geekeries et d'autres choses - Mot-clé - linux2024-01-29T10:26:26+01:00urn:md5:51ff50324f4f72c0e78683659647f2c8DotclearMes problèmes de suspend, et comment je les ai résolusurn:md5:d67b9d823730a607066156a647a4642a2015-07-05T10:36:00+02:002024-01-29T11:19:43+01:00Julien WajsbergInformatiquelinuxsuspendsystemdtouchscreen<p>Depuis quelque temps, je restais sur le noyau 3.14 car c'était le seul qui fonctionnait sans trop de souci. Notamment les noyaux plus récents provoquaient des soucis au <em>suspend</em>: le PC se réveillait presque immédiatement.</p>
<p>J'ai essayé récemment le noyau 4.1 compilé manuellement, et j'ai eu le même souci... et même un souci supplémentaire puisqu'il ne se mettait parfois même plus en veille. Il était temps de déboguer un peu tout ça.</p>
<p><strong>Update novembre 2016</strong>: j'ai changé le type de service pour <code>multitouch_reload</code>.</p> <h3>Le PC ne se met plus en veille.</h3>
<p>La première étape consiste à comprendre pourquoi le PC ne se mettait plus en veille. Un peu de logs supplémentaires nous seraient utiles. Le plus simple pour les activer temporairement est d'exécuter la commande suivante en <em>root</em>:</p>
<pre>
systemctl set-environment SYSTEMD_LOG_{LEVEL=debug,TARGET=journal}
systemctl restart systemd-logind
</pre>
<p>Une fois ces commandes exécutées, on peut avoir des logs avec la commande <code>journalctl -b -u systemd-logind</code>:</p>
<pre>
juil. 01 08:12:22 beitou systemd-logind[22720]: Lid closed.
juil. 01 08:12:22 beitou systemd-logind[22720]: Ignoring lid switch request, 4 displays connected.
juil. 01 08:12:22 beitou systemd-logind[22720]: Ignoring lid switch request, 4 displays connected.
juil. 01 08:12:28 beitou systemd-logind[22720]: Lid opened.
</pre>
<p>Oh, j'ai donc 4 moniteurs connectés en même temps ! Ah, en fait non. Il doit donc y avoir une détection qui échoue. Pour en savoir plus, on peut demander gentiment à ACPI:</p>
<pre>
$ cat /sys/class/drm/*/*/status
unknown
unknown
unknown
unknown
</pre>
<p>Mais je m'aperçois qu'après un boot les valeurs sont correctes:</p>
<pre>
$ cat /sys/class/drm/*/*/status
disconnected
connected
disconnected
disconnected
</pre>
<p>Les valeurs deviennent incorrectes uniquement après un retour de veille. Cependant elles redeviennent normales après (par exemple) un appel à <code>xrandr</code>.</p>
<p>Après <a href="https://bugzilla.kernel.org/show_bug.cgi?id=100741">quelques rapports</a> <a href="https://github.com/systemd/systemd/issues/451">de bug</a>, j'ai des pistes. Il semble que ce souci n'arrive que depuis le noyau 4.1. Après avoir appliqué <a href="http://thread.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/62584/focus=62733">le patch d'un mail de la liste du noyau</a>, ce premier souci est corrigé. Il semble aussi que systemd v221 inclue un contournement au souci, mais je ne l'ai pas essayé.</p>
<p>Place aux autres soucis !</p>
<h3>Le PC se réveille après quelques secondes.</h3>
<p>Quelques forums m'ont mis la puce à l'oreille: il semble que ce soit le module USB qui envoie des événements de réveil.</p>
<p>On peut le voir en affichant <code>/proc/acpi/wakeup</code>:</p>
<pre>
$ cat /proc/acpi/wakeup
Device S-state Status Sysfs node
P0P1 S4 *disabled
XHC S3 *enabled pci:0000:00:14.0
HDEF S4 *disabled pci:0000:00:1b.0
RP01 S4 *disabled pci:0000:00:1c.0
PXSX S4 *disabled
RP03 S4 *disabled pci:0000:00:1c.2
PXSX S5 *disabled pci:0000:04:00.0
PXSX S4 *disabled pci:0000:05:00.0
*disabled platform:rtsx_pci_sdmmc.0
*disabled platform:rtsx_pci_ms.0
PEG0 S4 *disabled
PEGP S4 *disabled
PEG1 S4 *disabled
PEG2 S4 *disabled
LID0 S4 *enabled platform:PNP0C0D:00
</pre>
<p>Cela sert normalement à réveiller le PC si le clavier est actionné, mais on dirait que des événements sont envoyés qui ne devraient pas être reçus... La solution évidente consiste à désactiver cette fonction (en root):</p>
<pre>
# echo XHC > /proc/acpi/wakeup
$ cat /proc/acpi/wakeup
Device S-state Status Sysfs node
P0P1 S4 *disabled
XHC S3 *disabled pci:0000:00:14.0
HDEF S4 *disabled pci:0000:00:1b.0
RP01 S4 *disabled pci:0000:00:1c.0
PXSX S4 *disabled
RP03 S4 *disabled pci:0000:00:1c.2
PXSX S5 *disabled pci:0000:04:00.0
PXSX S4 *disabled pci:0000:05:00.0
*disabled platform:rtsx_pci_sdmmc.0
*disabled platform:rtsx_pci_ms.0
PEG0 S4 *disabled
PEGP S4 *disabled
PEG1 S4 *disabled
PEG2 S4 *disabled
LID0 S4 *enabled platform:PNP0C0D:00
</pre>
<p>Pour l'exécuter au boot, voici ce que j'ai fait.</p>
<p>J'ai d'abord édité <code>/etc/systemd/system/disable-xhc-wakeup.service</code> avec le contenu suivant:</p>
<pre>
[Unit]
Description=Disable XHC Wakeup
[Service]
ExecStart=/usr/local/bin/disable-xhc-wakeup
[Install]
WantedBy=multi-user.target
</pre>
<p>Puis j'ai édité <code>/usr/local/bin/disable-xhc-wakeup</code> avec ce contenu:</p>
<pre><code class="language-bash">#!/bin/sh
if grep -q XHC.*enabled /proc/acpi/wakeup ; then
echo XHC > /proc/acpi/wakeup
fi</code></pre>
<p>Et j'ai enfin activé ce nouveau service (en root):</p>
<pre>
# systemctl enable disable-xhc-wakeup.service
</pre>
<h3>Le touchscreen ne fonctionne plus après un <em>resume</em></h3>
<p>Après un peu de recherche, j'ai découvert que simplement décharger et recharger le module <code>hid_multitouch</code> corrigeait le souci:</p>
<pre>
modprobe -r hid_multitouch
modprobe hid_multitouch
</pre>
<p>Il ne reste plus qu'à le faire de manière systématique.</p>
<p><strong>Attention</strong>, beaucoup de documentation pointe vers <code>/usr/lib/pm-utils/defaults</code>, mais ce fichier n'est plus utilisé avec <code>systemd</code>.</p>
<p>J'ai donc créé un fichier <code>/etc/systemd/system/reload_multitouch.service</code>:</p>
<pre>
[Unit]
Description=Reload hid_multitouch kernel module
After=sleep.target
[Service]
Type=oneshot
ExecStart=/sbin/modprobe -r hid_multitouch ; /sbin/modprobe hid_multitouch
[Install]
WantedBy=sleep.target
</pre>
<p>Puis je l'ai activé:</p>
<pre>
# systemctl enable reload_multitouch
</pre>
<p>Et voilà !</p>
<p><a href="https://bugzilla.kernel.org/show_bug.cgi?id=100951">J'ai rapporté le bug sur le bugtracker du noyau Linux</a> donc vous pourrez suivre la résolution éventuelle !</p>VMware Player 3 (ou Workstation 7) et Linux 2.6.32urn:md5:139fe128aedd454227c7a1246b4bacdd2010-01-12T10:30:00+01:002010-01-13T13:24:18+01:00Julien WajsbergInformatique2.6.32linuxvmnetvmware <p>Il y a des problèmes avec la compilation de certains modules spécifiques à VMware. On obtient une erreur du type :</p>
<pre>
/tmp/vmware-root/modules/vmnet-only/vnetUserListener.c: In function ‘VNetUserListenerEventHandler’:
/tmp/vmware-root/modules/vmnet-only/vnetUserListener.c:240: error: ‘TASK_INTERRUPTIBLE’ undeclared (first use in this function)
/tmp/vmware-root/modules/vmnet-only/vnetUserListener.c:240: error: (Each undeclared identifier is reported only once
/tmp/vmware-root/modules/vmnet-only/vnetUserListener.c:240: error: for each function it appears in.)
/tmp/vmware-root/modules/vmnet-only/vnetUserListener.c: In function ‘VNetUserListenerRead’:
/tmp/vmware-root/modules/vmnet-only/vnetUserListener.c:282: error: ‘TASK_INTERRUPTIBLE’ undeclared (first use in this function)
/tmp/vmware-root/modules/vmnet-only/vnetUserListener.c:282: error: implicit declaration of function ‘signal_pending’
/tmp/vmware-root/modules/vmnet-only/vnetUserListener.c:282: error: implicit declaration of function ‘schedule’
make[4]: *** [/tmp/vmware-root/modules/vmnet-only/vnetUserListener.o] Erreur 1
make[3]: *** [_module_/tmp/vmware-root/modules/vmnet-only] Erreur 2
</pre>
<p>La méthode la plus simple pour le faire fonctionner, je l'ai trouvée sur <a href="http://sadevil.org/blog/2009/12/31/vmware-player-3-vs-linux-2-6-32/" hreflang="en">un blog de geek</a>. Je la recopie ici afin d'apporter un peu de pérennité, on sait jamais. Les deux dernières commandes sont à exécuter avec les droits root :</p>
<pre>
cd /tmp
tar xf /usr/lib/vmware/modules/source/vmnet.tar
tar xf /usr/lib/vmware/modules/source/vmci.tar
cd vmnet-only
sed -i "/vnetInt.h/ a\#include \"compat_sched.h\"" vnetUserListener.c
cd ../vmci-only/include
sed -i "/compat_page.h/ a\#include \"compat_sched.h\"" pgtbl.h
cd /tmp
tar cf /usr/lib/vmware/modules/source/vmnet.tar vmnet-only
tar cf /usr/lib/vmware/modules/source/vmci.tar vmci-only
</pre>
<p>Il suffit ensuite de redémarrer vmplayer (ou vmware si c'est Workstation) et leur appli se charge de recompiler les modules si elle ne les trouve pas.</p>Flex Builder 3 avec Eclipse Galileo 3.5.1 sous Linuxurn:md5:987401deaf389a0b2aa63706a40ec7e92010-01-04T16:02:00+01:002010-01-04T16:06:30+01:00Julien WajsbergInformatiqueeclipseflexgalileolinux <p>Un petit billet pour pointer vers les sites qui m'ont servi à résoudre ça :</p>
<ul>
<li><a href="http://labs.adobe.com/technologies/flex/flexbuilder_linux/" hreflang="en">le site d'Adobe</a> pour récupérer la dernière alpha 5</li>
<li><a href="http://blog.danyul.id.au/?p=68" hreflang="en">Le blog de Danyul</a>, qui explicite pas à pas comment installer Eclipse 3.5, Flex Builder, et qui propose un patch pour faire fonctionner l'ensemble. Notez qu'il faut adapter pour la version 3 alpha 5. Il a aussi écrit <a href="http://blog.danyul.id.au/?p=115" hreflang="en">un autre billet qui résume où on en est</a></li>
<li><a href="http://www.jamesward.com/2009/09/29/flex-builder-3-on-eclipse-3-5/" hreflang="en">Le patch de James Ward</a> (et <a href="http://www.insideria.com/2009/09/fixed-an-internal-build-error.html" hreflang="en">les instructions pour résoudre le même problème sous Windows</a>). Ce patch résout l'erreur "Internal Error" qui apparait dans Eclipse; cette erreur apparait lorsqu'il y a des warnings. L'erreur complète peut être lue dans les logs d'erreur d'Eclipse, et concerne la classe interne à Flex <code>ProblemManager</code>.</li>
<li><a href="http://raghuonflex.wordpress.com/2007/10/03/how-do-i-get-data-visualization-charting-components-for-linux/" hreflang="en">Le billet de raghunathrao</a> pour ajouter Flex Chart (ou datavisualization.swc)</li>
<li>A tester : il semble que quelqu'un <a href="http://code.google.com/p/fb4linux/" hreflang="en">ait réussi à porter Flash Builder 4 sous Linux</a>... à tester</li>
</ul>
<p>(et oui, désolé, je fais du Flex, un peu...)</p>How to update the BIOS firmware on a Dell Laptop using only Debian Linuxurn:md5:e6c68a0756ae7dcc8b05224bd07ab7332009-12-24T16:05:00+01:002009-12-24T16:13:54+01:00Julien WajsbergInformatiquebiosdebiandellfirmwarehdrlaptoplinuxwine <p>(Yes, I know that's GNU/Linux, but my title was already too long :-) )
Translation of my <a href="http://www.everlong.org/blog/index.php/post/2009/12/Dell%2C-BIOS%2C-Linux" hreflang="fr" title="Comment mettre à jour le Bios de son portable Dell sous Debian Linux">last post</a> in english. Hope it will be readable :-)</p>
<p>Dell publishes all BIOS firmwares as a Windows .EXE. When we try naively to execute it using Wine, Wine stops because the exe tries to flash the firmware using direct access to the hardware... which doesn't work with Wine.</p>
<p>The solution is to use <code>dellBiosUpdate</code>, which ships with the Debian package <code>libsmbios-bin</code>:</p>
<pre>aptitude install libsmbios-bin</pre>
<p>This tool needs 2 things : the bios firmware in HDR format, and the kernel module <code>dell_rbu</code> to do the update. For this last part, it's easy on a normal Debian (read: with a Debian kernel):</p>
<pre>modprobe dell_rbu</pre>
<p>For the HDR file, I tried during 2 hours... and indeed it was very easy (please replace the filename by the actual filename):</p>
<pre>wine E6400A19.EXE -writehdrfile</pre>
<p>Yes, Dell's .EXE knows how to write the HDR file !</p>
<p>Now, you can execute <code>dellBiosUpdate</code> :</p>
<pre>dellBiosUpdate -f ./E6400A19.hdr -u</pre>
<p>And reboot !</p>
<p>Please note that if you don't use Debian, <a href="http://linux.dell.com/wiki/index.php/Repository/firmware" hreflang="en">Dell has some easy setup to update the BIOS firmware under Linux</a>. It seems to work on RPM distributions, and also in Ubuntu. I tried to make it work with Debian, I think I successed but the repository seems to contain rather old firmwares. Maybe I'll try to help them make it work with Debian :-)</p>Comment mettre à jour le Bios de son portable Dell sous Debian Linuxurn:md5:80fa48d0e2238556c501360814259ac62009-12-24T15:35:00+01:002009-12-24T16:13:32+01:00Julien WajsbergInformatiquebiosdebiandellhdrlinuxwine <p>(oui, je sais, on dit GNU/Linux, mais mon titre était déjà trop long)</p>
<p>(<a href="http://www.everlong.org/blog/index.php/post/2009/12/How-to-update-the-BIOS-firmware-on-a-Dell-Laptop-using-only-Debian-Linux" hreflang="en" title="How to update the BIOS firmware on a Dell Laptop using only Debian Linux">English translation</a>)</p>
<p>Aujourd'hui, on continue encore un peu avec les billets geeks. Et ça me permettra de pas perdre 2 heures la prochaine fois :-)</p>
<p>En effet, aujourd'hui, j'ai voulu mettre à jour mon BIOS. En effet, il est possible que ce soit ça qui fasse que... bref, cette histoire sera pour plus tard.</p>
<p>Il faut savoir que Dell fournit ses nouveaux bios sous forme d'un exécutable Windows. Quand on l'exécute bêtement avec Wine, ça plante... car il essaie de flasher directement le Bios en accédant au matériel, et Wine n'a pas implémenté ça.</p>
<p>La solution consiste à passer par l'utilitaire <code>dellBiosUpdate</code>, qui se trouve dans le paquet Debian <code>libsmbios-bin</code>:</p>
<pre>aptitude install libsmbios-bin</pre>
<p>Cet utilitaire a besoin de deux choses : le Bios au format HDR, et le module noyau <code>dell_rbu</code> pour faire l'update proprement dite. Pour le module, rien de plus simple sur une Debian "normale" :</p>
<pre>modprobe dell_rbu</pre>
<p>Pour le fichier HDR, j'ai peiné pendant 2 heures, et en fait, c'est très simple (remplacer le nom du fichier par le nom correct):</p>
<pre>wine E6400A19.EXE -writehdrfile</pre>
<p>Et oui, les exécutables de flashage du Bios Dell savent écrire le HDR !</p>
<p>Et voilà, il ne reste plus qu'à exécuter <code>dellBiosUpdate</code> :</p>
<pre>dellBiosUpdate -f ./E6400A19.hdr -u</pre>
<p>Et à redémarrer sa machine.</p>
<p>Notez que si vous n'êtes pas sur Debian, <a href="http://linux.dell.com/wiki/index.php/Repository/firmware" hreflang="en">Dell propose une manière facile de mettre à jour son Bios</a>. J'ai essayé de faire marcher ça sous Debian, je pense que j'ai réussi à peu près, mais le dépôt ne semble pas à jour avec les derniers Bios. Je vais voir si je peux pas les aider à faire marcher ça pour Debian<sup>[<a href="https://everlong.org/blog/index.php/post/2009/12/Dell%2C-BIOS%2C-Linux#pnote-399-1" id="rev-pnote-399-1">1</a>]</sup>.</p>
<div class="footnotes"><h4>Notes</h4>
<p>[<a href="https://everlong.org/blog/index.php/post/2009/12/Dell%2C-BIOS%2C-Linux#rev-pnote-399-1" id="pnote-399-1">1</a>] Chouette, un autre projet, j'en manquais.</p></div>
Votre vieux noyau Linux tue vos processus ?urn:md5:5da5e40f9001a2acf4c553cfcf4222012009-11-22T21:10:00+01:002009-11-22T21:10:00+01:00Julien WajsbergInformatique2.6.9highmemlinuxlowmemoom killerredhatrhel4sysctl<p>Oui, c'est un peu ce qui est arrivé sur nos machines du boulot.</p>
<p>On a du vieux Redhat Enterprise Linux 4, qui vient avec un vieux noyau 2.6.9 patché jusqu'au cou<sup>[<a href="https://everlong.org/blog/index.php/post/2009/11/Votre-vieux-noyau-Linux-tue-vos-processus#pnote-395-1" id="rev-pnote-395-1">1</a>]</sup>.</p>
<p>Et voilà, ce bon vieux noyau contenait un mécanisme appelé l'<acronym title="Out of memory">OOM</acronym> killer. Ce mécanisme permet, lorsqu'il n'y a plus de mémoire vive disponible, de tuer le "meilleur" processus afin de récupérer de la mémoire vive.</p>
<p>En soi, c'est plutôt louable. Mais voilà, vous vous en doutez, c'est bien la définition de "meilleur" qui pêche ! En l'occurence, c'étaient les processus serveurs. Gênant.</p>
<div class="footnotes"><h4>Notes</h4>
<p>[<a href="https://everlong.org/blog/index.php/post/2009/11/Votre-vieux-noyau-Linux-tue-vos-processus#rev-pnote-395-1" id="pnote-395-1">1</a>] Pour info, on en est au 2.6.31 aujourd'hui. Le 2.6.9 "original" date d'octobre 2004. De l'eau a coulé sous les ponts...</p></div>
<h3>Le log du problème</h3>
<p>Pour commencer, on va passer en revue les informations disponibles dans le fichier <code>/var/log/syslog/kernel.log</code> (j'ai déjà enlevé les parties inintéressantes):</p>
<pre>
Free pages: 14732kB (1536kB HighMem)
Active:219399 inactive:14723 dirty:0 writeback:0 unstable:0 free:3683 slab:3741 mapped:214946 pagetables:871
DMA free:12516kB min:16kB low:32kB high:48kB active:0kB inactive:0kB present:16384kB pages_scanned:331 all_unreclaimable? yes
protections[]: 0 0 0
Normal free:680kB min:928kB low:1856kB high:2784kB active:236kB inactive:148kB present:901120kB pages_scanned:544 all_unreclaimable? yes
protections[]: 0 0 0
HighMem free:1536kB min:512kB low:1024kB high:1536kB active:877360kB inactive:58744kB present:1179648kB pages_scanned:0 all_unreclaimable? no
protections[]: 0 0 0
DMA: 5*4kB 4*8kB 3*16kB 2*32kB 3*64kB 1*128kB 1*256kB 1*512kB 1*1024kB 1*2048kB 2*4096kB = 12516kB
Normal: 0*4kB 1*8kB 2*16kB 0*32kB 0*64kB 1*128kB 0*256kB 1*512kB 0*1024kB 0*2048kB 0*4096kB = 680kB
HighMem: 0*4kB 2*8kB 3*16kB 0*32kB 1*64kB 3*128kB 2*256kB 1*512kB 0*1024kB 0*2048kB 0*4096kB = 1536kB
Swap cache: add 228354, delete 228254, find 68953/77275, race 0+4
0 bounce buffer pages
Free swap: 2062584kB
524288 pages of RAM
294896 pages of HIGHMEM
5620 reserved pages
12977 pages shared
100 pages swap cached
Out of Memory: Killed process 24620 (java).
</pre>
<p>Comme ça, ça fait peur.</p>
<p>Et ce qui est surtout bizarre, c'est qu'il semble qu'il y a encore de la mémoire ! Ce qui est confirmé par la mention :</p>
<pre>HighMem free:1536kB</pre>
<p>et surtout :</p>
<pre>Free swap: 2062584kB</pre>
<p>Effectivement, de la mémoire haute et plein de mémoire virtuelle, même si non-performante, sont disponibles. Mais alors, pourquoi l'OOM Killer se met-il en route ?</p>
<h3>La mémoire sous Linux</h3>
<p>C'est assez compliqué, je vais essayer de simplifier. J'espère que les puristes me pardonneront et/ou me corrigeront le cas échéant.</p>
<p>Pour des raisons que je n'expliquerai pas ici, mais que vous pourrez lire en consultant les liens marqués plus bas, dans tout système en 32 bits qui contient plus de 1 Go de mémoire, la mémoire physique est divisée en deux parties : la partie basse (<code>LOWMEM</code>) et la partie haute (<code>HIGHMEM</code>). On peut voir leurs états avec la commande <code>free</code> :</p>
<pre>
[root@localhost ~]# free -lm
total used free shared buffers cached
Mem: 2026 1106 919 0 12 92
Low: 874 218 655
High: 1151 887 264
-/+ buffers/cache: 1001 1024
Swap: 2015 377 1638
</pre>
<p>Voici les points-clés concernant ces zones :</p>
<ul>
<li>Certains travaux ne peuvent être effectués dans la partie haute</li>
<li>Le noyau a besoin de la partie basse pour adresser la partie haute</li>
<li>L'OOM Killer se met en route s'il n'y a plus de mémoire disponible dans l'une de ces parties</li>
</ul>
<h3>Retour au problème</h3>
<p>C'est bien ce dernier point qu'on voit dans le syslog :</p>
<pre>Normal <strong>free:680kB min:928kB</strong> low:1856kB high:2784kB active:236kB inactive:148kB present:901120kB pages_scanned:544 all_unreclaimable? yes</pre>
<p>La mémoire disponible (680ko) est inférieure à la valeur minimum configurée (928ko) !</p>
<h3>Une solution</h3>
<p>La solution que j'ai mise en oeuvre a été de demander gentiment au noyau de garder de la zone basse de mémoire, de manière plus agressive. Cela se fait par exemple avec la commande suivante :</p>
<pre># echo "250" > /proc/sys/vm/lower_zone_protection</pre>
<p>Ou en mettant la ligne suivante dans <code>/etc/sysctl.conf</code>:</p>
<pre>vm.lower_zone_protection = 250</pre>
<p>Évidemment une meilleure solution aurait été de passer à un noyau récent. On fait pas toujours ce qu'on veut.</p>
<h3>Documentation</h3>
<ul>
<li><a href="http://linux-mm.org/HighMemory" hreflang="en">HighMem</a> sur Linux-mm</li>
<li><a href="http://lwn.net/Articles/75174/" hreflang="en">Virtual Memory: the problem</a> sur LWN</li>
<li><a href="http://kerneltrap.org/node/2450" hreflang="en">High Memory In The Linux Kernel</a> sur Kerneltrap</li>
<li><a href="http://www.redaht.com/archives/redhat-list/2007-August/msg00060.html" hreflang="en">Un e-mail détaillé sur le problème et ses solutions</a></li>
</ul>Rescanner le bus SCSI sous Linux 2.6urn:md5:3198ce33ede6cfc39d9f9e407b9f8f292009-11-20T15:20:00+01:002009-11-22T21:11:15+01:00Julien WajsbergInformatiquelinuxrescanscsivmware <p>C'est tout simple :</p>
<pre>echo “- - -” > /sys/class/scsi_host/host<strong>H</strong>/scan</pre>
<p>Il faut évidemment remplacer <strong>H</strong> par un numéro, généralement <strong>0</strong> lorsqu'on n'a qu'un bus SCSI.</p>
<p>Avec cette commande, on détecte donc les devices SCSI qui ont été ajoutés depuis le dernier scan du bus... utile lorsqu'on ajoute un disque dynamiquement dans une VM gérée par VMWare (ou autres (?)).</p>
<p>On peut vérifier la détection avec la commande <code>dmesg</code> :</p>
<pre>
SCSI device sdb: 20971520 512-byte hdwr sectors (10737 MB)
sdb: cache data unavailable
sdb: assuming drive cache: write through
sdb: unknown partition table
Attached scsi disk sdb at scsi0, channel 0, id 1, lun 0
</pre>
<p>(oui, c'est un aide-mémoire... mais qui sait, ça peut servir à d'autres ?)</p>
<p>Trouvé sur <a href="http://publib.boulder.ibm.com/infocenter/dsichelp/ds8000ic/index.jsp?topic=/com.ibm.storage.ssic.help.doc/f2c_intllndynsan_2hsag7.html" hreflang="en">le site d'IBM</a>, où se trouvent aussi d'autres commandes qui peuvent servir.</p>VMWare, linux, sourisurn:md5:6a45662f2c9ea6c41218ad469e0b74972009-10-01T23:52:00+02:002009-10-01T23:52:00+02:00Julien WajsbergInformatiquegtklinuxsourisvmware <p>Depuis que j'avais mis à jour ma Debian, la souris ne fonctionnait plus correctement dans mon VMWare Windows que j'utilise pour accéder aux applications spécifiques du boulot. En effet, elle n'affectait plus la VM guest, donc je n'arrivais plus à contrôler le système.</p>
<p>J'ai <a href="http://blog.creonfx.com/linux/vmware-player-workstation-mouse-grab-input-focus-bug" hreflang="en">trouvé la solution sur un blog anglophone</a>: il suffit de lancer, à la place de <code>vmplayer</code> :</p>
<pre>VMWARE_USE_SHIPPED_GTK=yes vmplayer</pre>
<p>et voilà :)</p>