I think it might be that bio sets up the iov incorrectly. I've had this problem that sdparm is receiving all-zero data (command completes OK but no data is written into specified buffer) with kernel 2.6.19, and I've found that blk_rq_map_user receives the correct user space buffer address but the iov generated for data transfer is not a map to that user address. So the low-level driver reads the data into a wrong buffer. I'm running 2.6.19 on a dual-opteron box with 4G memories, kernel compiled for x86_64. I haven't tried the git tree but I've read all commit log ( til Dec 22nd ) and didn't find any commit on this problem. I thought it might be introduced in recent kernels ( 2.6.17-2.6.19 ) because sdparm works fine with SuSE Linux 10.1's kernel ( customized 2.6.16 ), which it seems is not the fact. I planed to look into it further but is currently having no spare time. If you've got an update, please let me know about it. TIA. Cheers, Albert Ke On 12/22/06, Ken Hwang <ken.hwang@xxxxxxxxx> wrote:
Hi, I had a utility which uses SG_IO ioctl (scsi passthrough?) to issue private commands to a USB dongle (reported as a USB Mass Storage but with 0 bytes) to get some information back. It works fine with kernel 2.6.12.2. But after we upgraded to kernel 2.6.15.4 then the program could not get information back anymore (reads all 0 with the private command). Can anyone please give me a hint of where I should go studying more? Thanks, Ken -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.409 / Virus Database: 268.15.26/594 - Release Date: 12/20/2006 - 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
- 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
