Date: Sun, 19 Dec 1999 17:18:37 -0500 (EST) From: Bill Paul <wpaul@skynet.ctr.columbia.edu> To: julian@whistle.com (Julian Elischer) Cc: hackers@freebsd.org Subject: Re: USB ethernet hacking Message-ID: <199912192218.RAA03775@skynet.ctr.columbia.edu> In-Reply-To: <Pine.BSF.4.10.9912191335460.41729-100000@current1.whistle.com> from "Julian Elischer" at Dec 19, 99 01:44:47 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Of all the gin joints in all the towns in all the world, Julian Elischer had to walk into mine and say: > Doug Ambrisko and I wrote a netgraph based USB-to-USB networking device > node. We used the async method and it works fine. We just added > a queue and called an interrupt level 'start routine' much like any other > driver. It works like a charm. I don't see why it wouldn't work for an > ethenet style device.. We had to add splimp() protection in some places > because splusb() is actually splbio() but it seems to work as expected. I don't know why it doesn't work either. Hence my posting here. :) > > I have worked around this for now by hacking usbdi.c so that it polls > > the controller interrupt/status register instead of tsleep()ing. I'm not > > sure this is the best solution, but it's the only one that seems to work. > > why not use the async method? Because this is not an asynchronous task that I'm trying to do here. I'm talking about reading and writing registers from the ethernet controller. If this was a PCI device, I'd be using bus_space_read_X()/bus_space_write_X() to read the registers directly. I don't want to start reading a register and then come back a while later to read the results. The code isn't meant to work like that. > > However that's not my biggest problem. My biggest problem is getting > > transfers over 1100 bytes or so to work reliably. My initial scheme > > for transmitting and receiving packets was to set up asynchronous > > transfers with callbacks. > > That's what we did and we can send 1500 byte packets with no problems. You're not allowed to say "that's what we did" without a) looking at the code that I wrote and comparing it and b) showing me your code so that I can compare it too and see where I might have gone wrong. One other interesting thing that I found is that I had to use the USBD_SHORT_XFER_OK flag in order to receive packets at all. Right now, the only way I can make it work at all is to set the interface MTU to 1000 bytes. Right now I'm just talking through a crossover cable to another machine, so I can set the MTU on both ends for experimenting, but obviously I can't keep it like that. I still would like to know what a "babble" error means in this context, and how to clear it. With ethernet, it usually means that somebody is sending way, way, *way* too much data in a single transaction, but I'm not sure how to interpret it here. > > Packets are sent over bulk transfer endpoints > > (one for RX, one for TX). For TX, I would set up a transfer and initiate > > it, then wait until the callback is called to free the mbuf containing > > the packet data. > > We just copied the data from the mbuf into a dedicated > buffer and freed the mbuff immediatly. Did you just allocate a buffer with malloc() (or contigmalloc()), or did you use usbd_alloc_buffer()? -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" ============================================================================= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199912192218.RAA03775>