On Mon, 18 Oct 2010, Manuel Reimer wrote: > Alan Stern wrote: > > This shows that usb-storage doesn't have a chance to use the device; it > > gets unbound before anything can happen. Which strongly suggests that > > the problem is caused by some other program running on your machine. > > Yes, that seems to be the case... > > > You might be able find out by enabling CONFIG_USB_DEBUG and turning on > > the usbfs_snoop module parameter for usbcore. Oh, and while you're > > doing that, it would also be a good idea to enable CONFIG_PRINTK_TIME. > > How to turn on the usbfs_snoop parameter? I don't have "usbcore" in lsmod. echo 1 >/sys/module/usbcore/parameters/usbfs_snoop > I did the other changes, you suggested and after booting up, my X-Server > failed to start (missed to recompile Nvidia driver). I still wanted to > give this a try (without X-Server) and plugged in the player stick. I > got messages on dmesg in an amount that it seems to be impossible to > save them and then my stick was mountable. I was able to copy some MP3 > files to my player and was also able to play those files. > > After this success, I decided to reinstall the graphics driver to be > able to tell you my results. As soon as my X-Server is up and running, > again, the output on dmesg reduces to the few lines, I'll attach at the > end of this message and my stick is, again, not usable... > > So current status is > X server not running: Stick works > X server running: Stick does not get a /dev/sdX device, not mountable. Evidently the "bad" program gets started by some utility running under X. When X is off, the player works. > And if stick works (without X), the amount of dmesg stuff, generated > after plugging in, seems to be impossible to handle. Does dmesg have > something like a "buffer overflow"? The kernel's buffer is fixed in size. If too much data is added, older messages simply get over-written. But it doesn't matter -- if the player is working then we don't care what the log messages say. (Except that once the problem is solved you'll want to turn CONFIG_USB_DEBUG and CONFIG_USB_STORAGE_DEBUG back off to prevent all those messages from being generated in the first place.) > Yours > > Manuel > > dmesg stuff follows: > > [ 1196.209269] usb usb2: usb wakeup-resume > [ 1196.209282] usb usb2: usb auto-resume > [ 1196.250023] hub 2-0:1.0: hub_resume > [ 1196.250045] hub 2-0:1.0: port 1: status 0501 change 0001 > [ 1196.351050] hub 2-0:1.0: state 7 ports 6 chg 0002 evt 0000 > [ 1196.351079] hub 2-0:1.0: port 1, status 0501, change 0000, 480 Mb/s > [ 1196.453037] usb 2-1: new high speed USB device using ehci_hcd and > address 9 > [ 1196.568313] usb 2-1: default language 0x0409 > [ 1196.569438] usb 2-1: udev 9, busnum 2, minor = 136 > [ 1196.569443] usb 2-1: New USB device found, idVendor=0402, idProduct=5668 > [ 1196.569449] usb 2-1: New USB device strings: Mfr=3, Product=1, > SerialNumber=2 > [ 1196.569454] usb 2-1: Product: Intenso Music Walker > [ 1196.569459] usb 2-1: Manufacturer: ALi Corp. > [ 1196.569463] usb 2-1: SerialNumber: 91029639100000001403 > [ 1196.569679] usb 2-1: usb_probe_device > [ 1196.569687] usb 2-1: configuration #1 chosen from 1 choice > [ 1196.569814] usb 2-1: adding 2-1:1.0 (config #1, interface 0) > [ 1196.570017] usb-storage 2-1:1.0: usb_probe_interface > [ 1196.570029] usb-storage 2-1:1.0: usb_probe_interface - got id > [ 1196.570035] usb-storage: USB Mass Storage device detected > [ 1196.570105] usb-storage: -- associate_dev > [ 1196.570110] usb-storage: Vendor: 0x0402, Product: 0x5668, Revision: > 0x0002 > [ 1196.570115] usb-storage: Interface Subclass: 0x06, Protocol: 0x50 > [ 1196.570122] usb-storage: Transport: Bulk > [ 1196.570142] usb-storage: Protocol: Transparent SCSI > [ 1196.570432] scsi13 : usb-storage 2-1:1.0 > [ 1196.570668] usb-storage: *** thread sleeping. > [ 1196.570796] drivers/usb/core/inode.c: creating file '009' > [ 1196.571022] usb-storage 2-1:1.0: device found > [ 1196.571028] usb-storage 2-1:1.0: waiting for device to settle before > scanning > [ 1196.640156] usb-storage 2-1:1.0: disconnect by usbfs > [ 1196.640176] usb-storage: storage_disconnect() called > [ 1196.640982] usb-storage: -- usb_stor_release_resources > [ 1196.640987] usb-storage: -- sending exit command to thread > [ 1196.640996] usb-storage: *** thread awakened. > [ 1196.641000] usb-storage: -- exiting > [ 1196.641019] usb-storage: -- dissociate_dev That's pretty much the same as before. > [ 1196.641107] usb 2-1: BOGUS urb flags, 1 --> 0 > [ 1196.641112] usb 2-1: usbfs: usb_submit_urb returned -22 > [ 1196.749032] usb 2-1: reset high speed USB device using ehci_hcd and > address 9 > [ 1196.864475] usb 2-1: BOGUS urb flags, 1 --> 0 > [ 1196.864481] usb 2-1: usbfs: usb_submit_urb returned -22 These error messages refer to actions taken by the "bad" program. 1 is the URB_SHORT_NOT_OK flag, and the reason for the error must be that the flag was set for an OUT transfer. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
