On Wednesday 03 January 2007 6:06 pm, Johnnie Peters wrote:
> I am helping to develop a hand held device based on the Xscale running 
> Linux.  One of the requirements is USB ethernet connectivity.  With some 
> minor changes I have g_ether working to both Linux and Windows hosts.

Good!  That was the general idea.  :)

What were those changes, by the way?


> I am now trying to get a connection to a MAC working.  It comes up and I 
> can ping between the two systems just fine.  But when I bring up the 
> lighttp daemon and try to mount a WebDAV service the Link freezes with 
> errors:
> 
> ...
> Nov  1 10:52:12 Monolith-2 kernel[0]: (77: coreservicesd)tfp: failed on 0:
> Nov  1 10:54:55 Monolith-2 kernel[0]: 0        0 AppleUSBCDCACMData: 
> start - Find CDC driver failed

I take it that the Apple code has wrongly attempted to use the RNDIS
interface, and then rightly failed binding to it.

> Nov  1 10:54:55 Monolith-2 kernel[0]: AppleUSBCDCECMData: Version number 
> - 3.1.9, Input buffers 8, Output buffers 4
> Nov  1 10:54:55 Monolith-2 kernel[0]: AppleUSBCDCECMData: Ethernet 
> address 4a:ea:a0:6b:e4:c4

... so far so good:  CDC Ethernet Control Model (ECM) looked to come
up reasonably correctly.  Though I'd suggest NoTmIxInGcAsEiNsYmBoLs
to Apple's style guide folk, and learning_about_separators too.  :)


> Nov  1 10:57:29 Monolith-2 kernel[0]: 0        0 AppleUSBCDCECMData: 
> getOutputBuffer - No buffers available, deadman expired
> Nov  1 10:57:29 Monolith-2 kernel[0]: 4        0 AppleUSBCDCECMData: 
> USBTransmitPacket - Output buffer unavailable

... well that's bizarre.  It's clearly an issue on the Apple side;
maybe their CDC Ethernet driver needs work yet.  It's routine for
network drivers to temporarily run out of resources, which is why
net driver stacks (should) have mechanisms to block queues pending
the necessary recycling.

 
> I am more than willing to do the footwork to correct this problem.  
> However I am not a MAC programmer and I was wondering if anybody else 
> has encountered this issue.  If not then maybe somebody has an idea of 
> where to start looking.
> 
> In the man time I am going to hook up a USB analyzer and see what is on 
> the cable when the problem occurs.

My guess would be nothing at the USB level went wrong ... the issue
being above that, TX packet mismanagement.

- Dave


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to