This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 428512 - Resets BIOS settings... badly.
Resets BIOS settings... badly.
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: pm-utils (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Till Maas
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-01-12 10:57 EST by Bill Nottingham
Modified: 2014-03-16 23:11 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-04-15 08:51:08 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Shellscript that prints all harddisks detected by hal (305 bytes, text/plain)
2008-01-12 16:42 EST, Till Maas
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Bugzilla 382061 None None None Never

  None (edit)
Description Bill Nottingham 2008-01-12 10:57:55 EST
/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.
Comment 1 Till Maas 2008-01-12 11:37:43 EST
(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.
Comment 2 Bill Nottingham 2008-01-12 16:18:09 EST
(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.
Comment 3 Till Maas 2008-01-12 16:42:08 EST
Created attachment 291479 [details]
Shellscript  that prints all harddisks detected by hal
Comment 4 Till Maas 2008-01-12 16:44:19 EST
(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. :-)
Comment 5 Bill Nottingham 2008-01-14 12:43:48 EST
(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.
Comment 6 Till Maas 2008-04-15 08:51:08 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.