Created attachment 80751 [details] kernel.log Symptoms (under 3.0, 3.1, 3.2, 3.3 and 3.5.2 and 3.5.4 amd64 kernels but not with 2.6.37-486-PAE kernel) under a TOSHIBA PORTEGE Z830/Portable PC, BIOS Version 1.60 If i shutdown the computer and wait some hours, the power consumption of the computer is not null, it's about the same as the power consumtion during a suspend of computer. In fact Boot and halt with: Windows 7 ---> No power consumption after Linux 2.6.37-486-PAE ---> No power consumption after Linux >= 3.0 ---> Power consumption (about 45-50 mW if acpitool is correct) I try 3.0, 3.1, 3.2.0 (Debian wheezy kernel), 3.3, 3.5.2 and 3.5.4 kernels. (System is a debian wheezy amd64 with (now) personnal kernel). This bugs is also on a Toshiba satellite A500. On a thread I launch on debian-user-french, someone tells he have the bug on a Vaio. First I think it was something like Wake-On-Lan then Wake-on-WLan but I found nothing (WLAN and WWLAN are disabled or not present), ACPI tell WLAN disabled at shutdown. Booting with apm=debug show nothing revelant at shutdown, and ACPI say that computer goes to S5 state (which is correct). If I make a # shutdown -h -H now and if I «power off» the computer by a long press on On/Off button. No battery consumption happens. If I shutdown the computer, restart it and immediatly «power off» it, no power consumption. The power consumption seems to be the same that when the computer is in suspend. The system is a debian Wheezy, with various kernel. 3 kernels amd64 of debian: 3.2.0-2, 3.2.0-3 3.3.0-rc6 I compiled and tried the 3.0.41, 3.2.28, 3.5.2 and 3.5.4 kernels (source take from kernel archives, .config used is the debian's one). The 3.5.2 and 3.5.4 were compiled with and without the AUFS3.5 patch. All these kernels lead to the same result. Here is the kernel messages with apm=debug option. Modules: Module Size Used by nls_utf8 12456 0 nls_cp437 16553 0 vfat 17316 0 fat 45667 1 vfat usb_storage 43939 0 uas 17468 0 pci_stub 12429 1 vboxpci 19066 0 vboxnetadp 25443 0 vboxnetflt 23571 0 vboxdrv 189965 3 vboxpci,vboxnetadp,vboxnetflt cpufreq_stats 12866 0 cpufreq_powersave 12454 0 cpufreq_conservative 13147 0 cpufreq_userspace 12576 0 parport_pc 22364 0 ppdev 12763 0 lp 17113 0 parport 31858 3 parport_pc,ppdev,lp bnep 17577 2 rfcomm 33666 4 uinput 17479 1 fuse 62285 3 nfsd 198170 2 nfs 271186 0 lockd 55200 2 nfsd,nfs fscache 36807 1 nfs auth_rpcgss 29252 2 nfsd,nfs nfs_acl 12511 2 nfsd,nfs sunrpc 159322 6 nfsd,nfs,lockd,auth_rpcgss,nfs_acl ath3k 12678 0 btusb 17470 0 bluetooth 148845 12 bnep,rfcomm,ath3k,btusb loop 22591 0 dm_crypt 22586 0 dm_mod 63574 1 dm_crypt snd_hda_codec_hdmi 30783 1 snd_hda_codec_realtek 50906 1 joydev 17266 0 uvcvideo 62689 0 videobuf2_core 25974 1 uvcvideo videodev 88014 2 uvcvideo,videobuf2_core media 18148 2 uvcvideo,videodev videobuf2_vmalloc 12664 1 uvcvideo videobuf2_memops 12526 1 videobuf2_vmalloc arc4 12458 2 coretemp 12898 0 kvm_intel 117866 0 snd_hda_intel 26504 2 kvm 298566 1 kvm_intel snd_hda_codec 83533 3 snd_hda_codec_hdmi,snd_hda_codec_realtek,snd_hda_intel ath9k 78275 0 mac80211 331039 1 ath9k snd_hwdep 13186 1 snd_hda_codec snd_pcm 64080 3 snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec i915 398799 4 ath9k_common 12728 1 ath9k snd_seq 45130 0 ath9k_hw 315821 2 ath9k,ath9k_common snd_timer 22917 2 snd_pcm,snd_seq psmouse 69266 0 microcode 25859 0 snd_seq_device 13176 1 snd_seq evdev 17562 16 ath 21417 3 ath9k,ath9k_common,ath9k_hw serio_raw 12980 0 lpc_ich 16665 0 mfd_core 12601 1 lpc_ich drm_kms_helper 27228 1 i915 snd 53077 13 snd_hda_codec_hdmi,snd_hda_codec_realtek,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_pcm,snd_seq,snd_timer,snd_seq_device drm 197822 5 i915,drm_kms_helper pcspkr 12595 0 toshiba_acpi 17994 0 cfg80211 138839 3 ath9k,mac80211,ath sparse_keymap 12760 1 toshiba_acpi i2c_algo_bit 12841 1 i915 soundcore 13026 1 snd i2c_core 23919 5 videodev,i915,drm_kms_helper,drm,i2c_algo_bit snd_page_alloc 12969 2 snd_hda_intel,snd_pcm rfkill 19012 5 bluetooth,toshiba_acpi,cfg80211 battery 13109 0 toshiba_bluetooth 12634 0 video 17629 1 i915 wmi 13243 1 toshiba_acpi acpi_cpufreq 12935 0 mperf 12453 1 acpi_cpufreq ac 12624 0 button 12937 1 i915 processor 28393 1 acpi_cpufreq ext4 361434 2 mbcache 13065 1 ext4 jbd2 71272 1 ext4 crc16 12343 2 bluetooth,ext4 sd_mod 36292 4 crc_t10dif 12348 1 sd_mod crc32c_intel 12747 0 ghash_clmulni_intel 12981 0 ahci 24997 3 libahci 22820 1 ahci aesni_intel 50484 0 e1000e 133724 0 cryptd 14517 2 ghash_clmulni_intel,aesni_intel aes_x86_64 16796 1 aesni_intel sdhci_pci 17894 0 sdhci 26993 1 sdhci_pci mmc_core 68635 2 sdhci_pci,sdhci aes_generic 33026 2 aesni_intel,aes_x86_64 libata 141139 2 ahci,libahci scsi_mod 162270 4 usb_storage,uas,sd_mod,libata xhci_hcd 73727 0 ehci_hcd 40215 0 thermal 17383 0 thermal_sys 18048 3 video,processor,thermal usbcore 128876 7 usb_storage,uas,ath3k,btusb,uvcvideo,xhci_hcd,ehci_hcd usb_common 12354 1 usbcore Thinks for reading and sorry for english.
This bug does not happen on Machine : Acer Aspire One D255 Système : Wheezy 100% à jour + kernel 3.5 (linux-image-3.5-trunk amd64/experimental)
I'm asking for people to make test, This bug does not happen on Acer Aspire One D255 Dell Latitude D-620 Asus 1225b 3.2.0-31-generic Toshiba satellite pro L300 but it happens on Toshiba Portege (Kernel 3.x amd64 but not with 2.6.27-486-PAE kernel) Toshiba A500 Toshiba satellite A300D-21H sous Linux debian 3.2.0-0.bpo.2-amd6 Toshiba Qosmio X500-101 2.6.38-16-generic HP Pavilion DM1 3130 3.5.4-1-ARCH #1 SMP x86_64 hope it's help
The bug is also with a 3.2.0-3-686-PAE kernel (debian) and is not specific to amd64 kernel.
Well. New things to add to this bug. This is not an acpi pbm I think but a bug in RTC. If we make hwclock --systohc just before halt, the battery drain when the computer is off. If we do not make this command, everything go well and battery does not drain. Seeing in rtc.c that writing in CMOS is done just 500ms after the command, I put a «sleep 1» after the hwclock, but battery still drains. So it's a more complicated bug. In conclusion: Putting HWCLOCKACCESS=no in /etc/default/hwclock (which stop all «hwclock --systohc» commands) is a rustin but the bug is still here.
Hi François, Thanks for the report. Is it possible for you to test which is the last working kernel and if the problem is still there on the latest mainline kernel(ie. 3.8)? Thanks.
This morning: jeudi 21 février 2013, 23:57:29 (UTC+0100) Battery #1 : Discharging, 85.35%, 05:51:18 Fri Feb 22 07:00:46 CET 2013 Battery #1 : Discharging, 81.53%, 02:46:17 $ uname -r 3.8.0-fb-aufs so the batterie still draining with this kernel. kernel is le linux-3.8.0 with aufs patch adapted to 3.8 on amd64. So bug still here, sorry.
Hi François, Thanks for reporting back. Can you please attach the output of: # cat /proc/acpi/wakeup and attach acpidump output: # acpidump > acpidump.out And next time, please do not use any out of tree code(aufs shouldn't matter in this case I suppose, but better do not involve them).
Created attachment 93821 [details] cat /proc/acpi/wakeup and acpidump Here are the two outputs. All is disabled in wakeup by a script before shutdown. Sorry for AUFS but I need this feature and I think all patch doesn't matter for this pbm. Next time I take the kernel tree only. Regards
Want to say «aufs patch», not «all patch»... regards
Hi François, Is there any new finding about this problem?
Any update?
Well for no answer but there is no more information. I tried another kernel but nothing more that was not write here before. It is possible for me to make tests (I just finish big work) but what tests? If you want to close this bug you can but in fact this bug is still here. Tell me what I can do but alone, I do not have any more idea then 6 months ago. François Boisson
I assume Aaron is looking for output from an unpatched kernel. Thanks and sorry for the trouble, Jonathan
Yes the bug is there and I'm glad you guys are all still there. I'll need to think about this, I think the hwclock is a good hint.
Bug still here with the 3.10.1 stable (unpatched) kernel. Same symptoms: battery goes from 100% to 98.3 % in about two hours after completed shutdown doing hwclock --systohc before halt. Here https://www.debian-fr.org/portable-toshiba-ne-tient-pas-la-charge-en-etant-eteind-t44574.html you will find another guy with the same problem using the standard wheezy debian amd64 kernel. Regards F.B
ping Aaron.
No idea, sorry.
First, please check your BIOS and disable the options that may consume power during shutdown, e.g. "Wake on Lan". Second, boot and disable all the stuff in /proc/acpi/wakeup, by "echo foo > /proc/acpi/wakeup" if the status of foo in /proc/acpi/wakeup is enabled. Then, shutdown the system and see if the problem still exists.
For BIOS. It's done, even the backlight of keyboard which is disabled. For wakeup, I do it. In fact, now i run this script at boot: #!/bin/sh /sbin/ethtool -s eth0 wol d acpitool -w | grep enabled | grep -v "LID" | sed -e '1,$s/ *\([0-9]*\)\..*$/\1/' | xargs -n 1 acpitool -W but everything I have done with wakeup does not change anything. The only thing which stop the battery consumption is to not save the system clock to hardware clock at shutdown (by setting HWCLOCKACCESS=no on debian in /etc/default/hwclock). This disable /sbin/hwclock --systohc during shutdown
I have the same bug (battery draining after shutdown on TOSHIBA PORTEGE Z830-11G). Am running 3.16-0.bpo.2-amd64 #1 SMP Debian 3.16.3-2~bpo70+1 (2014-09-21) x86_64 GNU/Linux Also the same problem with kernels 3.14 and 3.2. Debian GNU/Linux 7.6 (wheezy) setting HWCLOCKACCESS=no in /etc/default/hwclock has solved the issue for me.
I did some research in google, and found that hwclock --systohc may enables RTC wakeup unexpected, on certain platforms. so my suggestion is 1. enable RTC wakeup by echo nr_sec > /sys/class/rtc/rtc0/wakealarm 2. attach the output of cat /proc/drivers/rtc both before and after the command in step1 3. shutdown the machine with "HWCLOCKACCESS=no" but RTC wakealarm enabled. If we're lucky, we can see that the battery also drains, and we can confirm that this is caused by the rtc wakeup. But TBH, all the test above has nothing to do with ACPI, and I don't know how to fix it even if we can find the root cause. Maybe we can ask Bryan Henderson <bryanh@giraffe-data.com>, the author of hwclock for help.
In fact, except that «cat /proc/drivers/rtc» gives nothing (no file), the battery drain with echo nr_sec > /sys/class/rtc/rtc0/wakealarm about 6% in then night.
(In reply to François Boisson from comment #22) > In fact, except that «cat /proc/drivers/rtc» gives nothing (no file), the > battery drain with > > echo nr_sec > /sys/class/rtc/rtc0/wakealarm > > about 6% in then night. so the battery drains even if HWCLOCKACCESS=no, which works before, right? Now the problem seems to be that "RTC wakeup capability is enabled unexpected by /sbin/hwclock --systohc".
I have sent an email to the RTC experts, let's see if we can get some help.
I just realize that I have a toshiba z830 laptop. I will try to reproduce your problem. Will update later.
I checked Ubuntu on my toshiba z830, it seems that rtc will not be poked during shutdown. Bug closed as this is a distro problem to me, rather than a kernel bug.
It's normal, by default Ubuntu does not update rtc clock on shutdown. Nevertheless it's seems that the time when an update rtc clock before shutdown is important. I wonder if upstart vs sysvrc explain why bug is always on debian (I know two Z830 on Ubuntu, first does not have the bug, second have the bug (!)).