Alan Cox wrote: >>> Sorry you can't just blindly do this because some of the controllers snoop >>> the SETXFER command to set their timings and whether they expect DMA. Also >>> we've no idea if this is a bug in a specific firmware revision, a quirky >>> pata/sata bridge or a timing problem of some sort. >> I think it'll generally be okay for SATA unless it's bridged over to >> PATA controller. Any other ideas? > > We seem to have one report, from one user, with one configuration, on one > controller, using one firmware set. There are two more reports linked from the thread. http://ubuntuforums.org/showthread.php?t=986871 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/299865 And all of them are showing the same problem. This being a slim SATA drive for a laptop, I don't really expect to see the drive in varied configurations. The problem might as well be limited to certain OEM drive(s). > That to me isn't meaningful evidence of anything that needs a workaround, > beyond maybe doing what old IDE does and if a setxfer times out > continuing in hope. So, as far as the validity of the report goes, I think it's at reasonable level. Add to that my general trigger happiness toward quirks and the machine is a VAIO and to me quirking it doesn't seem too careless. > (We should of course then re-read the identify pages and check the mode > in use) Of course, whether the workaround is proper is a completely separate issue but unless other devices with the same problem creep up and the device is happy with the quirk, I don't really think we should modify the default configuration sequence for devices like this. That said, Moritz, can you please post the output of "hdparm -I" with and without the quirk applied? And can you please use a preoper mail address? Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
