(Please CC me on replies as I'm not a subscriber) I'm trying to get working a Freecom DVB-T USB stick (ID 14aa:0225) on an embedded MIPS board; it works with an x86 PC, and I've tested it on more MIPS boards and even with other DVB-T sticks, while most other peripherals are ok. I initially thought of portability problems in the driver, but after some analysis (I'm not an USB expert but I'm comfortable with kernel sources) and reading this thread (on this ML):
http://www.spinics.net/lists/usb/msg07868.html it seems a problem in the USB controller. Can somebody please help me with solving this problem? == STEPS TO REPRODUCE == I plug the stick, load the firmware, run the scan (or dvbscan) utility, and the stick is abruptly disconnected by the controller (see below) after the DVBT driver sends a certain command (for reference, the driver is drivers/media/dvb/dvb-usb/dvb-usb-dtt200u.ko). I think this command requires the stick to something "unusual", because most other USB devices work fine (both high speed and low speed devices do work, while both high speed and low speed DVBT sticks do not). I've applied the patch in that mail to a 2.6.22.4 kernel (it applied fine); it did not solve the problem, and moreover I see various instances of "Start ASS: 8000" (and I was using 2050 as timeout, not 500 as suggested by subsequent email !). So I fear an hardware problem is involved, but I hope it is possible to workaround it. == LOGS == Some logs are attached, I can give you any detail you want (I read that thread so most things are already included). First, an excerpt of dmesg without USB debugging (with only some DVBT debugging parameters enabled). The '>>>' lines are commands sent to the USB stick by the DVBT driver (see functions drivers/media/dvb/dvb-usb/dvb-usb-urb.c:dvb_usb_generic_write,dvb_usb_generic_rw). [ 5385.970875] function : dvb_dmxdev_filter_set [ 5385.971851] start pid: 0x0000, feedtype: 1 [ 5385.972828] setting pid (yes): 0 0000 at index 0 'on' [ 5385.973804] >>> 04 00 00 00 This is caused by drivers/media/dvb/dvb-usb/dtt200u.c:dtt200u_pid_filter(). [ 5385.979664] submitting all URBs [ 5385.980640] submitting URB no. 0 [ 5385.981617] submitting URB no. 1 [ 5385.982593] submitting URB no. 2 [ 5385.983570] submitting URB no. 3 [ 5385.984547] submitting URB no. 4 [ 5385.985523] submitting URB no. 5 [ 5385.986500] submitting URB no. 6 [ 5385.987476] controlling pid parser [ 5385.988453] start feeding [ 5385.989429] >>> 08 01 This is caused by dtt200u_streaming_ctrl(). Every time I test this, this is the last command sent before disconnection. I'm curious about why this command causes problems - what unusual feature of the USB standard is the pen now going to use? [ 5385.991382] usb 1-2: USB disconnect, address 3 Below there is an excerpt of dmesg around the disconnection. You can note the "Start ASS: 8000" (which is abnormal) in the output. '>> 08 01' is missing, but I bet it is a problem of busybox syslogd, since it is still shown in usbmon output. [ 582.762396] >>> 81 //81 is drivers/media/dvb/dvb-usb/dtt200u.h:GET_TUNE_STATUS, which is sent periodically during the tuning. [ 582.763373] Start ASS: 8000 [ 582.764350] <<< 01 c8 0a [ 582.778998] End ASS: 8000 [ 582.787787] >>> 81 [ 582.788764] Start ASS: 8000 [ 582.789740] <<< 01 c8 0a [ 582.792670] >>> 81 [ 582.800482] function : dvb_dmxdev_filter_set [ 582.801459] >>> 04 00 00 00 //The command sent by dtt200u_pid_filter() // >> 08 01 is lost here [ 582.817084] ehci_hcd 0000:00:01.2: fatal command 010038 (park)=0 ithresh=1 Async Periodic period=256 HALT [ 582.817084] ehci_hcd 0000:00:01.2: fatal status e008 Async Periodic Recl FLR [ 582.817084] hub 1-0:1.0: state 7 ports 4 chg 0000 evt 0004 [ 582.817084] ehci_hcd 0000:00:01.2: GetStatus port 2 status 00100a POWER sig=se0 PEC CSC [ 582.817084] hub 1-0:1.0: port 2, status 0100, change 0003, 12 Mb/s [ 582.817084] usb 1-2: USB disconnect, address 8 [ 582.818060] usb 1-2: unregistering device [ 582.818060] usb 1-2: usb_disable_device nuking all URBs [ 582.818060] usb 1-2: unlink qh64-0001/a11f7200 start 63 [2/0 us] [ 582.818060] ehci_hcd 0000:00:01.2: shutdown urb 80941780 pipe 40410880 ep2in-intr [ 582.818060] ehci_hcd 0000:00:01.2: shutdown urb 80941c80 pipe c0030880 ep6in-bulk [ 582.818060] ehci_hcd 0000:00:01.2: shutdown urb 80941880 pipe c0030880 ep6in-bulk [ 582.818060] ehci_hcd 0000:00:01.2: shutdown urb 80941d00 pipe c0030880 ep6in-bulk [ 582.818060] ehci_hcd 0000:00:01.2: shutdown urb 80941300 pipe c0030880 ep6in-bulk [ 582.818060] ehci_hcd 0000:00:01.2: shutdown urb 80941380 pipe c0030880 ep6in-bulk [ 582.818060] ehci_hcd 0000:00:01.2: shutdown urb 80941400 pipe c0030880 ep6in-bulk [ 582.818060] ehci_hcd 0000:00:01.2: shutdown urb 80941600 pipe c0030880 ep6in-bulk [ 582.818060] usb 1-2: unregistering interface 1-2:1.0 [ 582.826850] function : dvb_dmxdev_filter_set [ 582.827826] End ASS: 8000 The same sequence captured with usbmon: 80941a00 1411074662 S Bo:008:01 -150 4 = 04000000 //this corresponds to [ 582.801459] >>> 04 00 00 00, -150 should be meaningless, here and below according to Documentation/usb/usbmon.txt since this is a submission 80941a00 1411074905 C Bo:008:01 0 4 > 80941c80 1411077030 S Bi:008:06 -150 4096 < 80941880 1411077206 S Bi:008:06 -150 4096 < 80941d00 1411077309 S Bi:008:06 -150 4096 < 80941300 1411077410 S Bi:008:06 -150 4096 < 80941380 1411077510 S Bi:008:06 -150 4096 < 80941400 1411077611 S Bi:008:06 -150 4096 < 80941600 1411077711 S Bi:008:06 -150 4096 < 80941a00 1411081373 S Bo:008:01 -150 2 = 0801 //this corresponds to >> 08 01, as I said 80941a00 1411090027 C Bo:008:01 0 2 > 811faf00 1411090345 C Ii:001:01 0 1 D 811faf00 1411090360 S Ii:001:01 -150 4 < 80941d80 1411090442 S Ci:001:00 s a3 00 0000 0002 0004 4 < 80941d80 1411090517 C Ci:001:00 0 4 = 00010300 80941d80 1411090530 S Co:001:00 s 23 01 0010 0002 0000 0 80941d80 1411090537 C Co:001:00 0 0 80941d80 1411090542 S Co:001:00 s 23 01 0011 0002 0000 0 80941d80 1411090547 C Co:001:00 0 0 811faf00 1411096619 C Ii:001:01 0 1 D 811faf00 1411096625 S Ii:001:01 -150 4 < // -143 is -ESHUTDOWN on MIPS, so the below lines are (IMHO) when those 6 URBs are shutdown after the disconnect. Note that the ID in the first column appear also elsewhere, both in usbmon above and in dmesg output. The 80941780 URB is active since the very beginning (when the firmware is sent, I think). 80941780 1411096860 C Ii:008:02 -143 0 80941c80 1411097416 C Bi:008:06 -143 0 80941880 1411097425 C Bi:008:06 -143 0 80941d00 1411097431 C Bi:008:06 -143 0 80941300 1411097436 C Bi:008:06 -143 0 80941380 1411097442 C Bi:008:06 -143 0 80941400 1411097447 C Bi:008:06 -143 0 80941600 1411097458 C Bi:008:06 -143 0 The content of files for the USB controller to which the pendrive is attached: # for i in /sys/class/usb_host/usb_host1/*; do [ -f $i -a -r $i ] && { echo $i; cat $i; }; done /sys/class/usb_host/usb_host1/async /sys/class/usb_host/usb_host1/companion /sys/class/usb_host/usb_host1/periodic size = 256 /sys/class/usb_host/usb_host1/registers bus pci, device 0000:00:01.2 (driver 10 Dec 2004) EHCI Host Controller EHCI 1.00, hcd state 1 ownership 00000001 SMI sts/enable 0xc0080000 structural params 0x00002204 capability params 0x00006872 status 0008 FLR command 010009 (park)=0 ithresh=1 period=256 RUN intrenable 37 IAA FATAL PCD ERR INT uframe 2bae port 1 status 001000 POWER sig=se0 port 2 status 001000 POWER sig=se0 port 3 status 001000 POWER sig=se0 port 4 status 001000 POWER sig=se0 irq normal 280608 err 3713 reclaim 2359 (lost 1553) complete 5774 unlink 8 /sys/class/usb_host/usb_host1/uevent After the stick is disconnected by the controller, registers stops changing and the content is the following: bus pci, device 0000:00:01.2 (driver 10 Dec 2004) EHCI Host Controller EHCI 1.00, hcd state 1 ownership 00000001 SMI sts/enable 0xc0080000 structural params 0x00002204 capability params 0x00006872 status 3008 Recl Halt FLR command 010008 (park)=0 ithresh=1 period=256 HALT intrenable 37 IAA FATAL PCD ERR INT uframe 11fc port 1 status 001000 POWER sig=se0 port 2 status 001801 POWER sig=j CONNECT port 3 status 001000 POWER sig=se0 port 4 status 001000 POWER sig=se0 irq normal 283803 err 3714 reclaim 2923 (lost 1848) complete 7254 unlink 10 in this status, I cannot connect any high-speed device to any USB port, while I can connect low-speed devices (a USB mouse was successfully recognized). It is the first time I see this, all other times I could unplug the stick and retest it; unfortunately, the ehci driver is statically linked in the kernel so I cannot retest unloading and reloading the kernel module (I've hit oops in the past with ehci_hcd as a module when using usbmon, with a 2.6.20 kernel). === THE BOARD I USED === The system is a 32bit little-endian system, so common portability issues cannot happen - I've seen that this box supports DMA_NONCOHERENT, but it should not be a problem unless the driver uses the noncoherent API (and I assume they do not). I'm using a modified version of the TX4938. >From Kconfig - config features supported by this board: HAVE_STD_PC_SERIAL_PORT DMA_NONCOHERENT GENERIC_ISA_DMA HAS_TXX9_SERIAL HW_HAS_PCI I8259 ISA SWAP_IO_SPACE SYS_HAS_CPU_TX49XX SYS_SUPPORTS_32BIT_KERNEL SYS_SUPPORTS_LITTLE_ENDIAN SYS_SUPPORTS_BIG_ENDIAN SYS_SUPPORTS_KGDB GENERIC_HARDIRQS_NO__DO_IRQ >From .config - some USB settings (including disabled experimental items) you may want to see: # # USB support # CONFIG_USB_ARCH_HAS_HCD=y CONFIG_USB_ARCH_HAS_OHCI=y CONFIG_USB_ARCH_HAS_EHCI=y CONFIG_USB=y CONFIG_USB_DEBUG=y # # Miscellaneous USB options # CONFIG_USB_DEVICEFS=y # CONFIG_USB_DEVICE_CLASS is not set # CONFIG_USB_DYNAMIC_MINORS is not set # CONFIG_USB_OTG is not set # # USB Host Controller Drivers # CONFIG_USB_EHCI_HCD=y # CONFIG_USB_EHCI_SPLIT_ISO is not set # CONFIG_USB_EHCI_ROOT_HUB_TT is not set # CONFIG_USB_EHCI_TT_NEWSCHED is not set # CONFIG_USB_EHCI_BIG_ENDIAN_MMIO is not set # CONFIG_USB_ISP116X_HCD is not set # CONFIG_USB_OHCI_HCD is not set CONFIG_USB_UHCI_HCD=y # CONFIG_USB_SL811_HCD is not set Bye and thanks in advance for any help -- Paolo 'Blaisorblade' Giarrusso ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Linux-usb-users@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-users
