Chinaunix首页 | 论坛 | 博客
  • 博客访问: 963554
  • 博文数量: 173
  • 博客积分: 3436
  • 博客等级: 中校
  • 技术积分: 1886
  • 用 户 组: 普通用户
  • 注册时间: 2009-01-07 09:29
文章分类

全部博文(173)

文章存档

2016年(6)

2015年(10)

2014年(14)

2013年(8)

2012年(36)

2011年(63)

2010年(19)

2009年(17)

分类: BSD

2012-03-22 09:18:14

2012年3月13日:
紧急报送CIR,blackberry 9650手机经过Thin Client设备映射后无法同步。
找资源,建环境,做对比测试。windows平台可以成功的映射,WTOS 失败。
 
1:看log发现 有个cancel xfer;而且在之后USB 传输不正常了。
   分析:是因为WTOS给server回的数据,导致了Server发送了该命令,因此需要找到之前数据不一样的地方。
          折腾了两天多,将枚举阶段的流程更改成和windows一直,仍然出现cancel xfer;
2: 引入工具:CDF control:
   对比通过windows client连接server与 WTOS client连接server上的记录,发现windows client连接时也有cancel xfer的命令;因此转向cancel xfer的线索;
   怀疑cancel的包不正确,或者cancel xfer执行不对;
   又引入工具: bushound,直接分析server上收到的数据,发现server上收到的数据保丢失了48字节。
 
3:研究cancel xfer
   通过建立测试程序,cancelUSB disk bulk 传输,发现同样的问题。
   对于cancel transfer而言,其实所谓cancel,对应EHCI spec就是 remove queue,其目的两个:a) 如果还传输未完成则停止传输;b)如果传输无法完成,强制停止传输;c)如果传输已经完成,则不需再做额外操作。remove queue时,不能破坏HOST controller分析QH的连续性,因此可以将所有的传输都变成 unactive的。然后等到ehci的中断时,再将queue真正删除。
 
经过该问题的解决历程后:
1)对于ICA映射后的设备,只要windows client可以正常工作,WTOS设备也应该可以正常供做;
通过CDF control直接分析server上的log,对比server发送的命令及收到的响应;
通过Bushound直接对比server上收到的USB数据,对比client返回的数据差异;
2)cancel xfer对于该命令,应该增强了自信!
3)对于出现的问题,应该及早的去追寻差异的地方,而对于一些相关的地方没有必要等到都搞的特别清楚后再去分析问题。
 
 
阅读(957) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~