Kernel Bug Tracker – Bug 16579
ahci.skip_host_reset=1 do not work anymore starting from 2.6.35 (regression)
Last modified: 2010-09-12 20:32:32 UTC
After switching to 2.6.35 the kernel command option ahci.skip_host_reset do not work. I have Acer Ferrari 1100 laptop that unlock the password protected HDD by the BIOS password entering system. So this option prevent kernel from resetting the HDD, so it can mount the rootfs. But starting from 2.6.35 the kernel resets HDD, so as it is became password protected again no rootfs can be mounted, so kernel panics while trying to mount the rootfs. Switching back to 2.6.34 or removing the password from HDD lets to normal boot again.
Can supply any additional info.
P.S. The laptop do not have the serial port, so serial console is not available.
What does /sys/module/ahci/parameters/skip_host_reset contain after you boot with ahci.skip_host_reset=1 ?
AHCI compiled in kernel, so such file does not exists.
[Hors]:rus:~ # cat /sys/module/ahci/parameters/skip_host_reset
cat: /sys/module/ahci/parameters/skip_host_reset: No such file or directory
[Hors]:rus:~ # cat /proc/cmdline
auto BOOT_IMAGE=Linux ro root=802 resume=/dev/sda1 vt.default_utf8=0 libata.force=1:nohrst ahci.skip_host_reset=1 noirqbalance panic=30 memory_corruption_check=1
The module got split into libahci.ko and ahci.ko to support
ahci_platform.ko, so the module parameter should now be
libahci.skip_host_reset. That said, if the drive doesn't remember the
unlocked state over link resets (it's called Software Setting
Preservation and enabled by default on modern drives), it doesn't have
much chance of operating reliably. In SATA, link resets may happen
involuntarily and the drive would lock up during operation.
Resolving as invalid. Sorry about the inconvenience.
Thanks, changing the parapmeter to libahci.skip_host_reset fixes the issue.
About possible drive lockup during link reset - I thought that the libahci.skip_host_reset option was created just for such cases - the reset must be skipped and not passed to the drive, isn't it ?
Well, the parameter makes the driver avoid hardreset during probing but nothing can prevent asynchronous phy events from happening. Such events aren't too frequent but they definitely can happen. Security lock without ssp on SATA is simply broken.