Re: USB Flash drive problem with 9.0

2012-03-31 Thread Alexander Motin 

On 03/31/12 07:57, Kaho Toshikazu wrote:

Could you collect more information about what's exactly happens
with the device? Can you execute some camcontrol inquiry or
camcontrol readcap commands after kernel misdetected size with
READ CAPACITY(16)?

If yes (device is still alive), could you run these commands
(with proper device name) and send me the output files:
camcontrol cmd da0 -E -v -c 12 00 00 00 80 00 -i 128 -  INQ.res
camcontrol cmd da0 -E -v -c 9e 10 00 00 00 00 00 00 00 00 00 00
00 20 00 00 -i 32 -  RC16.result


usbconfig -d 0.3 dump_device_desc

ugen0.3:Mass Storage Device JetFlash  at usbus0, cfg=0 md=HOST spd=HIGH 
(480Mbps) pwr=ON

   bLength = 0x0012
   bDescriptorType = 0x0001
   bcdUSB = 0x0200
   bDeviceClass = 0x
   bDeviceSubClass = 0x
   bDeviceProtocol = 0x
   bMaxPacketSize0 = 0x0040
   idVendor = 0x8564
   idProduct = 0x1000
   bcdDevice = 0x1100
   iManufacturer = 0x0001JetFlash
   iProduct = 0x0002Mass Storage Device
   iSerialNumber = 0x000383CA7S8M3LD8UGSF
   bNumConfigurations = 0x0001

-- dmesg without any quirks --
ugen0.3:JetFlash  at usbus0
umass0:JetFlash Mass Storage Device, class 0/0, rev 2.00/11.00, addr 3  on 
usbus0
da0 at umass-sim0 bus 0 scbus11 target 0 lun 0
da0:JetFlash Transcend 16GB 1100  Removable Direct Access SCSI-4 device
da0: 40.000MB/s transfers
da0: 17454747090944MB (71776119061217281 512 byte sectors: 64H 32S/T 0C)

hexdump -Cv RC16.result
  00 ff 00 00 00 00 00 00  00 00 02 00 00 00 00 00  ||
0010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
0020

`hexdump -Cv INQ.res`
  00 80 04 02 1f 73 6d 69  4a 65 74 46 6c 61 73 68  |.smiJetFlash|
