| Summary: | streamzap driver fails during load | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Barry Fishman <barry> | ||||||
| Component: | libmtp | Assignee: | Linus Walleij <triad> | ||||||
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | unspecified | Docs Contact: | |||||||
| Priority: | unspecified | ||||||||
| Version: | 15 | CC: | gansalmon, itamar, jarod, jonathan, kernel-maint, madhu.chinakonda, triad | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Unspecified | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2011-04-02 10:25:13 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Attachments: |
|
||||||||
|
Description
Barry Fishman
2011-03-26 19:37:59 UTC
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. |