On Mon, Aug 03, 2009 at 05:49:09PM -0400, Andrew Lutomirski wrote: > On Mon, Aug 3, 2009 at 5:20 PM, Greg KH<greg@xxxxxxxxx> wrote: > > On Mon, Aug 03, 2009 at 05:14:56PM -0400, Andrew Lutomirski wrote: > >> Hi all- > >> > >> I'm trying to use usbtmc on an Aglient N9310A (The only TMC device I > >> have), and it sort of works, but it seems to be both extremely buggy > >> and missing a good deal of rather important functionality. Is there > >> anyone maintaining it? > > > > Yes, me. > > > >> If the answer is yes, I can describe the bugs (logspam, spurious > >> errors, delayed messages, inability to read status, etc.) in greater > >> detail. > > > > Please do, but also please use the latest version, in 2.6.30.3, we fixed > > some bad problems in it recently. > > I am. > > Almost anything I do triggers this: > > usbtmc 3-1:1.0: Unable to read data, error -110 > > The easiest way is to write something that wasn't a query and then try > to read. Of course, the read should fail, but there's no reason it > should spam the logs. Ok, care to send a patch reducing the error level of the message? > On occasion, sending garbage to the device will cause even a > subsequent USBTMC_IOCTL_CLEAR to fail with ETIMEDOUT. (Maybe I wanted > USBTMC_IOCTL_ABORT_BULK_IN? That seems wrong, though, since > presumably the driver should manage pending Bulk-IN requests on its > own.) Possibly, although I don't know the protocol for what should happen when sending garbage to devices, except that it is probably undefined :) > On other occasions (usually triggered by sending a garbage command, > but, when this happens, the problem persists across several messages), > every response will be delayed. That is, if I send a query, I get > back the previous query's answer or ETIMEDOUT if the previous command > wasn't a query. This persists across closing and reopening the > device. > > Sometimes write() fails with ETIMEDOUT. This failure happens with no > perceivable delay and I have no idea why. Device problems? > An ioctl for GET_CAPABILITIES would be nice, but is not mandatory. What's wrong with the sysfs file for this instead? > Finally, I see no way to read the USB488 status byte or detect a > status interrupt. Hm, is this in the spec somewhere that I missed? Patches are always welcome. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
