update to 0.114-0intrepid2 makes system hang for 30 seconds while booting

Thank you for taking the time to report this bug and help to improve Ubuntu.

Please post the output of the following command:

  sudo hdparm -i -I /dev/sda

Thank you. I have attached the output of hdparm and here is a more recent kern.log snippet:

Oct 24 22:11:35 homer kernel: [ 28.196968] ADDRCONF(NETDEV_UP): eth0: link is not ready
Oct 24 22:11:35 homer kernel: [ 57.804265] ata1.00: exception Emask 0x0 SAct 0xf80007 SErr 0x0 action 0x6 frozen
Oct 24 22:11:35 homer kernel: [ 57.804272] ata1.00: cmd 60/80:00:bf:5e:47/00:00:15:00:00/40 tag 0 ncq 65536 in
Oct 24 22:11:35 homer kernel: [ 57.804274] res 40/00:fe:00:00:00/00:00:00:00:00/40 Emask 0x4 (timeout)
Oct 24 22:11:35 homer kernel: [ 57.804277] ata1.00: status: { DRDY }
Oct 24 22:11:35 homer kernel: [ 57.804281] ata1.00: cmd 60/08:08:6f:01:6c/00:00:16:00:00/40 tag 1 ncq 4096 in
Oct 24 22:11:35 homer kernel: [ 57.804282] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Oct 24 22:11:35 homer kernel: [ 57.804285] ata1.00: status: { DRDY }
Oct 24 22:11:35 homer kernel: [ 57.804288] ata1.00: cmd 60/08:10:df:46:04/00:00:10:00:00/40 tag 2 ncq 4096 in
Oct 24 22:11:35 homer kernel: [ 57.804290] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Oct 24 22:11:35 homer kernel: [ 57.804292] ata1.00: status: { DRDY }
Oct 24 22:11:35 homer kernel: [ 57.804296] ata1.00: cmd 61/08:98:07:41:4d/00:00:19:00:00/40 tag 19 ncq 4096 out
Oct 24 22:11:35 homer kernel: [ 57.804297] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Oct 24 22:11:35 homer kernel: [ 57.804300] ata1.00: status: { DRDY }
Oct 24 22:11:35 homer kernel: [ 57.804304] ata1.00: cmd 61/08:a0:97:40:4e/00:00:19:00:00/40 tag 20 ncq 4096 out
Oct 24 22:11:35 homer kernel: [ 57.804305] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Oct 24 22:11:35 homer kernel: [ 57.804307] ata1.00: status: { DRDY }
Oct 24 22:11:35 homer kernel: [ 57.804311] ata1.00: cmd 61/10:a8:1f:49:4e/00:00:19:00:00/40 tag 21 ncq 8192 out
Oct 24 22:11:35 homer kernel: [ 57.804312] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Oct 24 22:11:35 homer kernel: [ 57.804315] ata1.00: status: { DRDY }
Oct 24 22:11:35 homer kernel: [ 57.804318] ata1.00: cmd 61/08:b0:a7:ac:4f/00:00:19:00:00/40 tag 22 ncq 4096 out
Oct 24 22:11:35 homer kernel: [ 57.804320] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Oct 24 22:11:35 homer kernel: [ 57.804322] ata1.00: status: { DRDY }
Oct 24 22:11:35 homer kernel: [ 57.804326] ata1.00: cmd 61/08:b8:4f:40:1a/00:00:24:00:00/40 tag 23 ncq 4096 out
Oct 24 22:11:35 homer kernel: [ 57.804327] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Oct 24 22:11:35 homer kernel: [ 57.804330] ata1.00: status: { DRDY }
Oct 24 22:11:35 homer kernel: [ 57.804334] ata1: hard resetting link
Oct 24 22:11:35 homer kernel: [ 58.124082] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
Oct 24 22:11:35 homer kernel: [ 58.136959] ata1.00: configured for UDMA/133
Oct 24 22:11:35 homer kernel: [ 58.136988] ata1: EH complete
Oct 24 22:11:35 homer kernel: [ 58.137090] sd 0:0:0:0: [sda] 625142448 512-byte hardware sectors: (320 GB/298 GiB)
Oct 24 22:11:35 homer kernel: [ 58.137106] sd 0:0:0:0: [sda] Write Protect is off
O...

I'm suffering from the same bug unter Ubuntu 9.10. The problem can be solved by adding a sleep timer of 20-60s (depends how fast the system is booted) the file "/usr/lib/pm-utils/power.d/95hdparm-apm" before the "hdparm"-command.

