Thanks Greg and Pete for the replies. As far as I can see, the device is working properly in both bulk and iso mode, as I managed to write a simular driver for the (sorry to mention) windows os. But things are getting allong now on Linux as well.
Sorry for being a noob, but I didn't realize that a kmalloc > 8K failed. I guess thats why my initial buffer allocation fo 128K is causing the problems and the deallocation is causing the panic. I'll take a closer look at it and add extra checks. Last night I encountered a website mentioning that USB2 devices might need multiple bulk URB's queued to get a constant stream of data. Maybe that's why the bulk transfers won't get through. I'll sort it out and post the results back on the list. Thanks anyway for the suggestions and a happy Easter. -- Paul ________________________________________________________________________ Clinical Science Systems Ter Weerlaan 58 2241 VC Wassenaar Tel. : +31 (0)70 514 21 06 GSM : +31 (0)6 110 44 725 URL : http://www.clinicalsciencesystems.com E-mail : [EMAIL PROTECTED] Op vrijdag 25 maart 2005 19:09, schreef Pete Zaitcev: > On Thu, 24 Mar 2005 16:37:21 +0100 Paul Koster <[EMAIL PROTECTED]> wrote: > > When I disable the iso URB submitting, the bulk works well for > > about 2 minutes. Unloading the > > driver results most of the time in kernel panics, but only when I > > actively used the driver in a open/close session. > > I don't know much about ISO, but the above was mildly interesting. > But I gave up reading pretty quickly. Took me 30 seconds to reach > > this part: > > static ssize_t fusbi_read(struct file *file, char *buffer, size_t count, > > loff_t *ppos) > > { > > char* temp_buffer = NULL; > > > > // Allocate temporary buffer > > temp_buffer = kmalloc(count, GFP_KERNEL); > > > > // Read from user buffer > > true_count = fusbi_dequeue_buffer(dev, temp_buffer, count); > > } > > Dude, you do realize that anything above 8K has NO chance to work? > The kmalloc will always fail (unchecked). > > This is hideous, too: > > case -EOVERFLOW: { > // This error occurs when a read request reads less bytes than > the buffer > contains. > // We use this option to determine the protocol packetlength > (byte 3) and > read the whole packet. > if(dev->bulk_recv_buffer[0] == 0xAA && dev->bulk_recv_buffer[1] > == 0xAA) > read_size = dev->bulk_recv_buffer[2] * 2 + 6; > else > read_size = 3; > break; > } > > Hardware designers strike! The length is 518 bytes at most (+3 bytes > header). Would it be too hard to read that much always, and therminate > the URB with short read? > > I think it's duff hardware. But the driver not being too pretty is not > helping things either. > > -- Pete > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > [email protected] > To unsubscribe, use the last form field at: > https://lists.sourceforge.net/lists/listinfo/linux-usb-devel ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
