Bug 691108 - streamzap driver fails during load
streamzap driver fails during load
Product: Fedora
Classification: Fedora
Component: libmtp (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Linus Walleij
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2011-03-26 15:37 EDT by Barry Fishman
Modified: 2011-04-08 14:23 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2011-04-02 06:25:13 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
lsusb -v output for streamzap device (1.67 KB, text/plain)
2011-03-30 14:19 EDT, Barry Fishman
no flags Details
New section of /var/log/messages (4.84 KB, text/plain)
2011-04-06 09:09 EDT, Barry Fishman
no flags Details

  None (edit)
Description Barry Fishman 2011-03-26 15:37:59 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

How reproducible:

Repeats whenever the cable is connected.

Steps to Reproduce:
1. Plug in the streamzap cable
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:
Comment 1 Chuck Ebbert 2011-03-26 17:08:26 EDT
Which kernel were you using? Please post the output of the 'uname -r' command so we can see the version and architecture.
Comment 2 Barry Fishman 2011-03-26 17:46:01 EDT
# 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
Comment 3 Chuck Ebbert 2011-03-27 01:13:10 EDT
You could try the kernel from updates-testing.
Comment 4 Barry Fishman 2011-03-27 20:01:27 EDT
The kernel gives the same results.
Comment 5 Jarod Wilson 2011-03-28 11:00:26 EDT
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?
Comment 6 Jarod Wilson 2011-03-28 11:07:07 EDT
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.
Comment 7 Linus Walleij 2011-03-30 12:32:25 EDT
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.
Comment 8 Barry Fishman 2011-03-30 14:19:42 EDT
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
Comment 9 Linus Walleij 2011-03-31 19:11:12 EDT
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!
Comment 10 Barry Fishman 2011-04-01 12:44:45 EDT
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.
Comment 11 Linus Walleij 2011-04-02 06:25:13 EDT
Great, I don't think libmtp is responsible for the selinux or input module
problems, so closing...
Comment 12 Barry Fishman 2011-04-06 09:09:28 EDT
Created attachment 490268 [details]
New section of /var/log/messages
Comment 13 Barry Fishman 2011-04-06 09:11:58 EDT
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.
Comment 14 Barry Fishman 2011-04-08 14:23:02 EDT
I did a update April 8, 2011 and a SELinux relabeling.
Now things seem to work correctly.

Note You need to log in before you can comment on or make changes to this bug.