[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#777633: [src:linux] sata_sil fails to detect some SSD



Hi Francesco,

Thanks for your response.

Francesco <f_presel@hotmail.it> [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 


Reply to: