SanDisk Extreme 64GB USB-stick: random resets

Soukyuu · 2015-12-29 22:42:21

Well, this is annoying. I got this stick because it's rather fast, and it seems to be working just fine on windows. On linux, I'm getting this:

[34991.527356] usb 2-2: new SuperSpeed USB device number 5 using xhci_hcd
[34991.546189] usb-storage 2-2:1.0: USB Mass Storage device detected
[34991.546267] scsi host14: usb-storage 2-2:1.0
[34992.548407] scsi 14:0:0:0: Direct-Access     SanDisk  Extreme          0001 PQ: 0 ANSI: 6
[34992.549396] sd 14:0:0:0: [sdi] 122544516 512-byte logical blocks: (62.7 GB/58.4 GiB)
[34992.549784] sd 14:0:0:0: [sdi] Write Protect is off
[34992.549790] sd 14:0:0:0: [sdi] Mode Sense: 53 00 00 08
[34992.550287] sd 14:0:0:0: [sdi] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[34992.560858]  sdi: sdi1
[34992.562297] sd 14:0:0:0: [sdi] Attached SCSI removable disk
[35446.859568] usb 2-2: reset SuperSpeed USB device number 5 using xhci_hcd

Journal also has this:

Dez 29 23:27:07 Takemikazuchi kernel: INFO: task kworker/u16:9:14531 blocked for more than 120 seconds.
Dez 29 23:27:07 Takemikazuchi kernel:       Tainted: P        W  O    4.3.3-1-ck #1
Dez 29 23:27:07 Takemikazuchi kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Dez 29 23:27:07 Takemikazuchi kernel: kworker/u16:9   D 0000000000000001     0 14531      2 0x00000000
Dez 29 23:27:07 Takemikazuchi kernel: Workqueue: writeback wb_workfn (flush-8:128)
Dez 29 23:27:07 Takemikazuchi kernel:  ffff8802fa787648 0000000000000046 0000000000000001 ffff8802673c42e8
Dez 29 23:27:07 Takemikazuchi kernel:  01ffffff81092e51 ffff8803215b7380 ffff88032fc55600 00001fac0c6bcc82
Dez 29 23:27:07 Takemikazuchi kernel:  ffff8802673c3f00 ffff880320a53480 ffff8802fa788000 ffff88032fc55600
Dez 29 23:27:07 Takemikazuchi kernel: Call Trace:
Dez 29 23:27:07 Takemikazuchi kernel:  [<ffffffff8159d41a>] schedule+0x3a/0xc0
Dez 29 23:27:07 Takemikazuchi kernel:  [<ffffffff8159ff53>] schedule_timeout+0x1b3/0x240
Dez 29 23:27:07 Takemikazuchi kernel:  [<ffffffff8128e6f7>] ? queue_unplugged+0x37/0xc0
Dez 29 23:27:07 Takemikazuchi kernel:  [<ffffffff810d3b57>] ? ktime_get+0x37/0xa0
Dez 29 23:27:07 Takemikazuchi kernel:  [<ffffffff8159c284>] io_schedule_timeout+0xa4/0x120
Dez 29 23:27:07 Takemikazuchi kernel:  [<ffffffff8128fd96>] get_request+0x436/0x7e0
Dez 29 23:27:07 Takemikazuchi kernel:  [<ffffffff810a88a0>] ? wake_atomic_t_function+0x60/0x60
Dez 29 23:27:07 Takemikazuchi kernel:  [<ffffffff812925d8>] blk_queue_bio+0xd8/0x360
Dez 29 23:27:07 Takemikazuchi kernel:  [<ffffffff81290676>] generic_make_request+0xd6/0x120
Dez 29 23:27:07 Takemikazuchi kernel:  [<ffffffff81290736>] submit_bio+0x76/0x180
Dez 29 23:27:07 Takemikazuchi kernel:  [<ffffffff811bfb76>] ? mem_cgroup_begin_page_stat+0x16/0xa0
Dez 29 23:27:07 Takemikazuchi kernel:  [<ffffffff8120810f>] submit_bh_wbc+0x12f/0x160
Dez 29 23:27:07 Takemikazuchi kernel:  [<ffffffff8120a130>] __block_write_full_page.constprop.19+0x110/0x340
Dez 29 23:27:07 Takemikazuchi kernel:  [<ffffffff8120a740>] ? I_BDEV+0x20/0x20
Dez 29 23:27:07 Takemikazuchi kernel:  [<ffffffff8120a740>] ? I_BDEV+0x20/0x20
Dez 29 23:27:07 Takemikazuchi kernel:  [<ffffffff8120a44e>] block_write_full_page+0xee/0x1a0
Dez 29 23:27:07 Takemikazuchi kernel:  [<ffffffff8120b2f8>] blkdev_writepage+0x18/0x20
Dez 29 23:27:07 Takemikazuchi kernel:  [<ffffffff8115def3>] __writepage+0x13/0x40
Dez 29 23:27:07 Takemikazuchi kernel:  [<ffffffff8115f882>] write_cache_pages+0x202/0x520
Dez 29 23:27:07 Takemikazuchi kernel:  [<ffffffff8115dee0>] ? mapping_tagged+0x20/0x20
Dez 29 23:27:07 Takemikazuchi kernel:  [<ffffffff8115fbf5>] generic_writepages+0x55/0xa0
Dez 29 23:27:07 Takemikazuchi kernel:  [<ffffffff8159c9bc>] ? __schedule+0x6bc/0x10e0
Dez 29 23:27:07 Takemikazuchi kernel:  [<ffffffff811608fe>] do_writepages+0x1e/0x40
Dez 29 23:27:07 Takemikazuchi kernel:  [<ffffffff811fe405>] __writeback_single_inode+0x45/0x320
Dez 29 23:27:07 Takemikazuchi kernel:  [<ffffffff8159d5be>] ? preempt_schedule_common+0x1e/0x40
Dez 29 23:27:07 Takemikazuchi kernel:  [<ffffffff811feca0>] writeback_sb_inodes+0x2a0/0x520
Dez 29 23:27:07 Takemikazuchi kernel:  [<ffffffff811fefac>] __writeback_inodes_wb+0x8c/0xc0
Dez 29 23:27:07 Takemikazuchi kernel:  [<ffffffff811ff2e4>] wb_writeback+0x244/0x300
Dez 29 23:27:07 Takemikazuchi kernel:  [<ffffffff811ffc2f>] wb_workfn+0x32f/0x3e0
Dez 29 23:27:07 Takemikazuchi kernel:  [<ffffffff810933a7>] process_one_work+0x147/0x460
Dez 29 23:27:07 Takemikazuchi kernel:  [<ffffffff81093708>] worker_thread+0x48/0x4a0
Dez 29 23:27:07 Takemikazuchi kernel:  [<ffffffff810936c0>] ? process_one_work+0x460/0x460
Dez 29 23:27:07 Takemikazuchi kernel:  [<ffffffff810936c0>] ? process_one_work+0x460/0x460
Dez 29 23:27:07 Takemikazuchi kernel:  [<ffffffff810996d8>] kthread+0xd8/0x100
Dez 29 23:27:07 Takemikazuchi kernel:  [<ffffffff81099600>] ? kthread_worker_fn+0x180/0x180
Dez 29 23:27:07 Takemikazuchi kernel:  [<ffffffff815a14df>] ret_from_fork+0x3f/0x70
Dez 29 23:27:07 Takemikazuchi kernel:  [<ffffffff81099600>] ? kthread_worker_fn+0x180/0x180
...
Dez 29 23:28:10 Takemikazuchi kernel: sd 14:0:0:0: [sdi] UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=0x08
Dez 29 23:28:10 Takemikazuchi kernel: sd 14:0:0:0: [sdi] Sense Key : 0x4 [current] 
Dez 29 23:28:10 Takemikazuchi kernel: sd 14:0:0:0: [sdi] ASC=0x0 ASCQ=0x0 
Dez 29 23:28:10 Takemikazuchi kernel: sd 14:0:0:0: [sdi] CDB: opcode=0x28 28 00 00 60 02 58 00 00 08 00
Dez 29 23:28:10 Takemikazuchi kernel: blk_update_request: I/O error, dev sdi, sector 6292056
Dez 29 23:28:10 Takemikazuchi kernel: Buffer I/O error on dev sdi1, logical block 786251, async page read

