Current hdapsd 2.6.19 kernel patch applies to 2.6.20 but breaks build. Patch to 2.6.20_rc6: http://thread.gmane.org/gmane.linux.drivers.hdaps.devel/979 http://news.gmane.org/find-root.php?message_id=%3c30311145.481170171206673.JavaMail.root%40epia.dresco.co.uk%3e http://cache.gmane.org//gmane/linux/drivers/hdaps/devel/979-001.bin Testing. I think uberlord is still handling this.
Hm, doesn't work; the completion handling seems to have changed since _rc6. We'll have to wait until someone fixes the patch for 2.6.20.
fyi: http://www.nabble.com/attachment/9047418/0/hdaps_protect-2.6.20.patch.bz2 works for me on sys-kernel/gentoo-source-2.6.20-r8
the patch from comment #2 works with sys-kernel/suspend2-sources-2.6.21-r4 and my ATA disk too. It applies fine with some offsets (you might want to fix that too). Please consider to include it to the portage.
Created attachment 121020 [details] ebuild for hdapsd-20070524 There is also a new hdapsd on http://www.zen24593.zen.co.uk/hdaps/ I modified the old ebuild to use the new hdapsd-20070524 and the patch for 2.6.20, which are currently downloaded from the web. Please note that this is the first time that I am messing with ebuilds, so there are no guarantees. It works on my system and that's all I can say.
There is one more thing about hdapsd. I tested it with 2.6.21 kernel and found out that the current daemon takes 19.9% ( 49.8) hdapsd : do_nanosleep (hrtimer_wakeup) wakeups from idle based on the output from powertop tool. I understand it has to be very fast to be able to park a harddisk, but the wake up time should be more reasonable, I think. How about... 10 times per second instead of 50?
Will the ebuild for hdapsd-20070524 be uploaded into the portage tree for testing?
Created attachment 125631 [details] ebuild for hdapsd-20070524 with new kernel patches for 2.6.20 to 2.6.22 I found a new kernel patch on http://article.gmane.org/gmane.linux.drivers.hdaps.devel/993 which supposedly works on 2.6.20 to 2.6.22. I updated the hdapsd ebuild to use this patch and also included some cosmetic improvements to the ebuild. I don't like the way the ebuild currently dumps the patches into /usr/share/doc/hdapsd-20070524-r1/. It's a nasty hack. If someone can point out the proper way to do this (or another ebuild where I can learn by example) I'll be happy to fix it. @Anton: I saw "Powertop Patches" for hdaps mentioned someplace, that might address your concerns about power consumtion. Haven't looked into it yet though. Insert Standard Disclaimer here: ... have no clue what I am doing ... bla, bla ... works on my machine ... use at your own risk ...
Some news: http://www.thinkwiki.org/wiki/HDAPS#Userspace_daemon http://article.gmane.org/gmane.linux.drivers.hdaps.devel/1045 http://article.gmane.org/gmane.linux.drivers.hdaps.devel/1040 hdapsd.c - Reduced power version - reduces timer interrupts, as measured by PowerTOP. This leads to lower power consumption on tickless kernels. Interrupt reduction requires the hdaps kernel module from tp_smapi 0.32 or newer, and a udev rule. hdapsd has to be updated and a new udev script should be included too. Tony, could you close all version bump HDAPS related bugs please?
*** Bug 196047 has been marked as a duplicate of this bug. ***
Ok -- from my other bug which was marked as duplicate: New patches for 2.6.22 and 2.6.23: http://article.gmane.org/gmane.linux.drivers.hdaps.devel/1077 The 2.6.22 patch works fine with my 2.6.22-suspend2-r2 kernel.
Created attachment 134514 [details] ebuild for hdapsd-20070524 with new kernel patches for 2.6.20 to 2.6.23 Ok guys, heres an updated ebuild that includes the new kernel patches. It opreates the same was as before and is STILL a nasty hack. So once again, if someone could tell me how to do this properly or point me to a cleaner example i'd be much obliged. The power patches are NOT included here. As Anton pointed out these patches rely on tp_smapi 0.32 or newer, but the newest version in the tree is 0.31, so i don't see much sense in including these patches currently. I would try to figure out how to put these patches into the ebuild as soon as one of you guys pulls a new tp_smapi ebuild together ...
I tried out the new r2 ebuild, but it fails to download the patches from gmane. Can anybody correct that? Thanks and cheers, buschaot
Have a look at: http://article.gmane.org/gmane.linux.drivers.hdaps.devel/1077 That's the thread that the patch is appended to. You have to mark the interesting part (there is a patch for 2.6.22 and 2.6.23), and paste it to a text file...
The gentoo-sources 2.6.23-r8 update to fix the vmsplice security issues motivated me to update from my own custom kernel. In the process I had to apply the hdaps protect patch so I went to ThinkWiki to see what was available, since the current ebuild doesn't have patches for 2.6.23. Thinkwiki pointed me to the following patches, which apply cleanly against gentoo-sources-2.6.23-r8, build correctly and seem to work fine (3 hours with no issues). There are 2 patches of interest - a disk-protect patch for 2.6.23 and a patch for 2.6.20 or greater that corrects a deadlock in the disk-protect patch. I don't have an ebuild handy since I applied these by hand, but I include the links here to the email threads and patch file downloads. Since many people probably want/should want to update gentoo-sources to fix the vmsplice issues, I suggest this might be a good time to get the hdaps patches up-to-date for thinkpad users. Disk protect patch ------------------- Thread URL: http://sourceforge.net/mailarchive/message.php?msg_name=87fxz3g2b2.fsf%40denkblock.local Patch URL: http://sourceforge.net/mailarchive/attachment.php?list_name=hdaps-devel&message_id=87pry7ehx3.fsf%40denkblock.local&counter=2 Deadlock patch -------------- Thread URL: http://sourceforge.net/mailarchive/message.php?msg_name=fj316o%24e7q%241%40ger.gmane.org Patch URL: http://sourceforge.net/mailarchive/attachment.php?list_name=hdaps-devel&message_id=fj316o%24e7q%241%40ger.gmane.org&counter=1
The kernel team are currently unwilling to add the HDAPS patches to the main gentoo-sources kernel - see bug #141565 I'm semi-maintaining some patched versions of the kernel in my overlay (layman -a welp - make sure you have git stuff), but that needs to be updated. Watch out for a .24 kernel coming soon (hopefully!)
*** Bug 209907 has been marked as a duplicate of this bug. ***
*** Bug 214202 has been marked as a duplicate of this bug. ***
*** Bug 163867 has been marked as a duplicate of this bug. ***
Created attachment 146829 [details] Reduced power version, requires tp_smapi >=0.32 Sorry for the dup. Jakub wants all issues together, so here we go.
This thing would be best removed altogether; completely useless as it is.
(In reply to comment #20) > This thing would be best removed altogether; completely useless as it is. It works here (although not with the kernel patch provided by the ebuild) - so at least its not useless for me.
(In reply to comment #21) > It works here (although not with the kernel patch provided by the ebuild) - so > at least its not useless for me. I've been talking about the ebuild... ;) While the in-kernel stuff might be POS according to bug #141565 Comment #26, it can hardly be more of a POS than this thing that fails to work with any supported Gentoo kernel and has been failing for over a year, with these random kernel patches causing more harm than good apparently, such as the issue in Bug 163867. Why exactly can't this stuff be pushed into vanilla kernel if the in-kernel stuff sucks that much?
> Why exactly can't this stuff be pushed into vanilla kernel if the > in-kernel stuff sucks that much? Because the blk_freeze patches that are required to make hdaps really work are of a highly experimental nature, based on my reading of the mailing lists from whence they come (see comment 14). Since they only benefit a small subset of users with specific hardware and touch crucial parts of the disk i/o subsystem, pushing them into the vanilla kernel by default seems imprudent. It sucks to require a kernel patch and rebuild to get hdaps working fully, but it's not that onerous. My recommendation would be to disable CONFIG_SENSORS_HDAPS by default in the vanilla sources since the in-kernel module is useless except as a novelty (maybe even patch it out so it isn't there to tempt people) and refer people to the tp_smapi package if they want disk parking. IMHO the blk_freeze patches supplied by this ebuild belong in the tp_smapi ebuild, since that package actually supplies the supplemental hdaps kernel module. Right now the module built by tp_smapi can't actually work fully until the blk_freeze patches are applied by this package. That seems broken to me, or at least confusing. The outcome of a tp_smapi install with hdaps enabled should be a fully working module with the appropriate kernel support. This package should just supply the daemon to make it work if the user chooses. This all sucks royally, of course. In the long run I'd like to see all the hardware support be part of the official kernel where it belongs. Not sure why things are the way they are now.
I have fixed bug #196052, bug #166166, bug #164518 and uploaded hdapsd ebuild + tp_smapi ebuild (bug #219285, #215967 fixed) to my sectools overlay: http://gentoo.o0o.nu/sectools.xml http://gentoo.o0o.nu/portage/app-laptop/hdapsd/ Let me know if any problem with it. P.S. to comment #23: I disagree, blk_freeze should stay together hdapsd daemon.
> P.S. to comment #23: I disagree, blk_freeze should stay together hdapsd daemon. Care to explain your reasoning? hdapsd is a *userspace* daemon that monitors the state of the accelerometer and initiates protection by communicating with the hdaps module via the hdaps_protect sysfs interface. It doesn't implement the protection - that's the job of the hdaps *kernel* module which requires the blk_freeze patch to the *kernel* to work properly. That patch logically belongs in the package that actually supplies the hdaps kernel module. That way, any other tool that wants to manage disk protection (eg. an alternative hdaps daemon with a better algorithm, or a custom user created tool) won't have to contend with a broken hdaps kernel module. The module should have the potential to function fully and properly regardless of which specific userspace daemon happens to be initiating disk protection.
> Care to explain your reasoning? Sorry, I was busy with the overlay. Well, first of all, our conversation is a bit pointless, because the patch soon or later should go to the kernel. While your reasons sounds logical and make 100% sence, my thoughts are that tp_smapi does not provide hdaps functionality only. Also, all functions of tp_smapi are more for monitoring purpose; user might not use hdaps freeze function at all and might not expect that it would patch system-level critical files and add an additional functionality to the kernel. Another point is that if we would use a kernel-space monitoring patch instead it would be logical to keep them together. Anyway, for now, everything is wrong: tp_smapi together with blk_freeze patches should be in the kernel, hdapsd should have it's own homepage and a maintainer.
(In reply to comment #26) Agree on all counts. Except I still think hdaps kernel patches belong with the kernel module. *wink* > Anyway, for now, everything is wrong: tp_smapi together with > blk_freeze patches should be in the kernel Seems to be happening gradually, which is hopeful. The deadlock patch mentioned in #14 I normally apply to my own kernels wasn't necessary in 2.6.26 any longer since the kernel code had the fix already. I guess the right thing to do instead of yakking about it here is to help Elias Oltmanns and others in their efforts to get this into the mainstream kernel. (/me prepares to follow my own advice) Some relevant links: http://mailman.linux-thinkpad.org/pipermail/linux-thinkpad/2008-May/043658.html http://lkml.org/lkml/2008/2/25/478 Peace.
*** Bug 216641 has been marked as a duplicate of this bug. ***
A new hdapsd has been released by Elias. See here: http://article.gmane.org/gmane.linux.drivers.hdaps.devel/1372 It's required for the 2.6.27 kernel release candidate patches AND is backwards compatible. So maybe when 2.6.28 becomes testing the hdapsd package can be "fixed" to use this version and require a kernel >=2.6.28. Cheers
Created attachment 167586 [details] The new hdapsd (based on the reduced power version)
Thank you Martin for the good news. Just to add, the new version of patch will be in 2.6.28, and backported for 2.6.27 can be find here: http://article.gmane.org/gmane.linux.drivers.hdaps.devel/1379 http://cache.gmane.org//gmane/linux/drivers/hdaps/devel/1379-001.bin
Created attachment 173738 [details] hdapsd-20081004.ebuild Here's an ebuild for hdapsd-20081004 together with the kernel patches for 2.6.26 and .27 (I left out all the older ones). It creates the necessary udev rule, adds -y in conf.d if tp_smapi isn't used (no warnings), and checks for already patched kernel in block/blk-sysfs.c It's EAPI="2" ('cause I use SRC_URI arrows for fetching the stuff from gmane), so you'll need to use >=portage-2.2_rc11.
(In reply to comment #32) Thomas, I didn't mention, but sectools overlay's users should be using it already. The url is still the same: http://gentoo.o0o.nu/portage/app-laptop/hdapsd/ I'm not sure how it's different from yours. It's still EAPI=1. Works well for me so far.
Created attachment 175470 [details] updated init file, 2.6.27 support the new location for 2.6.27 kernel is: /sys/block/${DISK}/device/unload_heads
Created attachment 175473 [details] kernel_patched function fixed an updated ebuild from my sectools overlay. We are using the following line for kernel_patched() check: "ata_id_has_unload" "${KERNEL_DIR}"/include/linux/ata.h Recent patches from the mailing list are also in the the same overlay
(In reply to comment #33) > I didn't mention, but sectools overlay's users should be using it already. Uh, I wasn't aware of that. > I'm not sure how it's different from yours. It's still EAPI=1. Works well for > me so far. Well, I've outlined my changes in #32. Main difference is the adding of the udev rule to support the new polling method. EAPI=2 is only used for fetching hdapsd source and kernel patches from gmane archives (instead of supllying them in ${FILESDIR}.
Thomas, I believe udev rule belongs to tp_smapi package (see manual) and the bug report #215967 has to be fixed. It'll be only installed if "hdaps" use flag is enabled in tp_smapi ebuild: http://gentoo.o0o.nu/portage/app-laptop/tp_smapi/tp_smapi-0.39-r1.ebuild
*** Bug 252591 has been marked as a duplicate of this bug. ***
*** Bug 242138 has been marked as a duplicate of this bug. ***
Created attachment 179153 [details] added ~amd64 This thing runs fine on amd64, so I took the liberty of adding the keyword.
Created attachment 180324 [details] Ebuild for hdapsd-20090129 Here is an ebuild for hdapsd-20090129. This release adds support for multiple disks using multiple -d options, but the init script only supports one disk.
(In reply to comment #41) > Ebuild for hdapsd-20090129 Also, the udev rule is now included upstream. The ebuild I posted should install it.
I created an HDAPS overlay: (clone) http://michael.orlitzky.com/git/hdaps-overlay.git (gitweb) http://michael.orlitzky.com/git/?p=hdaps-overlay.git;a=summary to make my life easier. I'll try to keep the hdapsd ebuild updated with whatever's available. I wrote the one in there now (20090129), but if somebody else posts a better one, I'll include it with his or her permission. There's an xfce4-hdaps panel plugin in there too, if anyone's using XFCE.
I managed to install ebuild for hdapsd-20090129(except for the part where here it doesn't have hdpasd.conf and hdapsd.init, used the ones from older version) and I'm running kernel 2.6.28.5, hdapsd managed to start but It's not working. I don't have the /sys/block/xda/queue/protect file and /sys/block/xda/device/unload_heads refuses any operations. Can't read or write to it. hdapsd can't either. I'm wondering if it's a problem with the kernel or just with my hard drive.
I had the same problem with one of laptops and I fixed it by RTFM :) /usr/src/linux/Documentation/laptops/disk-shock-protection.txt: If you know that your device really does support the unload feature (for instance, because the vendor of your laptop or the hard drive itself told you so), then you can tell the kernel to enable the usage of this feature for that drive by writing the special value -1 to the unload_heads attribute: # echo -1 > /sys/block/sda/device/unload_heads will enable the feature for /dev/sda, and giving -2 instead of -1 will disable it again.
With kernel 2.6.28. I had a problem with a wrong error message that comes from /etc/init.d/hdapsd There, I could find the lines: if [[ ! -e /sys/block/${DISK}/queue/protect ]] ; then eerror "No protect entry for ${DISK}!" eerror "Make sure your kernel is patched with the blk_freeze patch" return 1 fi Obviously, Kernel 2.6.28 doesn't neet that check. So I just commented out those lines. This can be done, by adding a # before every line. Maybe, one also want to write echo -1 > /sys/block/sda/device/unload_heads instead of these lines, to force the disk to enable unloading. Then everything works.
(In reply to comment #46) > With kernel 2.6.28. I had a problem with a wrong error message that comes from > /etc/init.d/hdapsd Anton's ebuild from sectools overlay has a correct check for that: http://gentoo.o0o.nu/portage/app-laptop/hdapsd/hdapsd-20090129.ebuild
Created attachment 187844 [details] modified to install udev rule
Created attachment 187845 [details] udev rule
With the ebuild and udev rules I just attached, plus the conf and init files from Anton's overlay, hdapsd works well on my T61 with tp_smapi-0.40 and tuxonice-sources 2.6.29.
Created attachment 187928 [details] Version bump. Udev rules obsolete http://gentoo.o0o.nu/portage/app-laptop/hdapsd/
*** Bug 263324 has been marked as a duplicate of this bug. ***
Comment on attachment 187845 [details] udev rule Anton, thank you -- your new ebuild works well for me.
(In reply to comment #53 > (From update of attachment 187845 [details] [edit]) Thanks for the update, works for me T61 kernel 2.6.27-r8, tp_smapi-0.40 , no kernel hsaps module. (needed to use -force_io though, since i didnt update the BIOS.)
Guys, please vote for this bug. kernel 2.6.29 is getting stable, hdapsd got its own homepage page and all other problems seems to be solved too. I don't see any reason why it's not in the portage yet.
Here's my vote. I'm just trying to migrate to TuxOnIce-2.6.28 and this issue is getting a pain in the posterior :-(
By "vote" I mean to use new and a bit hidden feature of gentoo's bugzilla: "vote for this bug" link https://bugs.gentoo.org/votes.cgi?action=show_user&bug_id=166166#vote_166166 We've got 23 guys in CC list and only 5 voted. You can set up to 10 points. Thanks. Peter, may be you could also update us on the status please?
I didn't know about this vote system. But fancy it is! And hidden too! So, I used this hdapsd-20090401 ebuild, kernel 2.6.30-rc7-git4 and tp_smapi 0.40. Works like it should on my ThinkPad R51 1830-DG4.
OK, I voted :-) And here's my experience so far: - Current hdapsd-20090401 (seems to) work(s) for me on a ThinkPad T43 with kernel tuxonice-sources-2.6.28-r10 and tp_smapi-0.40 (HD light shows activity on shaking the laptop; what other possibilities to check parking state?). - I had to add "echo -1 > /sys/block/${DISK}/device/unload_heads" to /etc/init.d/hdapsd as mentioned in comment #46. - Neither khdapsmonitor nor khdapsmon from portage seem to recognize the current hdapsd interface and report no drive protected.
(In reply to comment #59) RTFM and use search :-): cat /sys/block/${DISK}/device/unload_heads bug #254322 ps. I think it make sense to stop supporting the old path "/queue/protect" in future. It brings more confusion then functionality.
(In reply to comment #59) > (HD light shows activity > on shaking the laptop; what other possibilities to check parking state?). > - I had to add "echo -1 > /sys/block/${DISK}/device/unload_heads" to > /etc/init.d/hdapsd as mentioned in comment #46. > - Neither khdapsmonitor nor khdapsmon from portage seem to recognize the > current hdapsd interface and report no drive protected. maybe you want to try the gnome-hdaps-applet from http://www.zen24593.zen.co.uk/hdaps/ (is in my overlay http://svn.xmw.de/gentoo-overlay/gnome-extra/hdaps-applet/ ).
Thanks Anton for pointing to the patch. I was able to integrate the ebuild and patch into my local overlay, khdapsmonitor is working now. When current hdapsd support is finally updated in portage this will also have to be included... Good work!
How about a version bump? Eix (sync as of 2009-09-28) keeps telling me theres a version from 2006 * app-laptop/hdapsd Available versions: ~*20060409 ~*20060409-r1 ~*20060409-r3 Homepage: http://hdaps.sourceforge.net/ Description: IBM ThinkPad Harddrive Active Protection disk head parking daemon While there are recent versions from 2009 http://sourceforge.net/projects/hdaps/files/hdapsd/
welp retired or something - assigning to maintainer. mobile: any input? i'm tempted to commit this...
*** Bug 254314 has been marked as a duplicate of this bug. ***
*** Bug 164518 has been marked as a duplicate of this bug. ***
+*hdapsd-20090401 (14 Oct 2009) + + 14 Oct 2009; Thilo Bangert <bangert@gentoo.org> +hdapsd-20090401.ebuild, + files/hdapsd.init: + version bump from bug #166166 + please test.
Seems to work fine here. I observe /sys/block/sda/device/unload_heads, and the number goes non-zero when I jerk the laptop. Thanks!
If this is just the same as the ebuild in the sectools overlay, then it works well - or are there any changes compared to the sectools-version and I'd really have to try it out?
yes - there are minor edits, but it shouldnt be anything big.
I've been running the ebuild from an overlay for months now on my X61s. No problems to report. The new ebuild from portage works fine, too.
Guys, all hdaps related ebuilds are in the portage now and I've removed them from sectools overlay. Thank you for using it. I didn't use my usual -r100.ebuild so you need to run "emerge -1 hdapsd" to start using version from the portage. This 3 years bug is fixed, please close it :)
anton: thanks for your work over the years. and thanks for the feedback. closing. please open new issues whenever you find something. remember to move your votes. thanks kind regards Thilo
Same here - no problems since yesterday, and sectools-version was running stable for about a month (before that I had used a version from jokey's overlay-which I also considered stable). So I'd vote for stable on amd64 (Thinkpad X61Tablet, Hitachi 500GB SATA 9mm version)
the initscript for version 20090401 has a bug which prevents the start of hdapsd: look at checkconfig() if [ ! -f /dev/${DISK} ] doesn't work, you must use -b instead of -f, because the hard disk file is not a regular file but a block device.
(In reply to comment #75) Did you remember to update the init script with dispatch-conf or cfg-update? The init script in the Portage files dir for hdapsd has no such line -- it relies on the config file /etc/conf.d/hdapsd. With this initscript, hdapsd functions is able to start on my machine.
no - mark is right. the check was added without a version bump, so you might not have it. i changed -f to -b as suggested. thanks for the report - sorry for the oversight. for new issues please open new and separate bug reports. thanks
