Zoom Recorders USB storage on 13.2

English Hardware
#1

Support for using these devices (well I’ve tried the H4 and H6) as USB storage devices seems to be broken on 13.2 (from the live DVD release up to the latest updates). It is fine on 13.1

I don’t get the KDE notifier. I can mount the drive and use it but unmounting produces an error message which is a bit disconcerting. Also on plugging the device in, systemd-udevd starts using 100% CPU and remains at that until some time after the device is disconnected.

I’ve tried looking at the output from journalctl. Here is a sample connect and disconnect:

Jun 27 16:27:03 worthy kernel: usb 1-3: new high-speed USB device number 11 using ehci-pci
Jun 27 16:27:09 worthy kernel: usb 1-3: new high-speed USB device number 12 using ehci-pci
Jun 27 16:27:09 worthy kernel: usb 1-3: New USB device found, idVendor=1686, idProduct=01c0
Jun 27 16:27:09 worthy kernel: usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=4
Jun 27 16:27:09 worthy kernel: usb 1-3: Product: H6
Jun 27 16:27:09 worthy kernel: usb 1-3: Manufacturer: ZOOM Corporation
Jun 27 16:27:09 worthy kernel: usb 1-3: SerialNumber: 000000000000
Jun 27 16:27:09 worthy kernel: usb-storage 1-3:1.0: USB Mass Storage device detected
Jun 27 16:27:09 worthy kernel: scsi11 : usb-storage 1-3:1.0
Jun 27 16:27:09 worthy mtp-probe[21994]: checking bus 1, device 12: "/sys/devices/pci0000:00/0000:00:12.2/usb1/1-3"
Jun 27 16:27:09 worthy mtp-probe[21994]: bus: 1, device: 12 was not an MTP device
Jun 27 16:27:10 worthy kernel: scsi 11:0:0:0: Direct-Access     ZOOM     H6 SD R&W        1.00 PQ: 0 ANSI: 2
Jun 27 16:27:10 worthy kernel: sd 11:0:0:0: Attached scsi generic sg5 type 0
Jun 27 16:27:10 worthy kernel: sd 11:0:0:0: [sde] 7812096 512-byte logical blocks: (3.99 GB/3.72 GiB)
Jun 27 16:27:10 worthy kernel: sd 11:0:0:0: [sde] Write Protect is off
Jun 27 16:27:10 worthy kernel: sd 11:0:0:0: [sde] Mode Sense: 03 00 00 00
Jun 27 16:27:10 worthy kernel: sd 11:0:0:0: [sde] No Caching mode page found
Jun 27 16:27:10 worthy kernel: sd 11:0:0:0: [sde] Assuming drive cache: write through
Jun 27 16:27:10 worthy kernel:  sde: sde1
Jun 27 16:27:10 worthy kernel: sd 11:0:0:0: [sde] Attached SCSI removable disk

Jun 27 16:27:59 worthy kernel: usb 1-3: USB disconnect, device number 12
Jun 27 16:28:11 worthy systemd-udevd[525]: worker [21990] /devices/pci0000:00/0000:00:12.2/usb1/1-3/1-3:1.0/host11/target11:0:0/11:0:0:0/block/sde is taking a long time
Jun 27 16:30:11 worthy systemd-udevd[525]: seq 3515 '/devices/pci0000:00/0000:00:12.2/usb1/1-3/1-3:1.0/host11/target11:0:0/11:0:0:0/block/sde' killed
Jun 27 16:30:11 worthy systemd-udevd[525]: worker [21990] terminated by signal 9 (Killed)
Jun 27 16:30:11 worthy systemd-udevd[21998]: inotify_add_watch(6, /dev/sde1, 10) failed: No such file or directory

I don’t notice any difference with the log on 13.1 up to “Attached SCSI removable disk”

#2

Attaching by USB 3 or 2??

#3

I have been using USB 2. I have just tried USB 3 and get the same symptoms.

#4

Thought it might be a USB 3 issue but I guess not

#5 
Jun 27 16:27:59 worthy kernel: usb 1-3: USB disconnect, device number 12
Jun 27 16:28:11 worthy systemd-udevd[525]: worker [21990] /devices/pci0000:00/0000:00:12.2/usb1/1-3/1-3:1.0/host11/target11:0:0/11:0:0:0/block/sde is taking a long time
Jun 27 16:30:11 worthy systemd-udevd[525]: seq 3515 '/devices/pci0000:00/0000:00:12.2/usb1/1-3/1-3:1.0/host11/target11:0:0/11:0:0:0/block/sde' killed
Jun 27 16:30:11 worthy systemd-udevd[525]: worker [21990] terminated by signal 9 (Killed)
Jun 27 16:30:11 worthy systemd-udevd[21998]: inotify_add_watch(6, /dev/sde1, 10) failed: No such file or directory

Well, it appears that you’ve found some kind of regression here, so a bug report may be required.

I also wondered why the disconnect event occurs so soon after device sde appears, and if USB power management was possibly causing an issue here? I’m probably on the wrong track here
but easy enough to test by disabling with a udev rule…


#Zoom Recorder
ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="0x1686", ATTR{idProduct}=="0x01c0", TEST=="power/control", ATTR{power/control}="on"

References:
https://wiki.archlinux.org/index.php/Power_management#USB_autosuspend
http://hamwaves.com/usb.autosuspend/en/

#6

Sorry. Perhaps I could have presented it better. The disconnect was a manual one by me.

I’ve tried setting up the rule anyway but it makes no difference.

One thing I’ve noticed is that on the systemd-udevd lines, it refers to

/devices/pci0000:00/0000:00:12.2/…

is that right or should it be

/sys/devices/pci0000:00/0000:00:12.2/…

#7

Okay.

I’ve tried setting up the rule anyway but it makes no difference.

No, unlikely to have been a power management issue anyway. It was the disconnect event that had made me wonder about the behaviour.

One thing I’ve noticed is that on the systemd-udevd lines, it refers to

/devices/pci0000:00/0000:00:12.2/…

is that right or should it be

/sys/devices/pci0000:00/0000:00:12.2/…

That’s just how it is reported, but you’ll probably need to report this as a bug IMHO.

#8

Just perhaps to clarify one other thing. The Zoom recorders also act as USB audio devices (I think mics on the lower end and sound cards on the H4 upwards). This (at least on the H4 and H6) seems fine - I have tried the H6 in multi track (6 in, 2 out) mode and even that seems to work well.

#9

Yes, I did realise that (following a quick search earlier today). Normally there should be no impact for a device that presents itself with multiple device types (classes). Since you say it was working with openSUSE 13.1, and not with 13.2, that suggests a regression to me.

#10

OK. I’ve never used the system before but I’ll report this as a bug later today.

#11

Not hard just present all the info you know in an tidy orderly manner.:wink: