Hi. I have a brand-new Corsair 'Flash Voyager Slider' USB 64GB memory stick but it won't work with my brand-new Linux kernel. The device works fine with my old 2.6.34.13 kernel but not a 4.3.3 kernel or a 4.4.2 kernel that I installed just today from kernel.org. Can anyone help?

This is the relevant line from a 'lsusb' listing:

Bus 003 Device 005: ID 1b1c:1a06 Corsair

And this is the relevant excerpt from /var/log/messages:

kernel: usb 3-13: new high-speed USB device number 5 using xhci_hcd
kernel: usb 3-13: New USB device found, idVendor=1b1c, idProduct=1a06
kernel: usb 3-13: New USB device strings: Mfr=1, Product=2, SerialNumber=3
kernel: usb 3-13: Product: Slider 3.0
kernel: usb 3-13: Manufacturer: Corsair
kernel: usb 3-13: SerialNumber: AXXXXXXXXXXXXX
kernel: usb-storage 3-13:1.0: USB Mass Storage device detected
kernel: scsi host7: usb-storage 3-13:1.0
mtp-probe: checking bus 3, device 5: "/sys/devices/pci0000:00/0000:00:14.0/usb3/3-13"
mtp-probe: bus: 3, device: 5 was not an MTP device
kernel: scsi 7:0:0:0: Direct-Access Corsair Slider 3.0 1100 PQ: 0 ANSI: 6
kernel: sd 7:0:0:0: alua: supports implicit and explicit TPGS
kernel: sd 7:0:0:0: alua: No target port descriptors found
kernel: sd 7:0:0:0: alua: Attach failed (-22)
kernel: sd 7:0:0:0: failed to add device handler: -22
kernel: sd 7:0:0:0: [sde] 125038592 512-byte logical blocks: (64.0 GB/59.6 GiB)
kernel: sd 7:0:0:0: [sde] Write Protect is off
kernel: sd 7:0:0:0: [sde] Asking for cache data failed
kernel: sd 7:0:0:0: [sde] Assuming drive cache: write through
kernel: sd 7:0:0:0: [sde] Attached SCSI removable disk
systemd-udevd: error: /dev/sde: No such device or address
systemd-udevd: error: /dev/sde: No such device or address

As you can see, the kernel 'finds' and describes the USB stick correctly, but then this 'alua' thing (whatever that is) reports these problems:

ernel: sd 7:0:0:0: alua: No target port descriptors found
kernel: sd 7:0:0:0: alua: Attach failed (-22)
kernel: sd 7:0:0:0: failed to add device handler: -22

The device is installed in /dev - /dev/sde in this example - but a test dd can't read from the device, instead reporting an I/O error. As you can see udev also can't handle it.

This is on a recent stable 4.3.3 kernel and also on a 4.4.2 kernel that I installed today. Other (older) USB memory sticks work fine. This problem Corsair USB stick works fine in a much older Linux kernel (it has a single partition with an NTFS filesystem).

Can anyone offer advice? Thanks.

can you eliminate kernel modules first please as thats the easy bit

go to your /boot and search your config for new kernel for ntfs and then search for alua, are both built as modules?

2) what is the name of your Linux distro?

3) I am not an expert on anything alua related, did you install it or was it a default install for your iso?

4) I am guessing you have no "true" udev rule that can handle alua and ntfs storage devices. udev rules often reside in /etc/udev/rules.d but also can be found in
*/lib/udev

Have a gander there and report back if you find something

5) do you have a /etc/multipath file?
https://www-01.ibm.com/support/knowl..._settings.html

Hello aus9, thanks for your reply.

> what is the name of your Linux distro?

I have installed the latest Centos 7 distribution - release 'CentOS Linux release 7.2.1511 (Core)'.

However I'm not running the kernel that came with that release; I downloaded, compiled and installed two 'stable' kernels from www.kernel.org, 4.3.3 and 4.4.2. The 4.4.2 kernel is only a few days old. Neither of those new kernels can attach the Corsair USB stick.

> search your config for new kernel for ntfs and then search for alua, are both built as modules?

Running egrep on the .config I used to build the kernels I get these results:

# egrep -i 'ntfs|alua' .config
CONFIG_SCSI_DH_ALUA=y
# CONFIG_NTFS_FS is not set

There are also no files with 'ntfs' or 'alua' in their names in /lib/modules/4.4.2.

So it looks like 'ALUA' is compiled into the kernel, not a module.

> I am not an expert on anything alua related, did you install it or was it a default install for your iso?

I don't even know what 'alua' is! :-( I'm wondering if I could somehow tell it to 'ignore' the Corsair whether it would then be attached as normal by whatever other device driver might normally handle USB sticks?

> I am guessing you have no "true" udev rule that can handle alua and ntfs storage devices.

Other USB memory sticks are attached and then mounted by udev with no problems. I think the udev errors are a result of the failure to 'attach' a device driver to the USB stick in the first place; udev is trying to do what I did manually, read the device - /dev/sde - to get partitions, etc, and failing, because the USB stick isn't attached/working.

hi

then re-compile kernel to give it ntfs support please.

my config line is

CONFIG_NTFS_FS=m
# CONFIG_NTFS_DEBUG is not set
# CONFIG_NTFS_RW is not set

its ok if alua is not a module but still not sure how useful it is but its ntfs that seems to be the main issue for now

Well, I set CONFIG_SCSI_DH_ALUA to be 'm', a module, and now everything works fine. The 'alua' lines aren't logged any more and the USB memory stick mounts perfectly when the scsi_dh_alua module is NOT loaded.

If I load the 'alua' module - 'modprobe scsi_dh_alua' - and then insert the USB memory stick the problem comes back, just like before.

So I guess the 'alua' device handler for SCSI was hijacking the device and not letting the normal (usb-storage?) handler from accessing it.

Thanks for your assistance in helping to clarify matters aus9!

glad you resolved it, can you mark post as solved please.