"hdparm" is executed twice during the boot, and both commands are called when the boot process do the most I/O-work on the harddisk.

Adding the sleep timer prevents this and "hdparm" will be executed after the heavy I/O-throughput, for example when the login manager appears and is waiting for the login.

For my notebook a 20s timer works perfectly, but

I'm suffering from the same bug unter Ubuntu 9.10. The problem can be solved by adding a sleep timer of 20-60s (depends how fast the system is booted) the file "/usr/lib/pm-utils/power.d/95hdparm-apm" before the "hdparm"-command :

   then
    level=$(hdparm_apm_option_for_disk $dev)
    if [ -n "$level" ]; then
     sleep 20 # Prevents harddisk from reseting
     hdparm -B $level $dev
    fi

"hdparm" is executed twice in a very short time (1s) during the boot and both commands are called when the boot process do the most I/O on the harddisk. Heavy I/O and setting a firmware command twice in a very short time does not work very well, so the harddisk is reseted by the kernel.

Adding the sleep timer prevents this and "hdparm" will be executed after the heavy I/O-throughput, for example when the login manager appears and is waiting for the login.

For my notebook a 20s timer works perfectly, but 60s seems to be a better value because most desktop-systems will be completely booted after 60s and have no more heavy harddisk I/O.

Well, adding a 'sleep' here is not a very practical solution, because it would block suspend/resume for 20 seconds for all users.

Ideally, we would fix this by making sure we only get one call to hdparm for each drive at boot time. We may be able to do this by making /usr/lib/pm-utils/power.d/95hdparm-apm detect when it's being called from /etc/init.d/rc and exiting silently, since we can trust udev to have already called hdparm.

The plan for fixing this is:
 - make sure on_ac_power works for users even when /usr isn't mounted (fairly easy - it already works for the ACPI case, and needs only minor adjustments to work for other power platforms *if* those platforms provide the standard sysfs interface)
 - update the hdparm udev rule to implement the default power management policy, with our default apm settings when no other options are specified in /etc/hdparm.conf
 - arrange to make pm-powersave not call hdparm when invoked from init

This bug was fixed in the package powermgmt-base - 1.30+nmu1ubuntu1

---------------
powermgmt-base (1.30+nmu1ubuntu1) lucid; urgency=low

  * on_ac_power: use /sys/class/power_supply if present on *all* systems,
    not just acpi systems, as this should be the preferred abstraction on
    all platforms. LP: #321219.
 -- Steve Langasek <email address hidden> Thu, 12 Nov 2009 13:59:00 +0000

This bug was fixed in the package pm-utils - 1.2.5-2ubuntu8

---------------
pm-utils (1.2.5-2ubuntu8) lucid; urgency=low

  * debian/95hdparm-apm: hdparm-functions is moved to /lib/hdparm now; depend
    on hdparm (>= 9.15-1ubuntu6) for this change and pick up the new function
    name.
  * debian/95hdparm-apm: now that we can rely on the udev rule to set the
    correct apm policy at boot time, make this hook a no-op when called from
    rcS (by checking $runlevel). LP: #321219.
 -- Steve Langasek <email address hidden> Fri, 13 Nov 2009 01:44:51 -0800

This bug was fixed in the package hdparm - 9.15-1ubuntu6

---------------
hdparm (9.15-1ubuntu6) lucid; urgency=low

  * debian/hdparm.init, debian/hdparm.udev-script: also don't call sync...
  * debian/hdparm-functions: refactor so that it can be used by the udev
    script as well
    - drop handling of "command_line" here - we shouldn't be running this
      for every hard drive and every power event, this should be supported
      only by an init script (if at all)
  * debian/hdparm.install: move hdparm-functions to /lib/hdparm.
  * debian/hdparm.udev-script: refactor to use the above functions instead of
    embedding a parser. LP: #321219.
  * debian/control: declare a Breaks: on pm-utils (<< 1.2.5-2ubuntu8), due to
    the change of the hdparm-functions API.
 -- Steve Langasek <email address hidden> Fri, 13 Nov 2009 09:38:52 +0000

In karmic and above, this is not a bug in acpi-support at all since the package now hands off all power management to pm-utils.

Intrepid Ibex reached end-of-life on 30 April 2010 so I am closing the report. The bug has been fixed in newer releases of Ubuntu.