Thanks James, I got your point will look more on this. Regards, Amit Sahrawat On Fri, Sep 30, 2011 at 11:41 PM, James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > On Fri, 2011-09-30 at 23:26 +0530, Amit Sahrawat wrote: >> Adding linux-usb - to get more insight's into the problem. >> >> On Fri, Sep 30, 2011 at 11:23 PM, Amit Sahrawat >> <amit.sahrawat83@xxxxxxxxx> wrote: >> > On Fri, Sep 30, 2011 at 5:48 PM, James Bottomley >> > <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: >> >> On Fri, 2011-09-30 at 12:26 +0530, Amit Sahrawat wrote: >> >>> Now, for the USB HDD which do have write cache - sginfo is showing >> >>> them to Write Cache Enabled as false. >> >>> Why do the result of hdparm identification and sginfo varies- (I know >> >>> they have different interface to work with and hdparm takes care of >> >>> that by using SG_IO interface from it's code)? hdparm showed me >> >>> correct results - that lead me to digging in the kernel code and >> >>> checking the performance for USB HDD with Write cache enabled/disabled >> >>> - which also showed that QUEUE ordering chosen for USB HDD is not >> >>> correct. >> >> >> >> Well, what all this means is the SATL in the USB device is implemented >> >> wrongly. Since USB devices only preset SCSI interfaces, that's what we >> >> have to believe. >> >> >> >> hdparm when used correctly sends an ATA inquiry command wrapped in an >> >> ATA_12 or ATA_16 SCSI command. A large number of legacy SATLs are known >> >> to crash on these commands. >> >> >> >> Are you sure the ATA command is reporting correctly? A write back cache >> >> is a remarkably silly thing to enable for a USB device because they're >> >> highly likely to be surprise ejected which powers the device down. >> >> >> > In addition to the problem reported - there is one more thing I have >> > noticed with USB HDD - they should be shown as 'removable' but the >> > removable is marked only for USB PEN Drives. This seems to be a bit of >> > confusing, any mass storage media connected on USB port should be >> > recognized as removable. > > I don't really think so. Removable to sd means that the drive can be > removed from the housing, not that the connector cable is hot plug so > the whole disk can disappear. I think your disk is the latter, and > therefore removable probably isn't what you want (otherwise the sd > driver will start probing for medium change and other things your device > won't understand). > >> > So, for handling the issue, I would consider adding the handling in >> > slave_configure()(usb/storage/scsiglue) which marks the HDD/pen drives >> > as removable also signifying them to be USB based. >> > Then, as part of sd_revalidation – how about adding the ATA_IDENTIFY >> > command part if the device is USB HDD? As far as the result of >> > ATA_IDENTIFY is concerned – they return proper ‘256’ bytes - response >> > and the Words – 82, 85 used for feature supported and enabled/disabled >> > returns proper values for the USB HDD’s I have seen. In case of USB >> > pen drives – they return failure – I did not see any crash – maybe I >> > don’t have one of the legacy SATL based disk. >> > Since, I am new to this – I will check more on this to get a viable >> > solution. Please add your opinion. Can you share the name of the >> > device which causes crash with these ATA commands, If I am able to get >> > one I can try on that also. > > How? There are many USB devices whose SATL crashes and burns on ATA_12 > or ATA_16, so this would add fragility to the detection path. The > detection path has to be cast iron because it has to work on a vast > range of devices. The only way this could really work is to add it in > the usb storage driver and then replace the bad mode pages. > > James > > > -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
