Hi Dave,


David Brownell wrote:
> 
> >        Now, I have found something I had
> > not seen before (although I had not looked for it either): dmesg throws the
> > following from the driver usbnet.c:
> >
> > usbnet.c:  genelink: illegal received packet count 286265102
> >
> > repeated a large number of times (probably one for each packet lost?). Once
> > again, both machines, which have got the same kernel 2.4.18 and the same config,
> > exhibit the same behaviour.
> >
> > Does this make sense to you?
> 
> Yes, it means that somehow the special framing used with that
> GeneSys hardware is misbehaving.  (The person who provided that
> driver support used it for Win32 driver interop, and it's a lot
> funkier than really seems necessary.)  If that's the case, then
> dropping lots of packets makes sense:  garbage input leads to,
> in this case, no output.
> 
> It's not clear to me how you'd get that behavior though.  The
> particular field in question is always written by that driver
> as "1".  Since I don't have that GeneSys hardware I can't even
> attempt to reproduce that problem.  For what it's worth, you
> are the only person who's reported this particular problem.
> (Though not many folk seem to use the GeneLink cable.)
> 
> If you want to experiment, you might try disabling that special
> framing.  In the definition of "genelink_info", comment out
> the FLAG_FRAMING_GL and the four function hooks (on the next
> four lines).  Rebuild, retest.  (Do that on both ends!)  Given
> what little I know about that hardware, I suspect that would
> work fine -- unless you need the Win32 interop.


It did not make any diferrence. Same behaviour, dropping loads of packets.
However, I've managed to get it to work by compiling the kernel
with the other UHCI. Bingo! I had to change the driver in both machines,
since only doing it in one did not work ( or it did, but slow, as before).
Actually, now that I think about it, I still have your proposed changes in 
the usbnet driver, so maybe it did do something. I think I'll undo the changes
to see whether the whole problem was in the UHCI driver (which is what I 
suspect, because I have got hold of another prolific-based cable, and it works
fine with this UHCI, but it did not with the UHCI-ALT that I had before).
I am gonna write a posting to linux-usb-users, in case my findings can be of
assistance to anyone else. 

 
> - Dave
> 
> p.s. What kind of host CPUs are you running this on?

SBC with a Mobile Pentium MMX@266MHz and a laptop with a Celeron(Mendocino)@433MHz

Thanks very much for your time and pointers. Greatly appreciated.

Jaime


_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-users

Reply via email to