0010  54 72 61 6e 73 63 65 6e  64 20 31 36 47 42 20 20  |Transcend 16GB  |
0020  31 31 30 30 00 80 02 00  00 00 00 00 00 00 00 00  |1100|
0030  00 00 00 00 00 00 28 00  03 01 82 06 00 3f 00 00  |..(..?..|
0040  00 00 28 32 00 00 00 00  00 00 00 50 50 00 00 00  |..(2...PP...|
0050  30 50 50 00 00 00 00 00  00 00 00 21 84 84 21 1e  |0PP!..!.|
0060  00 03 48 00 00 c0 00 00  00 00 00 00 00 00 00 00  |..H..@..|
0070  00 00 00 00 00 00 01 00  24 15 01 09 00 00 00 00  |$...|
0080

-- dmesg with UQ_MSC_NO_INQUIRY --
ugen0.3:JetFlash  at usbus0
umass0:JetFlash Mass Storage Device, class 0/0, rev 2.00/11.00, addr 3  on 
usbus0
da0 at umass-sim0 bus 0 scbus11 target 0 lun 0
da0: Removable Direct Access SCSI-2 device
da0: 40.000MB/s transfers
da0: 15477MB (31696896 512 byte sectors: 255H 63S/T 1973C)


   Hmm, READ CAPACITY(16) can be used and device is alive.
With UQ_MSC_NO_INQUIRY, after run camcontrol, dd can read normally.
Without UQ_MSC_NO_INQUIRY, camcontrol can return something,
but dd can not be usable.


Thank you.

I see number of inconsistencies there. Device reports support for SPC-2 
spec, but has PROTECT bit set in INQUIRY data, which is defined only 
since SPC-3 and reserved in SPC-2. Protection information, same as READ 
CAPACITY(16) command, defined only from SPC-3. SPC-2 devices should not 
know about it, returning error, but this device doesn't return error, 
instead returning something strange (correct sector size, but wrong 
number of sectors).


I see the only clean solution in following specs more closely and not 
checking PROTECT bit for pre-SPC-3 devices. I don't know why Linux does 
for all SCSI-3/SPC devices, but for this device result is fatal.


Please try the following patch. It should disable use of READ 
CAPACITY(16) in your case.


--- scsi_da.c   (revision 233697)
+++ scsi_da.c   (working copy)
@@ -1631,9 +1631,7 @@
softc-minimum_cmd_size = 16;

/* Predict whether device may support READ CAPACITY(16). */
-   if (SID_ANSI_REV(cgd-inq_data) = SCSI_REV_SPC3 ||
-   (SID_ANSI_REV(cgd-inq_data) = SCSI_REV_SPC 
-(cgd-inq_data.spc3_flags  SPC3_SID_PROTECT))) {
+   if (SID_ANSI_REV(cgd-inq_data) = SCSI_REV_SPC3) {
softc-flags |= DA_FLAG_CAN_RC16;
softc-state = DA_STATE_PROBE2;
}


--
Alexander Motin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: USB Flash drive problem with 9.0

2012-03-31 Thread Kaho Toshikazu 
  Hello Alexander Motin,

Your patch solves the problem. Thank you.

--
Kaho Toshikazu  

 On 03/31/12 07:57, Kaho Toshikazu wrote:
  Could you collect more information about what's exactly happens
  with the device? Can you execute some camcontrol inquiry or
  camcontrol readcap commands after kernel misdetected size with
  READ CAPACITY(16)?
 
  If yes (device is still alive), could you run these commands
  (with proper device name) and send me the output files:
  camcontrol cmd da0 -E -v -c 12 00 00 00 80 00 -i 128 -  INQ.res
  camcontrol cmd da0 -E -v -c 9e 10 00 00 00 00 00 00 00 00 00 00
  00 20 00 00 -i 32 -  RC16.result
 
  usbconfig -d 0.3 dump_device_desc
 
  ugen0.3:Mass Storage Device JetFlash  at usbus0, cfg=0 md=HOST spd=HIGH 
  (480Mbps) pwr=ON
 
 bLength = 0x0012
 bDescriptorType = 0x0001
 bcdUSB = 0x0200
 bDeviceClass = 0x
 bDeviceSubClass = 0x
 bDeviceProtocol = 0x
 bMaxPacketSize0 = 0x0040
 idVendor = 0x8564
 idProduct = 0x1000
 bcdDevice = 0x1100
 iManufacturer = 0x0001JetFlash
 iProduct = 0x0002Mass Storage Device
 iSerialNumber = 0x000383CA7S8M3LD8UGSF
 bNumConfigurations = 0x0001
 
  -- dmesg without any quirks --
  ugen0.3:JetFlash  at usbus0
  umass0:JetFlash Mass Storage Device, class 0/0, rev 2.00/11.00, addr 3  
  on usbus0
  da0 at umass-sim0 bus 0 scbus11 target 0 lun 0
  da0:JetFlash Transcend 16GB 1100  Removable Direct Access SCSI-4 device
  da0: 40.000MB/s transfers
  da0: 17454747090944MB (71776119061217281 512 byte sectors: 64H 32S/T 0C)
 
  hexdump -Cv RC16.result
    00 ff 00 00 00 00 00 00  00 00 02 00 00 00 00 00  
  ||
  0010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  
  ||
  0020
 
  `hexdump -Cv INQ.res`
    00 80 04 02 1f 73 6d 69  4a 65 74 46 6c 61 73 68  
  |.smiJetFlash|
  0010  54 72 61 6e 73 63 65 6e  64 20 31 36 47 42 20 20  |Transcend 16GB 
   |
  0020  31 31 30 30 00 80 02 00  00 00 00 00 00 00 00 00  
  |1100|
  0030  00 00 00 00 00 00 28 00  03 01 82 06 00 3f 00 00  
  |..(..?..|
  0040  00 00 28 32 00 00 00 00  00 00 00 50 50 00 00 00  
  |..(2...PP...|
  0050  30 50 50 00 00 00 00 00  00 00 00 21 84 84 21 1e  
  |0PP!..!.|
  0060  00 03 48 00 00 c0 00 00  00 00 00 00 00 00 00 00  
  |..H..@..|
  0070  00 00 00 00 00 00 01 00  24 15 01 09 00 00 00 00  
  |$...|
  0080
 
  -- dmesg with UQ_MSC_NO_INQUIRY --
  ugen0.3:JetFlash  at usbus0
  umass0:JetFlash Mass Storage Device, class 0/0, rev 2.00/11.00, addr 3  
  on usbus0
  da0 at umass-sim0 bus 0 scbus11 target 0 lun 0
  da0: Removable Direct Access SCSI-2 device
  da0: 40.000MB/s transfers
  da0: 15477MB (31696896 512 byte sectors: 255H 63S/T 1973C)
 
 
 Hmm, READ CAPACITY(16) can be used and device is alive.
  With UQ_MSC_NO_INQUIRY, after run camcontrol, dd can read normally.
  Without UQ_MSC_NO_INQUIRY, camcontrol can return something,
  but dd can not be usable.
 
 Thank you.
 
 I see number of inconsistencies there. Device reports support
 for SPC-2 
 spec, but has PROTECT bit set in INQUIRY data, which is defined
 only since SPC-3 and reserved in SPC-2. Protection information,
 same as READ CAPACITY(16) command, defined only from
 SPC-3. SPC-2 devices should not know about it, returning error,
 but this device doesn't return error, instead returning
 something strange (correct sector size, but wrong number of
 sectors).
 
 I see the only clean solution in following specs more closely
 and not checking PROTECT bit for pre-SPC-3 devices. I don't know
 why Linux does for all SCSI-3/SPC devices, but for this device
 result is fatal.
 
 Please try the following patch. It should disable use of READ
 CAPACITY(16) in your case.
 
 --- scsi_da.c   (revision 233697)
 +++ scsi_da.c   (working copy)
 @@ -1631,9 +1631,7 @@
 softc-minimum_cmd_size = 16;
 
 /* Predict whether device may support READ CAPACITY(16). */
 -   if (SID_ANSI_REV(cgd-inq_data) = SCSI_REV_SPC3 ||
 -   (SID_ANSI_REV(cgd-inq_data) = SCSI_REV_SPC 
 -(cgd-inq_data.spc3_flags  SPC3_SID_PROTECT))) {
 +   if (SID_ANSI_REV(cgd-inq_data) = SCSI_REV_SPC3) {
 softc-flags |= DA_FLAG_CAN_RC16;
 softc-state = DA_STATE_PROBE2;
 }
 
 
 -- 
 Alexander Motin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: USB Flash drive problem with 9.0

2012-03-31 Thread Alexander Motin 

On 03/31/12 13:40, Kaho Toshikazu wrote:

Your patch solves the problem. Thank you.


Committed to HEAD at r233746.


On 03/31/12 07:57, Kaho Toshikazu wrote:

Could you collect more information about what's exactly happens
with the device? Can you execute some camcontrol inquiry or
camcontrol readcap commands after kernel misdetected size with
READ CAPACITY(16)?

If yes (device is still alive), could you run these commands
(with proper device name) and send me the output files:
camcontrol cmd da0 -E -v -c 12 00 00 00 80 00 -i 128 -   INQ.res
camcontrol cmd da0 -E -v -c 9e 10 00 00 00 00 00 00 00 00 00 00
00 20 00 00 -i 32 -   RC16.result


usbconfig -d 0.3 dump_device_desc

ugen0.3:Mass Storage Device JetFlash   at usbus0, cfg=0 md=HOST spd=HIGH 
(480Mbps) pwr=ON

bLength = 0x0012
bDescriptorType = 0x0001
bcdUSB = 0x0200
bDeviceClass = 0x
bDeviceSubClass = 0x
bDeviceProtocol = 0x
bMaxPacketSize0 = 0x0040
idVendor = 0x8564
idProduct = 0x1000
bcdDevice = 0x1100
iManufacturer = 0x0001JetFlash
iProduct = 0x0002Mass Storage Device
iSerialNumber = 0x000383CA7S8M3LD8UGSF
bNumConfigurations = 0x0001

-- dmesg without any quirks --
ugen0.3:JetFlash   at usbus0
umass0:JetFlash Mass Storage Device, class 0/0, rev 2.00/11.00, addr 3   on 
usbus0
da0 at umass-sim0 bus 0 scbus11 target 0 lun 0
da0:JetFlash Transcend 16GB 1100   Removable Direct Access SCSI-4 device
da0: 40.000MB/s transfers
da0: 17454747090944MB (71776119061217281 512 byte sectors: 64H 32S/T 0C)

hexdump -Cv RC16.result
  00 ff 00 00 00 00 00 00  00 00 02 00 00 00 00 00  ||
0010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
0020

`hexdump -Cv INQ.res`
  00 80 04 02 1f 73 6d 69  4a 65 74 46 6c 61 73 68  |.smiJetFlash|
0010  54 72 61 6e 73 63 65 6e  64 20 31 36 47 42 20 20  |Transcend 16GB  |
0020  31 31 30 30 00 80 02 00  00 00 00 00 00 00 00 00  |1100|
0030  00 00 00 00 00 00 28 00  03 01 82 06 00 3f 00 00  |..(..?..|
0040  00 00 28 32 00 00 00 00  00 00 00 50 50 00 00 00  |..(2...PP...|
0050  30 50 50 00 00 00 00 00  00 00 00 21 84 84 21 1e  |0PP!..!.|
0060  00 03 48 00 00 c0 00 00  00 00 00 00 00 00 00 00  |..H..@..|
0070  00 00 00 00 00 00 01 00  24 15 01 09 00 00 00 00  |$...|
0080

-- dmesg with UQ_MSC_NO_INQUIRY --
ugen0.3:JetFlash   at usbus0
umass0:JetFlash Mass Storage Device, class 0/0, rev 2.00/11.00, addr 3   on 
usbus0
da0 at umass-sim0 bus 0 scbus11 target 0 lun 0
da0:   Removable Direct Access SCSI-2 device
da0: 40.000MB/s transfers
da0: 15477MB (31696896 512 byte sectors: 255H 63S/T 1973C)


Hmm, READ CAPACITY(16) can be used and device is alive.
With UQ_MSC_NO_INQUIRY, after run camcontrol, dd can read normally.
Without UQ_MSC_NO_INQUIRY, camcontrol can return something,
but dd can not be usable.


Thank you.

I see number of inconsistencies there. Device reports support
for SPC-2
spec, but has PROTECT bit set in INQUIRY data, which is defined
only since SPC-3 and reserved in SPC-2. Protection information,
same as READ CAPACITY(16) command, defined only from
SPC-3. SPC-2 devices should not know about it, returning error,
but this device doesn't return error, instead returning
something strange (correct sector size, but wrong number of
sectors).

I see the only clean solution in following specs more closely
and not checking PROTECT bit for pre-SPC-3 devices. I don't know
why Linux does for all SCSI-3/SPC devices, but for this device
result is fatal.

Please try the following patch. It should disable use of READ
CAPACITY(16) in your case.

--- scsi_da.c   (revision 233697)
+++ scsi_da.c   (working copy)
@@ -1631,9 +1631,7 @@
 softc-minimum_cmd_size = 16;

 /* Predict whether device may support READ CAPACITY(16). */
-   if (SID_ANSI_REV(cgd-inq_data)= SCSI_REV_SPC3 ||
-   (SID_ANSI_REV(cgd-inq_data)= SCSI_REV_SPC
-(cgd-inq_data.spc3_flags  SPC3_SID_PROTECT))) {
+   if (SID_ANSI_REV(cgd-inq_data)= SCSI_REV_SPC3) {
 softc-flags |= DA_FLAG_CAN_RC16;
 softc-state = DA_STATE_PROBE2;
 }



--
Alexander Motin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: USB Flash drive problem with 9.0

2012-03-30 Thread Alexander Motin 

On 03/26/12 02:55, Kaho Toshikazu wrote:

   Hello, Andriy Gapon and ML members,


Date: Sun, 25 Mar 2012 13:15:26 +0300

on 25/03/2012 08:02 Kaho Toshikazu said the following:

   Hello Andriy Gapon,
Thank you for your comment.


Message-ID:4f6d9672.4050...@freebsd.org
Date: Sat, 24 Mar 2012 11:40:02 +0200

on 24/03/2012 04:17 Kaho Toshikazu said the following:

   Hello,

   I have a similar problem with Transcend 16GB USB flash. When the flash
is plugged, FreeBSD attache it, but reports very big capacity and can
not read/write it. UQ_MSC_NO_INQUIRY makes jobs in my machines.
10-current and 8-stable have same problem, and 9-stable is not tested.


Could the problem be related to r229288 (r232943 in stable/9)?
The dates below match the MFC date 2012-03-13.


   10-current r26 with reveting only scsi_da.c changed by
r233288 has same problem. Should I revert whole system ?



Sorry, it seems that I copied wrong revisions into my email.
They should have been r232941 for stable/9 and r228846 for head.


   Yes, r228846 for current is related this problem. 10-current reverting
scsi/scsi_da.c introduced by r228846 detects valid capacity and
can read/write USB flash. USB flash may be died of READ CAPACITY(16).


Could you collect more information about what's exactly happens with the 
device? Can you execute some camcontrol inquiry or camcontrol readcap 
commands after kernel misdetected size with READ CAPACITY(16)?


If yes (device is still alive), could you run these commands (with 
proper device name) and send me the output files:

camcontrol cmd da0 -E -v -c 12 00 00 00 80 00 -i 128 -  INQ.res
camcontrol cmd da0 -E -v -c 9e 10 00 00 00 00 00 00 00 00 00 00 00 20 
00 00 -i 32 -  RC16.result


--
Alexander Motin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: USB Flash drive problem with 9.0

2012-03-30 Thread Kaho Toshikazu 
  Hello Alexander Motin,

 Could you collect more information about what's exactly happens
 with the device? Can you execute some camcontrol inquiry or
 camcontrol readcap commands after kernel misdetected size with
 READ CAPACITY(16)?
 
 If yes (device is still alive), could you run these commands
 (with proper device name) and send me the output files:
 camcontrol cmd da0 -E -v -c 12 00 00 00 80 00 -i 128 -  INQ.res
 camcontrol cmd da0 -E -v -c 9e 10 00 00 00 00 00 00 00 00 00 00
 00 20 00 00 -i 32 -  RC16.result

usbconfig -d 0.3 dump_device_desc

ugen0.3: Mass Storage Device JetFlash at usbus0, cfg=0 md=HOST spd=HIGH 
(480Mbps) pwr=ON

  bLength = 0x0012 
  bDescriptorType = 0x0001 
  bcdUSB = 0x0200 
  bDeviceClass = 0x 
  bDeviceSubClass = 0x 
  bDeviceProtocol = 0x 
  bMaxPacketSize0 = 0x0040 
  idVendor = 0x8564 
  idProduct = 0x1000 
  bcdDevice = 0x1100 
  iManufacturer = 0x0001  JetFlash
  iProduct = 0x0002  Mass Storage Device
  iSerialNumber = 0x0003  83CA7S8M3LD8UGSF
  bNumConfigurations = 0x0001 

-- dmesg without any quirks --
ugen0.3: JetFlash at usbus0
umass0: JetFlash Mass Storage Device, class 0/0, rev 2.00/11.00, addr 3 on 
usbus0
da0 at umass-sim0 bus 0 scbus11 target 0 lun 0
da0: JetFlash Transcend 16GB 1100 Removable Direct Access SCSI-4 device 
da0: 40.000MB/s transfers
da0: 17454747090944MB (71776119061217281 512 byte sectors: 64H 32S/T 0C)

hexdump -Cv RC16.result
  00 ff 00 00 00 00 00 00  00 00 02 00 00 00 00 00  ||
0010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
0020

`hexdump -Cv INQ.res`
  00 80 04 02 1f 73 6d 69  4a 65 74 46 6c 61 73 68  |.smiJetFlash|
0010  54 72 61 6e 73 63 65 6e  64 20 31 36 47 42 20 20  |Transcend 16GB  |
0020  31 31 30 30 00 80 02 00  00 00 00 00 00 00 00 00  |1100|
0030  00 00 00 00 00 00 28 00  03 01 82 06 00 3f 00 00  |..(..?..|
0040  00 00 28 32 00 00 00 00  00 00 00 50 50 00 00 00  |..(2...PP...|
0050  30 50 50 00 00 00 00 00  00 00 00 21 84 84 21 1e  |0PP!..!.|
0060  00 03 48 00 00 c0 00 00  00 00 00 00 00 00 00 00  |..H..@..|
0070  00 00 00 00 00 00 01 00  24 15 01 09 00 00 00 00  |$...|
0080

-- dmesg with UQ_MSC_NO_INQUIRY --  
ugen0.3: JetFlash at usbus0
umass0: JetFlash Mass Storage Device, class 0/0, rev 2.00/11.00, addr 3 on 
usbus0
da0 at umass-sim0 bus 0 scbus11 target 0 lun 0
da0:Removable Direct Access SCSI-2 device 
da0: 40.000MB/s transfers
da0: 15477MB (31696896 512 byte sectors: 255H 63S/T 1973C)


  Hmm, READ CAPACITY(16) can be used and device is alive.
With UQ_MSC_NO_INQUIRY, after run camcontrol, dd can read normally.
Without UQ_MSC_NO_INQUIRY, camcontrol can return something,
but dd can not be usable.

--
Kaho Toshikazu


___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: USB Flash drive problem with 9.0

2012-03-25 Thread Andriy Gapon 
on 25/03/2012 08:02 Kaho Toshikazu said the following:
   Hello Andriy Gapon,
 Thank you for your comment.
 
 Message-ID: 4f6d9672.4050...@freebsd.org
 Date: Sat, 24 Mar 2012 11:40:02 +0200

 on 24/03/2012 04:17 Kaho Toshikazu said the following:
   Hello,

   I have a similar problem with Transcend 16GB USB flash. When the flash
 is plugged, FreeBSD attache it, but reports very big capacity and can
 not read/write it. UQ_MSC_NO_INQUIRY makes jobs in my machines.
 10-current and 8-stable have same problem, and 9-stable is not tested.

 Could the problem be related to r229288 (r232943 in stable/9)?
 The dates below match the MFC date 2012-03-13.
 
   10-current r26 with reveting only scsi_da.c changed by
 r233288 has same problem. Should I revert whole system ?
 

Sorry, it seems that I copied wrong revisions into my email.
They should have been r232941 for stable/9 and r228846 for head.

-- 
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: USB Flash drive problem with 9.0

2012-03-25 Thread Kaho Toshikazu 
  Hello, Andriy Gapon and ML members,

 Date: Sun, 25 Mar 2012 13:15:26 +0300

 on 25/03/2012 08:02 Kaho Toshikazu said the following:
Hello Andriy Gapon,
  Thank you for your comment.
  
  Message-ID: 4f6d9672.4050...@freebsd.org
  Date: Sat, 24 Mar 2012 11:40:02 +0200
 
  on 24/03/2012 04:17 Kaho Toshikazu said the following:
Hello,
 
I have a similar problem with Transcend 16GB USB flash. When the flash
  is plugged, FreeBSD attache it, but reports very big capacity and can
  not read/write it. UQ_MSC_NO_INQUIRY makes jobs in my machines.
  10-current and 8-stable have same problem, and 9-stable is not tested.
 
  Could the problem be related to r229288 (r232943 in stable/9)?
  The dates below match the MFC date 2012-03-13.
  
10-current r26 with reveting only scsi_da.c changed by
  r233288 has same problem. Should I revert whole system ?
  
 
 Sorry, it seems that I copied wrong revisions into my email.
 They should have been r232941 for stable/9 and r228846 for head.

  Yes, r228846 for current is related this problem. 10-current reverting
scsi/scsi_da.c introduced by r228846 detects valid capacity and
can read/write USB flash. USB flash may be died of READ CAPACITY(16).

 
 -- 
 Andriy Gapon

--
Kaho Toshikazu
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: USB Flash drive problem with 9.0

2012-03-24 Thread Andriy Gapon 
on 24/03/2012 04:17 Kaho Toshikazu said the following:
   Hello,
 
   I have a similar problem with Transcend 16GB USB flash. When the flash
 is plugged, FreeBSD attache it, but reports very big capacity and can
 not read/write it. UQ_MSC_NO_INQUIRY makes jobs in my machines.
 10-current and 8-stable have same problem, and 9-stable is not tested.

Could the problem be related to r229288 (r232943 in stable/9)?
The dates below match the MFC date 2012-03-13.

 To: freebsd-...@freebsd.org
 Subject: Re: USB Flash drive problem with 9.0
 From: Hans Petter Selasky hsela...@c2i.net
 Date: Fri, 23 Mar 2012 08:25:32 +0100
 Cc: Alexander Motin m...@freebsd.org, freebsd-current@freebsd.org, J.J. 
 Day day1...@hotmail.com
 
 On Friday 23 March 2012 06:14:08 J.J. Day wrote:
 I am upgrading a FreeBSD server and have encountered a problem with
 mounting a USB flash drive. The system was on 6.3 and I upgraded to 9.0
 using CVS repositories. The flash drive worked properly at all steps
 throughout the upgrade. However, after the OS upgrade was complete, I
 made a mistake and destroyed some of the server application.

 So, I set the
 upgraded drive aside, copied the original source drive to a different
 spare, and repeated the upgrade process taking care to verify the
 functioning of the applications during the process. When I finished the
 second time, everything worked properly except for mounting the flash
 drive.

 it appears that something changed with the OS code that reads the drive
 firmware between the first time I ran cvsup on (about) the 9th and the
 second time I ran it about the 18th.



 This is the output from the first upgrade (3/11/2012) when the drive is
 inserted:



  ugen4.2: HP at usbus4
 umass0: HP v165w, class 0/0, rev 2.00/32.76, addr 2 on usbus4
 umass0:  SCSI over Bulk-Only; quirks = 0x0100
 umass0:2:0:-1: Attached to scbus2
 da0 at umass-sim0 bus 0 scbus2 target 0 lun 0
 da0: hp v165w 3276 Removable Direct Access SCSI-4 device
 da0: 40.000MB/s transfers
 da0: 30960MB (63406080 512 byte sectors: 255H 63S/T 3946C)
 And diskinfo output:



  da0
  512 # sectorsize
  32463912960 # mediasize in bytes (30G)
  63406080# mediasize in sectors
  0   # stripesize
  0   # stripeoffset
  3946# Cylinders according to firmware.
  255 # Heads according to firmware.
  63  # Sectors according to firmware.
  AA22064F0035# Disk ident.
 This is the output from the second upgrade (3/18/2012) when the drive is
 inserted:



  ugen4.2: HP at usbus4
 umass0: HP v165w, class 0/0, rev 2.00/32.76, addr 2 on usbus4
 umass0:  SCSI over Bulk-Only; quirks = 0x0100
 umass0:2:0:-1: Attached to scbus2
 da0 at umass-sim0 bus 0 scbus2 target 0 lun 0
 da0: hp v165w 3276 Removable Direct Access SCSI-4 device
 da0: 40.000MB/s transfers
 da0: 17454747090944MB (71776119061217281 512 byte sectors: 64H 32S/T 0C)
 And diskinfo shows:

 
 Hi,
 

  da0
  512 # sectorsize
  -144115188075855360 # mediasize in bytes ()
  -281474976710655# mediasize in sectors
  0   # stripesize
  0   # stripeoffset
  -137438953471   # Cylinders according to firmware.
  64  # Heads according to firmware.
  32  # Sectors according to firmware.
  AA22064F0035# Disk ident.
 Since the size information is incorrect, the /dev/da0s1 device is not
 created and the drive cannot be mounted. The problem only happens with a
 large drive. When I use a 4GB or 8GB drive, everything works correctly.

 If there is any information that I can submit that can assist in solving
 the problem please let me know.

 
 This does not look like a USB problem. It is the SCSI/CAM layer which queries 
 over SCSI USB how big the disk is.
 
 BTW:
 
 dec2hex(17454747090944)
 ans = FE0
 
 So it looks like some additional bits have sneaked in there?
 
 dec2hex(32463912960)
 ans = 78F00
 
  0xFE0 / 0x78F00
 ans =  537.67
 
 So it looks like the mediasize was multiplied by 512 when it shouldn't.
 
 --HPS


-- 
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: USB Flash drive problem with 9.0

2012-03-24 Thread Kaho Toshikazu 
  Hello Andriy Gapon,
Thank you for your comment.

 Message-ID: 4f6d9672.4050...@freebsd.org
 Date: Sat, 24 Mar 2012 11:40:02 +0200
 
 on 24/03/2012 04:17 Kaho Toshikazu said the following:
Hello,
  
I have a similar problem with Transcend 16GB USB flash. When the flash
  is plugged, FreeBSD attache it, but reports very big capacity and can
  not read/write it. UQ_MSC_NO_INQUIRY makes jobs in my machines.
  10-current and 8-stable have same problem, and 9-stable is not tested.
 
 Could the problem be related to r229288 (r232943 in stable/9)?
 The dates below match the MFC date 2012-03-13.

  10-current r26 with reveting only scsi_da.c changed by
r233288 has same problem. Should I revert whole system ?

-- 
Kaho Toshikazu
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: USB Flash drive problem with 9.0

2012-03-23 Thread Hans Petter Selasky 
On Friday 23 March 2012 06:14:08 J.J. Day wrote:
 I am upgrading a FreeBSD server and have encountered a problem with
 mounting a USB flash drive. The system was on 6.3 and I upgraded to 9.0
 using CVS repositories. The flash drive worked properly at all steps
 throughout the upgrade. However, after the OS upgrade was complete, I
 made a mistake and destroyed some of the server application.
 
 So, I set the
 upgraded drive aside, copied the original source drive to a different
 spare, and repeated the upgrade process taking care to verify the
 functioning of the applications during the process. When I finished the
 second time, everything worked properly except for mounting the flash
 drive.
 
 it appears that something changed with the OS code that reads the drive
 firmware between the first time I ran cvsup on (about) the 9th and the
 second time I ran it about the 18th.
 
 
 
 This is the output from the first upgrade (3/11/2012) when the drive is
 inserted:
 
 
 
   ugen4.2: HP at usbus4
 umass0: HP v165w, class 0/0, rev 2.00/32.76, addr 2 on usbus4
 umass0:  SCSI over Bulk-Only; quirks = 0x0100
 umass0:2:0:-1: Attached to scbus2
 da0 at umass-sim0 bus 0 scbus2 target 0 lun 0
 da0: hp v165w 3276 Removable Direct Access SCSI-4 device
 da0: 40.000MB/s transfers
 da0: 30960MB (63406080 512 byte sectors: 255H 63S/T 3946C)
 And diskinfo output:
 
 
 
   da0
   512 # sectorsize
   32463912960 # mediasize in bytes (30G)
   63406080# mediasize in sectors
   0   # stripesize
   0   # stripeoffset
   3946# Cylinders according to firmware.
   255 # Heads according to firmware.
   63  # Sectors according to firmware.
   AA22064F0035# Disk ident.
 This is the output from the second upgrade (3/18/2012) when the drive is
 inserted:
 
 
 
   ugen4.2: HP at usbus4
 umass0: HP v165w, class 0/0, rev 2.00/32.76, addr 2 on usbus4
 umass0:  SCSI over Bulk-Only; quirks = 0x0100
 umass0:2:0:-1: Attached to scbus2
 da0 at umass-sim0 bus 0 scbus2 target 0 lun 0
 da0: hp v165w 3276 Removable Direct Access SCSI-4 device
 da0: 40.000MB/s transfers
 da0: 17454747090944MB (71776119061217281 512 byte sectors: 64H 32S/T 0C)
 And diskinfo shows:
 

Hi,

 
   da0
   512 # sectorsize
   -144115188075855360 # mediasize in bytes ()
   -281474976710655# mediasize in sectors
   0   # stripesize
   0   # stripeoffset
   -137438953471   # Cylinders according to firmware.
   64  # Heads according to firmware.
   32  # Sectors according to firmware.
   AA22064F0035# Disk ident.
 Since the size information is incorrect, the /dev/da0s1 device is not
 created and the drive cannot be mounted. The problem only happens with a
 large drive. When I use a 4GB or 8GB drive, everything works correctly.
 
 If there is any information that I can submit that can assist in solving
 the problem please let me know.
 

This does not look like a USB problem. It is the SCSI/CAM layer which queries 
over SCSI USB how big the disk is.

BTW:

dec2hex(17454747090944)
ans = FE0

So it looks like some additional bits have sneaked in there?

dec2hex(32463912960)
ans = 78F00

 0xFE0 / 0x78F00
ans =  537.67

So it looks like the mediasize was multiplied by 512 when it shouldn't.

--HPS
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: USB Flash drive problem with 9.0

2012-03-23 Thread Kaho Toshikazu 
  Hello,

  I have a similar problem with Transcend 16GB USB flash. When the flash
is plugged, FreeBSD attache it, but reports very big capacity and can
not read/write it. UQ_MSC_NO_INQUIRY makes jobs in my machines.
10-current and 8-stable have same problem, and 9-stable is not tested.

--
Kaho Toshikazu

--
To: freebsd-...@freebsd.org
Subject: Re: USB Flash drive problem with 9.0
From: Hans Petter Selasky hsela...@c2i.net
Date: Fri, 23 Mar 2012 08:25:32 +0100
Cc: Alexander Motin m...@freebsd.org, freebsd-current@freebsd.org, J.J. Day 
day1...@hotmail.com

On Friday 23 March 2012 06:14:08 J.J. Day wrote:
 I am upgrading a FreeBSD server and have encountered a problem with
 mounting a USB flash drive. The system was on 6.3 and I upgraded to 9.0
 using CVS repositories. The flash drive worked properly at all steps
 throughout the upgrade. However, after the OS upgrade was complete, I
 made a mistake and destroyed some of the server application.
 
 So, I set the
 upgraded drive aside, copied the original source drive to a different
 spare, and repeated the upgrade process taking care to verify the
 functioning of the applications during the process. When I finished the
 second time, everything worked properly except for mounting the flash
 drive.
 
 it appears that something changed with the OS code that reads the drive
 firmware between the first time I ran cvsup on (about) the 9th and the
 second time I ran it about the 18th.
 
 
 
 This is the output from the first upgrade (3/11/2012) when the drive is
 inserted:
 
 
 
   ugen4.2: HP at usbus4
 umass0: HP v165w, class 0/0, rev 2.00/32.76, addr 2 on usbus4
 umass0:  SCSI over Bulk-Only; quirks = 0x0100
 umass0:2:0:-1: Attached to scbus2
 da0 at umass-sim0 bus 0 scbus2 target 0 lun 0
 da0: hp v165w 3276 Removable Direct Access SCSI-4 device
 da0: 40.000MB/s transfers
 da0: 30960MB (63406080 512 byte sectors: 255H 63S/T 3946C)
 And diskinfo output:
 
 
 
   da0
   512 # sectorsize
   32463912960 # mediasize in bytes (30G)
   63406080# mediasize in sectors
   0   # stripesize
   0   # stripeoffset
   3946# Cylinders according to firmware.
   255 # Heads according to firmware.
   63  # Sectors according to firmware.
   AA22064F0035# Disk ident.
 This is the output from the second upgrade (3/18/2012) when the drive is
 inserted:
 
 
 
   ugen4.2: HP at usbus4
 umass0: HP v165w, class 0/0, rev 2.00/32.76, addr 2 on usbus4
 umass0:  SCSI over Bulk-Only; quirks = 0x0100
 umass0:2:0:-1: Attached to scbus2
 da0 at umass-sim0 bus 0 scbus2 target 0 lun 0
 da0: hp v165w 3276 Removable Direct Access SCSI-4 device
 da0: 40.000MB/s transfers
 da0: 17454747090944MB (71776119061217281 512 byte sectors: 64H 32S/T 0C)
 And diskinfo shows:
 

Hi,

 
   da0
   512 # sectorsize
   -144115188075855360 # mediasize in bytes ()
   -281474976710655# mediasize in sectors
   0   # stripesize
   0   # stripeoffset
   -137438953471   # Cylinders according to firmware.
   64  # Heads according to firmware.
   32  # Sectors according to firmware.
   AA22064F0035# Disk ident.
 Since the size information is incorrect, the /dev/da0s1 device is not
 created and the drive cannot be mounted. The problem only happens with a
 large drive. When I use a 4GB or 8GB drive, everything works correctly.
 
 If there is any information that I can submit that can assist in solving
 the problem please let me know.
 

This does not look like a USB problem. It is the SCSI/CAM layer which queries 
over SCSI USB how big the disk is.

BTW:

dec2hex(17454747090944)
ans = FE0

So it looks like some additional bits have sneaked in there?

dec2hex(32463912960)
ans = 78F00

 0xFE0 / 0x78F00
ans =  537.67

So it looks like the mediasize was multiplied by 512 when it shouldn't.

--HPS
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org