bug: 340014 title: Samsung NC10 fails suspend/Resume tests date-reported: Mon, 09 Mar 2009 16:01:43 -0000 date-updated: Mon, 05 Dec 2011 19:02:19 -0000 reporter: Manoj Iyer (manjo) duplicate-of: duplicates: 343203 344183 attachments: https://bugs.launchpad.net/bugs/340014/+attachment/486140/+files/screen-shot.pdf application/pdf https://bugs.launchpad.net/bugs/340014/+attachment/486141/+files/logs.tgz application/x-tar https://bugs.launchpad.net/bugs/340014/+attachment/540874/+files/dmesg.out text/plain https://bugs.launchpad.net/bugs/340014/+attachment/781057/+files/dmidecode.txt text/plain https://bugs.launchpad.net/bugs/340014/+attachment/781058/+files/lspci.txt text/plain patches: tags: jaunty karmic resume suspend ubuntu-unr subscribers: Manoj Iyer (manjo) Leann Ogasawara (leannogasawara) Teemu Kiviniemi (teemuki) Thilo-Alexander Ginkel (thilo.ginkel) Steve Kowalik (stevenk) BjornW (bjornw) Louis-Marie (lmouton) Paul Elliott (omahn) modhas (launchpad-modhas) panos (panoskolivanis) Fabien Tassin (fta) Andy Whitcroft (apw) Nico Isenbeck (nico-isenbeck) Arkangel (arkangel) tumteetum11 (permanent-daylight) Lex Berger (lexberger) Beelyte (beelyte) Ryan Anderson (ryan-michonline) Kev (ukev) Steve Langasek (vorlon) Marjo F. Mercado (marjo-mercado) papukaija (papukaija) Alexander Johnson (alexmontjohn) task: linux status: Won't Fix date-created: Tue, 02 Jun 2009 10:17:03 -0000 date-closed: Sat, 05 Sep 2009 09:53:11 -0000 reporter: David Stansby (dstansby-deactivatedaccount) watch: https://bugzilla.kernel.org/show_bug.cgi?id=13416 importance: Medium assignee: milestone: task: acpi-support (Ubuntu) status: Invalid date-created: Tue, 25 May 2010 21:48:48 -0000 date-left-new: Tue, 06 Sep 2011 17:46:36 -0000 date-closed: Mon, 05 Dec 2011 19:02:17 -0000 reporter: Steve Langasek (vorlon) importance: Undecided component: main assignee: milestone: task: linux (Ubuntu) status: Invalid date-created: Mon, 09 Mar 2009 16:01:43 -0000 date-left-new: Tue, 24 Mar 2009 19:45:18 -0000 date-assigned: Wed, 25 Mar 2009 15:18:10 -0000 date-closed: Tue, 06 Oct 2009 23:58:42 -0000 reporter: Manoj Iyer (manjo) importance: High component: main assignee: Manoj Iyer (manjo) milestone: ubuntu-9.10 task: pm-utils (Ubuntu) status: Fix Released date-created: Sat, 05 Sep 2009 06:30:10 -0000 date-left-new: Tue, 06 Oct 2009 18:09:40 -0000 date-confirmed: Tue, 06 Oct 2009 18:09:40 -0000 date-triaged: Tue, 06 Oct 2009 18:09:40 -0000 date-assigned: Tue, 06 Oct 2009 18:09:41 -0000 date-inprogress: Wed, 07 Oct 2009 00:02:45 -0000 date-closed: Wed, 07 Oct 2009 00:02:45 -0000 date-fix-committed: Wed, 07 Oct 2009 00:02:45 -0000 date-fix-released: Wed, 07 Oct 2009 00:02:45 -0000 reporter: Thilo-Alexander Ginkel (thilo.ginkel) importance: High component: universe assignee: Steve Langasek (vorlon) milestone: ubuntu-9.10 task: acpi-support (Ubuntu Jaunty) status: Invalid date-created: Tue, 25 May 2010 21:48:48 -0000 date-left-new: Tue, 25 May 2010 21:57:24 -0000 date-closed: Tue, 25 May 2010 21:57:24 -0000 reporter: Steve Langasek (vorlon) importance: Undecided assignee: milestone: task: linux (Ubuntu Jaunty) status: Invalid date-created: Tue, 24 Mar 2009 19:34:19 -0000 date-left-new: Tue, 24 Mar 2009 19:45:18 -0000 date-assigned: Wed, 25 Mar 2009 15:18:10 -0000 date-closed: Wed, 07 Oct 2009 01:28:29 -0000 reporter: Pete Graner (pgraner) importance: Medium assignee: Manoj Iyer (manjo) milestone: task: pm-utils (Ubuntu Jaunty) status: Won't Fix date-created: Sat, 05 Sep 2009 06:30:10 -0000 date-left-new: Tue, 25 May 2010 21:49:58 -0000 date-closed: Tue, 25 May 2010 21:49:58 -0000 reporter: Thilo-Alexander Ginkel (thilo.ginkel) importance: Undecided assignee: milestone: task: acpi-support (Ubuntu Karmic) status: Invalid date-created: Tue, 25 May 2010 21:48:48 -0000 date-left-new: Tue, 25 May 2010 21:57:10 -0000 date-closed: Tue, 25 May 2010 21:57:10 -0000 reporter: Steve Langasek (vorlon) importance: Undecided assignee: milestone: task: linux (Ubuntu Karmic) status: Invalid date-created: Mon, 05 Oct 2009 12:28:00 -0000 date-left-new: Tue, 24 Mar 2009 19:45:18 -0000 date-assigned: Wed, 25 Mar 2009 15:18:10 -0000 date-closed: Tue, 06 Oct 2009 23:58:42 -0000 reporter: Matt Zimmerman (mdz) importance: High assignee: Manoj Iyer (manjo) milestone: ubuntu-9.10 task: pm-utils (Ubuntu Karmic) status: Fix Released date-created: Mon, 05 Oct 2009 12:28:00 -0000 date-left-new: Tue, 06 Oct 2009 18:09:40 -0000 date-confirmed: Sat, 07 Nov 2009 13:23:31 -0000 date-triaged: Sat, 07 Nov 2009 13:23:31 -0000 date-assigned: Tue, 06 Oct 2009 18:09:41 -0000 date-inprogress: Sat, 07 Nov 2009 13:23:31 -0000 date-closed: Tue, 25 May 2010 21:50:19 -0000 date-fix-committed: Tue, 25 May 2010 21:50:19 -0000 date-fix-released: Tue, 25 May 2010 21:50:19 -0000 date-left-closed: Sat, 07 Nov 2009 11:26:36 -0000 reporter: Matt Zimmerman (mdz) importance: High assignee: Steve Langasek (vorlon) milestone: ubuntu-9.10 Content-Type: multipart/mixed; boundary="===============3758204863534023146==" MIME-Version: 1.0 --===============3758204863534023146== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Suspend resume tests on Samsung NC10 fails. The testst that involve attaching & removing the power cord causes the failure. dmesg reports ata1.0: link is slow to respond, please be patient ata1: device is not ready. and the application that are run after the suspend resume failure spits out I/O errors. I have attached the photos of the screen & log files. --===============3758204863534023146== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Author: Manoj Iyer (manjo) Date: Mon, 09 Mar 2009 16:01:43 -0000 Message-Id: <20090309160144.808.51341.malone@potassium.ubuntu.com> --===============3758204863534023146== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Author: Manoj Iyer (manjo) Date: Mon, 09 Mar 2009 16:02:10 -0000 Message-Id: <20090309160210.8517.25960.malone@gangotri.canonical.com> Log files. --===============3758204863534023146== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Author: Matt Zimmerman (mdz) Date: Wed, 25 Mar 2009 15:18:09 -0000 Message-Id: <20090325151810.4258.65124.malone@palladium.canonical.com> Assigning to Manoj per pgraner --===============3758204863534023146== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Author: Teemu Kiviniemi (teemuki) Date: Wed, 01 Apr 2009 20:56:04 -0000 Message-Id: <20090401205604.13188.97968.malone@gangotri.canonical.com> This seems to be the same problem as described in bug #344183. --===============3758204863534023146== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Author: Manoj Iyer (manjo) Date: Tue, 07 Apr 2009 00:41:12 -0000 Message-Id: <20090407004114.7380.75855.malone@gangotri.canonical.com> attaching dmesg output & debugging problem, for reference. --===============3758204863534023146== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Author: Manoj Iyer (manjo) Date: Fri, 10 Apr 2009 14:41:19 -0000 Message-Id: <20090410144119.25913.67454.malone@palladium.canonical.com> I am seeing these errors on resume when there is a transition of power state from "AC unplugged" to "AC plugged in" or vice versa. ata_check_ready() reads the status register which contains the value 0xd0 when the ATA reset error occurs, 0xd0 is not a valid value, and SRST fails and eventually the error handling routine give up trying to reset the device. There are some upstream patches to libata but those dont fix this problem. Similar problems have been reported on other Laptops and the suggestion that worked frequently is to change the BIOS setting for SATA from extendend mode to compatible mode. But the current bios version does not provide any options to change SATA settings. --===============3758204863534023146== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Author: Thilo-Alexander Ginkel (thilo.ginkel) Date: Mon, 13 Apr 2009 23:15:37 -0000 Message-Id: <20090413231537.13382.88401.malone@palladium.canonical.com> The BIOS does have some hidden settings, one of which enables setting the SATA mode. The problem is that the default (at least in BIOS version 04CA) already is "Compatible". To show the undocumented settings, enter the CMOS setup (by hitting F2 during boot). Then, press Fn+F11 followed by Fn+F12. Use a cursor key to force a screen redraw. An "Intel" menu entry will appear. The SATA settings are located at "Intel" -> "ICH Control Sub-Menu" -> "Integrated Device Control Sub-Menu" -> "SATA - Device 31, Function 2". --===============3758204863534023146== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Author: Manoj Iyer (manjo) Date: Tue, 14 Apr 2009 21:53:00 -0000 Message-Id: <20090414215300.18474.57291.malone@potassium.ubuntu.com> Similar discussion on lkml last year, but the patch mentioned in this threa= d is already present in this kernel. Similar related problem ?=20 http://kerneltrap.org/mailarchive/linux-kernel/2008/5/7/1754774 --===============3758204863534023146== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Author: Thilo-Alexander Ginkel (thilo.ginkel) Date: Wed, 15 Apr 2009 22:56:47 -0000 Message-Id: <20090415225647.11436.95348.malone@palladium.canonical.com> I think that the fact that this occurs during the suspend/resume tests is a mere coincidence. I am also seeing these ATA timeouts during regular system boots (with a similar probability). --===============3758204863534023146== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Author: Thilo-Alexander Ginkel (thilo.ginkel) Date: Wed, 15 Apr 2009 23:27:15 -0000 Message-Id: <20090415232715.6280.81990.malone@gandwana.canonical.com> Ok, after some further testing I set the SATA mode on my NC10 to "Enhanced" using the hidden BIOS menu described above. The error seems to be gone, i.e., I have neither been able to reproduce it during suspend/resume or boot nor using the instructions from https://bugs.launchpad.net/ubuntu/+source/linux/+bug/344183/comments/11. Sounds like a BIOS bug that probably needs to be worked around... --===============3758204863534023146== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Author: Manoj Iyer (manjo) Date: Thu, 16 Apr 2009 14:53:57 -0000 Message-Id: <20090416145357.4806.12304.malone@gangotri.canonical.com> I had email communication with Tejun Heo, and here is the chain of thoughts= :=20 >> I am looking at a launchpad bug = =20 >> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/340014 = =20 >> = =20 >> What I am doing is: = =20 >> = =20 >> 1. suspend/resume with AC plugged in = =20 >> 2. suspend/resume with AC unplugged = =20 >> 3. suspend/resume with AC plugged in = =20 >> 4. suspend plugged in, remove AC power, resume = =20 >> 5. suspend with AC removed, plug in AC power, resume = =20 >> = =20 >> Usually after 3 (or 4) I get: = =20 >> = =20 >> ata1: link is slow to respond, please be patient (ready=3D0) = =20 >> ata1: SRST failed (errno=3D-16) = =20 >> ata1: soft resetting link = =20 >> = =20 >> ata1: reset failed, giving up = =20 >> ata1.00: disabled = =20 >> ata1: EH complete = =20 >> sd 0:0:0:0: [sda] Result: hostbyte=3DDID_BAD_TARGET = =20 >> driverbyte=3DDRIVER_OK,SUGGEST_OK = =20 >> end_request: I/O error, dev sda, sector 152855535 = =20 >> Aborting journal on device sda1. = =20 >> = =20 >> After some long hours of debugging I find that when the above happens = =20 >> the ata taskfile status register ap->ioaddr.status_addr is set to = =20 >> 0xd0. returned by function: ata_sff_check_status(), as a result, = =20 >> ata_eh_reset() fails. = =20 >> = =20 >> Any idea what might be going on? Any pointers to help me debug/fix = =20 >> this further is really appreciated. = =20 = =20 Looks like the device or HSM (likely the device) is locking up after = =20 some disturbance at the link. Link problem isn't too surprising after = =20 suspend/resume cycle or AC plug in/out. libata EH can handle those = =20 event just fine. The problem here seems to be... = =20 = =20 * The device needs hardreset to get back to operational state again. = =20 = =20 * Unfortunately, ICH7 currently can't access sata control registers in = =20 ata_piix mode, so it can only do softreset. From ICH8 on, hardreset = =20 works because SCRs are accessible via SIDPR. = =20 = =20 ICH7 has two mechanisms to access SCRs - via ABAR or SIRI/STRD. The = =20 former requires AHCI BAR to be mapped (which isn't true for most = =20 BIOSen) and SCRAE turned on. The SIRI/STRD pair provides windowed = =20 access into ABAR area which includes the SCRs but I've never got = =20 around to do it and I don't know how it would actually work. = =20 = =20 There's also another mechanism. Toggling port enable bits in PCS = =20 might generate hardreset. = =20 = =20 After the device is gone, if you unload and reload ata_piix, does the = =20 device come back? = =20 = =20 Thanks. =20 = =20 manoj.iyer@canonical.com wrote: = =20 >> There's also another mechanism. Toggling port enable bits in PCS = =20 >> might generate hardreset. = =20 > = =20 > This is something I can try, can you point me in the right direction ? = =20 = =20 Well, there's no code yet. rmmoding and insmoding is the easiest it = =20 gets at this point. = =20 = =20 >> After the device is gone, if you unload and reload ata_piix, does the = =20 >> device come back? = =20 > = =20 > in Jaunty kernel, ata_piix is not built as a module, rather, built into = =20 > the kernel. = =20 = =20 Can you roll a vanilla kernel and test it? I wanna make sure that = =20 hardreset is what's required before proceeding further. = =20 = =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I installed jaunty on a USB stick, chrooted into it, and tried my exe= rcise. Interesting =20 observation below: = =20 = =20 1. Boot from HDD, when I remain chrooted to the USB stick suspend/resume ( = with AC plugged in/ unplugged ) no =20 ATA errors. I tried this exercise a few times and noticed that system behav= es well. I even ran suspend/resume =20 multiple times as described in #3. = =20 = =20 2. I boot from HDD, = =20 = =20 - chroot into USB drive, exit. suspend/resume with AC plugged in, chroot in= to USB drive quickly and run dmesg. =20 OK = =20 - exit chroot, unplug AC, suspend/resume, quickly chroot into USB, run dmes= g. OK =20 - exit chroot, plug in AC, suspend/resume, quickly chroot into USB, run dme= sg. ATA errors appear. I rmmod -f =20 ata_piix, it waits for the softresets to timeout, then removed the modules.= I see EXT3 errors now, then I =20 insmod ata_piix.ko. No change, still see ATA errors, hdd does not seem to r= eset, cannot use the filesystem. I =20 rmmod and insmod a few times just in case, no luck, still seeing EXT3 error= s and filesystem on HDD is =20 un-usable. = =20 = =20 3. I boot from USB stick, mount the HDD as /jaunty, and go through my whole= exercise of suspend/resume tests =20 with AC plugged in AC unplugged, even suspend/resume for 30 sec each with 3= 0 sec intervel in between and =20 repeated 60 times. OK. No ATA errors, (using ata_piix as module). = =20 = =20 Now I am thoughly confused. = =20 = =20 Cheers = =20 --- manjo --===============3758204863534023146== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Author: yurukov (yurukov) Date: Fri, 22 May 2009 14:00:34 -0000 Message-Id: <20090522140035.4203.72135.malone@potassium.ubuntu.com> I'm getting the same errors with Easy Peasy 1.0 which is based on 8.10, so that bug is nothing new. Sometimes the wireless works and sometimes it doesn't after resume. I need to restart the system to get it back on. Very annoying! --===============3758204863534023146== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Author: Nico Isenbeck (nico-isenbeck) Date: Sun, 31 May 2009 11:20:33 -0000 Message-Id: <20090531112033.32163.42947.malone@gandwana.canonical.com> The mentioned BIOS settings do not exist any longer in BIOS version 07CA --===============3758204863534023146== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Author: Thilo-Alexander Ginkel (thilo.ginkel) Date: Sun, 31 May 2009 13:08:25 -0000 Message-Id: <20090531130825.28521.241.malone@palladium.canonical.com> @Nico: It won't help anyway. That it initially did for me was most likely a coincidence. How do we proceed? Has this issue been reported upstream already? If not, should I do so? --===============3758204863534023146== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Author: Nico Isenbeck (nico-isenbeck) Date: Sun, 31 May 2009 13:44:15 -0000 Message-Id: <20090531134415.28618.92661.malone@palladium.canonical.com> Please do so, this issue is really annoying. Would be great to get it solved... --===============3758204863534023146== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Author: Thilo-Alexander Ginkel (thilo.ginkel) Date: Sun, 31 May 2009 15:55:12 -0000 Message-Id: <20090531155513.13508.73519.malone@potassium.ubuntu.com> Done: http://bugzilla.kernel.org/show_bug.cgi?id=3D13416 Unfortunately, I can't seem to figure out how to add a bug watch for this URL. Maybe, somebody, who knows how to do this could take care of this. Thanks! --===============3758204863534023146== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Author: David Stansby (dstansby-deactivatedaccount) Date: Tue, 02 Jun 2009 10:17:27 -0000 Message-Id: <20090602101727.5620.49924.malone@potassium.ubuntu.com> Added the bug watch :) --===============3758204863534023146== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Author: Luke Whitmore (lwhitmore) Date: Tue, 14 Jul 2009 15:11:27 -0000 Message-Id: <20090714151127.25823.65045.malone@potassium.ubuntu.com> Hi I'm still getting this error on a regular basis -> especially when I plug or unplug the power (and the power states change). It generally leads to a system freeze and I loose work. I'm currently running Jaunty with 2.6.30-020630-generic. Is there anything I could do to prevent this error from occurring while a fix is being developed? --===============3758204863534023146== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Author: Lex Berger (lexberger) Date: Tue, 14 Jul 2009 15:30:19 -0000 Message-Id: <20090714153019.5765.70151.malone@gandwana.canonical.com> I have not experienced the issue since I use the NC10-optimized kernel provided here: http://www.voria.org/forum/showthread.php?tid=3D41 --===============3758204863534023146== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Author: Fortunato Ventre (voria) Date: Sat, 08 Aug 2009 10:00:30 -0000 Message-Id: <20090808100030.11770.38400.malone@gandwana.canonical.com> The kernel on my NC10 repository is not optimized in any way, it's just a backport to jaunty of the latest kernel available for karmic. --===============3758204863534023146== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Author: Kev (ukev) Date: Wed, 02 Sep 2009 09:39:03 -0000 Message-Id: <20090902093903.25169.13362.malone@palladium.canonical.com> Hi, just found this bug report here after having these issues since a half year.. It's a really annoying bug. (nc10, jaunty 2.6.28-15-generic #49) Is there any progress on this? Last comment is one month ago. --===============3758204863534023146== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Author: Thilo-Alexander Ginkel (thilo.ginkel) Date: Thu, 03 Sep 2009 05:59:56 -0000 Message-Id: <20090903055956.25169.17635.malone@palladium.canonical.com> If you are interested in the current progress, feel free to follow the Kernel bug report, which is referenced from this one. --===============3758204863534023146== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Author: Thilo-Alexander Ginkel (thilo.ginkel) Date: Sat, 05 Sep 2009 06:25:32 -0000 Message-Id: <20090905062532.26756.23888.malone@potassium.ubuntu.com> After a lengthy analysis via the referenced Linux Kernel bug report (thanks, Tejun!) it turned out that the HDD most commonly built into the NC10, a SAMSUNG HM160HI, responds kind of picky when handling the APM feature of the ATAPI SET FEATURE command (typically invoked by hdparm -B) and most likely gets stuck if it receives the command while some load is placed on the system or it receives the same comand multiple times in a row. There are two candidates, which do this after resuming and/or changing the battery state: laptop-mode and acpi-support. While laptop-mode offers a switch (CONTROL_HD_POWERMGMT) in /etc/laptop- mode/laptop-mode.conf to turn off this behavior, acpi-support offers no way of turning off this behavior (apart from turning on CONTROL_HD_POWERMGMT for laptop-mode). If you'd like to debug which commands are sent to the HDD, there is a debugging patch available, which allows printing out all non-data related commands sent to the HDD: http://bugzilla.kernel.org/show_bug.cgi?id=3D13416#c51 Consequently, I am switching over this report to the acpi-support package. As a quick workaround, get rid of all 90-hdparm.sh files below /etc/acpi/ and make sure that CONTROL_HD_POWERMGMT is set to 0 in /etc/laptop-mode/laptop-mode.conf. --===============3758204863534023146== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Author: Manoj Iyer (manjo) Date: Tue, 06 Oct 2009 00:05:22 -0000 Message-Id: <20091006000522.16325.33388.malone@gandwana.canonical.com> dmidecode & lspci infomation. --===============3758204863534023146== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Author: Manoj Iyer (manjo) Date: Tue, 06 Oct 2009 00:06:21 -0000 Message-Id: <20091006000621.6148.32144.malone@palladium.canonical.com> --===============3758204863534023146== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Author: Steve Langasek (vorlon) Date: Tue, 06 Oct 2009 08:57:01 -0000 Message-Id: <20091006085704.31476.57455.malone@potassium.ubuntu.com> acpi-support has been fixed in karmic to not call hdparm -B further; the remaining calls to hdparm (on power event and resume) are in pm-utils. --===============3758204863534023146== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Author: Manoj Iyer (manjo) Date: Tue, 06 Oct 2009 17:14:46 -0000 Message-Id: <20091006171446.16386.8914.malone@gandwana.canonical.com> steve, thanks a ton, is there a ppa that I can install or is it in the daily-build already? I can test this if you point me in the right direction --===============3758204863534023146== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Author: Steve Langasek (vorlon) Date: Tue, 06 Oct 2009 18:06:11 -0000 Message-Id: <20091006180611.6210.73409.malone@palladium.canonical.com> The changes to acpi-support are already in the archive, but are not actually related to the resume hangs at all - I was merely saying that pm-utils is the package that's calling hdparm on resume, so that's what needs to be fixed. As I mentioned on IRC, there is a fix to a /related/ bug in the archive now for pm-utils: we were unnecessarily calling hdparm -B twice on resume, we've now cut this down to one call. So this should improve resume times in general for folks, and *may* be enough to let the NC10 avoid hanging; but if not, we can cook up a quirk mechanism based on the above DMI information. --===============3758204863534023146== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Author: Manoj Iyer (manjo) Date: Tue, 06 Oct 2009 23:58:38 -0000 Message-Id: <20091006235840.32482.11802.malone@gangotri.canonical.com> Latest update of apci-support package from the archive + "rm /etc/pm/sleep.d/99laptop-mode" With the acpi work around I was able to suspend and resume, removing power cord before/after suspend/resume over 30 times with no errors. I believe this an acceptable threshold. Marking this bug as fixed for Karmic. --===============3758204863534023146== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Author: Manoj Iyer (manjo) Date: Wed, 07 Oct 2009 00:02:35 -0000 Message-Id: <20091007000236.16386.11220.malone@gandwana.canonical.com> Latest update of apci-support package from the archive + "rm /etc/pm/sleep.d/99laptop-mode" With the acpi work around I was able to suspend and resume, removing power cord before/after suspend/resume over 30 times with no errors. I believe this an acceptable threshold. Marking this bug as fixed for Karmic. --===============3758204863534023146== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Author: Manoj Iyer (manjo) Date: Wed, 07 Oct 2009 00:03:58 -0000 Message-Id: <20091007000359.16325.84682.malone@gandwana.canonical.com> changes are actually in pm-utils, linux part is invalid, so changing this to invalid from fix-released. --===============3758204863534023146== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Author: Steve Langasek (vorlon) Date: Wed, 07 Oct 2009 01:33:41 -0000 Message-Id: <20091007013341.6148.4449.malone@palladium.canonical.com> Note that the relevant fixes were to the pm-utils and laptop-mode-tools packages, not acpi-support; acpi-support had a gratuitous call to hdparm but only in a path that was unrelated to this bug. Fixing pm-utils and laptop-mode-tools cut the number of back-to-back 'hdparm -B' calls on resume from 3 to 1. The power transition event from unplugging the power while suspended would add an extra 1 call (via gnome-power-manager+devkit-power), so this is a max 2 'hdparm -B' calls vs. 4 before. Since the problem was only being reported in the case where hdparm -B was being called 4 times back-to-back, we are probably now safely below the threshold where we'll trigger this; but a quirk blacklist *can* be implemented, if this problem recurs. --===============3758204863534023146== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Author: Thilo-Alexander Ginkel (thilo.ginkel) Date: Sat, 07 Nov 2009 11:18:50 -0000 Message-Id: <20091107111850.30637.55326.malone@potassium.ubuntu.com> Unfortunately, the issue still pops up after upgrading to Karmic, so the fix did not solve the problem. Could we try the blacklisting approach? --===============3758204863534023146== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Author: Steve Langasek (vorlon) Date: Sat, 07 Nov 2009 11:47:37 -0000 Message-Id: <20091107114737.17212.90682.malone@wampee.canonical.com> Thilo-Alexander, Do you have laptop-mode enabled on this system, or anything else that could generate additional calls to hdparm? In Manoj's tests, suspend/resume worked reliably after the changes tha have been made. --===============3758204863534023146== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Author: Nico Isenbeck (nico-isenbeck) Date: Sat, 07 Nov 2009 12:34:05 -0000 Message-Id: <20091107123405.694.9996.malone@palladium.canonical.com> Hi For me the bug seems to be fixed after upgrading to karmic. I tried to suspend/resume about 15 times without any errors. The above mentioned file /etc/pm/sleep.d/99laptop-mode doesn't exist on my = system. Relevant settings in /etc/laptop-mode/laptop-mode.conf: CONTROL_HD_POWERMGMT=3D1 ENABLE_LAPTOP_MODE_ON_BATTERY=3D1 I did those tests on battery... Steve, would you recommend to disable laptop-mode completely to avoid problems? --===============3758204863534023146== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Author: Thilo-Alexander Ginkel (thilo.ginkel) Date: Sat, 07 Nov 2009 13:39:07 -0000 Message-Id: <20091107133907.17212.54618.malone@wampee.canonical.com> I had CONTROL_HD_POWERMGMT set to 0, so my assumption was that laptop- mode would not issue any APM calls to my HDD. I will patch my current kernel again so that APM calls are traced again, so I can better quantify the calls that are made. (BTW, sorry for the duplicate status change, my Internet connection was kind of unstable when I did the changes.) --===============3758204863534023146== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Author: Steve Langasek (vorlon) Date: Sun, 08 Nov 2009 12:14:49 -0000 Message-Id: <20091108121449.30637.90840.malone@potassium.ubuntu.com> In addition to CONTROL_HD_POWERMGMT, there are two other hdparm settings that may be set: CONTROL_HD_IDLE_TIMEOUT and CONTROL_HD_WRITECACHE, and of these, CONTROL_HD_IDLE_TIMEOUT is also set by default. I don't think this problem is limited only to APM calls, but that any hdparm calls contribute to triggering it. You shouldn't need to patch your kernel to get a trace of apm calls, though; a simple wrapper script should do the job: $ sudo dpkg-divert --add --local --rename /sbin/hdparm $ cat | sudo tee /sbin/hdparm #!/bin/sh echo "called with args: $@" >> /var/log/hdparm.log exec /sbin/hdparm.distrib "$@" ^D $ sudo chmod a+x /sbin/hdparm $ This should give you a log in /var/log/hdparm.log showing every invocation of hdparm on the system. --===============3758204863534023146== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Author: Steve Langasek (vorlon) Date: Sun, 08 Nov 2009 12:16:23 -0000 Message-Id: <20091108121623.694.98844.malone@palladium.canonical.com> Nico, I don't think you need to disable laptop-mode completely, but I think you probably want to set CONTROL_HD_POWERMGMT=3D0 to let pm-utils take care of this. --===============3758204863534023146== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Author: Thilo-Alexander Ginkel (thilo.ginkel) Date: Sun, 08 Nov 2009 23:45:56 -0000 Message-Id: <20091108234556.18603.87642.malone@gangotri.canonical.com> Unfortunately, even single hdparm invocations seem to trigger the issue: called with args: -B 254 /dev/sda init-+-NetworkManager-+-dhclient [...] |-hald---hald-runner-+-hal-system-powe---hal-system-powe---pm-powersav= e---95hdparm-apm---hdparm---pstree [ 1625.989172] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 fr= ozen [ 1625.989213] ata1.00: cmd c8/00:40:67:f4:58/00:00:00:00:00/e2 tag 0 dma 3= 2768 in [ 1625.989219] res 40/00:fe:00:00:00/00:00:00:00:00/40 Emask 0x4 (= timeout) [ 1625.989234] ata1.00: status: { DRDY } [ 1631.028084] ata1: link is slow to respond, please be patient (ready=3D0) [ 1636.012086] ata1: device not ready (errno=3D-16), forcing hardreset [ 1636.012109] ata1: soft resetting link [ 1636.194513] ata1.00: configured for UDMA/133 [ 1636.194536] ata1.00: device reported invalid CHS sector 0 [ 1636.194569] ata1: EH complete The above error was triggered by re-connecting the NC10's power adapter. BTW, the BIOS is already the most recent version (11CA; as somebody suggested a BIOS update via mail). --===============3758204863534023146== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Author: Steve Langasek (vorlon) Date: Mon, 09 Nov 2009 11:24:19 -0000 Message-Id: <20091109112419.30637.190.malone@potassium.ubuntu.com> Just to confirm, could you please add the option 'nohdparm' to your kernel boot line and see whether this problem is still reproducible then? --===============3758204863534023146== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Author: Thilo-Alexander Ginkel (thilo.ginkel) Date: Wed, 11 Nov 2009 04:35:31 -0000 Message-Id: <20091111043531.694.61564.malone@palladium.canonical.com> I can confirm that I see no more hdparm invocations after specifying "nohdparm". Proving that the bug now no longer appears under any circumstances is kind of tricky for a sporadic problem, but I tried dozens of power adapter state changes and a couple of suspend/resume cycles and have not seen the issue surfacing again. --===============3758204863534023146== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Author: giorgio_fornara (giorgio-fornara) Date: Tue, 29 Dec 2009 21:15:52 -0000 Message-Id: <20091229211552.22922.12170.malone@wampee.canonical.com> even with nohdparm in grub the bug STILL remains. Linux 2.6.31-9-rt #152-Ubuntu SMP PREEMPT RT Thu Oct 15 05:01:14 UTC 2009 i= 686 GNU/Linux. ASUS A8J with ST9100824A Ultra ATA/100 100GB (seagate). --===============3758204863534023146== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Author: Steve Langasek (vorlon) Date: Tue, 29 Dec 2009 21:53:00 -0000 Message-Id: <20091229215300.GB4882@dario.dodds.net> On Tue, Dec 29, 2009 at 09:15:52PM -0000, giorgio_fornara wrote: > even with nohdparm in grub the bug STILL remains. Then you must have a different bug. --=20 Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org --===============3758204863534023146== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Author: Steve Langasek (vorlon) Date: Wed, 10 Feb 2010 04:32:40 -0000 Message-Id: <20100210043241.24686.83056.malone@palladium.canonical.com> don't assign bugs to other people. --===============3758204863534023146== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Author: Alexander Johnson (alexmontjohn) Date: Tue, 25 May 2010 19:28:25 -0000 Message-Id: <20100525192826.15785.60073.malone@potassium.ubuntu.com> Has this been fixed? I'm running a relatively fresh install of 10.04 with the latest Kernal on my NC10 (with most recent BIOS) and am still having trouble suspending and resuming. The only setup that works for me is when I suspend from the system menu with my AC cord plugged in. When I select this option, the screen saver comes on for one or two seconds and then the computer goes to sleep. When it wakes back up, the screen saver is on for a moment and then I get the "screen unlock" screen where I have to enter my password. I've also tried without the AC cord, by pressing the "Sleep key" (Fn + F1) and by closing the lid, none of which work. When I awaken the computer (using the power button) I get only a blank screen and cannot use any controls. I'm forced to shutdown by holding down the power key. Interestingly, suspending using these settings (no AC cord, or by pressing the sleep key, or by closing the lid) don't turn on the screen saver for a split second either. It seems that when the screen saver turns on during the suspend process, then I'll be able to wake back up. Does anyone have any ideas where I should go from here? I'm getting the idea that everyone else has worked out a solution to this problem. --===============3758204863534023146== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Author: Steve Langasek (vorlon) Date: Tue, 25 May 2010 21:48:12 -0000 Message-Id: <20100525214811.GA13203@dario.dodds.net> On Tue, May 25, 2010 at 07:28:25PM -0000, Alexander Johnson wrote: > Does anyone have any ideas where I should go from here? I'm getting the > idea that everyone else has worked out a solution to this problem. I recently learned that upower is calling pm-powersave, *in addition* to acpi-support calling it. This would appear to explain the reappearance of the problem, after it was thought to be fixed in karmic before release. Could you try commenting out the 'pm-powersave' line in /etc/acpi/power.sh, and see if this fixes your suspend/resume problems? If it doesn't, you're probably experiencing a different bug. --=20 Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org --===============3758204863534023146== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Author: Alexander Johnson (alexmontjohn) Date: Tue, 25 May 2010 22:15:04 -0000 Message-Id: <20100525221504.5848.76000.malone@palladium.canonical.com> I've tried to edit this file, but I cannot. It's read-only. I changed to root via terminal (sudo bash) but still can't edit the file. Once I can, I comment out with #, correct? --===============3758204863534023146== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Author: Steve Langasek (vorlon) Date: Tue, 25 May 2010 22:22:08 -0000 Message-Id: <20100525222208.13861.43068.malone@wampee.canonical.com> Well, the acpi-support issue is already tracked as bug #582471, so closing the acpi-support tasks here that I just opened. Thilo-Alexander, can you test whether this problem is still present for you in Lucid when booting without nohdparm, and if so, can you try disabling /etc/acpi/power.sh as described to see if that resolves the problem for you? --===============3758204863534023146== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Author: Steve Langasek (vorlon) Date: Tue, 25 May 2010 22:31:06 -0000 Message-Id: <20100525223106.GB13203@dario.dodds.net> On Tue, May 25, 2010 at 10:15:04PM -0000, Alexander Johnson wrote: > I've tried to edit this file, but I cannot. It's read-only. I changed to > root via terminal (sudo bash) but still can't edit the file. With sudo bash, you should be able to edit it. > Once I can, I comment out with #, correct? Yes. --=20 Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org --===============3758204863534023146== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Author: Alexander Johnson (alexmontjohn) Date: Tue, 25 May 2010 22:36:42 -0000 Message-Id: <20100525223642.9725.60808.malone@gandwana.canonical.com> OK, thanks for your help, Steve. I've commented it out, rebooted, and am still experiencing the same problems. Could you describe how to "boot without nohdparm" and how to disable /etc/acpi/power.sh? --===============3758204863534023146== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Author: Steve Langasek (vorlon) Date: Tue, 25 May 2010 22:57:58 -0000 Message-Id: <20100525225758.GC13203@dario.dodds.net> On Tue, May 25, 2010 at 10:36:42PM -0000, Alexander Johnson wrote: > OK, thanks for your help, Steve. I've commented it out, rebooted, and am > still experiencing the same problems. > Could you describe how to "boot without nohdparm" If you're using Grub2 (which is the default when installing Ubuntu 9.10 or later), information about changing the default boot options can be found here: https://help.ubuntu.com/community/Grub2#Configuring%20GRUB%202 > and how to disable /etc/acpi/power.sh? If you've commented out the pm-powersave call, then it *is* disabled, as that's the only thing the script does. --=20 Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org --===============3758204863534023146== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Author: Alexander Johnson (alexmontjohn) Date: Wed, 26 May 2010 19:44:26 -0000 Message-Id: <20100526194426.13504.13925.malone@wampee.canonical.com> Sorry to be such a bother about this, but I'm still having trouble. I've read through that guide, but couldn't find anything related to nohdparm. I found a bunch of files on my computer which included the text "hdparm," but I still have no idea what it does or how to boot without it. Is there any chance you can explain in brief how to do this? Or point me to someone who could? And just to be clear, I'm trying to boot *without* *nohdparm*, correct? That double negative (without...no...) is mixing me up. Thanks in advance if you have the time/energy to continue helping me out with this. --===============3758204863534023146== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Author: Steve Langasek (vorlon) Date: Wed, 26 May 2010 20:11:37 -0000 Message-Id: <20100526201137.13414.13630.malone@wampee.canonical.com> The aim is for you to boot *with* the "nohdparm" option. The guide provides information about how to add extra options when booting, in general; 'nohdparm' is the specific option you need to add to your boot commandline. --===============3758204863534023146== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Author: Alexander Johnson (alexmontjohn) Date: Fri, 28 May 2010 03:16:28 -0000 Message-Id: <20100528031628.2282.79417.malone@wampee.canonical.com> I've tried all combinations of commenting out pm-powersave and using nohdparm. The computer is still unable to suspend and resume. Is there anything else to try from here? Do I need to provide more background information? --===============3758204863534023146== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Author: Steve Langasek (vorlon) Date: Fri, 28 May 2010 03:58:47 -0000 Message-Id: <20100528035847.GB10091@dario.dodds.net> On Fri, May 28, 2010 at 03:16:28AM -0000, Alexander Johnson wrote: > I've tried all combinations of commenting out pm-powersave and using > nohdparm. The computer is still unable to suspend and resume. In that case, you have an unrelated bug. Please file a separate bug report on the linux package using the command 'ubuntu-bug linux'. --=20 Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org --===============3758204863534023146== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Author: Alexander Johnson (alexmontjohn) Date: Fri, 28 May 2010 23:29:04 -0000 Message-Id: <20100528232904.1993.74985.malone@wampee.canonical.com> I've posted my related bug here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/586996 --===============3758204863534023146== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Author: =?utf-8?q?Marek_Bardo=C5=84ski_=28bdfhjk=29?= Date: Mon, 05 Dec 2011 07:26:10 -0000 Message-Id: <20111205072610.6047.13920.malone@chaenomeles.canonical.com> Actual in Oneiric. Please fix, and ask if need info. Unfortunatelly, I've found nothing in kern.log regarding system resume. Thanks in advance! --===============3758204863534023146== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Author: papukaija (papukaija) Date: Mon, 05 Dec 2011 19:02:15 -0000 Message-Id: <20111205190216.31225.6773.malone@chaenomeles.canonical.com> This bug was fixed im pm-utils. Please open a new bug (for linux package) if you still have issues with suspend/resume. --===============3758204863534023146==--