This happens while both writing or reading a large amount of data (~30GB), at various points. Attempting to access the drive via GUI hangs, terminal commands state "endpoint not connected".
I tried NTFS and exFAT (formatted using win10 just to be sure) so far, both show the same behavior, so it's probably not the FS.

The USB3.0 controller is an Etron Technology, Inc. EJ168 USB 3.0 Host Controller (rev 01)
Any idea what might be causing this?

Last edited by Soukyuu (2015-12-29 22:43:59)

Soukyuu · 2015-12-29 23:24:25

It seems to not be the USB stick itself, either. Just did the same operations via USB 2.0 and everything is fine.
So it looks like an issue with my USB3.0 controller. Googling seems to return various problems running it on linux, but so far no solution - if someone knows of one, please let me know.

R00KIE · 2015-12-30 11:05:18

I'd say the best place to start looking is upstream, more specifically in the kernel's bug tracker. If there isn't a bug report open one, if there is, chime in and help get it fixed.

Soukyuu · 2016-01-09 19:28:00

Hmm, I can't seem to reproduce it with 4.3.3 (mainline). Hopefully it was just fixed and is not happening because of the -ck patches.

Soukyuu · 2016-01-25 20:21:22

As it turns out, it's a problem with the stick. It seems to require some workaround, at least on the two USB controllers I tested with.
I'm returning it, because it doesn't seem likely it will be fixed to me. If someone stumbles upon the same issue, you might want to poke people on the linux-usb mailing list.
The bug report is here.

