Date: Mon, 15 Apr 2002 11:32:03 +0200 (CEST) From: Nick Hibma <n_hibma@van-laarhoven.org> To: Peter Haight <peterh@sapros.com> Cc: Andrew Gordon <arg-bsd@arg1.demon.co.uk>, "hardware@freebsd.org" <hardware@freebsd.org> Subject: Re: Reading from the USB ugen device. Message-ID: <20020415112318.L36693-100000@heather.van-laarhoven.org> In-Reply-To: <200204150107.g3F17WRg033229@wartch.sapros.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> From what you told me and a brief look at the USB spec, I'm guessing it > isn't a coincidence that it is failing on that read where I'm expecting 64 > bytes (the max size of a USB packet payload). I'm guessing that in short > read mode, the driver gets a full length packet and is expecting another > data packet but it never comes because that's the end of the data, so it > doesn't return from the read until it gets a timeout. No. If you read 64 byes in 64 bytes with short_XFER switched on you will be reading 64 bytes and then 0 bytes. > I'd like to watch the debug messages for the ugen driver, but I'm having > trouble getting the debug messages to go. I put 'options UGEN_DEBUG' in my > kernel conf file and I recompiled and installed, but when I do a 'nm > /modules/ugen.ko | grep ugendebug' that symbol isn't defined and if I try to > do an ioctl(USB_SETDEBUG) I get an 'Invalid Argument' error. It turns out > that if I do 'nm ugen.o | grep ugendebug' in my kernel compile directory it > prints out the symbol, but the kernel module doesn't seem to be getting the > option. In fact if I look at opt_usb.h in my kernel compile directory I see > '#define UGEN_DEBUG 1', but if I look at > 'modules/usr/src/sys/modules/ugen/opt_usb.h' under my kernel compile > directory, it is blank. kernel config doesn't cover module build. Add CFLAGS+= -DUGEN_DEBUG in /sys/modules/ugen/Makefile. > - write a request to the palm for a list of databases > - read the packet header returned from the palm: read(6) > - from the packet header, get the length and read that: read(123) > > I think the problem he was trying to combat was that he thought that the > following could happen: > - write a request to the palm for a list of databases > - read the packet header returned from the palm: read(6) > - the ugen driver reads a 129 byte transaction from the USB bus and returns > 6 bytes, but deletes the other 123 bytes because it doesn't buffer between > reads. > - from the packet header, get the length and read that: read(123), but this > read would then fail because the rest of that data was wiped after the > previous read > > Is that possible? If it is, I think that it is working without his buffering > because the header is sent in a separate transaction from the payload. So > when he does that read(6) it is just grabbing the header transaction and > the next 123 bytes comes in the next transaction. > (These headers and payloads are a protocol on top of USB, not the USB > protocol headers and payloads). The USB subsystem does not do any buffering at all on bulk transfers. When you ask for N bytes the ugen driver goes and asks for the device for N bytes, or up to N bytes if SHORT_XFER is switched on, possibly in multiple transfers, but always a multiple of the packet size on the wire (to avoid missing a short tranfser). Nick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hardware" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020415112318.L36693-100000>