> On Wed, 2009-01-07 at 09:30 -0200, Pablo Borges wrote: > > > The only bummer is, after a few minutes surfing teh internets my > > blackberry reboots (O_O). I guess it has something to do with the > > firmware that I need to upgrade. :/ > > Someone reported something similar to me on my blog the other day: > > "Barry does show great potential, but has a show-stopping bug for me. > See my report on SF: Bug # 2480631…"
> http://www.happyassassin.net/2009/01/04/activity-and-blackberry-tethering-article/ > and ISTR it's been reported to the list, too. This seems to be a general > bug...and at least for your case and the blog case, the offending model > is a Curve... > The bug report referred to in the comment is: > http://sourceforge.net/tracker/index.php?func=detail&aid=2480631&group_id=153722&atid=788904 > -- > adamw > http://www.happyassassin.net I seem to have run afoul of the same problem. I just got a Blackberry Curve 8320 from T-Mobile (OS version 4.5.0.81), and I set up tethering with my laptop running FreeBSD. In my case, the crash occurs during periods of heavy network load. One of the first things I did after I set it up was to try to measure the data transfer speed by downloading a file using fetch(1) (similar to wget(1) in linux). The transfer would run for a while, then the Blackberry would reset. I've observed two failure modes: - The LED turns red, the screen turns white, a spinning hourglass appears and remains on screen for up to a minute, then the T-Mobile logo appears for a few seconds, and finally the menu appears. - The LED turns red, the screen turns white for about 10 seconds, then the menu reappears. As soon as the main menu returns, the EDGE link appears good, but then it drops (red X through the antenna icon) and renegotiates. In both cases, the Curve disconnects from the USB bus. This coincides with an I/O error during usb_bulk_read(). I ran pppob with debugging turned on, and the log file shows what looks like a partial read: normally it's reading full sized frames of about 1492 bytes (which corresponds to the TCP segments arriving) but the last read before the crash only gets about 1088 bytes. Oh, with my EDGE connection via T-Mobile, the link speed seems to max out at about 26KB/sec. (That's kilobytes per second.) I do device driver development for a living, and to me, a failure under load such as this typically indicates a race condition. Races are somewhat less likely to occur in user mode code, but I suppose they're still possible. I don't know for sure what's causing the problem yet, but I have a suspicion. Looking at the log file generated by pppob, there seems to be a pattern to the data transfer. In particular, whenever pppob does a USB bulk write, it's typically followed by a USB bulk read of an "IPModem special packet." The DataReadThread() method in m_ipmodem.cc does not do any special processing of these messages and just discards them, but I think this might be the wrong behavior. It looks an awful lot like these messages are write completion acknowledgements; if so, I think the right thing to do is wait for the acknowledgement after each write before proceeding to the next write. That is, instead of just doing a usb_bulk_write() and returning immediately, I think you need to do the bulk write, then issue a bulk read and wait for the acknowledgement to arrive, _then_ return. (And then it's safe to monitor the read pipe for incoming traffic again.) My money says that this mechanism is used to both rate limit the data transfered from the host to the device and to keep host and device synchronized. I looked over the code briefly hoping that I might be able to do a quick experiment to test this theory, but that turned out to be a little trickier than I expected. This is partly because the code is written in C++ (I'm an expert in C, but I only know a little bit about C++), and partly because it uses threads. The m_ipmodem.cc module in particular uses a thread to listen for inbound data from the device. This complicates things a little: I was hoping to avoid having the read and write operations running indepentently of each other (since I want the "wait for acknowledgement" operation performed after a write not to collide with the normal read operations -- I especially don't want to end up trying to queue two bulk read operations at once). It should be possible to avoid the use of threads here and obtain the desired behavior by making use of select() in pppob to monitor both the stdin file descriptor and the USB bulk read descriptor simultaneously. Unfortunately, the current design of both pppob and the m_ipmodem.cc module make this a little hard to do. I think I can rework them a little to make it possible to at least test this approach and modify the IpModem::Write() method to wait for acknowledgement, but it may take me a few days. Oh, a few notes on getting pppob to work with FreeBSD: - Building barry fails unless you have GCC 4. This is because the router.cc module seems to depend on something called C++ Technical Report 1 library extensions, which are not present in GCC 3. (Current versions of FreeBSD include GCC 4 in the base install, but FreeBSD 6.0 comes with GCC 3.4.4. This means I had to build a newer GCC on my laptop before I could compile barry.) Is it really necessary to make the code dependent on this extension? - The version of pppd included with FreeBSD is 2.3 patch level 5. Linux seems to use pppd 2.4. The main problem with this is that the "pty" directive doesn't exist in pppd 2.3pl5, which makes it hard to use pppob with it. I found a workaround for this, but I still had problems (pppd would not negotiate a link). I finally gave up on pppd and used the user-space ppp(8) utility in FreeBSD, and had better luck with it. (The one trick to it seems to be that you have to disable VJ header compression.) -Bill -- ============================================================================= -Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu wp...@windriver.com | Wind River Systems ============================================================================= "I put a dollar in a change machine. Nothing changed." - George Carlin ============================================================================= ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Barry-devel mailing list Barry-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/barry-devel
