> dmesg has: > Nov 26 10:25:49 vbook kernel: ucom0: invalid receive data size, > -754491385 chars > Nov 26 10:25:49 vbook kernel: ucom0: invalid receive data size, > -754491390 chars > Nov 26 10:25:51 vbook kernel: ucom0: invalid receive data size, > -754491385 chars > Nov 26 10:25:52 vbook kernel: ucom0: invalid receive data size, > -754491390 chars > Nov 26 10:25:56 vbook kernel: ucom0: invalid receive data size, > 626606082 chars > Nov 26 10:25:59 vbook kernel: ucom0: invalid receive data size, > 466214914 chars > Nov 26 10:26:00 vbook kernel: ucom0: invalid receive data size, > 466214919 chars > Nov 26 10:26:01 vbook kernel: ucom0: invalid receive data size, > 466214914 chars Could you try the following: Change the ibufsize and obufsize values to a power of 2 in u3g_attach: ucom->sc_ibufsize = 4096; ucom->sc_ibufsizepad = ucom->sc_ibufsize; ucom->sc_obufsize = 4096; Perhaps the USB stack does not like arbitrarily sized buffers due to transfer rollovers at the end of the buffer / memory page or something. If that does not work could you lower it to 512, and if that does not work change it to: ucom->sc_ibufsize = UGETW(ed->wMaxPacketSize); ucom->sc_ibufsizepad = ucom->sc_ibufsize; ucom->sc_obufsize = UGETW(ed->wMaxPacketSize); That last case is worst case as it would considerably increase overhead, especially in USB 1.0 cases where the max. wMaxPacketSize is 64 bytes. If it works I'd be interested to hear about performance (download from SUN is always a good one), and any messages in dmesg or in a ppp logfile for dropped chars, and invalid FCS. Cheers, NickReceived on Wed Nov 26 2008 - 08:29:16 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:38 UTC