Hello, Henrique. Henrique de Moraes Holschuh wrote: > On Mon, 14 May 2007, Francesco Pretto wrote: >> Ubuntu [1] ang Gentoo [2] bugs opened. Sent a mail to Miquel van >> Smoorenburg, dev of sysvinit. > > For all Debian sysvinit issues, please send email to > pkg-sysvinit-devel@xxxxxxxxxxxxxxxxxxxxxxx (added to CC). > > For the Debian sysvinit crew: Guys, have a look at > http://linux-ata.org/shutdown.html. We need to act on it, and also file a > bug on all of our current kernels (poweroff causes minor but accumulating- > over-time damage to all hardware under control of libata). This is really > something we should be trying to fix on our 2.6.18 kernels and stable > sysvinit. > >> [1] https://bugs.launchpad.net/upstart/+bug/114683 >> [2] http://bugs.gentoo.org/show_bug.cgi?id=178559 There have been further developments, http://article.gmane.org/gmane.linux.ide/18823 (bugfix) http://article.gmane.org/gmane.linux.ide/18846 (in discussion) The second patch makes libata turn off the warning message and just issue STANDBYNOW without userland modification, iff userland halt/shutdown doesn't issue STANDBYNOW during shutdown. I'm not sure whether this will be accepted or not. It makes the change much less intrusive for distros which don't issue STANDBYNOW from userland but disks will always do emergency-unload on all kernels with this problem. > Tejun, am I right to assume that any servers with self-contained SCSI disks > (i.e. that are not plugged into externally powered drive enclosures, etc) > also get the emergency head unloads when they are powered off? AFAIK, yes, all SCSI disks attached to a single host and shares power on/off status will do emergency unload on poweroff. In the updated kernel, this is controlled by the following sysfs node. /sys/class/scsi_disk/h:c:i:l/manage_start_stop. It defaults to 1 for libata devices and 0 for all others. Echoing 1 to it makes the sd driver spindown the device on suspend to ram/disk and poweroff. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
