Bug 198647

Summary: MX-ES USB Drive by Mach Xtreme ILLEGAL REQUEST asc:21,0 (Logical block address out of range)
Product: Base System Reporter: Chris Baker <cmbaker82>
Component: usbAssignee: Hans Petter Selasky <hselasky>
Status: Closed FIXED    
Severity: Affects Some People CC: cmbaker82, harald.linden, hselasky
Priority: ---    
Version: CURRENT   
Hardware: Any   
OS: Any   

Description Chris Baker 2015-03-17 02:10:20 UTC
I am trying to install FreeBSD 9.3, also tried 10.1 and 11.0, to an mx-ex 8gb flash drive. Here is a link to the specifications: http://mx-technology.com/h5/en/flash2.php?sid=38
It is a usb3 device, but plugged into usb2 ports.

If I go to the shell and unplug the device then plug it back in here are the errors I get (partial, some scroll off screen):
[CODE](da0:umass-sim0:0:0:0): Error 22, Unretryable error
(da0:umass-sim0:0:0:0): Read(10). CDB: 28 00 00 ee 4f ff 00 00 01 00
(da0:umass-sim0:0:0:0): CAM status: SCSI Status Error
(da0:umass-sim0:0:0:0): SCSI status Check Condition
(da0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:21,0 (Logical block address out of range)
[/CODE]
and then it repeats the same error, I think I saw some flash by that said Write() instead of Read(10) during one of my attempts.

I have tried reinitializing the disk using windows disk manager which seemed to work fine. Drive behaves as expected in my windows machines and linux CentOS.
This has happened both on a Dell R610 and a HP touchsmart tx2 laptop.  The dell R610 works with FreeBSD except for this memory stick.


If I drop to shell during installation I can get the following information:
[CODE]camcontrol inquiry da1:
pass3: <MX MXUB3SES-8GB 1.00> Removable Direct Access SCSI-6 device
pass3: Serial Number 000000000000000133
pass3: 40.000MB/s transfers

dmesg | grep ^da1
da1: at umass-sim1 bus 1 scbus 4 target 0 lun 0
da1: <MX MXUB3SES-8GB 1.00> Removable Direct Access SCSI-6 device
da1: Serial Number 000000000000000133
da1: 40.000MB/s transfers
da1: 7626MB (15618048 512 byte secotrs: 255H 63S/T 972C)
da1: quirks=0x2<NO_6_BYTE>
[/CODE]
Seems similar, but different to bug 194062

If from shell before trying to install I do a [CMD]sysctl kern.cam.da.1.minimum_cmd_size=16[/CMD] then I am able to get farther showing the "please review the disk setup" screen, and instead of giving read errors it gives the following error after hitting commit:
[CODE]write(16). cdb: 8a 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00
cam status: ccb request completed with an error
error 5, retries exhausted[/CODE]
Comment 1 Chris Baker 2015-03-17 02:14:28 UTC
Initially I had posted to the forums: https://forums.freebsd.org/threads/mx-es-usb-drive-by-mach-xtreme-error-22.50845/
Comment 2 Hans Petter Selasky freebsd_committer 2015-03-17 07:54:08 UTC
Hi,

The following series of digits indicate the location of the disk access "00 ee 4f ff". Assuming the block size is 512 bytes, this is location

0xee4fff*512 = 7.9964e+09

which is below 8GB. Can you extract information about how many 512-byte blocks the disk has under Linux and what the block size is?

--HPS
Comment 3 Chris Baker 2015-03-17 15:22:52 UTC
on linux "fdisk -l" lists the following:
Disk /dev/sdb: 7988 MB, 7988051968 bytes, 15601664 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

"cat /sys/class/block/sda/size" also reports block size of 15601664
Comment 4 Hans Petter Selasky freebsd_committer 2015-03-17 15:50:59 UTC
Hi,

dec2hex(15601664) = EE1000

The LBA=0xee4fff is then invalid. Did you check that the partition table and MBR is valid?

Maybe you can dump them:

gpart show /dev/daX

--HPS
Comment 5 Chris Baker 2015-03-17 16:37:05 UTC
from within linux parted -l shows
Model: MX MXUB3SES-8GB (scsi)
Disk /dev/sdb: 7988MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

Number  Start   End     Size    Type     File system  Flags
 1      1049kB  525MB   524MB   primary  xfs          boot
 2      525MB   7988MB  7463MB  primary               lvm


from FreeBSD installation shell gpart show gives the following
63        15617985 da0 MBR (7.4G)
63        1985         - free - (993K)
2048      1024000    1 linux-data [active] (500M)
1026048   14575616   2 linux-lvm (7.0G)
15601664  16384        - free - (8.0M)
Comment 6 Chris Baker 2015-03-17 17:20:21 UTC
The results from gpart seems strange, the last section of free space seems to start after the end of the disk if I am interpreting the results right.  

If i plug the drive into windows and use R-Studio it lists the following partition info:

Disk 
Start: 0
Size: 15601664 Secorts

1st Partition:
Name: Partition2
Paritition Number: 0
Type: Unknown (0x8e) 
Offset: 1026048 Sectors
Size: 14575616 Sectors

2nd Partition:
Name: g:
Type: Ext2FS/XIAFS
Partition Number: 1
Offset: 2048 Sectors
Size: 1024000 Sectors
Comment 7 Chris Baker 2015-03-17 17:34:57 UTC
gpart seems to be showing more sectors then it actually has, the first line from gpart: 63        15617985 lists the sector size right?

gpart list shows the last sector as 15618047 and first sector as 63
Comment 8 Hans Petter Selasky freebsd_committer 2015-03-18 07:15:30 UTC
Hi,

The MBR given size is invalid: dec2hex(15617985) = EE4FC1 which is above EE1000.

That's most likely why the disk is not working. Try correcting that first.

--HPS
Comment 9 Chris Baker 2015-03-18 13:04:43 UTC
How would I go about changing the size in the MBR?  I had already recreated it once using windows diskpart clean all which overwrites the entire disk with 0s including the MBR and then created a new MBR and new partition which had the exact same result.

Also I am still not getting why FreeBSD is showing a different size then Windows and Linux.  
Windows shows: 15601664 sectors
Linux shows: 15601664 sectors
FreeBSD shows: 15617985 sector (but with offset of 63 sectors) size using gpart show
FreeBSD shows: 15618048 sectors using diskinfo
Comment 10 Hans Petter Selasky freebsd_committer 2015-03-18 13:14:33 UTC
Hi,

There is an old tool called "fdisk" which can edit the MBR:

man fdisk

--HPS
Comment 11 Chris Baker 2015-03-18 13:33:24 UTC
well running fdisk -B /dev/da0 from FreeBSD resulted in the same errors as when attempting to install FreeBSD to the drive 
(da0:umass-sim0:0:0:0): Error 22, Unretryable error
(da0:umass-sim0:0:0:0): Read(10). CDB: 28 00 00 ee 4f ff 00 00 01 00
(da0:umass-sim0:0:0:0): CAM status: SCSI Status Error
(da0:umass-sim0:0:0:0): SCSI status Check Condition
(da0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:21,0 (Logical block address out of range)
Comment 12 Hans Petter Selasky freebsd_committer 2015-03-18 13:35:27 UTC
Hi,

If wiping the disk is OK, try this:

fdisk -BI /dev/daX

--HPS
Comment 13 Chris Baker 2015-03-18 13:43:07 UTC
fdisk -BI /dev/da0 gives the following error several times:
Error 22, unretryable error
read(10). CDB: 28 00 00 ee 44 ca 00 00 01 00
cam status: scsi status error
scsi status: check condition
scsi sense: illegal request asc:21,0 (logical block address out of range)
Comment 14 Hans Petter Selasky freebsd_committer 2015-03-18 13:47:23 UTC
Hi,

Can you try something like this from Linux:

dd if=/dev/zero of=/dev/xxx bs=512 count=1

Then insert the disk into freebsd again?

--HPS
Comment 15 Chris Baker 2015-03-18 14:13:41 UTC
I ran the DD command from linux and it worked as expected, all partition info was erased.
put back into freebsd and ran fdisk -BI /dev/da0 which gives the following error several times:
Error 22, unretryable error
read(10). CDB: 28 00 00 ee 44 ca 00 00 01 00
cam status: scsi status error
scsi status: check condition
scsi sense: illegal request asc:21,0 (logical block address out of range)
Comment 16 Hans Petter Selasky freebsd_committer 2015-03-18 16:18:28 UTC
What does:

gpart show /dev/da0

output after the MBR erase?

--HPS
Comment 17 Hans Petter Selasky freebsd_committer 2015-03-18 16:19:30 UTC
Also try to zero the whole memory stick from Linux.

There might be a GPT partition left somewhere.

--HPS
Comment 18 Chris Baker 2015-03-18 17:42:08 UTC
a ran in linux a dd if=/dev/zero of=/dev/sdX to write zeros to the entire usb drive. that operation completed successfully.

Then back to freebsd 
diskinfo -c /dev/da0 shows:
15618048 sectors
gpart show /dev/da0:
No such geom: /dev/da0
Comment 19 Chris Baker 2015-03-18 17:47:42 UTC
trying to do gpart create -s mbr da1 resulted in the same errors:
(da0:umass-sim0:0:0:0): Error 22, Unretryable error
(da0:umass-sim0:0:0:0): Read(10). CDB: 28 00 00 ee 4f ff 00 00 01 00
(da0:umass-sim0:0:0:0): CAM status: SCSI Status Error
(da0:umass-sim0:0:0:0): SCSI status Check Condition
(da0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:21,0 (Logical block address out of range)
Comment 20 Chris Baker 2015-03-18 17:48:46 UTC
after the gpart create command, the gpart show command does show the following:
63  15617985 da0 mbr (7.5g)
63 15617985 -free-
Comment 21 Chris Baker 2015-03-18 18:30:23 UTC
After all of this I tried installing again.  Got the same errors, but this time it did finish the install.  rebooted and it got several passes of the same error message and then gotto mountroot: waiting for 
device /dev/da1s1a
mounting from ufs:/dev/das1a failed with error 19.
Comment 22 Chris Baker 2015-03-18 19:28:51 UTC
This seems very similar to this post:
https://www.mail-archive.com/freebsd-bugs@freebsd.org/msg16614.html
Comment 23 Hans Petter Selasky freebsd_committer 2015-03-18 19:44:39 UTC
Hi,

You can try adding:

+       {
+               {T_DIRECT, SIP_MEDIA_REMOVABLE, "MX", "MXUB3SES*",
+                "*"}, /*quirks*/ DA_Q_NO_RC16
+       },

To the scsi da quirks table.

--HPS
Comment 24 Chris Baker 2015-03-19 13:18:14 UTC
I believe this requires recompiling the kernel correct?  If so I have not done that before so it may take me a while.  I'll report back after I get it done.
Comment 25 Hans Petter Selasky freebsd_committer 2015-03-19 14:45:57 UTC
Yes, I believe so.

--HPS
Comment 26 Chris Baker 2015-03-19 22:20:13 UTC
I added the code you suggested to scsi_da.c and recompiled the kernel.  after installing the new kernel and rebooting the issue seems to be resolved.  I was able to create partitions on the device without a problem.  Now I just need to figure out how to copy the kernel onto an installation image.
Comment 27 Chris Baker 2015-03-19 22:58:42 UTC
In an effort to test the new kernel during installation I did the following (which feels like the wrong way to do this, but i don't know the correct way, especially wrong because I compiled the kernel on 11.0 used 9.3 for the following):
Created USB install disk as normal
Mounted the USB install disk in the FreeBSD system with the new kernel
Mounted the freebsd-ufs partition to /mnt/usb
deleted the kernel directory from /mnt/usb/boot/kernel
realized there was not enough space to copy the new kernel
deleted the freebsd-swap partition
expanded the partition with gpart resize to 1GB
expanded the filesystem with growfs
created a new freebsd-swap partition

Then i booted the computer with the USB install disk.  It failed to find the boot partition so i had to manually specify: ufs:/dev/da0p3

the installer booted but flashed by a couple of errors that I did not get written down.  

I inserted the MX-ES flash drive, and the system recognized it without any errors

I proceeded to install to the MX-ES flash drive.
The installation succeeded but upon reboot had a couple of errrors
first it couldn't mountroot due to drive number change so i had to type ufs:/da0s1
after that the boot process began and I saw several of the same error messages as before but the system did boot

After it booted I copied the new kernel over to /boot/kernel 
during the copy got an error: block order reversal for bufwait (/usr/src/sys/kern/vfs_bio.c) and dirhash (/usr/src/sys/ufs/ufs/ufs_dirhash.c)

then the copy finished 
I then changed the entry in /etc/fstab to have the right da number.
and then I rebooted
After rebooting the system did come up.  No more usb errors.  I did get some NOQUEUE opendaemonsocket errors about SMTP but i suspect that may be because of the version differences.
Comment 28 Chris Baker 2015-03-20 15:35:17 UTC
Because I had a few errors on my last attempt I tried it again.  This time Using 9.3 for compiling the kernel, and 9.3 installation media.  Same steps, but this time completed with no errors.
Comment 29 Chris Baker 2015-03-20 16:01:46 UTC
I also tried a third attempt, this time updating the kernel on the usb memstick image in bot /boot/kernel and in /usr/freebsd-dist/kernel.txz
Also updated the checksum in the MANIFEST file.  
After completing those steps I started the installation onto the MX-ES thumbdrive.  
During the last step of the install I changed the disk numbers in /etc/fstab to match what I knew they would be.

Rebooted and the system booted fine with no errors.  

I believe that the patch to scsi_da.c has corrected the problem with the MX-ES drives.  

Will the PR suffice for getting it committed or should I submit a new one that follows the guidelines here: http://www.root.org/~nate/freebsd/scsi/quirks.html
Comment 30 Hans Petter Selasky freebsd_committer 2015-03-20 17:40:08 UTC
Hi,

I will make a patch for this issue.

This PR is enough.

Thank you for your patience!

--HPS
Comment 31 Chris Baker 2015-03-23 15:33:59 UTC
Ok. Thanks.
Comment 32 commit-hook freebsd_committer 2015-03-25 13:29:11 UTC
A commit references this bug:

Author: hselasky
Date: Wed Mar 25 13:28:14 UTC 2015
New revision: 280597
URL: https://svnweb.freebsd.org/changeset/base/280597

Log:
  Add DA_Q_NO_RC16 quirk for USB mass storage device.

  PR:		198647
  MFC after:	1 week

Changes:
  head/sys/cam/scsi/scsi_da.c
Comment 33 Harald Linden 2015-04-01 10:49:05 UTC
Hi,

We have been forced to do some testing because we have quite a few machines running FreeBSD from these sticks. This patch does not cover all of them. Here is a list of the IDs that we have found the same problem with:


MXUB3SESU-32G
MXUB3SES-16G
Innostor Innostor

The following are not covered by the patch yet:

MXUB3MES-8GB
MXUB3MES-16GB
MXUB3MES-16GB
MXUB3MLX-32GB
MXUB3MES-8GB
Comment 34 Harald Linden 2015-04-01 12:01:36 UTC
...and MXUB3MESU-32GB
Comment 35 Hans Petter Selasky freebsd_committer 2015-04-01 13:21:54 UTC
Hi,

Will extending the existing quirk in 11-current to "MXUB3*" solve your problem?

--HPS
Comment 36 Harald Linden 2015-04-01 15:20:51 UTC
(In reply to Hans Petter Selasky from comment #35)

Yep, that would likely cover all the various sticks from MX that we've seen this problem in.
Comment 37 commit-hook freebsd_committer 2015-04-21 22:56:10 UTC
A commit references this bug:

Author: delphij
Date: Tue Apr 21 22:55:53 UTC 2015
New revision: 281840
URL: https://svnweb.freebsd.org/changeset/base/281840

Log:
  Extend DA_Q_NO_RC16 to MXUB3* devices.

  PR:		kern/198647
  MFC after:	2 weeks

Changes:
  head/sys/cam/scsi/scsi_da.c
Comment 38 commit-hook freebsd_committer 2015-05-05 20:04:45 UTC
A commit references this bug:

Author: hselasky
Date: Tue May  5 20:04:02 UTC 2015
New revision: 282512
URL: https://svnweb.freebsd.org/changeset/base/282512

Log:
  MFC r280597:
  Add DA_Q_NO_RC16 quirk for USB mass storage device.

  PR:		198647

Changes:
_U  stable/10/
  stable/10/sys/cam/scsi/scsi_da.c
Comment 39 Hans Petter Selasky freebsd_committer 2015-05-05 20:05:50 UTC
Does this patch need to go to 9-stable?
Comment 40 commit-hook freebsd_committer 2015-05-08 22:23:00 UTC
A commit references this bug:

Author: delphij
Date: Fri May  8 22:22:52 UTC 2015
New revision: 282670
URL: https://svnweb.freebsd.org/changeset/base/282670

Log:
  MFC r281840:

  Extend DA_Q_NO_RC16 to MXUB3* devices.

  PR:		kern/198647

Changes:
_U  stable/10/
  stable/10/sys/cam/scsi/scsi_da.c