reassign 693720 src:linux forwarded 693720 https://bugzilla.kernel.org/show_bug.cgi?id=47811 thanks
On Montag, 19. November 2012, François Boisson wrote: > Package: base > Severity: normal > > > > -- System Information: > Debian Release: wheezy/sid > APT prefers testing > APT policy: (500, 'testing'), (500, 'stable'), (1, 'experimental') > Architecture: amd64 (x86_64) > > Kernel: Linux 3.5.4-fb-aufs (SMP w/4 CPU cores) > Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > > Lorsqu'on arrête la machine avec l'option HWCLOCKACCESS non précisé ou mise > à yes (c'est pareil), donc lorsque la machine effectue un english version below... > hwclock --systohc > > juste avant de s'arrêter, la batterie perd sa charge. En fait la > consommation est à peu près celle d'une mise en veille. > > Si on met l'option HWCLOCKACCESS=no (par exemple dans /etc/default/hwclock) > alors cette perte de charge n'a plus lieu. Un «sleep 1» juste après le > hwclock ne résoud pas le problème. Ce bug arrive avec les noyaux 3.0 -> > 3.5.4. > > À noter que ce bug n'a pas lieu sur une Ubuntu (il faudrait voir si cette > option est par défaut sur Ubuntu). > > J'ai constaté la présence de ce bug sur tous les Toshiba et sur d'autres > machines. Voir à ce sujet > > https://bugzilla.kernel.org/show_bug.cgi?id=47811 > > (je pensais ce bug lié au noyau auparavant). > > English: Halt the computer with HWCLOCKACCESS not set or set to yes causes > battery to drain. (Consumption is about the same that when the computer > is in sleep mode). > If we put HWCLOCKACCESS=yes in /etc/default/hwclock, then battery doesn't > drain off then. So doing > > hwclock --systohc > > before halt causes battery to drain. Put «sleep 1» after hwclock doesn't > change anything. > This happens on various computers but not with the Ubuntu distribution. > Look at https://bugzilla.kernel.org/show_bug.cgi?id=47811 for the first > bug report when I thought that it was an ACPI bug. (Now I think it's a > kernel bug in the gestion of RTC but may be I'm wrong). > > Regards