Bug#650081: ACPI wakeup doesn't work on ASUS P8H67-M EVO
Hi, On 17/01/12 20:40, Jonathan Nieder wrote: Eric Lavarde wrote: Could it be that the BIOS overwrites my command line entry at shutdown time, but not at suspend time? Sure, I can believe that. It's also possible that when you try to enter S5, something goes wrong and the machine ends up powering off completely and then the BIOS writes to the RTC at bootup. Here's an experiment to try: echo shutdown>/sys/power/disk echo disk>/sys/power/state It performs a suspend-to-disk but enters S5 instead of S4. Bingo! The PC doesn't come back up after this, so it's a difference between S4 and S5. Stupid question: do you know if it would be possible to shutdown (going through init and all this) into S4? After that: maybe RTC or ACPI folks can help (see the MAINTAINERS file[1], and please cc me or this bug log if contacting them so we can track it). But I'd be more inclined to work on getting Will do. Thanks a lot for your help so far! suspend-to-disk working without unloading the media capture driver first. I will also follow-up on this, fine with me, but I'm more a friend of clean shutdowns :-) so it'll be either as fallback strategy or for the community. Cheers, Eric [1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob_plain;f=MAINTAINERS -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#650081: ACPI wakeup doesn't work on ASUS P8H67-M EVO
Eric Lavarde wrote: > Could it be that the BIOS overwrites my command line entry at > shutdown time, but not at suspend time? Sure, I can believe that. It's also possible that when you try to enter S5, something goes wrong and the machine ends up powering off completely and then the BIOS writes to the RTC at bootup. Here's an experiment to try: echo shutdown >/sys/power/disk echo disk >/sys/power/state It performs a suspend-to-disk but enters S5 instead of S4. After that: maybe RTC or ACPI folks can help (see the MAINTAINERS file[1], and please cc me or this bug log if contacting them so we can track it). But I'd be more inclined to work on getting suspend-to-disk working without unloading the media capture driver first. [1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob_plain;f=MAINTAINERS -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#650081: ACPI wakeup doesn't work on ASUS P8H67-M EVO
Hello, On 14/01/12 17:33, Jonathan Nieder wrote: Eric Lavarde wrote: I'm surely not experienced in these topics, but I thought that there should be no difference for the BIOS / ACPI between a pure shutdown and a suspend to disk. Nah, they are different. Suspend to disk happens with ACPI cooperation. [...] Let me know if I can test / do anything further to solve the issue, It's possible your machine only supports wake from S4 and not S5, in which case the best bet would be to get your (out-of-tree?) driver to suspend to disk sanely. By the way, has there been any effort to get that out-of-tree driver merged upstream? Please file a bug describing the missing functionality it provides, and I can try working on that. All that said, I see no reason _in principle_ that a machine that can wake from S4 should not be able to wake from S5. It might be possible to debug this as an ACPI or RTC issue. Please test 3.2-rc7 from experimental without any out-of-tree drivers, and provide: i. full "dmesg" output from booting, setting the wakeup timer, hibernating with "echo disk>/sys/power/state", and waking up ii. information about what happens if you instead boot, set the wakeup time, shutdown with "shutdown -h now", and wake up Done (see attached files from an xterm -l logfile + the script used) - in the 2nd case it doesn't wake up, so that's easy... Also, when you set the wakeup timer, is it visible from the CMOS menus? If it is, that might help in comparing what happens in cases (i) and (ii). With "CMOS menus" you mean the BIOS? If yes, then it doesn't appear, I only see what I enter in the BIOS. Perhaps interesting: if I do a 'cat /proc/driver/rtc' after a reboot (i.e. before having entered myself a time), I see what I entered manually in the BIOS under alrm_time and alrm_date: rtc_time: 07:39:05 rtc_date: 2012-01-17 alrm_time : 18:15:00 alrm_date : 2012-01-17 alarm_IRQ : yes alrm_pending: no update IRQ enabled : no periodic IRQ enabled: no periodic IRQ frequency : 1024 max user IRQ frequency : 64 24hr: yes periodic_IRQ: no update_IRQ : no HPET_emulated : yes BCD : yes DST_enable : no periodic_freq : 1024 batt_status : okay If I read the rtc after resume from suspend, I see the time I had entered from the command line before the suspend: rtc_time: 07:53:29 rtc_date: 2012-01-17 alrm_time : 07:52:21 alrm_date : 2012-01-17 alarm_IRQ : yes alrm_pending: no update IRQ enabled : no periodic IRQ enabled: no periodic IRQ frequency : 1024 max user IRQ frequency : 64 24hr: yes periodic_IRQ: no update_IRQ : no HPET_emulated : yes BCD : yes DST_enable : no periodic_freq : 1024 batt_status : okay Could it be that the BIOS overwrites my command line entry at shutdown time, but not at suspend time? I have the impression that the BIOS has 2 places with wake-up time: A for the configuration itself (what has been entered in the BIOS by the user, me, and is visible in the BIOS GUI) and B to actually get the PC to wake-up, and it copies A to B at shutdown time... What do you think? Am I f* up? Thanks, Jonathan I thank you, Eric Xterm.log.emil.2012.01.17.08.13.05.DISKSUSPEND.gz Description: GNU Zip compressed data Xterm.log.emil.2012.01.17.08.24.24.HALT.gz Description: GNU Zip compressed data acpi_test.sh.gz Description: GNU Zip compressed data
Bug#650081: ACPI wakeup doesn't work on ASUS P8H67-M EVO
Eric Lavarde wrote: > I'm surely not experienced in these topics, but I thought that there > should be no difference for the BIOS / ACPI between a pure shutdown > and a suspend to disk. Nah, they are different. Suspend to disk happens with ACPI cooperation. [...] > Let me know if I can test / do anything further to solve the issue, It's possible your machine only supports wake from S4 and not S5, in which case the best bet would be to get your (out-of-tree?) driver to suspend to disk sanely. By the way, has there been any effort to get that out-of-tree driver merged upstream? Please file a bug describing the missing functionality it provides, and I can try working on that. All that said, I see no reason _in principle_ that a machine that can wake from S4 should not be able to wake from S5. It might be possible to debug this as an ACPI or RTC issue. Please test 3.2-rc7 from experimental without any out-of-tree drivers, and provide: i. full "dmesg" output from booting, setting the wakeup timer, hibernating with "echo disk >/sys/power/state", and waking up ii. information about what happens if you instead boot, set the wakeup time, shutdown with "shutdown -h now", and wake up Also, when you set the wakeup timer, is it visible from the CMOS menus? If it is, that might help in comparing what happens in cases (i) and (ii). Thanks, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#650081: ACPI wakeup doesn't work on ASUS P8H67-M EVO
Hi, On 24/12/11 08:24, Jonathan Nieder wrote: forwarded 650081 http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/42256 quit Eric Lavarde wrote: [ 581.247437] I2C timeout [ 581.247442] IRS 0001 [... hundreds of line of this type ...] Let's take this upstream, starting with this bit, under the principle "fix the most egregiously broken piece first". Many thanks, Jonathan Sorry for the delay and possibly for the confusion, but holiday and the VDR is in production so my users r my family doesn't like extensive test sessions (or they can't look TV ;-) ). Anyway, as already written in the answer to [1], I've now the possibility to do tests with a clean kernel and the result is exactly the same: waking up after a halt / poweroff does NOT work, waking up after a 'disk' suspend DOES work (even with latest Kernel linux-image-3.1.0-1-amd64 / 3.1.8-2). I'm surely not experienced in these topics, but I thought that there should be no difference for the BIOS / ACPI between a pure shutdown and a suspend to disk. Checking what is done differently in the kernel might tell us what the issue is, no?! Let me know if I can test / do anything further to solve the issue, I can possibly work around the other issues with suspend to disk (probably the right rmmod at the right place) but I'm not a big fan of suspend as I favor stability over speed of boot. Thanks, Eric [1] http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/42256 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#650081: ACPI wakeup doesn't work on ASUS P8H67-M EVO
Hi, On 24/12/11 08:24, Jonathan Nieder wrote: forwarded 650081 http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/42256 quit Eric Lavarde wrote: [ 581.247437] I2C timeout [ 581.247442] IRS 0001 [... hundreds of line of this type ...] Let's take this upstream, starting with this bit, under the principle "fix the most egregiously broken piece first". Many thanks, Jonathan Sorry for the delay and possibly for the confusion, but holiday and the VDR is in production so my users r my family doesn't like extensive test sessions (or they can't look TV ;-) ). Anyway, as already written in the answer to [1], I've now the possibility to do tests with a clean kernel and the result is exactly the same: waking up after a halt / poweroff does NOT work, waking up after a 'disk' suspend DOES work (even with latest Kernel linux-image-3.1.0-1-amd64 / 3.1.8-2). I'm surely not experienced in these topics, but I thought that there should be no difference for the BIOS / ACPI between a pure shutdown and a suspend to disk. Checking what is done differently in the kernel might tell us what the issue is, no?! Let me know if I can test / do anything further to solve the issue, I can possibly work around the other issues with suspend to disk (probably the right rmmod at the right place) but I'm not a big fan of suspend as I favor stability over speed of boot. Thanks, Eric [1] http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/42256 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#650081: ACPI wakeup doesn't work on ASUS P8H67-M EVO
forwarded 650081 http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/42256 quit Eric Lavarde wrote: > [ 581.247437] I2C timeout > [ 581.247442] IRS 0001 > [... hundreds of line of this type ...] Let's take this upstream, starting with this bit, under the principle "fix the most egregiously broken piece first". Many thanks, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#650081: ACPI wakeup doesn't work on ASUS P8H67-M EVO
Hi, On 26/11/11 13:02, Jonathan Nieder wrote: I hope to find time to look at this more soon. For now I've assigned you bug#650081. If these turn out to have the same cause, we can merge them later. After a look at [1], I extracted the ACPI tables according to: acpidump >acpidump # cp your ACPI tables from memory to disk acpixtract -a acpidump # extract them into raw, single tables and attach them here. I must admit that the rest looks like voodoo to me, but if you can provide some more specific instructions, I'd be more than happy to help drive this forward. Thanks, Eric [1] http://lwn.net/Articles/237085/ ASUS_P8H67-M_EVO_acpi.tgz Description: application/compressed-tar
Bug#650081: ACPI wakeup doesn't work on ASUS P8H67-M EVO
Hello, for what's it's worth, I've contacted ASUS and their only answer, beside we don't support Linux because there are so many of them, was that their board supports the ACPI Specification 2.0a. Eric -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#650081: ACPI wakeup doesn't work on ASUS P8H67-M EVO
On 26/11/11 13:02, Jonathan Nieder wrote: Hi Eric, Eric Lavarde wrote: I have exactly the same problem with my new computer with an ASUS P8H67-M EVO mainboard and latest 3.1.0 kernel (amd64) - I attach a reportbug created on the same computer. I hope to find time to look at this more soon. For now I've assigned you bug#650081. If these turn out to have the same cause, we can merge them later. Thanks for writing, Jonathan No idea at all if it's related but nvram-wakeup doesn't work either... See https://sourceforge.net/tracker/index.php?func=detail&aid=3442733&group_id=35022&atid=412959 I am now really, really f*-up! My new VDR-computer is useless without wake-up capability... Any help would be more than welcome. Thanks, Eric -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
