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



Reply via email to