Re: Western Digital Elements 2620 not shown on the 400 MByte port

On 9/14/25 04:08, Matthias Apitz wrote:
> 
> Hello,
> 
> My Acer C720, running FreeBSD 14.0-CURRENT r1400094, does not show an
> attached external USB disk, no lines in /var/log/messages in the moment
> of attaching, nothing in
> 
> # usbconfig dump_all_desc
> 
> Only the small light goes on on the disk.
> 
> On the other USB port with 40 MByte transfer rate it says fine:
> 
> Sep 14 10:27:00 c720-1400094 kernel: usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage device Western Digital Elements 2620 (0x1058:0x2620)
> Sep 14 10:27:00 c720-1400094 kernel: usb_msc_auto_quirk: UQ_MSC_NO_TEST_UNIT_READY set for USB mass storage device Western Digital Elements 2620 (0x1058:0x2620)
> Sep 14 10:27:00 c720-1400094 kernel: usb_msc_auto_quirk: UQ_MSC_NO_PREVENT_ALLOW set for USB mass storage device Western Digital Elements 2620 (0x1058:0x2620)
> Sep 14 10:27:02 c720-1400094 kernel: usb_msc_auto_quirk: UQ_MSC_NO_SYNC_CACHE set for USB mass storage device Western Digital Elements 2620 (0x1058:0x2620)
> Sep 14 10:27:02 c720-1400094 kernel: usb_msc_auto_quirk: UQ_MSC_NO_PREVENT_ALLOW set for USB mass storage device Western Digital Elements 2620 (0x1058:0x2620)
> Sep 14 10:27:02 c720-1400094 kernel: usb_msc_auto_quirk: UQ_MSC_NO_TEST_UNIT_READY set for USB mass storage device Western Digital Elements 2620 (0x1058:0x2620)
> Sep 14 10:27:02 c720-1400094 kernel: usb_msc_auto_quirk: UQ_MSC_NO_START_STOP set for USB mass storage device Western Digital Elements 2620 (0x1058:0x2620)
> Sep 14 10:27:02 c720-1400094 kernel: ugen0.2: <Western Digital Elements 2620> at usbus0
> Sep 14 10:27:02 c720-1400094 kernel: umass0 on uhub0
> Sep 14 10:27:02 c720-1400094 kernel: umass0: <Western Digital Elements 2620, class 0/0, rev 2.10/10.23, addr 5> on usbus0
> Sep 14 10:27:02 c720-1400094 kernel: umass0:  SCSI over Bulk-Only; quirks = 0xc105
> Sep 14 10:27:02 c720-1400094 kernel: umass0:1:0: Attached to scbus1
> Sep 14 10:27:02 c720-1400094 kernel: da0 at umass-sim0 bus 0 scbus1 target 0 lun 0
> Sep 14 10:27:02 c720-1400094 kernel: da0: <WD Elements 2620 1023> Fixed Direct Access SPC-4 SCSI device
> Sep 14 10:27:02 c720-1400094 kernel: da0: Serial Number 575838324137344831564E50
> Sep 14 10:27:02 c720-1400094 kernel: da0: 40.000MB/s transfers
> Sep 14 10:27:02 c720-1400094 kernel: da0: 1907697MB (3906963456 512 byte sectors)
> Sep 14 10:27:02 c720-1400094 kernel: da0: quirks=0x2<NO_6_BYTE>
> 
> Other disks do fine on the 400 MByte port.
> 
> What could I do/test? Thanks

   Though not FreeBSD specific, you can 'very' slowly (don't remember 
exact timing but several seconds to fully insert seemed to do it) 
connect a USB3 type A connector and it will establish a USB2 connection. 
I used that with a flash drive where USB3 had failed to communicate 
successfully on many machines. During insertion, I usually plugged in 
slowly until the drive activity started responding, held still (or 
inserted slightly further if I thought it would be intermittent then 
waited) a few seconds while initialization happens, and then fully 
inserted it.
   Have you tried the drive successfully on another OS or any other 
computer and confirmed it was USB3 connected when doing so? If possible 
also try another USB cable. I presume the other disks working fine on 
400MB port are referring to doing so under FreeBSD but are they also 
confirmed as achieving more than USB2 speeds?
  Some USB drives are a SATA drive + USB adapter put into an enclosure 
but if I recall I think WD makes a number of drives where the USB 
adapter is part of the drive itself so cannot be removed if it fails. If 
removable, connecting the internal drive with another adapter would be a 
workaround.

   For FreeBSD specific thinking, maybe more details would help such as 
USB controller (found during bootup logs which are likely also in 
/var/run/dmesg.boot ). 14-current is quite old (16-current I think is 
becoming a thing for the current branch's versioning); may be worth 
trying a newer (or even maybe older?) release, stable, or current..
   In my experience FreeBSD has been good about making it clear if 
things are connecting (even if it cannot use said connection) and 
communicating so seeing no response during 400MB connection when the 
400MB port is already confirmed as working would have me start 
questioning hardware (drive, computer and its firmware/BIOS/UEFI, and 
cable) before thinking it is software if you have other 400MB 
connections succeeding. Brings back memories where a friend had a new 
digital camera and Windows said 'something' was wrong leaving the user 
with no idea if it was software or what hardware, OSX implied it 'might' 
be a camera issue though don't remember its wording, and FreeBSD 
connection messages pointed me to thinking the camera was the issue.

> 	matthias
> 
>