After I installed kernel version 4.14.17 and 4.15.4, I noticed that they won't boot as the SATA controller reset failed always. For more information about my hardware, see here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890870 With kernel 4.14.13, there is a chance that the SATA controller reset will success. Today I do some custom builds of 4.14.x, and found that: 1. up to kernel 4.14.10, everything works fine. 2. since kernel 4.14.11, there is a big chance to "reset failed". Then I do a bisect between v4.14.10 and v4.14.11, and found that: 1. commit 3dfd9fd8d897214b1a880c7fd8ed36b88faa1c02 is the first bad commit, but not so bad, I just encountered 1 failure in all boot attempts (> 10). 2. commit dfa58126d7630c0db0b64fa7bd15741293b517b5, same as the above one. 3. commit 27e16c33bb796cceb92e339998d30145076b43cd, from this commit, the chance is about 2-4/10. I have tried set pti=off with kernel 4.15.4, but it didn't help.
(In reply to Zhang Jingqiang from comment #0) > 1. commit 3dfd9fd8d897214b1a880c7fd8ed36b88faa1c02 is the first bad commit, This one add the PTI Kconfig CONFIG_PAGE_TABLE_ISOLATION, the previos one I bisected good is 36a72ab52c8d969a7a302082f52731c1be0e9ada
I build 4.15.4 with CONFIG_PAGE_TABLE_ISOLATION disabled, no "reset failed" now.
Situation improved with 4.15.5, 'nopti' can be used to avoid the 'reset failed' error.
It seems 4.16.13 fix this,I have rebooted 3 times, and see no failure, though it need more time to wait before the 'blocks' message appears. The 'pti' options have no special meanings to this bug since some previous versions.
I didn't observe a failure with 4.17rc7, so close this.