Dear Maintainer,
I have a fresh install of debian jessie in a notebook with systemd as the init system.
When I install the package hdparm, my system freezes at start up and take more than 1 minute to boot up, instead of 18 seconds without hdparm installed.
The interesant portion of the system log is the following:
[...]
mar 22 04:21:16 Link systemd-udevd[188]: timeout '/lib/udev/hdparm'
mar 22 04:21:17 Link systemd-udevd[178]: worker [188] /devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/bloc
mar 22 04:21:17 Link systemd-udevd[178]: seq 1033 '/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/s
mar 22 04:21:17 Link systemd-udevd[178]: worker [191] /devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/bloc
mar 22 04:21:17 Link systemd-udevd[178]: seq 1035 '/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/s
mar 22 04:21:17 Link systemd-udevd[178]: worker [188] terminated by signal 9 (Killed)
mar 22 04:21:17 Link systemd-journal[160]: Forwarding to syslog missed 1 messages.
mar 22 04:21:18 Link kernel: ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
mar 22 04:21:18 Link kernel: ata1.00: failed command: READ DMA
mar 22 04:21:18 Link kernel: ata1.00: cmd c8/00:90:28:a8:4c/00:00:00:00:00/e0 tag 0 dma 73728 in
res 40/00:fe:00:00:00/00:00:00:00:00/40 Emask 0x4 (timeout)
mar 22 04:21:18 Link kernel: ata1.00: status: { DRDY }
mar 22 04:21:23 Link kernel: ata1: link is slow to respond, please be patient (ready=0)
mar 22 04:21:28 Link kernel: ata1: device not ready (errno=-16), forcing hardreset
mar 22 04:21:28 Link kernel: ata1: soft resetting link
mar 22 04:21:28 Link kernel: ata1.00: configured for UDMA/133
mar 22 04:21:28 Link kernel: ata1.00: device reported invalid CHS sector 0
mar 22 04:21:28 Link kernel: ata1: EH complete
mar 22 04:21:28 Link systemd-udevd[178]: worker [191] terminated by signal 9 (Killed)
mar 22 04:21:28 Link keyboard-setup[180]: Setting preliminary keymap...done.
mar 22 04:21:28 Link kernel: EXT4-fs (sda2): re-mounted. Opts: errors=remount-ro
mar 22 04:21:28 Link systemd-journal[160]: Runtime journal is using 5.0M (max allowed 40.2M, trying to leave 60.3M free of
mar 22 04:21:29 Link kernel: ip_tables: (C) 2000-2006 Netfilter Core Team
mar 22 04:21:29 Link kbd[307]: Setting console screen modes.
mar 22 04:21:29 Link kernel: nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
mar 22 04:21:29 Link kernel: ip6_tables: (C) 2000-2006 Netfilter Core Team
mar 22 04:21:29 Link kbd[307]: setterm: $TERM is not defined.
mar 22 04:21:30 Link console-setup[366]: Setting up console font and keymap...done.
mar 22 04:21:30 Link ufw[308]: Starting firewall: ufw...Setting kernel variables (/etc/ufw/sysctl.conf)...done.
mar 22 04:21:54 Link systemd-journal[160]: Forwarding to syslog missed 6 messages.
mar 22 04:22:12 Link systemd[1]: Job dev-disk-by\x2duuid-babc1c5f\x2d5158\x2d479d\x2d8401\x2d1a3842c124a1.device/start tim
mar 22 04:22:12 Link systemd[1]: Timed out waiting for device dev-disk-by\x2duuid-babc1c5f\x2d5158\x2d479d\x2d8401\x2d1a38
mar 22 04:22:12 Link systemd[1]: Dependency failed for /dev/disk/by-uuid/babc1c5f-5158-479d-8401-1a3842c124a1.
mar 22 04:22:12 Link systemd[1]: Dependency failed for Swap.
[...]
Another example of a portion of a boot log:
[...]
mar 22 04:32:48 Link kernel: ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
mar 22 04:32:48 Link kernel: ata1.00: failed command: READ DMA
mar 22 04:32:48 Link kernel: ata1.00: cmd c8/00:20:30:bd:96/00:00:00:00:00/e1 tag 0 dma 16384 in
res 40/00:fe:00:00:00/00:00:00:00:00/40 Emask 0x4 (timeout)
mar 22 04:32:48 Link kernel: ata1.00: status: { DRDY }
mar 22 04:32:48 Link systemd-udevd[209]: timeout '/lib/udev/hdparm'
mar 22 04:32:49 Link systemd-udevd[209]: timeout: killing '/lib/udev/hdparm' [244]
mar 22 04:32:49 Link systemd-udevd[209]: '/lib/udev/hdparm' [244] terminated by signal 9 (Killed)
mar 22 04:32:53 Link kernel: ata1: link is slow to respond, please be patient (ready=0)
mar 22 04:32:58 Link kernel: ata1: device not ready (errno=-16), forcing hardreset
mar 22 04:32:58 Link kernel: ata1: soft resetting link
mar 22 04:32:58 Link kernel: ata1.00: configured for UDMA/133
mar 22 04:32:58 Link kernel: ata1.00: device reported invalid CHS sector 0
mar 22 04:32:58 Link kernel: ata1: EH complete
mar 22 04:32:58 Link kernel: iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11
mar 22 04:32:58 Link kernel: iTCO_wdt: Found a ICH7-M or ICH7-U TCO device (Version=2, TCOBASE=0x1060)
mar 22 04:32:58 Link kernel: iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
mar 22 04:32:58 Link systemd-udevd[212]: timeout 'net.agent'
mar 22 04:32:58 Link systemd-udevd[212]: timeout '/lib/systemd/systemd-sysctl --prefix=/proc/sys/net/ipv4/conf/eth0 --pref
mar 22 04:32:59 Link systemd-journal[159]: Permanent journal is using 6.2M (max allowed 50.0M, trying to leave 2.7G free o
mar 22 04:32:59 Link systemd-journal[159]: Time spent on flushing to /var is 113.253ms for 671 entries.
mar 22 04:33:00 Link kernel: ath: phy0: Enable LNA combining
mar 22 04:33:00 Link kernel: ath: phy0: ASPM enabled: 0x42
mar 22 04:33:00 Link kernel: ath: EEPROM regdomain: 0x65
mar 22 04:33:00 Link kernel: ath: EEPROM indicates we should expect a direct regpair map
mar 22 04:33:00 Link kernel: ath: Country alpha2 being used: 00
mar 22 04:33:00 Link kernel: ath: Regpair used: 0x65
mar 22 04:33:00 Link kernel: ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
mar 22 04:33:00 Link kernel: ieee80211 phy0: Atheros AR9285 Rev:2 mem=0xf8660000, irq=16
mar 22 04:33:00 Link kernel: media: Linux media interface: v0.10
mar 22 04:33:00 Link kernel: Linux video capture interface: v2.00
mar 22 04:32:59 Link mtp-probe[298]: checking bus 3, device 2: "/sys/devices/pci0000:00/0000:00:1d.7/usb3/3-8"
mar 22 04:32:59 Link mtp-probe[298]: bus: 3, device: 2 was not an MTP device
mar 22 04:33:00 Link systemd-journal[159]: Forwarding to syslog missed 1 messages.
mar 22 04:32:58 Link systemd-udevd[207]: timeout 'mtp-probe /sys/devices/pci0000:00/0000:00:1d.7/usb3/3-8 3 2'
[...]
Hello, Could you please provide any custom settings you have in /etc/hdparm.conf ? What model is your HDD? Some new disks (I have seen it with some SSHD hybrid disks in particular) may not respond to certain SATA commands in the way one would expect. Suggestions for debugging: Please be cautious when experimenting with hdparm values and make sure you have a good understanding of the settings you specify. It would be best to find out which hdparm setting freezes your hard drive. It might be the apm level. If you haven't set anything in the configuration file, it will try to set hdparm -B 254 as you don't have powermgmt-base installed, so AC power will be assumed. Try running commenting out the "quiet" keyword in the configuration file and then try running DEVNAME=/dev/sdX /lib/udev/hdparm as root manually (with the right drive instead of sdX) to find out if it prints any error messages. I hope this will help to resolve this issue. Kind regards, Ondřej Grover
Dear Ondřej Grover,
Any.
ATA device, with non-removable media
Model Number: SAMSUNG HM160HI
Serial Number: S1WWJF0S880359
Firmware Revision: HH100-06
Transport: Serial, ATA8-AST, SATA 1.0a, SATA II Extensions, SATA Rev 2.5
*> *Try running commenting out the "quiet" keyword in the configuration file and then try
running DEVNAME=/dev/sdX /lib/udev/hdparm as root manually (with the right drive instead of
sdX) to find out if it prints any error messages.
I have commented out the "quiet" keyword. Any error messages running that command. The
output is:
/dev/sda:
setting Advanced Power Management level to 0xfe (254)
APM_level = 254
I have installed the package "powermgmt-base" and the result is the same: time out, freeze,
and kill the process.
(In debian "wheezy" I had not this problem with hdparm).
Attached is this session's full system log (with "powermgmt-base" installed and no
modifications to /etc/hdparm.conf except to the #quiet).
If you need any information, it's a pleasure to inform or to try to debug the problem.
Best regards.
settings you have in /etc/hdparm.conf ? Sorry, I mean that I have no modifications in /etc/hdparm.conf. Regards.
messages running that >command. And here I meant "There isn't error messages running that command" instead of "Any error messages running that command". Sorry for my english. Best regards.
Dear maintainers, I have installed the hdparm package version 9.43-1ubuntu3 from ubuntu "vivid" repository and it works fine. The package is the following: http://packages.ubuntu.com/vivid/hdparm Regards.
I have also compiled hdparm version 9.45 from sources (downloaded from http://sourceforge.net/projects/hdparm/) and it is working fine too. Regards.
The list of changes between the Debian version and the Ubuntu version is fairly short. I have attached the diff (minus d/changelog) here and we are down to: """ debian/95hdparm-apm | 5 +++-- debian/control | 5 +++-- debian/hdparm.init | 5 ----- debian/hdparm.udev | 4 ++-- debian/rules | 3 +-- hdparm.c | 42 ++++++++++++++++++++++++++++++++++++++++++ identify.c | 8 ++++---- sgio.h | 1 + 8 files changed, 56 insertions(+), 17 deletions(-) """ Given you suggest that compiling the new upstream also works for you, I am suspecting it could be this change: """ + * hdparm.c, identify.c, sgio.h: import patch from + http://sourceforge.net/p/hdparm/patches/35/ to add support to 'hdparm -I' + for reporting DevSleep information. LP: #1031173. """ Which brings us to the DevSleep disk. Sadly, I am not sure I see how the actual change matters (unless hdparm handles "unknown" disks differently from "known" disks) - or the code does something beyond what I can trivially guess from the changes. Failing that, Ubuntu also removed the "hdparm-resync.lock". Assuming what we exactly see is a deadlock and "timeout" killing hdparm to workaround said deadlock. But at this point, I am guessing! Thanks, ~Niels https://bugs.launchpad.net/intel/+bug/1031173
I just checked hdparm-9.45 and it does *not* have that change AFAICT.
Sorry, it was likely a red herring.
Upstream's changelog does mention the following:
"""
hdparm-9.45:
- fixed blocksize handling in fibmap code to use result from
FIGETBSZ in more places (Anton Altaparmakov).
- fixed divide by zero exception in geom.c
- tidying up formatting in sgio.c
hdparm-9.44:
- changed reg_flags struct to more closely match kernel
definition (Lucas Magasweran).
- added fwdownload mode "E" support (Rusty Carruth).
- fix timeouts for security-erase (again!)
- change display of security "supported" to handle ambiguous
reporting from drives
- don't rely upon C-library for byte-swapping
- added --dco-setmax support, courtesy of Geoff Papilion.
"""
(Assuming it rings any bells).
Thanks,
~Niels
Dear Mr. Niels Thykier, ¿How can I know if I have a DevSlp disk? When I enter "hdparm -I /dev/sda" it doesn't show anything containing DevSleep nor Devslp. Thank you very much for your valuable help. Best regards.
To complement my previous message, I have ran "hdparm -I /dev/sda" with the hdparm version from Jessie's repository. According to this patch http://sourceforge.net/p/hdparm/patches/35/ that is supposedly included in Jessie's hdparm package, it should show an output about DevSlp when the device supports it, and in my case it doesn't show anything about it. So, according to that assumption, my device doesn't support DevSleep. Thank you very much.
Dear maintainers, Finally I have found the problem to package hdparm in debian jessie. Resume: *the problem is the way that the package hdparm in debian jessie's repository is compiled*. Well, to get to that conclusion, first I compared the sources of hdparm from debian jessie and from ubuntu vivid. Unlike our colleague Niels, I didn't find differences between both. Then, I downloaded the sources of hdparm from debian jessie's repository, descompressed them, and typed in the terminal "make" and finally "checkinstall". The utilities used to compile the sources are the default in debian jessie's package repository. Finally, I have tested and that way the problem is solved. To get sure that the package hdparm that I downloaded from jessie's repository wasn't corrupted, I typed in terminal "aptitude clean" and then "aptitude update" to finally try again to "aptitude install hdparm" from jessie's package repository. The result is the same, freeze's and kill of hdparm at boot time. My package repository is: "deb http://ftp.debian.org/debian/ jessie main". My machine has the x86 architecture. I have also checked the md5sum of the package and it is OK. Conclusion to my tests: the way that the package hdparm in debian jessie's respository is compiled is causing problems to my system. Best regards, Víctor.
Víctor, Just running make quite likely didn't apply some of the debian patches. If it's a patch issue, `dpkg-buildpackage -us -uc` will likely produce a package that will break, you could try that too as a first attempt. You could also try applying patches selectively and see if a specific one breaks it. From what I understand, you may not have had all the libraries installed against which the standard Debian hdparm package is built when you compiled it. So perhaps you could try installing the build-dep libraries one by one and recompiling and testing until you find the one that breaks it. Kind regards, Ondřej Grover
Hi,
Thanks for following up. It is indeed an interesting find.
compiled. Nevertheless, it certainly confirms that the problem is
entirely on the Debian side.
I got two possible leads, Víctor do you have:
* a RAID setup?
* a block device named something like /dev/sdaa or /dev/hdaa?
- Minimum 4 /letters/ and starting with either "sd" or "hd". All
other letters can vary in the a-z range.
If you have a RAID:
* Please provide the output of:
egrep -iq "resync|repair|recover|check" /proc/mdstat
cat /proc/rd/status
* Combined they should just say "OK" (or complain about missing
files). If not, your system is triggering the "RAID" resync code.
If this happens on every reboot, the issue is probably that it
takes your system is about a minute to resync them and Debians
init scripts forces you to wait for it to happen.
This /sounds/ like you just downloaded the "hdparm_9.43.orig.tar.gz"
file and only used that. If so, a very likely alternative to your
conclusion would be a Debian specific change causes this issue (as
Ondrej suggested).
The debian source also includes (in this case) a
"hdparm_9.43-2.diff.gz", which contains the debian packaging and
possibly some changes to the source.
* Debian has *no* direct changes to the upstream code
* Ubuntu /has/ direct changes to the upstream source. However, these
are not applied upstream last I checked. Given a "vanilla"
upstream release "just works(tm)", lets whitelist all of these
changes as "safe" for now.
This leaves an interdiff between Ubuntu (as "orig") and Debian (as
"new") of [excluding the changelog]:
"""
95hdparm-apm | 5 ++---
control | 5 ++---
hdparm.init | 5 +++++
hdparm.udev | 4 ++--
rules | 3 ++-
5 files changed, 13 insertions(+), 9 deletions(-)
"""
(attached as hdparm-ubuntu-debian.interdiff)
Lets spread these changes into distinct changesets:
* debian/hdparm.init => Debian has a *lock* in place for a RAID
"workaround".
* debian/hdparm.udev => Change a rule to only match /dev/[sh]d[a-z]
instead of /dev/[sh]d[a-z]*
* debian/95hdparm-apm => comments only / noise
* debian/control => Add dependency on lsb-base (and some noise)
- Unlikely to be the problem as I doubt you uninstalled lsb-base
just to test this.
* debian/rules => Change to if/how the service should be started.
- My take here is that this is Ubuntu specific due to their
(previous?) use of upstart
Thanks,
~Niels
Niels, from the logs and output Víctor posted it seems it is a simple /dev/sda drive. However, it is possible that the drive that fails is not /dev/sda as the logs identify the drive by its hardware slot. The RAID lock lead sounds promising, it might explain the hang. Víctor, could you please post the output of `lsblk --all --output-all` (in a text file as the lines will be very wide) so that we have a better idea of your HDD layout? Also post the relevant lines from the system log but also in a text file because in your first message they were truncated. We need to determine which drive exactly fails. Kind regards, Ondřej Grover
Hello, Reading your messages, I have learned the way that the sources are managed in debian's package website. So to complete my previous message, I compiled with "make" the "hdparm_9.43.orig.tar.gz" from debian's hdparm package website, that now I know that are the unmodifyed upstream sources. *Conclusion: compilyng with simple "make" and "checkinstall" the upstream's sources for hdparm version 9.43 works fine*. Thanks to you, now I know to download the orig sources, the "diff" archive and the "dsc" archive to make with "dpkg-source -x archive.dsc" the sources that are used for generating the debian package. Like our colleague Ondrej said, if I compile that sources with a simple "make" and then "checkinstall", the package works fine. In other case, if I compile that sources with the command "dpkg-buildpackage -us -uc", the resulting package has the problem. Ondrej explained that it is because with dpkg-buildpackage the package is compiled with debian patches, and with a simple "make" it doesn't compile with the debian patches. OK, so I started trying more things. I donwloaded the ubuntu sources, diff, and dsc and ran "dkpg-source" to make the ubuntu sources. I compiled that sources with "dpkg-buildpackage -us -uc" and the resulting package *has the problem*. If I download and install the .deb package directly from "ubuntu vivid" repository, that package doesn't have the problem. I can think in two conclusions: a) Ubuntu compile the sources in a way that is not causing the problem. b) Ubuntu are not providing their complete modifications of the original sources in the .diff archive found in ubuntu vivid's website of hdparm package. Then I tried to selectively apply some of the patches included in debian jessie's diff archive. Every time I try it, "dpkg-buildpackage -us -uc" give me errors. For example, if I delete from debian sources the file "hdparm- functions" that is not included in the original sources, when I run "dpkg- buildpackage -us -uc" it gives an error saying (traduced from spanish) "cp: can't make `stat' over «./debian/hdparm-functions»: File not found". I don't know how dpkg-buildpackage works, so I don't know how to apply selective patches to the source code because it won't compile with dpkg-buildpackage. I remember to you that with a simple "make" and "checkinstall", the resulting package has no problems. I haven't tried this proposal from Ondrej yet: "So perhaps you could try installing the build-dep libraries one by one and recompiling and testing until you find the one that breaks it." Answer to your questions: 1) I don't have RAID. 2) My only (SATA) hard disk is /dev/sda. My computer consists only on a simple stand alone netbook. 3) Output of `lsblk --all --output-all` is attached in this message. 4) Attached in this message is the relevant portion of the following full log: https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=15;filename=hdparm+freezes+bug+systemlog;att=2;bug=780940 Regards, Víctor.
-- December 9, 2015 Konnichiwa! It is with respect to directly write this proposal letter to you, informing you of a potential business proposal project that can be established from your country with your help, which will mutually be profitable to us having no risk involved. If you are agreeable to this business proposal, please indicate your interest by giving me a direct response email. Feel free to contact me via electronic mail or telephone for further discussion. I look forward to hearing from you positively on this proposal. Domo arigato ! Suki
-- December 9, 2015 Konnichiwa! It is with respect to directly write this proposal letter to you, informing you of a potential business proposal project that can be established from your country with your help, which will mutually be profitable to us having no risk involved. If you are agreeable to this business proposal, please indicate your interest by giving me a direct response email. Feel free to contact me via electronic mail or telephone for further discussion. I look forward to hearing from you positively on this proposal. Domo arigato ! Suki
Dear Víctor, do you have a chance to test the new upstream release of hdparm ? it is not yet in the Debian distribution, but the source is available here: http://anonscm.debian.org/cgit/collab-maint/hdparm.git You will need to clone the repository and build the package. Thank you in advance, Alex
I'm reducing the severity of this bug as there's only person who claims to have been affected. And it's not a hard lockup, just taking more time than what we want. You probably want to make some package available... otherwise it's hard for people to test. We can make a release to experimental if needed. Or you can make packages available from some scratch space that you might have. Cheers,
Placing a binary package to a non-debian site doesn't sound good to me. I personally wouldn't install it. The current packaging status is definitely good for the experimental or even for unstable in my opinion. Shell I open RFS bug for that ? Regards, Alex
I can do the upload but I would like to see a fix for the only RC bug left (#725284). I believe I gave you some indications in my last review mail. Dropping the init script would fix this bug too as without any init script, the startup can't be frozen... (except if the udev script can have a similar effect, I don't know). Cheers,