On Fri, 2009-01-16 at 10:28 -0800, Bill Paul wrote: > > 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
I don't think that is the case. I think it shows incomplete initialization handshaking. I'm pretty sure I got it to stop sending this packet in response to every write by paying closer attention to the init sequence. > 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 > ------------------------------------------------------------------------------ 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
