Red Hat Bugzilla – Bug 691108
streamzap driver fails during load
Last modified: 2011-04-08 14:23:02 EDT
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
Repeats whenever the cable is connected.
Steps to Reproduce:
1. Plug in the streamzap cable
The device should work. It works under Ubuntu Maverick, SuSE 11.4,
Debian Squeeze, and Fedora 14 on the same computer.
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 220.127.116.11-6 kernel from updates-testing.
The 18.104.22.168-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
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
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.