Hi Francesco, Thanks for your response.
Francesco <[email protected]> [2018-12-08 21:19:09 +0000]: > > Yes, I did find a workaround, which is forcing Linux to use ata_generic > instead of sata_sil to manage the controller. > Yes, I saw that in your original posting, but was actually looking for something more along the lines of a fix or even a putative custom patch to sata_sil, rather than a workaround. (I should have mentioned that, sorry, it would have saved you the time of repeating the instructions you'd already given in the original report on how to force ata_generic.) My concern is that going with ata_generic may have more of a speed penalty than I'm willing to bear in this application (although I've not actually tried it.) The thing that's frustrating about this bug is that it seems like it might be fairly straightforward to fix, since the IDENTIFY command (which fails) is done very early on in the device recognition sequence. My uneducated guess would be just some sort of device-dependent init issue or maybe some interrupt confusion. The SATAlink BIOS has no problem detecting the SSD and is able to run all the drive self-tests on it, so it seems like the problem has to be sata_sil itself. Fwiw, in case anyone else might benefit from what I've found in googling the archives: There was a patch to sata_sil back in ancient times (2007) that had vaguely similar symptoms: Initial report on LKML is here: https://lkml.org/lkml/2007/2/23/195 Patch is here: http://article.gmane.org/gmane.linux.ide/16304 I have no clue whether the above could actually be related to the current issue or simply "sounds similar", based on symptoms. But, if someone with the present issue and some ATA driver knowledge gets interested enough, maybe it could provide some insight. Anyway, if anything further shows up that is useful, I will post it to this thread. Thanks again for your time Francesco, Glenn
