Date: Fri, 9 Jan 2009 22:45:15 +0100 From: Nick Hibma <nick@van-laarhoven.org> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: freebsd-current@freebsd.org Subject: Re: 3G modem and USB, old & new Message-ID: <200901092245.16450.nick@van-laarhoven.org> In-Reply-To: <23654.1231535410@critter.freebsd.dk> References: <23654.1231535410@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
> >I've not been able to reproduce the problems reliably. But looking at > > the symptoms somehow buffering goes pear-shaped somewhere. There is no > > buffering being done in the u3g code.That's all handled by ucom, but to > > me that looks like cut&paste from other code. So I presume (wildly > > pointing fingers at code I do not yet understand) that the problem is > > somewhere in the combination of ucom and tty layer, or perhaps even in > > the TTY layer. > > I can shoot that theory down right away: It worked great when I hacked > the magic mode bit support into ubsa.c > > It must be a u3g issue. Explain that to the people that get great performance on u3g, which had big troubles using ubsa (the same problems you are seeing; me for one). So I am pretty sure I am right. Second: I've had reports of E220 working and the same device not working and choking on 'AT' on the second channel. It is most definitely a buffering issue. Perhaps the buffers are not properly configured, but making them larger or smaller does not change the symptoms in any case for these people. Would you know of a serial device using tty layer code with high speed serial links that I could look at to see what could be wrong in either u3g and/or ucom? Thanks. Nick
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200901092245.16450.nick>