lsusb -vt
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 10000M
ID 1d6b:0003 Linux Foundation 3.0 root hub
|__ Port 2: Dev 5, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
ID 8564:1000 Transcend Information, Inc. JetFlash

however it may accidentally become

usb 3-3: Product: SM3265AB MEMORY BAR
usb 3-3: Manufacturer: Silicon Motion,Inc.

|__ Port 3: Dev 8, If 0, Class=Mass Storage, Driver=usb-storage, 480M
ID 090c:3265 Silicon Motion, Inc. - Taiwan (formerly Feiya
Technology Corp.)

Hmm... I'm way out of my depth here, but the one thing that I notice
that the the Transcend state is using USB3 (hence xHCI) whereas the
Silicon Motion state uses USB2 speed (and presumably the EHCI).

It seems, attempt of booting live system is a reliable way to put the device into its "Silicon Motion" state.

My guess is that the boot code (BIOS? Grub?) doesn't support USB3 (it
doesn't have a driver for the xHCI controller, only for the EHCI
controller).


Stefan

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

Max Nikulin wrote:

Usually the device as recognized as (ignore discrepancy in bus and port numbers, they are from notes taken at different moments on 2 laptops)
...
|__ Port 2: Dev 5, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
ID 8564:1000 Transcend Information, Inc. JetFlash
however it may accidentally become
...
|__ Port 3: Dev 8, If 0, Class=Mass Storage, Driver=usb-storage, 480M
ID 090c:3265 Silicon Motion, Inc. - Taiwan (formerly Feiya Technology Corp.)

I understand that USB Vendor Id and Product Id are told by the USB
device's firmware to the operating system.

Somewhat undisciplined usage of the Id 8564:1000 can be seen at:
https://flashboot.ru/iflash/page45/
FLASH FLASH VID PID CHIP CHIP MEMORY SIZE
VENDOR MODEL VENDOR MODEL CHIP
----------------------------------------------------------------------
transcend d33193 8564 1000 ALCOR 16
JetFlash Transcend 64Gb 8564 1000 SMI 64
Silicon Motion Transcend 090C 3265 SMI SM3265AB TRANSCEND 128

It seems that the firmware is wavering between something like the second
and the third identity. There seems to be a 128 GB version of 8564:1000,
too:
https://usb-ids.gowdy.us/read/UD/8564/1000

My feeble theory is that the booting software issues some kind of reset
which makes the USB stick's firmware forget its commercial vendor and lets
it fall back to its manufacturing vendor. Further it forgets how to deal
with Linux.


Have a nice day :)

Thomas

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

Max Nikulin wrote:

Just booting grub from internal drive in the case of a USB3 port does not cause switch from Transcend to SMI for Linux kernel.

Can you provoke the transition while this Linux kernel is running ?
If so: what does the kernel log say about that point in time ?

I am curious if it is possible to change device mode by some reset-like command while Linux kernel is booted up.

It looks to me as if the firmware of the USB stick is dysfunctional after
the transition and that only a power cycle resets it.
This theory predicts that the Linux log shows the Transcend device
disappearing and the SMI device appearing shortly afterwards.

Search gives dozens of records for this vid:pid pair. My device is
Transcend JetFlash 700 USB 3.1 128 GB (TS128GJF700)

I imagine that the USB-and-memory controller was made by SMI with ID
090c:3265 and programmed by Transcend to tell ID 8564:1000. The controller crashes after doing some work and reboots partially to its 090c:3265 personality but cannot bring up the memory device functionality together
with the Transcend personality ... or so.


Have a nice day :)

Thomas

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

Max Mikulin wrote:

Oct 09 09:02:25 hp kernel: usb 3-3: new high-speed USB device number 7 using xhci_hcd
Oct 09 09:02:25 hp kernel: usb 3-3: New USB device found, idVendor=8564, idProduct=1000, bcdDevice=11.00
...
Oct 09 09:02:25 hp kernel: scsi host4: usb-storage 3-3:1.0
Oct 09 09:02:27 hp kernel: scsi 4:0:0:0: Direct-Access JetFlash
Transcend 128GB 1100 PQ: 0 ANSI: 6

This is when the kernel USB layer attaches the device as Transcend
8564:1000.
The SCSI layer then gets "JetFlash Transcend 128GB" as identification of
the storage device (from the SCSI command named "INQUIRY").

Oct 09 09:51:22 hp kernel: usb 3-3: reset high-speed USB device number 7 using xhci_hcd
Oct 09 09:51:24 hp kernel: usb 3-3: device firmware changed

Something has happend on the USB bus so that the kernel is surprised.

Oct 09 09:51:24 hp kernel: sd 4:0:0:0: [sdb] tag#0 FAILED Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK cmd_age=2s
Oct 09 09:51:24 hp kernel: sd 4:0:0:0: [sdb] tag#0 CDB: Read(10) 28 00 0b f1 de 30 00 00 f0 00
Oct 09 09:51:24 hp kernel: I/O error, dev sdb, sector 200400432 op 0x0:(READ) flags 0x84700 phys_seg 2 prio class 0
Oct 09 09:51:24 hp kernel: usb 3-3: USB disconnect, device number 7

The SCSI layer perceives a failed read command.
The USB layer disconnects the device.

Oct 09 09:51:24 hp kernel: sd 4:0:0:0: [sdb] tag#0 FAILED Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK cmd_age=0s
Oct 09 09:51:24 hp kernel: sd 4:0:0:0: [sdb] tag#0 CDB: Read(10) 28 00 0b f1 df 20 00 00 20 00

The USB disconnect does not keep the SCSI layer from trying another read,
240 blocks higher (0x0df1df20 versus 0x0bf1de30 in the first attempt).

Oct 09 09:51:24 hp kernel: I/O error, dev sdb, sector 200400672 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
Oct 09 09:51:24 hp kernel: device offline error, dev sdb, sector 200400704 op 0x0:(READ) flags 0x84700 phys_seg 2 prio class 0

The block device layer chimes in.

Oct 09 09:51:26 hp udisksd[1214]: Cleaning up mount point

Userland takes action.

Oct 09 09:51:26 hp kernel: usb 3-3: new high-speed USB device number 8 using xhci_hcd
Oct 09 09:51:26 hp kernel: usb 3-3: New USB device found, idVendor=090c, idProduct=3265, bcdDevice= 1.00
...
Oct 09 09:51:27 hp kernel: scsi 4:0:0:0: Direct-Access SMI USB MEMORY BAR 1000 PQ: 0 ANSI: 5

The kernel USB layer detects the device again which now identifies itself
as Silicon Motion Inc. 090c:3265.
The SCSI identification is now "SMI USB MEMORY BAR".

(To my theory these are the generic ids of the board inside the USB stick, which normally should change to the Transcend ids, when the firmware reads
what was programmed or configured by Transcend.)

It is possible to boot from the USB stick when it is connected to a USB3
port of HP ProBook 445 G7. It fails in the case of the USB2 port of the same laptop.

Looks like there is some problem in the USB hardware of the stick,
which strikes on most USB ports.


I would stop plugging it into the USB ports where it does not work well.
If it contains private data, i'd overwrite it with random data via the
port where it works (if it works long enough, that is).
Then i would return it to the seller.


Have a nice day :)

Thomas

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)