Re: USB3 SSD/HD device file disappears after "eject"
On 29.05.2013 17:01, Grant wrote: [...] I'm not sure I follow. Why only unmount filesystems if it isn't possible to detect powerdown support of hardware (is that the port or the drive)? I noticed this in linux-3.10-rc2 for the first time but I think it is always enabled on previous kernels and this option only allows it to be disabled: CONFIG_USB_DEFAULT_PERSIST: Say N here if you don't want USB power session persistance enabled by default. If you say N it will make suspended USB devices that lose power get reenumerated as if they had been unplugged, causing any mounted filesystems to be lost. The persist feature can still be enabled for individual devices through the power/persist sysfs node. See Documentation/usb/persist.txt for more info. Should I file a kernel bug? Hi again, this sounds also related for me to this... [PATCH] usb: xhci: Disable runtime PM suspend for quirky controllers. <1369419177-23281-1-git-send-email-sha...@chromium.org> -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB3 SSD/HD device file disappears after "eject"
Hi, On 29.05.2013 05:32, Grant wrote: [...] sd 8:0:0:0: [sdb] Synchronizing SCSI cache sd 8:0:0:0: Device offlined - not ready after error recovery Unplugging and replugging the device does not result in the reappearance of the /dev/sdb device file like it does with my other external drives. The only way to bring the /dev/sdb device file back is to 'modprobe -r xhci_hcd && modprobe xhci_hcd'. [...] I'm not sure where the problem is exactly but I think it is really a problem with the power down of some USB hardware in the chain. I am wondering why this still exists on your quite new hardware. I see this here on my own (a few years old) laptop with experimenting some power control settings. I think your USB port got power switched off and so can't detect that you have re-plugged a new device. So my idea is, with reloading the kernel module the power is switched on again. Maybe there should be a config option in userspace to disable powerdown and only unmount filesystems if it is not possible to detect powerdown support of hardware?! Best regards, Markus -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usb: class: cdc-acm: /dev/ttyACM0 HowTo disable interrupt and control URBs
On 09.11.2012 15:43, Oliver Neukum wrote:
On Friday 09 November 2012 14:42:24 Markus Kolb wrote:
[...]
I've found e.g.
URB_NO_INTERRUPT and USBDEVFS_URB_NO_INTERRUPT in
http://code.metager.de/source/xref/linux/stable/drivers/usb/core/devio.c#1386
but how do I set this?
You don't. This is for usbfs. If your modem cannot handle status
transfers it makes no sense to use cdc-acm. You better blacklist the
device and use usb-serial.
Ok. Should the vendor_id/product_id combination be blacklisted in
cdc-acm?
I think the device is detected for cdc-acm because of
http://code.metager.de/source/xref/linux/stable/drivers/usb/class/cdc-acm.c#1653
1653/* control interfaces without any protocol set */
1654{ USB_INTERFACE_INFO(USB_CLASS_COMM, USB_CDC_SUBCLASS_ACM,
1655USB_CDC_PROTO_NONE) },
Or is udev the right place to handle buggy descriptors?
Thanks
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
usb: class: cdc-acm: /dev/ttyACM0 HowTo disable interrupt and control URBs
Hi, is it and how is it possible when using the acm_tty that there is not sent any interrupt or control URB? My connected device has problems handling this stuff and doesn't respond to the bulk URB which is timed somewhere between. I've found e.g. URB_NO_INTERRUPT and USBDEVFS_URB_NO_INTERRUPT in http://code.metager.de/source/xref/linux/stable/drivers/usb/core/devio.c#1386 but how do I set this? Can it be done with ioctl? Some notes would be fine. Thanks a lot Markus -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How-to start reverse engineering serial communication
Bjørn Mork wrote on 07.11.2012 01:17: Markus Kolb writes: I've a bike computer SIGMA ROX 9.1 which can be connected via a small USB docking station to retrieve the collected data. [snip] But I don't see how to interpret the data. So do you have any idea how to go on? Not really, but googling the device brought me this: http://www.freakysoft.de/rox_sigma/ Looks like someone beat you to it :-) Hey, cool... freakysoft sounds like a software search site with dubious results and so I have not read more about this link on my own search. My fault ;-) I think the code is for an older Sigma Rox but sure this is a nice starting point. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
How-to start reverse engineering serial communication
Hello, I've a bike computer SIGMA ROX 9.1 which can be connected via a small USB docking station to retrieve the collected data. However there is a proprietary software called "Data Center" (DaCe) which is not available for Linux and doesn't run with Wine. At least it doesn't find the connected device via com port in Wine. I'd like to write my own software for Linux to collect the training data. In Windows the Data Center (DaCe) software uses a virtual serial port driver with "com3". Now my problem is that I've no idea about the communication with the device. I've tried to use some serial port sniffer. But this didn't work. If the software sniffs the DaCe doesn't find the device. If the DaCe has connected to the device, the sniffers denies to sniff on the serial port. I've tried multiple sniffers without success. Of course it is possible to sniff on USB with usbmon and wireshark. But I've no idea how to go on with the collected jumble of data. The Data Center is an Adobe AIR application. In Windows the usbser.sys is used and Linux detects it as USB ACM device: [12302.367098] usb 6-1: new full-speed USB device number 3 using uhci_hcd [12302.600240] usb 6-1: New USB device found, idVendor=1d9d, idProduct=1030 [12302.600251] usb 6-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [12302.600259] usb 6-1: Product: SIGMA DS ROX 11 [12302.600265] usb 6-1: Manufacturer: STMicroelectronics [12302.602292] usbserial_generic 6-1:1.0: Generic device with no bulk out, not allowed. [12302.602310] usbserial_generic: probe of 6-1:1.0 failed with error -5 [12302.602330] cdc_acm 6-1:1.0: This device cannot do calls on its own. It is not a modem. [12302.602373] cdc_acm 6-1:1.0: ttyACM0: USB ACM device I've the 2 books USB Complete - http://www.amazon.de/gp/product/1931448086 Serial Port Complete - http://www.amazon.de/gp/product/193144806X where I can get more knowledge from ;-) E.g. if I retrieve battery status of 4 units I currently get this data 05:33:64:50:64:41:50:01:00:02:10:40:17:70:04:01:01:06:32:32:32:1e:1e:50:55:55:55:5f:c0:33:21:33:21:96:12:89:53:20:90:49:17:96:09:00:37:15:56:21:10:12:21:42:75:00:28:36:07:00:21:04:79:19:50:06:be:69:86:98:be:00:01:00:02:00:03:95:24:82:17:74:20:23:10:65:37:00:15:17:23:20:32:38:00:30:16:27:00:07:29:05:00:01:15:13:00:02:10:01:00:11:47:21:79:04:40:75:93:67:04:00:55:62:75:01:05:70:37:95:29:03:00:39:03:02:27:13:00:40:20:0c:88:15:af:52:0a:04:02:62:61:5b:ac:a4:6c:03:11:1f:30:29:33:31:43:0f:04:43:be:20:d4:74:94:35 and the DaCe says the batteries of the 4 units (bike computer, chest belt, speed transmitter and cadence transmitter) are fine. But I don't see how to interpret the data. So do you have any idea how to go on? Thanks Markus -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
