hi gergely i can't answer your next emails befor the 11. october due to holidays :-) > I'm a user too, and and not a kernel hacker - yet. I'm asking because > I want to help fixing it, not just wait for a patch that will or will > not arrive. If there are a dozen people with the same issues, one > writes to the list while the others just sit around reading it and > don't make their voices heard, how the knowledgeable developers would > know what issues are important for more people? > I do apologize if it was a duplicate. I wrote it after reading the > archive because I thought I have sufficient extra information to > contribute. your first message suggested that you thought you are the first one with this problem. thats why i pointed to the mailinglist archive. your bug reporting was fine, at least from my point of view. you tested and reported different things than me. mainly because i reported the first errors i've seen and left the others away. for me to make sure i report in a usable style for the kernel developers. it makes sense to ask again after some time, if there is progress :-) > > as i know, this works also with the agilent driver. i testet a lot > > sending big amount of data to the tmc device (>500mbyte). with tmc > > reads i haven't seen some 1024 byte limits. > > Have you tested anything like this with the kernel driver? And I was > reading _from_ the device, not sending to it, so it might be > different. What device do you use? I couldn't see it in your message. yes. i'm not sure anymore about the result. i think it was possible to send a big bunch of data to a device. but always after reading a response i had to send a usbtmc clear control command to set the driver and the device back. my testing ended more or less, when i saw that the basics are broken. for testing i use a agilent arbitary frequency generator (thats my "reference" it has his own non standard behaviour). my main work is to develop a opensource firmware for a cypress fx2 where we use usb-dfu and usbtmc as device classes: http://labs.ti.bfh.ch/gecko/wiki/systems/gecko3com/start fortunately in our project we don't need interrupt endpoint support (for *opc? command with overlapped commands) as it is described in the usbtmc usb488 subclass. Andrew Lutomirski asked usb488 support (interrupt handling) here on the list. in future this is clearly needed. all the best, christoph-- 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
