/usr/lib/pm-utils/sleep.d/99hd-apm-restore.hook 1. If this really is needed everywhere, we need to be pulling disks from HAL, not the top of the config file. 1. We really shouldn't be changing settings from the what the BIOS sets. If the settings are wrong after resume, this should be fixed in the power management layer in the kernel, the same way as, for example, HPA is. It just seems like a bad idea overall; we certainly don't set a default for these settings on boot for the same reasons, similarly, we don't have /etc/sysconfig/harddisks any more. If the chipset isn't set up correctly by the kernel, that's a kernel bug.
(In reply to comment #0) > 1. If this really is needed everywhere, we need to be pulling disks from HAL, > not the top of the config file. I do not know how to do this, e.g. hal-find-by-property which seems to be the tool for this, does not support to search for all udis that have a "block.device" property. Also it does not seem that it is stored, whether a block.device is the real device or a partition on the device. According to the specs block.is_volume is true, when it can be mounted, but afaik it is also possible to run mke2fs on /dev/sdb and then mount it. But then /dev/sdb would not math the condition, that block.is_volume needs to be false. But even when there was a bool to check, there seems to be no tool to search by bools. I will happily apply any patches that improve this. > 1. We really shouldn't be changing settings from the what the BIOS sets. If > the settings are wrong after resume, this should be fixed in the power > management layer in the kernel, the same way as, for example, HPA is. Does the script change anything on you system? In the default configuration it should only restore the settings of the device, that it had before suspend. But nothing should be changed. Hm, the script could be improved, that it first queries, whether the devices has different settings after resume, that it had before suspend, and only in case a change is detected, the hdparm could be run with "-B". But in case that this shows different results in the drives beheaviour, I would consider hdparm to be buggy. > It just seems like a bad idea overall; we certainly don't set a default for > these settings on boot for the same reasons, similarly, we don't have > /etc/sysconfig/harddisks any more. If the chipset isn't set up correctly by he > kernel, that's a kernel bug. As far as I understand the issue, it is a property that is set within the device, not the chipset. The problem is, that the device forgets the setting when it is powered off, therefore it needs to be restored by the hook. In case the kernel should remember the setting, please reassign bug #382061 to the kernel maintainers.
(In reply to comment #1) > (In reply to comment #0) > > 1. If this really is needed everywhere, we need to be pulling disks from HAL, > > not the top of the config file. > > I do not know how to do this, e.g. hal-find-by-property which seems to be the > tool for this, does not support to search for all udis that have a > "block.device" property. Also it does not seem that it is stored, whether a > block.device is the real device or a partition on the device. According to the > specs block.is_volume is true, when it can be mounted, but afaik it is also > possible to run mke2fs on /dev/sdb and then mount it. But then /dev/sdb would > not math the condition, that block.is_volume needs to be false. But even when > there was a bool to check, there seems to be no tool to search by bools. I will > happily apply any patches that improve this. Something like (psuedocode): for device in hal-find-by-capability storage ; do if storage.drive_type = disk ... > > 1. We really shouldn't be changing settings from the what the BIOS sets. If > > the settings are wrong after resume, this should be fixed in the power > > management layer in the kernel, the same way as, for example, HPA is. > > Does the script change anything on you system? In the default configuration it > should only restore the settings of the device, that it had before suspend. Right, but we should not need a script to do this - if we do, that implies a problem in the suspend layer. > As far as I understand the issue, it is a property that is set within the > device, not the chipset. The problem is, that the device forgets the setting > when it is powered off, therefore it needs to be restored by the hook. In case > the kernel should remember the setting, please reassign bug #382061 to the > kernel maintainers. Comment made, kernel ATA layer people CC'd.
Created attachment 291479 [details] Shellscript that prints all harddisks detected by hal
(In reply to comment #2) > Something like (psuedocode): > > for device in hal-find-by-capability storage ; do > if storage.drive_type = disk > ... Thanks, I attached a script that does what you had in mind I guess. Maybe you can take a look. > Comment made, kernel ATA layer people CC'd. Fine, I hope they can fix it. :-)
(In reply to comment #4) > (In reply to comment #2) > > > Something like (psuedocode): > > > > for device in hal-find-by-capability storage ; do > > if storage.drive_type = disk > > ... > > Thanks, I attached a script that does what you had in mind I guess. Maybe you > can take a look. Works for me with normal parititons and LVM. Haven't tested RAID.
The hook script in pm-utils now uses hal to detect the devices and as long as this is not fixed in the kernel, I do not see any reason not to provide this hook. Therefore I close this bug.