From: Mike B. <ma...@po...> - 2004-03-16 05:21:23
|
So after days of fighting with timeout errors and blue screens of death (from trying to work around the timeout errors), I have come to the conclusion that the proper USB drivers are highly important. :) I'm currently using a FutureDial cable ("For Samsung model A310, A600"). The first set of samsung drivers I tried to use were the boxwave drivers found here: http://www.boxwave.com/products/minisync/samsung/samsung_drivers.zip These caused me no end of crashes and timeouts. The new set of samsung drivers that I am using can be found here: http://www.susteen.com/download/drivers/SamsungCQX.zip These drivers let me backup the entire filesystem without a single timeout, which enabled me to remove all of my flawed(?) timeout code. Just a bit of learning experience, for everyone to possibly benefit from, here's what I saw and tried before switching drivers: - First, I was getting a timeout message. It was consistently reading 198 bytes from a packet that listed the size as 256 bytes. - To work around this, I changed sendbrewcommand locally to the following: def sendbrewcommand(self, request, responseclass, callsetmode=True, numsendretry=2): if callsetmode: self.setmode(self.MODEBREW) buffer=prototypes.buffer() request.writetobuffer(buffer) data=buffer.getvalue() self.logdata("brew request", data, request) data=escape(data+crcs(data))+self.brewterminator firsttwo=data[:2] isendretry=numsendretry while isendretry>=0: try: self.comm.write(data, log=False) # we logged above data=self.comm.readuntil(self.brewterminator, logsuccess=False) break except modeignoreerrortypes: if isendretry>0: self.log("Resending request packet...") time.sleep(0.3) else: self.mode=self.MODENONE self.raisecommsdnaexception("manipulating the filesystem") isendretry-=1 self.comm.success=True origdata=data # sometimes there is junk at the begining, eg if the user [...] - This appeared briefly to work. The first time it retried, it would get unstuck. However, it would then give me a bad size exception. Comparing the packets sent during a successful read of the file vs an unsuccesful read, the *only* difference was that the second to last packet from the phone set the "has more data" flag to false instead of true. ARGH. - I then tried, in this situation, to ignore the "has more data" flag and force it to keep reading anyways. This led very quickly to a blue screen of death in my USB drivers. ARGGGH. - I then tried to override the getfilecontents function, and wrapped the whole thing in a try/except block to try to force the entire file read to restart. Oddly enough, this also led very quickly to a blue screen of death, though it's possile I didn't do it correctly. - Finally, I switched USB drivers, and I was able to go from reading 10-15 files from the filesystem to a full set of 105 or so files. Time to start poking at the files to see what I can find... Mike |