R00KIE · 2016-01-25 21:33:43

The bug got some attention and seems to be on the right track to get fixed or a workaround, however it might be quick to fix or it may take time, it all depends on what the root cause of the bug is and what the best fix may be.

Obviously you want it to work right now, not sometime in the future, so returning it is the logical option, but most probably it will stall the progress made in fixing the bug as there will be no one to test fixes.

That said, it irks me to no end how bad compliance testing is these days, manufacturers seem to be doing compliance tests against windows and not the usb spec.

Soukyuu · 2016-01-26 16:37:23

You are right, it will most likely stall. However, it appears to me it already did - the last reply was back on 14.01. When I asked if it is likely to be fixed at a later time, no one replied after about 4 days. So that makes week and a half without visible progress.
This, for me, indicates it's either not a trivial thing to fix, or the problem is very low priority. After all, it's not like I have a support contract with linux devs.

So yes, I've sent it back. It only working in windows kinda defies the purpose of having a fast USB stick for me, since all my data is on linux filesystems windows can't access.
Should there be some progress someday, I might buy the stick again.

Arch Linux

#1 2015-12-29 22:42:21

SanDisk Extreme 64GB USB-stick: random resets

#2 2015-12-29 23:24:25

Re: SanDisk Extreme 64GB USB-stick: random resets

#3 2015-12-30 11:05:18

Re: SanDisk Extreme 64GB USB-stick: random resets

#4 2016-01-09 19:28:00

Re: SanDisk Extreme 64GB USB-stick: random resets

#5 2016-01-25 20:21:22

Re: SanDisk Extreme 64GB USB-stick: random resets

#6 2016-01-25 21:33:43

Re: SanDisk Extreme 64GB USB-stick: random resets

#7 2016-01-26 16:37:23

Re: SanDisk Extreme 64GB USB-stick: random resets

Board footer