Hide Forgot
Description of problem: The system continously loops trying to load the streamzap module. The /var/log/messages file contains the repeating messages: Mar 26 11:46:17 ecube kernel: [ 1730.527149] usb 6-1: USB disconnect, address 50 Mar 26 11:46:17 ecube kernel: [ 1730.536102] streamzap 6-1:1.0: urb terminated, status: -108 Mar 26 11:46:17 ecube kernel: [ 1730.788118] usb 6-1: new low speed USB device using ohci_hcd and address 51 Mar 26 11:46:17 ecube kernel: [ 1730.947151] usb 6-1: New USB device found, idVendor=0e9c, idProduct=0000 Mar 26 11:46:17 ecube kernel: [ 1730.954987] usb 6-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 Mar 26 11:46:17 ecube kernel: [ 1730.964535] usb 6-1: Product: Streamzap Remote Control Mar 26 11:46:17 ecube kernel: [ 1730.973990] usb 6-1: Manufacturer: Streamzap, Inc. Mar 26 11:46:17 ecube kernel: [ 1730.993158] Registered IR keymap rc-streamzap Mar 26 11:46:17 ecube kernel: [ 1731.001082] input: Streamzap PC Remote Infrared Receiver (0e9c:0000) as /devices/pci0000:00/0000:00:13.1/usb6/6-1/6-1:1.0/rc/rc49/input54 Mar 26 11:46:17 ecube kernel: [ 1731.009094] rc49: Streamzap PC Remote Infrared Receiver (0e9c:0000) as /devices/pci0000:00/0000:00:13.1/usb6/6-1/6-1:1.0/rc/rc49 Mar 26 11:46:17 ecube kernel: [ 1731.011515] rc rc49: lirc_dev: driver ir-lirc-codec (streamzap) registered at minor = 1 Mar 26 11:46:17 ecube kernel: [ 1731.019534] streamzap 6-1:1.0: Registered Streamzap, Inc. Streamzap Remote Control on usb6:51 Mar 26 11:46:17 ecube mtp-probe: checking bus 6, device 51: "/sys/devices/pci0000:00/0000:00:13.1/usb6/6-1" Mar 26 11:46:17 ecube kernel: [ 1731.060508] usb 6-1: USB disconnect, address 51 Mar 26 11:46:17 ecube kernel: [ 1731.069100] streamzap 6-1:1.0: urb terminated, status: -108 Mar 26 11:46:17 ecube mtp-probe: bus: 6, device: 51 was not an MTP device Until I unplug the USB cable. Version-Release number of selected component (if applicable): Streamzap model USBIR2 How reproducible: Repeats whenever the cable is connected. Steps to Reproduce: 1. Plug in the streamzap cable 2. 3. Actual results: Expected results: The device should work. It works under Ubuntu Maverick, SuSE 11.4, Debian Squeeze, and Fedora 14 on the same computer. Additional info:
Which kernel were you using? Please post the output of the 'uname -r' command so we can see the version and architecture.
# uname -a Linux ecube.site 2.6.38-1.fc15.x86_64 #1 SMP Tue Mar 15 05:29:00 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux I'm using a AMD Phenom(tm) II X6 1045T Processor
You could try the 2.6.38.1-6 kernel from updates-testing.
The 2.6.38.1-6 kernel gives the same results.
What the heck is this MTP thing? Not finding the string mtp-probe anywhere in the kernel source, nor any evidence of the MTP error messages you're seeing. Are you running any out-of-tree code here?
Its been pointed out to me that those messages actually come from libmtp, whatever that is. Googling around suggests that similar problems abound with all sorts of devices. Pretty sure this is libmtp's fault, reassigning bug accordingly.
Yes libmtp probes all devices with a custom device class to see if it is an MTP device. And it outputs messages to the syslog, which is what /var/messages is. If you want a pure kernel log use dmesg... Anyway: libmtp just reports that the device was probed and found not to be an MTP device, and right above it is recognized as an input device so what is the problem? Do you want me to patch libmtp's mtp-probe program so that it does not print to syslog or...? Please provide lsusb -v for this device so we know more about it, I would prefer to avoid probing it if possible.
Created attachment 488860 [details] lsusb -v output for streamzap device I have attached the output of lsusb -v. I did it from Ubuntu 10.10, since leaving the device plugged in (under fedora 15 alpha) for any amount of time causes my display to end up in a unreadable state. But, no matter what, shouldn't the udev handler prevent the mtpprobe from leaving the system in a hard module load/unload loop, irrespective of its output.
I see. I kicked a build of 1.0.6-2 that avoid probing anonymous devices with != 3 endpoints, since that is what MTP devices should have. Please say if this helps, it might even be the initial libusb open() command that disturbs the device, in that case I will need to add a blacklist, so feedback is much appreciated!
After the upgrade, and convincing selinux to let someone log into the system, the udev problem of trying to repeatively load the streamzap module no longer happened. The module was loaded, but did not work.
Great, I don't think libmtp is responsible for the selinux or input module problems, so closing...
Created attachment 490268 [details] New section of /var/log/messages
libmpm and selinux are not really part of the bug being reported. Even after a kernel update, I again have the problem. See the attached section of /var/log/messages. The streamzap driver does not work. Udev choosing to repeatedly load and unload the driver is another symptom which might be handled better. Ubuntu 10.04 seems to work fine using the same 2.6.38 upstream kernel. (It of course has its own issues elsewhere.) I could file a new bug if you like.
I did a update April 8, 2011 and a SELinux relabeling. Now things seem to work correctly.