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]
Initially I had posted to the forums: https://forums.freebsd.org/threads/mx-es-usb-drive-by-mach-xtreme-error-22.50845/
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
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
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
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)
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
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
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
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
Hi, There is an old tool called "fdisk" which can edit the MBR: man fdisk --HPS
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)
Hi, If wiping the disk is OK, try this: fdisk -BI /dev/daX --HPS
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)
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
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)
What does: gpart show /dev/da0 output after the MBR erase? --HPS
Also try to zero the whole memory stick from Linux. There might be a GPT partition left somewhere. --HPS
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
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)
after the gpart create command, the gpart show command does show the following: 63 15617985 da0 mbr (7.5g) 63 15617985 -free-
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.
This seems very similar to this post: https://www.mail-archive.com/freebsd-bugs@freebsd.org/msg16614.html
Hi, You can try adding: + { + {T_DIRECT, SIP_MEDIA_REMOVABLE, "MX", "MXUB3SES*", + "*"}, /*quirks*/ DA_Q_NO_RC16 + }, To the scsi da quirks table. --HPS
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.
Yes, I believe so. --HPS
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.
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.
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.
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
Hi, I will make a patch for this issue. This PR is enough. Thank you for your patience! --HPS
Ok. Thanks.
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
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
...and MXUB3MESU-32GB
Hi, Will extending the existing quirk in 11-current to "MXUB3*" solve your problem? --HPS
(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.
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
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
Does this patch need to go to 9-stable?
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