[linux-usb-devel] Serial gadget sending extra characters
I have been testing the g_serial serial gadget with my superh_udc driver on the 2.4.21 kernel. It works when I send data from the host to the device but when I send from the device to the host I get extra characters. Example: device# echo 1234 /dev/ttygs0 host# cat /dev/usb/tts/0 1234 1^ I don't think these extra characters are being introduced by the UDC driver, they seem to be being sent by the g_serial driver, possibly due to some problem with line discipline in the tty driver. Here is some debug output, I can see the 1234 followed by CR/LF being sent but then gs_put_char gets called with the extra characters. There also seems to be a timing issue as when I have really verbose debug the extra characters carry on forever. # echo 1234 /dev/ttygs0 gs_open: (0,8ce7d000,8c1027b0) gs_open: (0,8ce7d000,8c1027b0) completed gs_ioctl: (0,8ce7d000,8c1027b0) cmd=0x5401, arg=2080374064 gs_write_room: (0,8ce7d000) room=8191 gs_flush_chars: (0,8ce7d000) gs_write: (0,8ce7d000) writing 4 bytes gs_send_packet: size=4, 31 gs_write: (0,8ce7d000) wrote 4 bytes gs_write_room: (0,8ce7d000) room=8191 gs_put_char: 0D gs_put_char: 0A gs_flush_chars: (0,8ce7d000) gs_write_room: (0,8ce7d000) room=8189 gs_put_char: 31 gs_flush_chars: (0,8ce7d000) gs_send_packet: size=3, 0D gs_write_room: (0,8ce7d000) room=8191 gs_put_char: 5E gs_flush_chars: (0,8ce7d000) gs_send_packet: size=1, 5E gs_write_room: (0,8ce7d000) room=8191 gs_put_char: 5E gs_flush_chars: (0,8ce7d000) gs_send_packet: size=1, 5E gs_write_room: (0,8ce7d000) room=8191 gs_put_char: 5E gs_flush_chars: (0,8ce7d000) gs_send_packet: size=1, 5E gs_write_room: (0,8ce7d000) room=8191 gs_put_char: 5E gs_flush_chars: (0,8ce7d000) gs_send_packet: size=1, 5E gs_write_room: (0,8ce7d000) room=8191 gs_put_char: 5E gs_flush_chars: (0,8ce7d000) gs_send_packet: size=1, 5E gs_close: (0,8ce7d000,8c1027b0) # I wonder if anyone else has seen anything similar on another platform with another UDC driver? Thanks Julian --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] 2.6.0-t9/cyberjack: might_sleep/copy_from_user
Mahlzeit I am currently testing the cyberJack driver under 2.6.0-test9 and get following message: Debug: sleeping function called from invalid context at include/asm/uaccess.h:498 in_atomic():0, irqs_disabled():1 c011b3c1: __might_sleep+0x91/0xb0 c783c67f: cyberjack_write+0x3df/0x4d0 c784b501: serial_write+0xa1/0x100 ... I suspect, that this might_sleep is the one called in copy_from_user(). Is the problem, that this is called inside a spin_lock_irqsave-section? Do I have to use a local buffer in cyberjack_write, then call the copy_from_user and the start the spin_lock_irqsave-section to copy it into the private data structure? Thanks endergone Zwiebeltuete --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: Serial gadget sending extra characters
Julian -- Julian Back wrote: I have been testing the g_serial serial gadget with my superh_udc driver on the 2.4.21 kernel. It works when I send data from the host to the device but when I send from the device to the host I get extra characters. Example: device# echo 1234 /dev/ttygs0 host# cat /dev/usb/tts/0 1234 1^ I don't think these extra characters are being introduced by the UDC driver, they seem to be being sent by the g_serial driver, possibly due to some problem with line discipline in the tty driver. Here is some debug output, I can see the 1234 followed by CR/LF being sent but then gs_put_char gets called with the extra characters. There also seems to be a timing issue as when I have really verbose debug the extra characters carry on forever. Be sure echo is turned off, use stty -echo /dev/ttyUSB0 on the host side and stty -echo /dev/ttygs0 on the device side. (The device names may not be quite right, I don't have time right now to check.) I have seen similar symptoms caused by each side echoing characters bounce back and forth. I will try to look into this more, but the echo problem is my first guess. -- Al --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.0-t9/cyberjack: might_sleep/copy_from_user
I suspect, that this might_sleep is the one called in copy_from_user(). Is the problem, that this is called inside a spin_lock_irqsave-section? Do I have to use a local buffer in cyberjack_write, then call the copy_from_user and the start the spin_lock_irqsave-section to copy it into the private data structure? Yes. HTH Oliver --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: Serial gadget sending extra characters
Al Borchers wrote: Be sure echo is turned off, use stty -echo /dev/ttyUSB0 on the host side and stty -echo /dev/ttygs0 on the device side. (The device names may not be quite right, I don't have time right now to check.) I have seen similar symptoms caused by each side echoing characters bounce back and forth. Al, Thanks for the reply - you are right, echo is the problem. Julian --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] interrupt endpoint and data loss/overrun
I'm working with two digital cameras - a Sanyo Xacti S1 and a Canon PowerShot A80 - and I'm writing an application to talk to them which uses libusb. Each DSC advertises that the maximum bytecount per transfer on the interrupt endpoint is 8 bytes, so I only read a maximum of 8 bytes at a time from the interrupt endpoint, even though the higher level protocol (PTP) usually sends a total of 16 bytes in a logical interrupt. Having hooked up a USB analyzer between the camera and my Linux system, I see interrupt data on the scope, but I don't always see the data when I read the interrupt endpoint. I've enabled debug in USB for this kernel, and I've cruised the source a little in core/urb.c and core/message.c, but I'm not sure of the best place to add a printk() or two (or otherwise enable more debug output) to see if the interrupt data I'm looking for is being seen by the kernel. Below is the output of dmesg from when I fire up my application and turn on the camera until I turn off the camera. Note that the USBDEVFS_BULK failed messages are instances of timeouts on reads to the interrupt endpoint. What you don't see here (because dmesg doesn't include it) is lots of successful I/O to and from the input, output, and interrupt endpoints. Suggestions? What other information would be useful? Thanks, -Del From dmesg: drivers/usb/host/uhci-hcd.c: 1060: wakeup_hc hub 1-0:1.0: port 2, status 101, change 1, 12 Mb/s hub 1-0:1.0: debounce: port 2: delay 100ms stable 4 status 0x101 hub 1-0:1.0: new USB device on port 2, assigned address 13 usb 1-2: new device strings: Mfr=1, Product=2, SerialNumber=3 drivers/usb/core/message.c: USB device number 13 default language ID 0x409 usb 1-2: Product: SANYO Digital Camera usb 1-2: Manufacturer: SANYO usb 1-2: SerialNumber: 68951222 drivers/usb/core/usb.c: usb_hotplug usb 1-2: registering 1-2:1.0 (config #1, interface 0) drivers/usb/core/usb.c: usb_hotplug drivers/usb/core/usb.c: usbfs driver claimed interface cf9f3d80 usb 1-2: bulk timeout on ep1in usbfs: USBDEVFS_BULK failed dev 13 ep 0x81 len 8 ret -110 usb 1-2: bulk timeout on ep1in usbfs: USBDEVFS_BULK failed dev 13 ep 0x81 len 8 ret -110 usb 1-2: bulk timeout on ep1in usbfs: USBDEVFS_BULK failed dev 13 ep 0x81 len 8 ret -110 usb 1-2: bulk timeout on ep1in usbfs: USBDEVFS_BULK failed dev 13 ep 0x81 len 8 ret -110 usb 1-2: bulk timeout on ep1in usbfs: USBDEVFS_BULK failed dev 13 ep 0x81 len 8 ret -110 usb 1-2: bulk timeout on ep1in usbfs: USBDEVFS_BULK failed dev 13 ep 0x81 len 8 ret -110 usb 1-2: bulk timeout on ep1in usbfs: USBDEVFS_BULK failed dev 13 ep 0x81 len 8 ret -110 usb 1-2: bulk timeout on ep1in usbfs: USBDEVFS_BULK failed dev 13 ep 0x81 len 8 ret -110 usb 1-2: bulk timeout on ep1in usbfs: USBDEVFS_BULK failed dev 13 ep 0x81 len 8 ret -110 usb 1-2: bulk timeout on ep1in usbfs: USBDEVFS_BULK failed dev 13 ep 0x81 len 8 ret -110 usb 1-2: bulk timeout on ep1in usbfs: USBDEVFS_BULK failed dev 13 ep 0x81 len 8 ret -110 usb 1-2: bulk timeout on ep1in usbfs: USBDEVFS_BULK failed dev 13 ep 0x81 len 8 ret -110 usb 1-2: bulk timeout on ep1in usbfs: USBDEVFS_BULK failed dev 13 ep 0x81 len 8 ret -110 usb 1-2: bulk timeout on ep1in usbfs: USBDEVFS_BULK failed dev 13 ep 0x81 len 8 ret -110 hub 1-0:1.0: port 2, status 100, change 3, 12 Mb/s usb 1-2: USB disconnect, address 13 usb 1-2: usb_disable_device nuking all URBs usb 1-2: unregistering interface 1-2:1.0 drivers/usb/core/usb.c: usb_hotplug usb 1-2: unregistering device drivers/usb/core/usb.c: usb_hotplug updfstab: numerical sysctl 1 23 is obsolete. hub 1-0:1.0: port 2 enable change, status 100 drivers/usb/host/uhci-hcd.c: 1060: suspend_hc From linux-2.6.0-test9/.config: 131 lines matching usb in buffer .config. 1106:CONFIG_USB_IRDA=m 1130:CONFIG_BT_HCIUSB=m 1131:CONFIG_BT_USB_SCO=y 1132:# CONFIG_BT_USB_ZERO_PACKET is not set 1426:CONFIG_VIDEO_CPIA_USB=m 1534:# USB support 1536:CONFIG_USB=m 1537:CONFIG_USB_DEBUG=y 1540:# Miscellaneous USB options 1542:CONFIG_USB_DEVICEFS=y 1543:# CONFIG_USB_BANDWIDTH is not set 1544:# CONFIG_USB_DYNAMIC_MINORS is not set 1547:# USB Host Controller Drivers 1549:CONFIG_USB_EHCI_HCD=m 1550:# CONFIG_USB_OHCI_HCD is not set 1551:CONFIG_USB_UHCI_HCD=m 1554:# USB Device Class drivers 1556:CONFIG_USB_AUDIO=m 1559:# USB Bluetooth TTY can only be used with disabled Bluetooth subsystem 1561:CONFIG_USB_MIDI=m 1562:CONFIG_USB_ACM=m 1563:CONFIG_USB_PRINTER=m 1564:CONFIG_USB_STORAGE=m 1565:CONFIG_USB_STORAGE_DEBUG=y 1566:CONFIG_USB_STORAGE_DATAFAB=y 1567:CONFIG_USB_STORAGE_FREECOM=y 1568:CONFIG_USB_STORAGE_ISD200=y 1569:CONFIG_USB_STORAGE_DPCM=y 1570:CONFIG_USB_STORAGE_HP8200e=y 1571:CONFIG_USB_STORAGE_SDDR09=y 1572:CONFIG_USB_STORAGE_SDDR55=y 1573:CONFIG_USB_STORAGE_JUMPSHOT=y 1576:# USB Human Interface Devices (HID) 1578:CONFIG_USB_HID=m 1579:CONFIG_USB_HIDINPUT=y 1581:CONFIG_USB_HIDDEV=y 1584:# USB HID Boot Protocol drivers 1586:#
[linux-usb-devel] Receiving interrupt URBS
Hello all, First, a disclaimer - I am very new to driver development, so please bear with my ignorance. I am trying to write a device driver for a USB U401 from usbmicro.com. The device works by sending a control packet to the device, then receiving an interrupt packet back. I have (I think) the send portion down pat, but I have yet to get the response URB correctly. I am trying to receive the URB by calling usb_fill_int_urb() and then usb_submit_urb() on the URB. I receive a -ENXIO from usb_submit_urb(), and the urb-status found in the callback function is -ENOPIPE. I'm not real sure what additional info I need to send, so please tell me if I need to give more info. Ian -- Ian R. Meinzen [EMAIL PROTECTED] There are many rhymes about magpies, but none of them is very reliable because they are not the ones the magpies know themselves. (Carpe Jugulum) --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: Serial gadget sending extra characters
On Tuesday 11 November 2003 15:20, Al Borchers wrote: host# cat /dev/usb/tts/0 1234 1^ I have seen similar symptoms caused by each side echoing characters bounce back and forth. Yes, that was my guess as well, but his log shows another problem i've been facing as well: Only the first byte of each bulk transfer gets echoed. Why is this? Ciao, Till -- Dr.-Ing. Till Harbaum Tel.: +49 721 4998963 BeeCon GmbH Fax: +49 721 4998962 Haid-und-Neu Strasse 7, 76131 Karlsruhe Mobil: +49 179 9087904 [EMAIL PROTECTED] http://www.beecon.de --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] default 05f9/ffff serial device?
Greg KH wrote: That number is used because it is not a device number of any shipping device. You should not use that device id for your device, as you are not PSC :) I've just pushed new vendor/product ids (0x0525/0xa4a6) into the gadget-2.4 and gadget-2.6 BK trees, at usb-gadget.bkbits.net, so this question shouldn't arise again for the Linux-USB serial gadget. - Dave --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] interrupt endpoint and data loss/overrun
On Tue, 11 Nov 2003, G. Del Merritt wrote: I'm working with two digital cameras - a Sanyo Xacti S1 and a Canon PowerShot A80 - and I'm writing an application to talk to them which uses libusb. Each DSC advertises that the maximum bytecount per transfer on the interrupt endpoint is 8 bytes, so I only read a maximum of 8 bytes at a time from the interrupt endpoint, even though the higher level protocol (PTP) usually sends a total of 16 bytes in a logical interrupt. Having hooked up a USB analyzer between the camera and my Linux system, I see interrupt data on the scope, but I don't always see the data when I read the interrupt endpoint. Do you _always_ see the interrupt data on the scope? That is, is it possible that on the few occasions you can't read it from the interrupt endpoint the camera didn't actually send it? I've enabled debug in USB for this kernel, and I've cruised the source a little in core/urb.c and core/message.c, but I'm not sure of the best place to add a printk() or two (or otherwise enable more debug output) to see if the interrupt data I'm looking for is being seen by the kernel. If it were seen, you would have received it. But if you want to experiment some more, look at usb_hcd_giveback_urb() in drivers/usb/core/hcd.c. Below is the output of dmesg from when I fire up my application and turn on the camera until I turn off the camera. Note that the USBDEVFS_BULK failed messages are instances of timeouts on reads to the interrupt endpoint. What you don't see here (because dmesg doesn't include it) is lots of successful I/O to and from the input, output, and interrupt endpoints. Suggestions? What other information would be useful? Thanks, -Del Is it possible that your timeout is set too short? Your problem reminds me a lot of another one reported last August. See the thread beginning with http://sourceforge.net/mailarchive/message.php?msg_id=5831507 Although the packets were sent to the host, the controller didn't indicate it received anything. We never resolved it -- it's possible that this is a flaw in some UHCI controllers. Alan Stern --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] interrupt endpoint and data loss/overrun
At 12:31 PM 11/11/2003, Alan Stern wrote: On Tue, 11 Nov 2003, G. Del Merritt wrote: I'm working with two digital cameras - a Sanyo Xacti S1 and a Canon PowerShot A80 - and I'm writing an application to talk to them which uses libusb. Each DSC advertises that the maximum bytecount per transfer on the interrupt endpoint is 8 bytes, so I only read a maximum of 8 bytes at a time from the interrupt endpoint, even though the higher level protocol (PTP) usually sends a total of 16 bytes in a logical interrupt. Having hooked up a USB analyzer between the camera and my Linux system, I see interrupt data on the scope, but I don't always see the data when I read the interrupt endpoint. Do you _always_ see the interrupt data on the scope? That is, is it possible that on the few occasions you can't read it from the interrupt endpoint the camera didn't actually send it? I don't have constant/ready access to the analyzer. In all the cases I saw (and captured data), the interrupts were there. I realize that's a little like the tree falling in the woods, though. I've enabled debug in USB for this kernel, and I've cruised the source a little in core/urb.c and core/message.c, but I'm not sure of the best place to add a printk() or two (or otherwise enable more debug output) to see if the interrupt data I'm looking for is being seen by the kernel. If it were seen, you would have received it. But if you want to experiment some more, look at usb_hcd_giveback_urb() in drivers/usb/core/hcd.c. OK. And thanks for this pointer. Below is the output of dmesg from when I fire up my application and turn on the camera until I turn off the camera. Note that the USBDEVFS_BULK failed messages are instances of timeouts on reads to the interrupt endpoint. What you don't see here (because dmesg doesn't include it) is lots of successful I/O to and from the input, output, and interrupt endpoints. Suggestions? What other information would be useful? Thanks, -Del Is it possible that your timeout is set too short? Possible, though it's long in computer-time: 1000ms. Your problem reminds me a lot of another one reported last August. See the thread beginning with http://sourceforge.net/mailarchive/message.php?msg_id=5831507 Although the packets were sent to the host, the controller didn't indicate it received anything. We never resolved it -- it's possible that this is a flaw in some UHCI controllers. Thanks - I'll look at that thread too. I'm still trying to grok the full picture of USB, libusb, and when new vs. generic device drivers are required. And when USB_DEBUG will do something for libusb... -Del --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] 2.6.0-test9 and ALI m5621 IDE-USB converter
Hi, I have a Pioneer DVR-106 drive housed in an external USB housing which uses the ALI m5621 IDE-USB chipset. This connects to the PC via a NEC based USB2.0 PCI card. Whenever I try and burn a DVD the unit fails after a few minutes. I enclose some debug information below - please let me know if you need anymore information. Needless to say, I would be grateful for any help in diagnosing the problem. The same unit works find when used on a machine running windows. Thanks, Steve T: Bus=03 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2 B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0 D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor= ProdID= Rev= 2.06 S: Manufacturer=Linux 2.6.0-test9 ohci_hcd S: Product=OHCI Host Controller S: SerialNumber=:00:0f.1 C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr= 0mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=255ms T: Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 3 B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0 D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor= ProdID= Rev= 2.06 S: Manufacturer=Linux 2.6.0-test9 ohci_hcd S: Product=OHCI Host Controller S: SerialNumber=:00:0f.0 C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr= 0mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=255ms T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 5 B: Alloc= 0/800 us ( 0%), #Int= 0, #Iso= 0 D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS= 8 #Cfgs= 1 P: Vendor= ProdID= Rev= 2.06 S: Manufacturer=Linux 2.6.0-test9 ehci_hcd S: Product=EHCI Host Controller S: SerialNumber=:00:0f.2 C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr= 0mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=256ms T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=0402 ProdID=5621 Rev= 1.05 S: Product=USB 2.0 Storage Device C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr= 0mA I: If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=125us Bus 003 Device 001: ID : Virtual Hub Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass9 Hub bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x Virtual idProduct 0x Hub bcdDevice2.06 iManufacturer 3 Linux 2.6.0-test9 ohci_hcd iProduct2 OHCI Host Controller iSerial 1 :00:0f.1 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 25 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x40 Self Powered MaxPower0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type none wMaxPacketSize 2 bInterval 255 Language IDs: (length=4) 0409 English(US) Bus 002 Device 001: ID : Virtual Hub Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass9 Hub bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x Virtual idProduct 0x Hub bcdDevice2.06 iManufacturer 3 Linux 2.6.0-test9 ohci_hcd iProduct2 OHCI Host Controller iSerial 1 :00:0f.0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 25 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x40 Self Powered MaxPower0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor:
[linux-usb-devel] Philips 1561
Hi all, I am a hardware design Engineer and I am new to USB. I am designing a board which should support a hi-speed(480Mbps) USB host controller. The board will run linux, hence I would be requiring a host controller for which linux driver is available. I found Philips 1561 to suit the requirements but I would like to know whether it has linux support. Please suggest any other hi-speed USB host controllers which linux supports. Thanks, Harishankkar ___ This mail sent using webmail - http://www.mail-online.co.uk Windows 2003 webhosting visit Http://www.fast2host.com Need Broadband Access ? Try http://www.fast2surf.com --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] reuse of urb
I am in the process of writing a device driver for a device which is a combination vacuum flourescent display and ir receiver. The driver is functional, but has some problems. The device has a single configuration, and single interface with 2 endpoints. The endpoints are transfer type interrupt. My open routine allocates 2 urb's (one for each endpoint, in and out) and fills them with usb_fill_int_urb. I have an in callback routine and an out callback routine. I can read ir byte codes from the device and write characters to the display including control codes which position subsequent character writes, clear the display and set brightness. My problem is that I cannot seem to reuse the out urb. When my write_callback routine is called, the urb-status is 0, but another write to the device blocks and the urb-status is thereafter -EINPROGRESS. If in my callback routine I usb_unlink_urb, usb_free_urb and then usb_alloc_urb(0) and re-initialize the structure, everything behaves correctly. After each successful write, I have to release and then re-allocate the out urb. Shouldn't I be able to reuse it? If so, does anyone have any helpful hints as to what might be going on here? -Henry Culver -Culver Consulting [EMAIL PROTECTED] --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Receiving interrupt URBS
On Tue, 11 Nov 2003, Ian R. Meinzen wrote: Hello all, First, a disclaimer - I am very new to driver development, so please bear with my ignorance. I am trying to write a device driver for a USB U401 from usbmicro.com. The device works by sending a control packet to the device, then receiving an interrupt packet back. I have (I think) the send portion down pat, but I have yet to get the response URB correctly. I am trying to receive the URB by calling usb_fill_int_urb() and then usb_submit_urb() on the URB. I receive a -ENXIO from usb_submit_urb(), and the urb-status found in the callback function is -ENOPIPE. I'm not real sure what additional info I need to send, so please tell me if I need to give more info. You didn't say what version of Linux you're running or which host controller driver -- my guess is 2.4.x and one of the UHCI drivers. They return -ENXIO when you try to submit two URBs for the same interrupt endpoint. (Note: when usb_submit_urb() returns an error code, urb-status is meaningless.) If that's what you're doing, it shouldn't be a problem to delay submitting each URB until after the previous one has completed. If you want to see more information, edit the source file for your HCD to leave DEBUG and dbg defined. Alan Stern --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.0-test9 and ALI m5621 IDE-USB converter
On Tue, 11 Nov 2003 [EMAIL PROTECTED] wrote: Hi, I have a Pioneer DVR-106 drive housed in an external USB housing which uses the ALI m5621 IDE-USB chipset. This connects to the PC via a NEC based USB2.0 PCI card. Whenever I try and burn a DVD the unit fails after a few minutes. I enclose some debug information below - please let me know if you need anymore information. Needless to say, I would be grateful for any help in diagnosing the problem. The same unit works find when used on a machine running windows. Thanks, Steve Nov 10 19:59:25 shaun kernel: usb-storage: -- transport indicates command failure Nov 10 19:59:25 shaun kernel: usb-storage: Not Ready: Logical unit not ready, long write in progress These errors are normal. The WRITEs are reissued and go through okay. The real problem occurs at the end of your debugging log: Nov 10 19:59:25 shaun kernel: usb-storage: usb_stor_bulk_transfer_sglist: xfer 63488 bytes, 2 entries Nov 10 19:59:25 shaun kernel: usb 1-1: sg_complete, unlink -- -19 Nov 10 20:01:05 shaun kernel: usb-storage: command_abort called Nov 10 20:01:05 shaun kernel: usb-storage: usb_stor_stop_transport called Nov 10 20:01:05 shaun kernel: usb-storage: -- cancelling sg request For all the world it looks like your USB connection has gone dead, except that there's no disconnection notification in the log. It would be interesting to see what happened next; the log shouldn't have stopped there. Someone who is more familiar with the EHCI controller may be able to suggest more things to try. Alan Stern --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] reuse of urb
On Tue, 11 Nov 2003, Henry Culver wrote: I am in the process of writing a device driver for a device which is a combination vacuum flourescent display and ir receiver. The driver is functional, but has some problems. The device has a single configuration, and single interface with 2 endpoints. The endpoints are transfer type interrupt. My open routine allocates 2 urb's (one for each endpoint, in and out) and fills them with usb_fill_int_urb. I have an in callback routine and an out callback routine. I can read ir byte codes from the device and write characters to the display including control codes which position subsequent character writes, clear the display and set brightness. My problem is that I cannot seem to reuse the out urb. When my write_callback routine is called, the urb-status is 0, but another write to the device blocks and the urb-status is thereafter -EINPROGRESS. If in my callback routine I usb_unlink_urb, usb_free_urb and then usb_alloc_urb(0) and re-initialize the structure, everything behaves correctly. I don't understand. What do you mean another write to the device blocks? If the write blocked, how would you know what urb-status was afterwards? -- your machine would be locked up. After submission, usb-status is _supposed_ to be -EINPROGRESS; it stays that value more or less until it has completed. After each successful write, I have to release and then re-allocate the out urb. Shouldn't I be able to reuse it? If so, does anyone have any helpful hints as to what might be going on here? You certainly should be able to reuse it. What version of Linux and which host controller driver are you using? If you aren't using 2.6, try it out and see if it works any better. Alan Stern --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] reuse of urb
On Tue, 2003-11-11 at 15:23, Alan Stern wrote: On Tue, 11 Nov 2003, Henry Culver wrote: I am in the process of writing a device driver for a device which is a combination vacuum flourescent display and ir receiver. The driver is functional, but has some problems. The device has a single configuration, and single interface with 2 endpoints. The endpoints are transfer type interrupt. My open routine allocates 2 urb's (one for each endpoint, in and out) and fills them with usb_fill_int_urb. I have an in callback routine and an out callback routine. I can read ir byte codes from the device and write characters to the display including control codes which position subsequent character writes, clear the display and set brightness. My problem is that I cannot seem to reuse the out urb. When my write_callback routine is called, the urb-status is 0, but another write to the device blocks and the urb-status is thereafter -EINPROGRESS. If in my callback routine I usb_unlink_urb, usb_free_urb and then usb_alloc_urb(0) and re-initialize the structure, everything behaves correctly. I don't understand. What do you mean another write to the device blocks? If the write blocked, how would you know what urb-status was afterwards? -- your machine would be locked up. After submission, usb-status is _supposed_ to be -EINPROGRESS; it stays that value more or less until it has completed. Sorry for the missing details. It's linux-2.4.21. When I say it blocks I mean that I call interruptible_sleep_on in the write routine and wake_up in the write_callback routine. If I remove the interruptible_sleep_on, the write never seems to finish (the status never changes from EINPROGRESS and the data never appears on the display). That is to say, the write_callback doesn't get called for the 2nd write. As near as I can tell the 2nd urb is never finishing. My next step I guess is to printk the various fields in the urb and see exactly how a new urb is different from a used one. After each successful write, I have to release and then re-allocate the out urb. Shouldn't I be able to reuse it? If so, does anyone have any helpful hints as to what might be going on here? You certainly should be able to reuse it. What version of Linux and which host controller driver are you using? If you aren't using 2.6, try it out and see if it works any better. Alan Stern Thanks, -Henry Culver -Culver Consulting --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.0-test9 and ALI m5621 IDE-USB converter
Alan, Thanks for taking timeout to reply. SNIP For all the world it looks like your USB connection has gone dead, except that there's no disconnection notification in the log. It would be interesting to see what happened next; the log shouldn't have stopped there. That's the final entry in the log. The dvdrecord process freezes and no further usb debug was recorded during the next 24 hours (at which point I rebooted the machine). Someone who is more familiar with the EHCI controller may be able to suggest more things to try. Yes, please! Thanks, Steve. - Email provided by http://www.ntlhome.com/ --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] reuse of urb
Replying to my own post ... I've found a way to make my code work without having to deallocate / reallocate the urb. It seems that after a successful call, urb-dev is getting set to 0. In my write_callback routine I simply re-set urb-dev to its correct value (which is stored in the private device structure) and the subsequent calls using that urb are fine. I haven't found anything in my code that could be stepping on it, but I guess I'm not quite ready to rule that possibility out yet either. On Tue, 2003-11-11 at 15:59, Henry Culver wrote: On Tue, 2003-11-11 at 15:23, Alan Stern wrote: On Tue, 11 Nov 2003, Henry Culver wrote: I am in the process of writing a device driver for a device which is a combination vacuum flourescent display and ir receiver. The driver is functional, but has some problems. The device has a single configuration, and single interface with 2 endpoints. The endpoints are transfer type interrupt. My open routine allocates 2 urb's (one for each endpoint, in and out) and fills them with usb_fill_int_urb. I have an in callback routine and an out callback routine. I can read ir byte codes from the device and write characters to the display including control codes which position subsequent character writes, clear the display and set brightness. My problem is that I cannot seem to reuse the out urb. When my write_callback routine is called, the urb-status is 0, but another write to the device blocks and the urb-status is thereafter -EINPROGRESS. If in my callback routine I usb_unlink_urb, usb_free_urb and then usb_alloc_urb(0) and re-initialize the structure, everything behaves correctly. I don't understand. What do you mean another write to the device blocks? If the write blocked, how would you know what urb-status was afterwards? -- your machine would be locked up. After submission, usb-status is _supposed_ to be -EINPROGRESS; it stays that value more or less until it has completed. Sorry for the missing details. It's linux-2.4.21. When I say it blocks I mean that I call interruptible_sleep_on in the write routine and wake_up in the write_callback routine. If I remove the interruptible_sleep_on, the write never seems to finish (the status never changes from EINPROGRESS and the data never appears on the display). That is to say, the write_callback doesn't get called for the 2nd write. As near as I can tell the 2nd urb is never finishing. My next step I guess is to printk the various fields in the urb and see exactly how a new urb is different from a used one. After each successful write, I have to release and then re-allocate the out urb. Shouldn't I be able to reuse it? If so, does anyone have any helpful hints as to what might be going on here? You certainly should be able to reuse it. What version of Linux and which host controller driver are you using? If you aren't using 2.6, try it out and see if it works any better. Alan Stern Thanks, -Henry Culver -Culver Consulting --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Receiving interrupt URBS
Alan Stern wrote: On Tue, 11 Nov 2003, Ian R. Meinzen wrote: Hello all, First, a disclaimer - I am very new to driver development, so please bear with my ignorance. I am trying to write a device driver for a USB U401 from usbmicro.com. The device works by sending a control packet to the device, then receiving an interrupt packet back. I have (I think) the send portion down pat, but I have yet to get the response URB correctly. I am trying to receive the URB by calling usb_fill_int_urb() and then usb_submit_urb() on the URB. I receive a -ENXIO from usb_submit_urb(), and the urb-status found in the callback function is -ENOPIPE. I'm not real sure what additional info I need to send, so please tell me if I need to give more info. You didn't say what version of Linux you're running or which host controller driver -- my guess is 2.4.x and one of the UHCI drivers. They return -ENXIO when you try to submit two URBs for the same interrupt endpoint. (Note: when usb_submit_urb() returns an error code, urb-status is meaningless.) If that's what you're doing, it shouldn't be a problem to delay submitting each URB until after the previous one has completed. If you want to see more information, edit the source file for your HCD to leave DEBUG and dbg defined. Alan Stern Sorry, I should have put at least that in. I'm running 2.4.22 with the usb-uhci driver. Should I get a -ENXIO on the first urb submitted, though? I don't submit any urbs before a read/write/ioctl, and I am getting an error on the first read, when the urb is first submitted. The device returns an interrupt urb when it receives the the control urb. Does the receipt urb need to be submitted BEFORE the control urb? -- Ian R. Meinzen [EMAIL PROTECTED] You know what I'd really, really like? What I'd pay MONEY for? A ZX81 with a disc drive. I *understood* the ZX81. It was so easy to interface stuff to it. (alt.fan.pratchett) --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
