Scsi - Index of
Scsi - Index of Scsi - Index of
下,USB_STOR_XFER_STALLED 对应于usb core 传回来的是-EPIPE,这种情况说明管道不通,就相当 于 您家里的下水管道堵塞,当然这也说明get CSW 再次失败了...,这种情况很简单,直接retry,为什么要 retry?我们看一下interpret_urb_result()函数,最重要的就是310 到314 行,这里判断了,因为我们曾经 讲过,bulk 端点可能会设置了halt 条件,设置了这种条件的端点必然会堵塞管道,所以这里就不管如何,试 一 试看,看清掉这个flag 是否会有好转.所以对于这种情况,我们可以重试一次.我们抱着试一试的心态去 retry, 应该说这种心态是正确的,我再重申一次,这里实际上反映的就是Linux 代码背后的哲学,反映的是一种勇 敢 面对挫折的人生态度,一枚贝壳要用一生的时间才能将无数的沙粒转化成一粒并不规则的珍珠,雨后的彩虹 绽放刹那的美丽却要积聚无数的水汽.如果把这些都看成是一次又一次挫折,那么是挫折成就了光彩夺目的 珍珠和美丽的彩虹.我们要相信,失败并不可怕,失败是通往成功的道路. 如果您不是像李白一样近视的话,(床前明月光都能看成地上霜的人,还不是近视吗?)您应该会看见这次 传递给usb_stor_bulk_transfer_buf()函数的最后一个参数不是像之前那样,这次是NULL,这是因为实 际上cswlen 作为一个临时变量,表征的是状态阶段的实际传输长度,但是在眼下这种情况我们已经不需要 使用这个临时变量了. 1042 行,好家伙,如果都这么重新获取了还不成功的话,不用再瞎耽误工夫了,直接返回吧,向领导汇报这 设备无药可救了.没办法,返回USB_STOR_TRANSPORT_ERROR,到这里还不成功那真的就是让人绝望 了.什么?你说失败是成功之母?对于这句话我没有异议,问题是失败在遇上我之前已经结扎了... 而从1046 行开始,正式分析CSW 了.结合我们从usb mass storage bulk only 协议中抓出来的那幅 图,那幅介绍CSW的格式的图,bcs->Residue 对应于CSW的dCSWDataResidue,她表示的是实际传输 的数据和期望传输的数据的差值.bcs->Signature 对应于CSW 中的dCSWSignature,bcs->Tag 对应 于CSW中的dCSWTag,而bcs->Status 对应于bCSWStatus.我们有些事情没道理的,有人很抢手,有人 没资格,路是人走的.在bcs 中成员的存储格式居然还有区别,有的是little endian 的,有些却不是.对于那 些 little endian 的,咱们需要调用像cpu_to_le32 这样的宏来转换,而其她的却不需要转换,对于bcs 来说, 其成员Residue 和Signature 就需要这样转换.这些规矩仿佛是没有道理的. 167 1050 行,和之前bcb 中使用US_BULK_CB_SIGN 一样,US_BULK_CS_SIGN这个宏用来标志这个数 据包是一个CSW包.而US_BULK_CS_OLYMPUS_SIGN也是一个宏,不过她是专为某种变态设备专门准 备的.这两个宏和接下来将提到的一些宏依然来自drivers/usb/storage/transport.h 中, 110 #define US_BULK_CS_SIGN 0x53425355 /* spells out 'USBS' */ 111 /* This is for Olympus Camedia digital cameras */ 112 #define US_BULK_CS_OLYMPUS_SIGN 0x55425355 /* spells out 'USBU' */ 113 #define US_BULK_STAT_OK 0 114 #define US_BULK_STAT_FAIL 1 115 #define US_BULK_STAT_PHASE 2 对大多数普通的设备来说,如果要标志一个CSW 包,其Signature 会是53425355h.但是Olympus Camedia 这种数码相机偏偏要标新立异,她愣是跟您换个数字,那咱也没办法.敢情人家设计者是穿美特斯 邦威长大的,就是不走寻常路. Tag 就是和CBW 相对应的,两个Tag 应该相同.要不然也就不叫接头暗号了.前面为Tag 赋值为 srb->serial_number,这回自然也应该等于这个值.
而bcs->Status,标志命令执行是成功还是失败,当她是0 表明命令是成功的,当她是非0,嘿嘿,肯定有问 题.目前的spec 规定,她只能是00h,01h,02h,而03h 到FFh 都是保留的,不能用,所以这里会判断她是否 是大于US_BULK_STAT_PHASE,也就是说是否会大于02h,大于了当然就不行.好,这样子,就是说这些条 件如果不满足的话,那么一定是有问题的.返回错误值吧. 1060行至1066行,如果residue不为0,那么说明数据没传完,或者说和预期的不一样,那么来细看一下, 首先该设备应该没有设置US_FL_IGNORE_RESIDUE这个flag,老规矩,让我们看一下什么样的设备设置 了这个flag, 269 /* Yakumo Mega Image 37 270 * Submitted by Stephan Fuhrmann */ 271 UNUSUAL_DEV( 0x052b, 0x1801, 0x0100, 0x0100, 272 "Tekom Technologies, Inc", 273 "300_CAMERA", 274 US_SC_DEVICE, US_PR_DEVICE, NULL, 275 US_FL_IGNORE_RESIDUE ), 276 277 /* Another Yakumo camera. 278 * Reported by Michele Alzetta */ 279 UNUSUAL_DEV( 0x052b, 0x1804, 0x0100, 0x0100, 280 "Tekom Technologies, Inc", 281 "300_CAMERA", 282 US_SC_DEVICE, US_PR_DEVICE, NULL, 283 US_FL_IGNORE_RESIDUE ), 284 285 /* Reported by Iacopo Spalletti */ 168 286 UNUSUAL_DEV( 0x052b, 0x1807, 0x0100, 0x0100, 287 "Tekom Technologies, Inc", 288 "300_CAMERA", 289 US_SC_DEVICE, US_PR_DEVICE, NULL, 290 US_FL_IGNORE_RESIDUE ), 291 292 /* Yakumo Mega Image 47 293 * Reported by Bjoern Paetzel */ 294 UNUSUAL_DEV( 0x052b, 0x1905, 0x0100, 0x0100, 295 "Tekom Technologies, Inc", 296 "400_CAMERA", 297 US_SC_DEVICE, US_PR_DEVICE, NULL, 298 US_FL_IGNORE_RESIDUE ), 299 300 /* Reported by Paul Ortyl 301 * Note that it's similar to the device above, only different prodID */ 302 UNUSUAL_DEV( 0x052b, 0x1911, 0x0100, 0x0100, 303 "Tekom Technologies, Inc", 304 "400_CAMERA",
- Page 115 and 116: 内核的核心位置,kernel/exit.c
- Page 117 and 118: 1023 dissociate_dev(us); 1024 retur
- Page 119 and 120: 917 行,再次判断设备有没有
- Page 121 and 122: 181 182 /* fail the command if we a
- Page 123 and 124: 83 struct timer_list eh_timeout; /*
- Page 125 and 126: 123 两个scsi_done,一个是struct
- Page 127 and 128: 56 jiffie count on our counter, the
- Page 129 and 130: 中 看到如下的定义: UNUSUAL_
- Page 131 and 132: 269 memcpy(data+16, us->unusual_dev
- Page 133 and 134: 一切准备好了之后,我们就
- Page 135 and 136: 238 (sg->offset + *offset) & (PAGE_
- Page 137 and 138: 所以对于那些不能相应INQUI
- Page 139 and 140: 239 行对unsigned int sglen 赋值
- Page 141 and 142: 请求,所以这里就判断abort
- Page 143 and 144: 112 case GPCMD_READ_HEADER: what =
- Page 145 and 146: 到北京,每每只有在夜深人
- Page 147 and 148: 580 /* 581 * If we have a failure,
- Page 149 and 150: 666 memcpy(srb->cmnd, old_cmnd, MAX
- Page 151 and 152: 950 struct bulk_cb_wrap *bcb = (str
- Page 153 and 154: 1034 /* get the status again */ 103
- Page 155 and 156: 426 /* store the actual length of t
- Page 157 and 158: 后她会给host 返回一个CSW.CB
- Page 159 and 160: 296 } 297 298 US_DEBUGP("-- transfe
- Page 161 and 162: 491 * scatter-gather or not, and ac
- Page 163 and 164: 迷雾重重的 Bulk 传输(五) us
- Page 165: 然后把她赋给了result.而us->
- Page 169 and 170: 就必须设置US_FL_IGNORE_RESIDUE
- Page 171 and 172: 485 }; 486 这是一个字符数组
- Page 173 and 174: srb->sense_buffer 里边的东西.S
- Page 175 and 176: 一个类似的函数,名叫usb_sto
- Page 177 and 178: 这种命令应该由mid level 来
- Page 179 and 180: Disk /dev/sda: 146.1 GB, 1461631057
- Page 181 and 182: through to the most significant bit
- Page 183 and 184: 1192 USB_TYPE_CLASS | USB_RECIP_INT
- Page 185 and 186: 315 行,scsi_report_device_reset(),
- Page 187 and 188: 285 US_DEBUGP("No reset during disc
- Page 189 and 190: 229 /* Wait for the aborted command
- Page 191 and 192: 两个函数中需要判断它,一
- Page 193 and 194: associate_dev()相对应.我们来
- Page 195 and 196: 束for 死循环,从而usb_stor_con
- Page 197 and 198: 317 for (i = 1; i < us->host->max_i
下,USB_STOR_XFER_STALLED 对应于usb core 传回来的是-EPIPE,这种情况说明管道不通,就相当<br />
于<br />
您家里的下水管道堵塞,当然这也说明get CSW 再次失败了...,这种情况很简单,直接retry,为什么要<br />
retry?我们看一下interpret_urb_result()函数,最重要的就是310 到314 行,这里判断了,因为我们曾经<br />
讲过,bulk 端点可能会设置了halt 条件,设置了这种条件的端点必然会堵塞管道,所以这里就不管如何,试<br />
一<br />
试看,看清掉这个flag 是否会有好转.所以对于这种情况,我们可以重试一次.我们抱着试一试的心态去<br />
retry,<br />
应该说这种心态是正确的,我再重申一次,这里实际上反映的就是Linux 代码背后的哲学,反映的是一种勇<br />
敢<br />
面对挫折的人生态度,一枚贝壳要用一生的时间才能将无数的沙粒转化成一粒并不规则的珍珠,雨后的彩虹<br />
绽放刹那的美丽却要积聚无数的水汽.如果把这些都看成是一次又一次挫折,那么是挫折成就了光彩夺目的<br />
珍珠和美丽的彩虹.我们要相信,失败并不可怕,失败是通往成功的道路.<br />
如果您不是像李白一样近视的话,(床前明月光都能看成地上霜的人,还不是近视吗?)您应该会看见这次<br />
传递给usb_stor_bulk_transfer_buf()函数的最后一个参数不是像之前那样,这次是NULL,这是因为实<br />
际上cswlen 作为一个临时变量,表征的是状态阶段的实际传输长度,但是在眼下这种情况我们已经不需要<br />
使用这个临时变量了.<br />
1042 行,好家伙,如果都这么重新获取了还不成功的话,不用再瞎耽误工夫了,直接返回吧,向领导汇报这<br />
设备无药可救了.没办法,返回USB_STOR_TRANSPORT_ERROR,到这里还不成功那真的就是让人绝望<br />
了.什么?你说失败是成功之母?对于这句话我没有异议,问题是失败在遇上我之前已经结扎了...<br />
而从1046 行开始,正式分析CSW 了.结合我们从usb mass storage bulk only 协议中抓出来的那幅<br />
图,那幅介绍CSW的格式的图,bcs->Residue 对应于CSW的dCSWDataResidue,她表示的是实际传输<br />
的数据和期望传输的数据的差值.bcs->Signature 对应于CSW 中的dCSWSignature,bcs->Tag 对应<br />
于CSW中的dCSWTag,而bcs->Status 对应于bCSWStatus.我们有些事情没道理的,有人很抢手,有人<br />
没资格,路是人走的.在bcs 中成员的存储格式居然还有区别,有的是little endian 的,有些却不是.对于那<br />
些<br />
little endian 的,咱们需要调用像cpu_to_le32 这样的宏来转换,而其她的却不需要转换,对于bcs 来说,<br />
其成员Residue 和Signature 就需要这样转换.这些规矩仿佛是没有道理的.<br />
167<br />
1050 行,和之前bcb 中使用US_BULK_CB_SIGN 一样,US_BULK_CS_SIGN这个宏用来标志这个数<br />
据包是一个CSW包.而US_BULK_CS_OLYMPUS_SIGN也是一个宏,不过她是专为某种变态设备专门准<br />
备的.这两个宏和接下来将提到的一些宏依然来自drivers/usb/storage/transport.h 中,<br />
110 #define US_BULK_CS_SIGN 0x53425355 /* spells out 'USBS' */<br />
111 /* This is for Olympus Camedia digital cameras */<br />
112 #define US_BULK_CS_OLYMPUS_SIGN 0x55425355 /* spells out<br />
'USBU' */<br />
113 #define US_BULK_STAT_OK 0<br />
114 #define US_BULK_STAT_FAIL 1<br />
115 #define US_BULK_STAT_PHASE 2<br />
对大多数普通的设备来说,如果要标志一个CSW 包,其Signature 会是53425355h.但是Olympus<br />
Camedia 这种数码相机偏偏要标新立异,她愣是跟您换个数字,那咱也没办法.敢情人家设计者是穿美特斯<br />
邦威长大的,就是不走寻常路.<br />
Tag 就是和CBW 相对应的,两个Tag 应该相同.要不然也就不叫接头暗号了.前面为Tag 赋值为<br />
srb->serial_number,这回自然也应该等于这个值.
Change language