Bug 12276 (sata-resume-dv5)
1. Is ALPM enabled? 2. Can you please post full kernel log including the boot messages? Created attachment 19449 [details]
dmesg output
Created attachment 19450 [details]
lspci -vvnn output
Created attachment 19453 [details]
kern.log
I hope these log files are what you're after, if there's something missing please let me know. I'm not exactly sure how to check if ALPM is enabled. Any suggestions? Did some looking around, the link power management policy is set to max_performance. I need to look at the failing messages but the disk goes offline after resuming so catching the log isn't easy. Can you please plug in a usb stick, cd to it, run "dmesg -c >> dmesg.out", suspend/resume, "dmesg -c >> dmesg.out" and cd out of it, unmount it and post the dmesg.out? It should work even when the disk goes offline. I tried what you suggested, a few different ways, but unfortunately it doesn't work. To use dmesg, or any other executable, one needs access to the filesystem on the failed SATA device. I'm currently trying to do this by booting the system from a USB device, my plan is to then mount the SATA device then capture the dmesg logs as it fails on resume. Will update when I've succeeded or otherwise. Do you have any better suggestions? Hmmm.. usually just keeping the needed binaries running works well enough. Another thing to try is to make a small chroot environment with with dmesg and necessary libraries (ldd `which dmesg`) or just use cat /proc/kmsg instead of dmesg with syslogd/klogd disabled. Well, whatever works should do. Created attachment 19732 [details]
dmesg output from boot (before suspend)
Created attachment 19733 [details]
cat /proc/kmsg started just before suspend and killed after resume
Ok, see the two attachments above. I'm running on a dv4-1080ei, so this isn't just a dv5 issue. Thanks. Does libata.force=1.5Gbps change anything? The link is failing to come up after resume. Unfortunately this didn't help. Any other ideas? Thanks. No, not really. What happens after resuming, you disconnect the drive and reconnect it? Removing and re-plugging SATA drive is safe, so your risk of damaging the hardware by doing it is very small. Created attachment 19908 [details]
dmesg before suspend
This is the dmesg output (booted from Sysrescue cd on USB flash) before suspend
Created attachment 19909 [details]
dmesg after resume
The output from dmesg after resuming
Sorry about the delay in getting back. Christmas / New Years & one nasty Java assignment later. I was able to boot my dv5 from a USB stick with the Sysrescuecd distrib. Obviously the SATA drive still fails to re-awake on resume under this kernel build. Hmmm... can't tell much from the log. I got my mom a dv5 recently and am gonna visit her in a few days. I'll try to test it there but can't tell for sure. Please wait a bit. Thanks. Wow, amazing... thanks a lot! I found an interesting anecdote whilst Googling my hardware. http://forums.macrumors.com/showthread.php?t=501409 This person bought the same hard drive that's in my dv5 as a replacement to install in a MacBook Pro. After installation they discovered that it caused OSX to crash on resuming from suspend. I wonder if it's possible that the hard drive firmware is to blame somehow? Whatever the case, Vista seems to manage the process without incident. I wonder what it does differently? Sorry, I forgot to add. I was looking into the hard drive because I read on the libata wiki that it's likely that error "DevExch" is as a result of a hardware problem; in this case, it's the drive that won't wake up. http://ata.wiki.kernel.org/index.php/Libata_error_messages#SATA_SError_expansion Heh... I played with dv5 for a while but failed to figure out what's going on. :-( I'll try to buy the specific drive and try to figure out more about it. Thanks. Thanks for your efforts Tejun! Let me know if there are any non-destructive tests I can perform on my HDD to help. Over at launchpad.net I'm trying to gather more data on what hardware is associated with this bug. So far the western digital hard drive seems common. Tejun, I've done a survey of the hard drives in affected machines. The majority are Western Digital, very comparable to mine, but there are a few that are not. Of those that are not WD HDDs, only one could really be confirmed as suffering from the identical symptoms on resume. So far all machines affected by this are of model HP dvXXXXX, with one other being a HP / Compaq. I've been doing some testing of my own. Here are the results: On resume the drive is powered up. It appears that the drive can even be powered down once again, after resume, with a hdparm command (embedded in the Ubuntu sleep shell script); but regardless the SATA link stays down. Also tried disconnecting the HDD after resume, merely resulted in the drive staying powered once reconnected. ... resulted in the drive staying powered down once reconnected. sorry. (In reply to comment #25) > Tejun, I've done a survey of the hard drives in affected machines. The > majority > are Western Digital, very comparable to mine, but there are a few that are > not. > Of those that are not WD HDDs, only one could really be confirmed as > suffering > from the identical symptoms on resume. So far all machines affected by this > are > of model HP dvXXXXX, with one other being a HP / Compaq. > I posted just now over at the launchpad page for this. I have a DV5t-1000 and swapped the Western Digital 160GB 5400rpm HDD out with a Hitachi 320GB 7200rpm 3GB/s SATA drive - problem persists. Doesn't appear to be a hard drive issue unless the WD and Hitachi are using same/similar parts/firmware. -Sean No, it doesn't seem to be harddisk dependent. Somehow the link is dead. Paul, what do you mean by "the drive can be powered down once again"? Can you elaborate a bit? I edited the sleep.sh script (which is the Ubuntu method for suspend / resume) and added a "hdparm -Y /dev/sda" to sleep the HDD immediately on resume, followed by "hdparm -z /dev/sda" to reawake it. The result was that on resume the drive awoke, then spun down (I could hear this) and then spun back up again, however the usual error messages persisted at this point. I have not had time to capture what actually happened in a log file but the noises and delays SEEMED to be self evident. I will try this again with logging on the weekend. It seemed quite odd to me considering the link appears to be dead. P.S. Thanks Sean for the feedback on swapping out the hard drive! I am experiencing this same problem on an HP HDX16t with the latest bios. Ubuntu 6.10 Kernel 2.6.27.11 Hitachi 320gb 7200rpm SATA drive Eh... just compared the lspci -nnvvvxxx output I took before and after resume and there was no difference at all. My best (and only) bet was the port enable bits in PCI configuration space. So, at this point, I'm fresh out of ideas and dv5 is the only machine reporting this problem, so I'm quite lost here. Somehow the phy isn't online after resume but I have no idea why. :-( Stuart, can you try to catch dmesg after resume? Also, can you guys please try to capture the output of "lspci -nnvvvxxx" before and after resume? I've just captured the output before and after the resume, and it's identical on this machine too. The suspend seemed to be much smoother now than when I tried it in early January, and I didn't see the error message that was there before. The hibernate also works now, although it still throws up some unsettling ATA errors and seems to spend a while chewing the HD. I'll attach the logs from suspend (before and after). Created attachment 20224 [details]
lspci output before suspend on hp dv3507
Created attachment 20225 [details]
lspci output after suspend on hp dv3507
Victoria, lspci should be run as root to dump all the registers. Can you please also post the output of dmesg after the failed resume? Thanks. Hi! Hmm. It looks like is not only hp is affected. I own a Toshiba L300-19J model, and it does not wake up from suspend. It lights up the led for a second, but after nothing. I do not have an eSATA connector on this laptop. So I cant try it out. Although I have the same SATA controller: 00:1f.2 SATA controller: Intel Corporation ICH9M/M-E SATA AHCI Controller (rev 03) Am I understanding right, that I should boot from an usb pendrive, and suspend resume from there? Can somebody point me to a doc or howto? I highly suspect, that I have the same problem. I tried with 2.6.28 and 2.6.29-rc5 too. Here are some identical(?) bugreports: https://bugzilla.redhat.com/show_bug.cgi?id=476392 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/324808/ Best regards, Khiraly Created attachment 20327 [details]
lscpi of toshiba l300-19j
Just a little question: Does both the DVD drive and the hard drive have a Sata connector?
I'm asking because, booting from a live DVD (ubuntu 9.04-alpha5), the suspend and resume does not work either.
I assume that the problem is with the SATA driver and not the hardrive themselve.
Paul: You managed to suspend/resume using an usb thumbdrive. Have you successed using a live cd/dvd ? I suspect your dvd drive will fail on resume (because of the sata connector).
Could you please verify my hunch?
Created attachment 20330 [details]
lspci -vvvnnnxxx before suspend on systemrescue linux on usb thumbdrive
Created attachment 20331 [details]
lspci -vvvnnnxxx after suspend on systemrescue linux on usb thumbdrive
Created attachment 20332 [details]
output of lsmod after suspend
I write down shortly what I did: 1. I downloaded systemrescue linux distribution(1.1.5) from here: http://kent.dl.sourceforge.net/sourceforge/systemrescuecd/systemrescuecd-x86-1.1.5.iso 2. I burned the .iso to a CD-rom 3. I followed the tutorial to create a bootable USB thumbdrive here: http://www.sysresccd.org/Sysresccd-manual-en_How_to_install_SystemRescueCd_on_an_USB-stick 4. I booted my Toshiba L300-19J laptop from this USB thumbdrive (F12 during boot to select the boot device) 5. I choosed the hungarian layout (18) 6. I issued the echo -n mem >/sys/power/state command to go into sleep mode 7. I pushed the power button. observation: a/ The led of the hdd drive light up for a sec. b/ The CAPSLOCK button worked! so the linux kernel worked. c/ The lcd laptop monitor stayed completely black, not even backlight. It looked the whole laptop just like the suspend from ubuntu. But the capslock worked! (I got curious on this moment) 8. As the capslock worked->the kernel worked. So I issued the following command blindly, and hoping everything goes fine: a/ mkdir /mnt/sda1 b/ mount /dev/sda1 /mnt/sda1 c/ lspci -vvvnnnxxx >/mnt/sda1/home/lspci_after_suspend.txt d/ lsmod >/mnt/sda1/home/lsmod_after_suspend.txt e/ dmesg >/mnt/sda1/home/dmesg_after_suspend.txt So I forgot to save the lspci before suspend. So I rebooted the machine to systemrescue distribution, and save the lspci output. But I didnt repeat the suspend, and blindly typing thing. It is really hard and timeconsuming. (tell me if it is necessary, and I will repeat the above steps in the correct order) If there are other tests Im willing to do, just tell me. Questions: - Does I have the same problem as this bug? Paul: Did you have your screen back after suspend? - I could mount the hard drive after suspend. Is it really SATA related? (if not why suspend from live dvd and normal ubuntu fails completely? (not even capslock working)) - Tejun: Do you need any additional information? Just tell me, and I will repeat the tests, everything. Best regards, Khiraly Created attachment 20334 [details]
dmesg output using systemrescue CD, after the suspend command.
I repeated the experience with systemrescue, using the CD.
It suspended, and woke up! (capslock worked, lcd monitor sayed completely black.)
Same as with the thumbdrive.
I saved the dmesg, it looks slightly different.
Maybe I do not have the same issue as you guys. How can I confirm this?
Best regards,
Khiraly
khiraly, thanks for testing. Your drive woke up just fine. ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata1.00: configured for UDMA/133 sd 0:0:0:0: [sda] 312581808 512-byte hardware sectors (160042 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA So, you don't have the same problem. Sounds like it's just the display that's not waking up. Created attachment 20390 [details]
Outputs from Suspend/Resume using Sysrescue-CD on USB stick
Hi, I followed khiraly's instructions on my HP Pavilion DV5-1000ea Laptop.
On each suspend/resume attempt the display did not come back on resume and I was forced to work 'blind', so to make generating the output easier I created shell scripts in advance.
Please find attached the outputs before and after the suspend/resume, using a Sysrescue-CD USB Stick.
corruptor1972, yes, you're seeing the same problem reported here. (In reply to comment #47) > corruptor1972, yes, you're seeing the same problem reported here. > Thanks Tejun, good to know I'm in the right place but not so good to have a laptop that won't suspend under Ubuntu (it works fine with Vista). I hope the logs help you, give me a shout if you need more info. Thanks for your efforts to resolve this. I've been following this bug for a while. Do you still need more dmesg/lspci dumps? Is there anything else that can be done to try and figure out what is wrong? I'm still waiting for HP to response. I've pinged them again. Is this something we can help with? I'm sure a few more emails from registered HP users could help. What are you waiting for from them? Did you mention that their BIOS update fixed the problem on certain models? Thanks for all your time on this, we really appreciate it :) I'm just trying to get hold of a laptop personnel in HP. I didn't know that BIOS update fixed the problem on some models. Can you please give some pointers? Thanks. There was an early bug report in which a bios update appeared to fix the issue for the dv7's that seemed to be the same. And on that note, the march 2009 bios recently released for dv5's doesn't help either. The previous report was here: http://bugzilla.kernel.org/show_bug.cgi?id=12113 Ah... thanks for the pointer. Great, at least someone knows how to fix it. I'm trying to find out what is going on. Please stand by a bit. Created attachment 21127 [details]
HP HDX full logs, hwinfo, lspci
The same issue with my new HP HDX18 laptop - no hard drives and no CD-Rom (BD-rom) after resume. I try Fedora 10 (X86 and X86_64), Suse 11 (X86_64), Ubuntu 8.10 (x86, x86_64), Gentoo (x86_64) with stock distribution kernels (2.6.27). When i try to build 2.6.29 kernel - problem persists. When i try to boot from USB hard drive with Ubuntu 8.10 (X86, 2.6.27-11). It successfully resumed and i was get all logs. Sorry for my English. I take it you haven't had any luck getting in contact with any hp laptop personnel? I'll have a lot more time to do any additional testing in a week or so if there is anything that would help. I'm in (apparently very slow) contact with HP and it seems it will be fixed one way or the other. I know it has been a loooong wait but please be patient just a bit more. Thanks. This problem exists identically on the HP Pavilion dv6-1030us model. It is not corrected by the recent F.11 nor F.12 BIOS updates for that model, so the differences between the dv7 update that corrects the problem and the dv5 and dv6 updates that do not might shed some light, if they can be determined. The bug anecdotally appears to be common with ICH9M/M-E SATA controllers on other brand laptops, and appears to be bypassed/negated if a BIOS toggle from AHCI to IDE mode is available and used. The dv5 and dv6 models do not provide this toggle in BIOS setup. Awaiting more word from Tejun. Thanks for pressing this issue with HP. I can confirm that this is still occurring on the HDX16 with the latest BIOS (F21a) installed. I have a dv5-1120el, latest bios f14A, and I have also these problems. If you have any fix, patch to test, feel free to ask me testing it. Thanks The same behavior on my Acer Aspire X3200 (Ubuntu 9.04 amd64) Sata disk can't resume from suspend to ram. Kernel option pci=nomsi partially helps: disk starts, but system seems unstable. Sergey, what you're seeing is most likely a different issue. Can you please open a separate bug report and attach 1. the output of "lspci -nn" 2. boot log w/o the pci=nomsi option and if possible log from resume failure 3. boot and suspend/resume log w/ pci=nomsi Thanks. HI !!! Now works! I had same problem with a HP DV4 1050el notebook (freeze in resuming), but after upgrade to latest BIOS release F34A, now suspend and resume work fine (YES !!!). Before only hibernate works fine for me. I use GNOME power manager or pm-suspend in a shell (same behaviour) I am using latest Mandriva 2009.1 64 bit version with original kernel 2.6.29.1, but no changes with Ubuntu 9.04 which I used before... Suspend works fine with internal wi-fi module activated and connected (INTEL 5100 Shiloh)... Instead, suspend don't works if external USB WI-FI is connected (Zydas 1211rw module)... I have only a black screen, and soft reboot (Sysreq REISUB) needed... May be this problem caused by module zd1211rw or Zydas firmware ? Congratulations Enrico, but this is a bug for the DV5 - which has a different BIOS. The DV5 BIOS is still HP abandonware. No successful resume available for DV5 owners yet. (In reply to comment #64) Ok Paul! I did not want to create a "bug report" only for the DV4 series because is very similar to DV5 (14,1' screen instead of 15,4') I think and hope that HP will release soon a Bios upgrade also for DV5 series Ciao Tejun, when you visit this bug again, please advise if I should open a separate bug for the dv6-1030us. The symptoms are identical to the dv5 postings, but it is indeed a slightly different product, with a different (but closely numbered) bios. Thanks. Good to hear that the problem is solved on one of the machines. Unfortunately, the best we can do here seems to be waiting for HP to release BIOS update with fixes, so I don't think opening a new bug report would do anything. :-( Thanks. I am a developer, but not in C++ and C. And i know, what if software can work with hardware well (i mean windows suspend and resume well) - and some program can't do that - bug in program - not in hardware. My HP HDX has up to date bios and can't success resume under linux - so, i mean, bug is open. Yeah, sure the bug is open. No one is saying otherwise. There just isn't anything I or anyone can do unless HP releases some information on the issue. I keep asking for it but haven't received anything material yet. Also, please note that whether something works or not isn't really representative of where the root cause of the problem is. I'll be happy to implement workaround for the problem if the information is available but that doesn't necessarily mean it's a bug in the linux driver. Thanks. I certainly have not been able to isolate the problem here to a Linux driver, but 30 years as a systems engineer leaves me with the idea that if one piece of software can perform a certain hardware manipulation and another one can't, there is a flaw or a missing feature in the second piece of software. Granted, the root cause may be that the hardware manufacturer has not shared proprietary data uniformly with all software creators. I'd agree that it's not reasonable to expect a fix without more hardware information from HP. It appears they could provide a workaround by including an IDE toggle in the BIOS, but it also appears that they know how to correct the Linux problem with AHCI in their firmware without doing that. (In reply to comment #71) > I certainly have not been able to isolate the problem here to a Linux driver, > but 30 years as a systems engineer leaves me with the idea that if one piece > of > software can perform a certain hardware manipulation and another one can't, > there is a flaw or a missing feature in the second piece of software. > Granted, > the root cause may be that the hardware manufacturer has not shared > proprietary > data uniformly with all software creators. I don't really get what you're trying to achieve here. Sure, it can be a bug in the kernel ACPI or ahci driver implementation but it's more likely some quirkiness in the BIOS acpi implementation of the affected machines. It just doesn't matter which way it is. Workarounds, features, bugs, why does that matter? It works, it works. It doesn't, it doesn't. > I'd agree that it's not reasonable to expect a fix without more hardware > information from HP. It appears they could provide a workaround by including > an IDE toggle in the BIOS, but it also appears that they know how to correct > the Linux problem with AHCI in their firmware without doing that. Yeah, they know, so my 30+ years of living tells me that the only sensible thing to do is to write to *THEM*. Well, HP had enough time to respond. ATA known issues entry added for HP laptops. http://ata.wiki.kernel.org/index.php/Known_issues#Recent_HP_laptops_fail_disk_detection_after_resuming_from_suspend Thanks. Thanks. The other sensible thing is to write _about_ them, which you've done. I apologize if my follow up on problem isolation and root cause gave any offense. I guess it was gratuitous, as you suggest. No worries. I'm just quite frustrated about the issue. At this point, I really don't see any other option than advising against getting those machines. If you already have one, please go ahead and complain as loud as you can to the vendor. :-( Thanks. In addition to encouraging Ubuntu users to contact HP support, I've started a HP Support Forum thread in an attempt to get HP's attention. http://h30434.www3.hp.com/psg/board/message?board.id=Hardware&thread.id=9394 As I see it, the big goal is to get noticed by someone in HP who can actually do something about this. Please, leave your reply on the thread to show your support. Tejun, while I'm busying petitioning HP for a fix, I'm wondering if there aren't other avenues that can also be explored. Vista is able to reactivate, or resume the prior state of, the ATA devices on the dv5 where Linux cannot. Perhaps Vista has more thorough, or non standard, way of bringing the devices back to life. Whatever the case, are there some compile time options, or perhaps a crude patch, for the libata driver that could let us experiment with different ways of resuming, reactivating or resetting the SATA drives, or controller, on the dv5? Whilst I have looked at the source code for the ATA drivers on a number of occasions, I am simply not a kernel engineer. Is there someone who could help us with this? I (and others) would be happy to recompile kernels, try different settings or apply simple hacks if I just new what to tinker with. It would be wonderfully to find a workaround while we wait, and hope, for HP to release a permanent fix. Thanks for your help to date! Hello, (In reply to comment #77) > Tejun, while I'm busying petitioning HP for a fix, I'm wondering if there > aren't other avenues that can also be explored. > > Vista is able to reactivate, or resume the prior state of, the ATA devices on > the dv5 where Linux cannot. Perhaps Vista has more thorough, or non standard, > way of bringing the devices back to life. Yeap, it's very likely there is some software workaround (or fix) driver can implement to resolve the situation. I tried a few things while I had access to the machine but none of the usual tricks worked. The thing is that things like this are pretty difficult to debug. There isn't much diagnostic information which can be obtained using usual techniques, so I was hoping that I could get some information on the subject from the vendor. Also, please note that these recent HP laptops are the only machines which are experiencing this problem out of all the intel ahci machines, laptop or not, which is why I'm a bit skeptical about linux doing something terribly wrong. But, really, blame game isn't that interesting. Regardless of standard compliance or whatever, nothing can replace actual testing and without testing breakages will happen one way or the other. I'm just a bit disappointed at how the situation played out. Oh well... > Whatever the case, are there some compile time options, or perhaps a crude > patch, for the libata driver that could let us experiment with different ways > of resuming, reactivating or resetting the SATA drives, or controller, on the > dv5? I tried the usual ahci suspects but none worked. If someone with hardware access is interested in trying out different things, it would be great. Thanks. I have a dv5-1120el and I know how to compile and patch kernels. I can do whatever test you need ;) Please tell me what kernel/patches I must use and what tests I can do. Thanks, Emilio Thanks for the prompt reply Tejun. I can also compile and patch kernels, and have a dv5 to test on. It's just that the driver code, to my eyes, is so copious that I'm not sure where start. If had some basic direction I could definitely begin trying different things. I can code, it's just that my experience in mostly in higher level languages such as Java and Python. Is there any additional documentation that accompanies the driver code? I found an older PDF out there but I can't be sure it's still valid. The source comments aren't always enough at my level. Or, is there anyway I get additional debug information from the driver, so that I can at least can more feedback whilst testing my system? Thanks for your continued help, it's all appreciated! Latest BIOS rev F.21 for the dv6-1030us cures the problem. I now have suspend. No BIOS update at HP yet for the dv5, but judging from the incremental progression, I'd guess there will be one soon: they've now cured the dv[4-6]. I don't have much idea what to try at this point. What we can do is to blacklist the affected machines such that the kernel can reject suspend and warn the user to update the BIOS. Can you please post dmidecode output before (if possible) and after the update which fixes the problem? Created attachment 21590 [details]
dv6-10308s dmidecode F.21 bios
Per request from Tejun
Created attachment 21591 [details]
dv6-10308s lshal F.21 bios
(In reply to comment #81) > Latest BIOS rev F.21 for the dv6-1030us cures the problem. I now have > suspend. > No BIOS update at HP yet for the dv5, but judging from the incremental > progression, I'd guess there will be one soon: they've now cured the dv[4-6]. Um, that should be: dv[4,6-7]. I request the f.21 BIOS be released for the dv5's and the response was to "Please get back to the Software and Driver Download page for your notebook later to get the updated the versions of BIOS." Hopefully it actually gets posted. As of this morning an F.16 A BIOS though it doesn't appear to have been uploaded to their ftp site quite yet so I have been unable to test it yet. The enchancements include : * Updates the Intel MRC Code to version 2.7. * Updates the Intel AHCI OP ROM to version iSrc 1.20_E.0012 11252008. * Updates the BIOS to support Microsoft Windows Vista Operating Systems with Service Pack 2 (SP2). So I am hopeful this will resolve the issue. I'll grab a dmidecode of before so older bios can be blacklisted, especially since an upgrade should at this point resolve the issue. Thanks for the update Trevor! I can confirm that it's not yet possible to download the file. Hopefully this is what we've been waiting for. Fingers crossed ... Please grab a dmidecode if you can; I'm currently only running Vista, hopefully that will be changing very soon! Trevor, regarding the F.16 A bios (for dv5?), could you please post the pack number of this bios (spXXXXX.exe) so we can download it from the hp ftp? Thanks The link provided is: ftp://ftp.hp.com/pub/softpaq/sp43501-44000/sp43819.exe but as I mentioned, they don't appear to have uploaded it to their ftp site yet. It is for a dv5 (dv5t-1000 CTO in my case) and I would guess most dv5's affected link to the same download though to be sure i'd recommend you browse to the proper download page for you laptop first rather then assume this BIOS is the same for all. Most if not all dv5's should be listed here: http://h20180.www2.hp.com/apps/Lookup?lang=en&h_client=S-A-R163-1&cc=us&h_query=pavilion+dv5&h_page=hpcom,igmx&submit=Go%20%C2%BB&y=0&h_pagetype=s-002&h_cc=us&x=0&h_lang=en I assume the delay in appearing on the ftp site due to it being queued and/or stalled on some approval process/mirror syncing before it is publicly available. If it doesn't show up in the next day or two I'll contact them again on the matter. I have just applied HP's F16A BIOS to my DV5-1000ea. This has solved the suspend/resume issue. A BIG thanks to Paul, TJ and all who took time to get involved. Created attachment 21611 [details]
dmidecode before upgrade F.14 A
Created attachment 21612 [details]
dmidecode after upgrade F.16 A
I can confirm the BIOS upgrade does fix the issue. I've attached a dmidecode before the upgrade and after from my laptop. Kudos to HP for releasing an update. I can confirm that the BIOS upgrade for the HDX series also fixes the problem. I'm attaching dmidecode before and after the upgrade. I was on F21A, which appeared briefly before they backed up to F20A. I'm now on F23A and the problem is fixed. Here's the update page: http://h10025.www1.hp.com/ewfrf/wc/softwareDownloadIndex?softwareitem=ob-71239-1&lc=en&dlc=en&cc=us&product=3884584&os=2100&lang=en Thanks to Tejun, Intel, HP, and everyone who helped to get this found and fixed. Created attachment 21614 [details]
DMI Decode output from HDX18t before upgrade to F23; resume doesn't work
Created attachment 21615 [details]
DMI Decode output from HDX18t after upgrade to F23; resume does work
Created attachment 21616 [details]
hp-broken-suspend.patch
Can you please test the above patch? It should do the followings if the bios is too old for suspend on dv5, 6 and hdx18.
1. print warning message during probing
2. veto suspend attempts and print error message
If you already have updated and don't or can't go back for verification, just modify .driver_data string such that it points to the next revision - ie. for hdx18, make it "F.24" and verify the warning message is printed and suspend fails with error message.
Thanks.
Tejun, I'll be applying the BIOS update this weekend, as I need to repartition and reload Ubuntu, so I'll let you know how this patch goes. I've noticed on the Ubuntu bug report that the HDX16 also seems included in this break / fix, not sure if that was included your patch or not. Thanks Tejun! Just a note that the BIOS update fixes the problem in the dv4 range as well. I have a dv4-1080ei; I don't recall my old BIOS release but an upgrade to F.30 (releases 2009-05-01, sp42636.exe) sorted me out. I see now that a few days later HP released a F.34 A BIOS on 2009-05-05 (sp43550.exe). According to Comment #65 this also fixes the problem, as he experienced on his HP DV4 1050el. I must also mention that the BIOS update only shows up under Support & Downloads for VISTA, and not XP. Hope this helps. Created attachment 21617 [details]
DMI decode from a dv4-1080ei after F.30 BIOS upgrade (fixes the issue)
Created attachment 21620 [details]
hp-broken-suspend.patch, dv4 added
dv4 added and the original patch included hdx18. Thanks.
Created attachment 21624 [details]
dv5-1120el_f.14a_withpatch
I've compiled a vanilla kernel 2.6.29.4 and applied Tejun's latest patch.
I've not already updated the f.14A bios, and if I try to suspend the message is written on dmesg:
ahci 0000:00:1f.2: BIOS update required for suspend/resume
So the patch is good for me. I've attached the full dmesg.
Thanks everybody for all the support.
Created attachment 21625 [details]
dv5-1120el_f.16a_withpatch
I've updated the bios, suspend works and the ahci driver doesn't display the warning as expected.
So it seems that dv5-1120el is fixed by the bios update.
Thanks hp for the fix, although it should have worked out of the box (software/firmware always have bugs, the important is to fix them).
Other pc productors simply would have replied us "we don't support linux" (I had a sony notebook and I've sold it for problems like this), so I'm happy ;)
(In reply to comment #104) > Other pc productors simply would have replied us "we don't support linux" (I > had a sony notebook and I've sold it for problems like this), so I'm happy ;) Actually, that's exactly what HP replied when I contacted support (they added "on that machine"). Created attachment 21631 [details]
hp-broken-suspend.patch, trigger warning only on suspend
As hibernation works fine, fail only suspend. I'm posting this version upstream. Thanks.
Tejun, I've tried the patch on my dv5 (1075er) and it worked as advertised. Is there anything else you need? Thanks for your help on this. Great. The patch is pending upstream (Jeff will probably pick it up soonish) and I don't think there's much else we can do at the moment. I'm resolving this one as CODE_FIX. Thanks for your patience. Thanks guy for your work. Now my suspend work! Version bugged: HP dv6-1014el BIOS F0.24 Updated BIOS to F 24 A released on 2009-07-03, no other modifications needed, only fresh install and bios update. Thanks!! Oooops, forgot, i'm running Kubuntu 9.04 Jaunty Jackalope on kernel 2.6.28-15-generic. It works like a charm! Thanks. Thank you for sharing good content. I found your blog on google search, it’s very helpful. Also, check out <a href="https://community.mcafee.com/t5/user/viewprofilepage/user-id/235732" rel="">Linkedin Jobs for Graduate in Nigeria</a> |
Latest working kernel version: None Earliest failing kernel version: 2.6.27.7 Distribution: Ubuntu 8.10 Hardware Environment: HP Pavilion dv5 Software Environment: Problem Description: When resuming from sleep (s3) on a HP Pavilion dv5 (and some similar models) the SATA hard drive will not wake. The initial error message is: btusb_intr_complete: hci0 urb f7d94a00 failed to resubmit (2) ata2: exception Emask 0x10 SAct 0x0 SErr 0x0 action 0x9 t4 ata2: irq_stat 0x00000040, connection status changed ata1: exception Emask 0x10 SAct 0x0 SErr 0x0 action 0x9 t4 ata1: irq_stat 0x00000040, connection status changed sd 0:0:0:0: rejecting I/O to offline device PM: Device 0:0:0:0; failed to resume: error 65536 Then, the most repeated error message is as follows: ata1: exception Emask 0x10 SAct 0x0 SErr 0x4000000 action 0xe frozen ata1: SError: { DevExch } ata2: exception Emask 0x10 SAct 0x0 SErr 0x4000000 action 0xe frozen ata2: irq_stat 0x00000040, connection status changed ata2: SError: { DevExch } There is a bug report filed on LaunchPad.net: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/301353/ Some comparable models with ostensibly the same problem have had this resolved through a BIOS update from HP. No such update is available for the dv5 series, at the moment, and suspend / resume works fine under other operating systems on this laptop. Steps to reproduce: Simply suspend then resume. This problem is consistent.