USB 3.0 stick folders disappeared

I have a 32 GB Kingston DT R3.0 usb stick. It’s formatted Fat32 (I use it also under windows). I use it mainly with my asus N55sf laptop and the Hp and dell computers at work. (My laptop has usb 3.0 and usb 2.0 ports as well and dual boot opensuse 13.1 and win7; some computers at work have Winxp some Win7 but only usb2.0 ports) It worked well under opensuse 13.1 on my laptop. But about two weeks ago suddenly i noticed that if I use the usb3.0 port on laptop I can’t see the folders on it.If I plugged to the usb2.0 port on the same laptop I see the folders and it worked well also.Then I reformatted the stick , then copied the content on it again. Then it worked well again, but yesterday the same happened again. The folders disappeared under Usb3.0 but if i use Usb2.0 everithing ok. Under win7 everithing is ok under usb 3.0 also.
What could be the problem?

Your issue (as described) does seem to indicate an apparent issue with the USB 3 driver. As part of the diagnostics, it might be useful to capture the kernel messages when the device is plugged in. Start by executing the following in a terminal window

sudo tail -f /var/log/messages

then plug in your device to a USB 3 interface. (CTRL-C to terminate.)

This output too

fdisk -l

If possible, it might be good to compare when the mounting does complete vs when it doesn’t.

FWIW, here is a kernel bug report describing an apparent regression (with 3.11)

Thanks for the answers. It mounts also when i cant see the folders, i can read the files in the root folder of stick only i can’t see the other folders.
I tried the ‘sudo tail…’ :

2014-02-05T23:41:11.084652+01:00 ASUS-NB kernel: 3095.029950] usb 4-2: new SuperSpeed USB device number 3 using xhci_hcd
2014-02-05T23:41:11.100632+01:00 ASUS-NB kernel: 3095.045967] usb 4-2: Parent hub missing LPM exit latency info. Power management will be impacted.
2014-02-05T23:41:11.113639+01:00 ASUS-NB kernel: 3095.058488] usb 4-2: New USB device found, idVendor=0951, idProduct=168e
2014-02-05T23:41:11.113665+01:00 ASUS-NB kernel: 3095.058495] usb 4-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
2014-02-05T23:41:11.113669+01:00 ASUS-NB kernel: 3095.058499] usb 4-2: Product: DT Rubber 3.0
2014-02-05T23:41:11.113670+01:00 ASUS-NB kernel: 3095.058503] usb 4-2: Manufacturer: Kingston
2014-02-05T23:41:11.113672+01:00 ASUS-NB kernel: 3095.058506] usb 4-2: SerialNumber: 0018F30C6AF2FDA0A10504DE
2014-02-05T23:41:11.115635+01:00 ASUS-NB kernel: 3095.060162] usb-storage 4-2:1.0: USB Mass Storage device detected
2014-02-05T23:41:11.115663+01:00 ASUS-NB kernel: 3095.060303] scsi8 : usb-storage 4-2:1.0
2014-02-05T23:41:11.118186+01:00 ASUS-NB mtp-probe: checking bus 4, device 3: “/sys/devices/pci0000:00/0000:00:1c.3/0000:04:00.0/usb4/4-2”
2014-02-05T23:40:37.410741+01:00 ASUS-NB laptop-mode: Warning: Configuration file /etc/laptop-mode/conf.d/board-specific/* is not readable, skipping.
2014-02-05T23:41:11.118922+01:00 ASUS-NB mtp-probe: bus: 4, device: 3 was not an MTP device
2014-02-05T23:41:11.151980+01:00 ASUS-NB laptop-mode: Warning: Configuration file /etc/laptop-mode/conf.d/board-specific/* is not readable, skipping.
2014-02-05T23:41:11.152399+01:00 ASUS-NB laptop-mode: Warning: Configuration file /etc/laptop-mode/conf.d/board-specific/* is not readable, skipping.
2014-02-05T23:41:11.182119+01:00 ASUS-NB laptop-mode: Laptop mode
2014-02-05T23:41:11.183499+01:00 ASUS-NB laptop-mode: enabled, not active
2014-02-05T23:41:11.199354+01:00 ASUS-NB laptop-mode: Laptop mode
2014-02-05T23:41:11.200687+01:00 ASUS-NB laptop-mode: enabled, not active
2014-02-05T23:41:12.211339+01:00 ASUS-NB kernel: 3096.157319] scsi 8:0:0:0: Direct-Access Kingston DT Rubber 3.0 1.00 PQ: 0 ANSI: 6
2014-02-05T23:41:12.211357+01:00 ASUS-NB kernel: 3096.157595] sd 8:0:0:0: Attached scsi generic sg2 type 0
2014-02-05T23:41:12.212619+01:00 ASUS-NB kernel: 3096.158110] sd 8:0:0:0: [sdc] 60435442 512-byte logical blocks: (30.9 GB/28.8 GiB)
2014-02-05T23:41:12.212631+01:00 ASUS-NB kernel: 3096.158643] sd 8:0:0:0: [sdc] Write Protect is off
2014-02-05T23:41:12.212633+01:00 ASUS-NB kernel: 3096.158649] sd 8:0:0:0: [sdc] Mode Sense: 4f 00 00 00
2014-02-05T23:41:12.213618+01:00 ASUS-NB kernel: 3096.159241] sd 8:0:0:0: [sdc] Write cache: disabled, read cache: enabled, doesn’t support DPO or FUA
2014-02-05T23:41:12.218631+01:00 ASUS-NB kernel: 3096.164662] sdc: sdc1
2014-02-05T23:41:12.220617+01:00 ASUS-NB kernel: 3096.166893] sd 8:0:0:0: [sdc] Attached SCSI removable disk
2014-02-05T23:41:12.331612+01:00 ASUS-NB kernel: 3096.277982] FAT-fs (sdc1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
2014-02-05T23:41:12.333304+01:00 ASUS-NB udisksd[2218]: Mounted /dev/sdc1 at /run/media/zoli/KINGSTON_DT on behalf of uid 1000
2014-02-05T23:41:12.464616+01:00 ASUS-NB kernel: 3096.410451] FAT-fs (sdc1): error, fat_get_cluster: invalid cluster chain (i_pos 0)
2014-02-05T23:41:12.464631+01:00 ASUS-NB kernel: 3096.410456] FAT-fs (sdc1): Filesystem has been set read-only
2014-02-05T23:41:12.464638+01:00 ASUS-NB kernel: 3096.410763] FAT-fs (sdc1): error, fat_get_cluster: invalid cluster chain (i_pos 0)

It shows it wasnt properly unmounted. It’s strange, because I pay attention on it from the first incident. I tried fsck, but it didn’t help. So i formatted it again. Now it mounts properly without errors.

It shows it wasnt properly unmounted. It’s strange, because I pay attention on it from the first incident. I tried fsck, but it didn’t help. So i formatted it again. Now it mounts properly without errors.

Yep, that makes sense.

Now I watched it continously as I used. (with the “sudo tail…” ) I always properly unmounted. But as I copied some files with long file names on it, and unmounted and remounted again, When I used USB3.0 port the file with long file name wasn’t readable. If i unmounted it and mounted it on usb2.0 port it was readable and worked well. So it seems the long file names doesn’t work properly under usb3.0.

I don’t to profess to understand that behaviour, since the XHCI driver handles low-level communication, and is not responsible for (or aware of) file systems, but obviously the data transfer is failing somehow. If you can identify consistent failure under particular conditions, then I would recommend reporting it as a bug, with the relevant kernel messages attached.