On Sat, Feb 11, 2006 at 10:50:23AM +0100, Stefan Richter wrote: > Yes, I will do so as soon I got spare time. > MODE_SENSE_10 seemed to be the trigger, as mentioned in > http://marc.theaimsgroup.com/?l=linux-scsi&m=112128914912105 . Also note > that this device reports to implement Direct-Access, unlike most other > SBP-2 HDDs which pose as Direct-Access-RBC. OK, I think I've seen one that does it. Behold the lossage: * bugger does, indeed, report itself to be type 0 * OK, says sd_read_cache_type(). Page 8 for you, then. * so called "SCSI device" spits out... <drumroll> RBC page 6. Sans mode page headers. So we see 0x86 0x0b where the data length should've been. And bytes 3 and 2 of device size where the block descriptors size should've been. Since sd.c doesn't expect that level of idiocy (it should, but...) we adjust length down from ~34000 to 20 _and_ blindly add block descriptors size. Or what we assume to be one. Then we proceed to call scsi_mode_sense() with buffer created by kmalloc(512, GFP_DMA) and len... well, anywhere up to 64Kb. One of the first things it does is memset(buffer, 0, len). That's an Initio bridge, BTW. I suspect that the best we can do is to blacklist the little shit with "don't trust that one, it's really type 14". If it reacts to request for page 6 in a saner fashion, that is... - : 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
