False positive uipaq probe
Hi. USB-connected WM6 communicators are able to operate in two main comm modes: serial and RNDIS. That two modes reported with different device IDs. I have noticed that my HTC Prophet WM6 communicator started to behave wrong on recent CURRENT: uipaq0: HTC Generic RNDIS, class 239/1, rev 2.00/0.00, addr 2 on usbus3 device_attach: uipaq0 attach returned 6 uipaq0: HTC Generic RNDIS, class 239/1, rev 2.00/0.00, addr 2 on usbus3 device_attach: uipaq0 attach returned 6 As soon as uipaq is a kind of serial driver, it should not attach to RNDIS device. -- Alexander Motin ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: False positive uipaq probe
Hans Petter Selasky wrote: On Friday 14 August 2009 22:26:32 Alexander Motin wrote: USB-connected WM6 communicators are able to operate in two main comm modes: serial and RNDIS. That two modes reported with different device IDs. I have noticed that my HTC Prophet WM6 communicator started to behave wrong on recent CURRENT: uipaq0: HTC Generic RNDIS, class 239/1, rev 2.00/0.00, addr 2 on usbus3 device_attach: uipaq0 attach returned 6 uipaq0: HTC Generic RNDIS, class 239/1, rev 2.00/0.00, addr 2 on usbus3 device_attach: uipaq0 attach returned 6 As soon as uipaq is a kind of serial driver, it should not attach to RNDIS device. Can you provide output from usbconfig -u XXX -a YYY dump_device_desc dump_curr_config_desc in the Serial and RNDIS case? Attached. -- Alexander Motin ugen0.2: Generic RNDIS HTC at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0200 bDeviceClass = 0x00ef bDeviceSubClass = 0x0001 bDeviceProtocol = 0x0001 bMaxPacketSize0 = 0x0040 idVendor = 0x0bb4 idProduct = 0x0bce bcdDevice = 0x iManufacturer = 0x0001 HTC iProduct = 0x0002 Generic RNDIS iSerialNumber = 0x no string bNumConfigurations = 0x0001 Configuration index 0 bLength = 0x0009 bDescriptorType = 0x0002 wTotalLength = 0x003e bNumInterfaces = 0x0002 bConfigurationValue = 0x0001 iConfiguration = 0x no string bmAttributes = 0x00c0 bMaxPower = 0x0032 Interface 0 bLength = 0x0009 bDescriptorType = 0x0004 bInterfaceNumber = 0x bAlternateSetting = 0x bNumEndpoints = 0x0001 bInterfaceClass = 0x00ef bInterfaceSubClass = 0x0001 bInterfaceProtocol = 0x0001 iInterface = 0x no string Additional Descriptor bLength = 0x05 bDescriptorType = 0x24 bDescriptorSubType = 0x01 RAW dump: 0x00 | 0x05, 0x24, 0x01, 0x00, 0x01 Additional Descriptor bLength = 0x04 bDescriptorType = 0x24 bDescriptorSubType = 0x02 RAW dump: 0x00 | 0x04, 0x24, 0x02, 0x00 Additional Descriptor bLength = 0x05 bDescriptorType = 0x24 bDescriptorSubType = 0x02 RAW dump: 0x00 | 0x05, 0x24, 0x02, 0x00, 0x01 Endpoint 0 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0081 bmAttributes = 0x0003 wMaxPacketSize = 0x0008 bInterval = 0x0001 bRefresh = 0x bSynchAddress = 0x Interface 1 bLength = 0x0009 bDescriptorType = 0x0004 bInterfaceNumber = 0x0001 bAlternateSetting = 0x bNumEndpoints = 0x0002 bInterfaceClass = 0x000a bInterfaceSubClass = 0x bInterfaceProtocol = 0x iInterface = 0x no string Endpoint 0 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0082 bmAttributes = 0x0002 wMaxPacketSize = 0x0040 bInterval = 0x bRefresh = 0x bSynchAddress = 0x Endpoint 1 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0003 bmAttributes = 0x0002 wMaxPacketSize = 0x0040 bInterval = 0x bRefresh = 0x bSynchAddress = 0x ugen0.2: USB Serial for Prophet HTC at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0200 bDeviceClass = 0x bDeviceSubClass = 0x bDeviceProtocol = 0x bMaxPacketSize0 = 0x0040 idVendor = 0x0bb4 idProduct = 0x0a51 bcdDevice = 0x iManufacturer = 0x0001 HTC iProduct = 0x0002 USB Serial for Prophet iSerialNumber = 0x no string bNumConfigurations = 0x0001 Configuration index 0 bLength = 0x0009 bDescriptorType = 0x0002 wTotalLength = 0x0020 bNumInterfaces = 0x0001 bConfigurationValue = 0x0001 iConfiguration = 0x no string bmAttributes = 0x00c0 bMaxPower = 0x0032 Interface 0 bLength = 0x0009 bDescriptorType = 0x0004 bInterfaceNumber = 0x bAlternateSetting = 0x bNumEndpoints = 0x0002 bInterfaceClass = 0x00ff bInterfaceSubClass = 0x00ff bInterfaceProtocol = 0x00ff iInterface = 0x no string Endpoint 0 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0081 bmAttributes = 0x0002 wMaxPacketSize = 0x0040 bInterval = 0x bRefresh = 0x bSynchAddress = 0x Endpoint 1 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0002 bmAttributes = 0x0002 wMaxPacketSize = 0x0040 bInterval = 0x bRefresh = 0x bSynchAddress
Re: False positive uipaq probe
Hans Petter Selasky wrote: On Tuesday 18 August 2009 12:54:22 Alexander Motin wrote: Alexander Motin m...@freebsd.org Try this patch: http://perforce.freebsd.org/chv.cgi?CH=167478 Now it looks better. uipaq attaches to serial, but not to RNDIS. -- Alexander Motin ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: serious issue caused by usb device, stalling almost all operations
Hans Petter Selasky wrote: On Wednesday 20 October 2010 17:30:40 Alexander Best wrote: hi there, i'm running HEAD (r213495; amd64). i stumbled upon this severe problem: after attaching my mobile phone, it simply resets without doing mount or anything. however after letting the device come up again it won't show up in the console. after detaching it the usb subsystem seemed to have completely crashed. but that's not all. the following programs now simply hang without producing any output C-C won't do anything: - dmesg - top - ps - killall - camcontrol devlist - usbconfig That's most likely because USB's umass driver is waiting for cam to drain. Possibly some refcounting is not correct. I suspect this is not a USB problem. Try to enter into the debugger, and look for backtrace for function stuck in umass_detach. It is a bit suspicious that problem happens only when device dies during request. Are you sure that running command was properly aborted when device got detached? Every running command has own set of references, denying detach. -- Alexander Motin ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: USB camera not detected by 8.1, was working in 7
Hans Petter Selasky wrote: On Tuesday 02 November 2010 22:44:38 Alexander Churanov wrote: Where should I look and whom to ask? Is freebsd-scsi a proper list for an issue like this? It is related, though I am also not sure it is SCSI issue. AutoSense failed means that CAM and umass were unable to get detailed information about error. Without that information CAM subsystem can't adequately handle it. We need more information about the problem. Try to reproduce the problem after booting with verbose kernel messages or enabling it via debug.bootverbose sysctl. If it won't give much - you may rebuild kernel with `options CAMDEBUG` and enable some debugging via `camcontrol debug`. -- Alexander Motin ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: USB camera not detected by 8.1, was working in 7
Hi. Alexander Churanov wrote: Some time ago I was asking for an advice on USB camera which fails to work after upgrade to FreeBSD 8 (the /dev/da* don't show up). Now I've enabled CAMDEBUG. The entries from /var/log/messages are available here: http://alexanderchuranov.com/freebsd8-usb-camera/autosense-failed If you have some time to look into this, your comments will be very much appreciated. As I can see, things go wrong just after first request to device - INQUIRY. After that CAM tries to fetch details of error with REQUEST SENSE and again fails. I think you had no enabled verbose kernel messages at that moment, so I can't see some error messages I would expect there. But from this data I don't think that something is wrong with CAM. I would start digging toward umass driver (enable debug there) to find out what can be the source of these errors. Device should not return error in response to INQUIRY. PS: I can see that umass has special quirk to simulate fake INQUIRY response in some cases. I have no idea what the hell it is, but may be it is related here. -- Alexander Motin ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: copying /dev/da0 with dd(1) to file: output differs
On 19.11.2010 20:39, Matthias Apitz wrote: El día Friday, November 19, 2010 a las 07:16:53PM +0100, Hans Petter Selasky escribió: I was thinking in a tool just reading each file block by block, comparing the blocks and noting the 1st diff with block offset number. (some 10 lines of C code :-)) matthias Maybe you need to write a small C-program to do that. You can use bcmp() to compare two buffers. Will do that tomorrow. Just an idea: The USB key in question was new and I only created the file system on it the usual way (fdisk, bsdlabel, newfs). Then I restored the dump on it (which took 26 hours for 3.1 GByte dump file). The USB key boots fine, btw. Could it be that unwritten/unformatted blocks are read as random data from that USB key? Should I overwrite the full USB key from /dev/zero? It is allowed behavior for SATA SSDs with TRIM command support. Deleted blocks can be not guarantied to return any predictable or even repeatable value. May be this logic could be extended to USB devices. -- Alexander Motin ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: Ongoing battle with umass(4) and xhci(4)
On 03/13/12 05:37, Brandon Gooch wrote:
On Mon, Mar 12, 2012 at 3:15 AM, Hans Petter Selaskyhsela...@c2i.net wrote:
Is there something fishy happening between the USB stack and CAM? hmmm...
No,
It is not the CAM layer this time, though there are some bugs there too.
In the beginning of the log I see that in the successful case we receive a
stall event:
-xhci_check_transfer: slot=1 epno=3 remainder=13 status=6
-xhci_check_transfer: TD is last
-xhci_cmd_stop_ep:
-xhci_check_command: Received command event
-xhci_configure_reset_endpoint: Could not stop endpoint 3
-xhci_cmd_reset_ep:
-xhci_check_command: Received command event
-xhci_cmd_set_tr_dequeue_ptr:
-xhci_check_command: Received command event
-xhci_cmd_evaluate_ctx:
-xhci_check_command: Received command event
-xhci_cmd_configure_ep:
-xhci_check_command: Received command event
-xhci_configure_reset_endpoint: Could not configure endpoint 3
-xhci_ep_clear_stall:
-xhci_device_generic_enter:
-xhci_setup_generic_chain_sub: NTRB=1
-xhci_setup_generic_chain_sub: LINK=0x82883180
-xhci_setup_generic_chain_sub: NTRB=1
-xhci_setup_generic_chain_sub: LINK=0x82883000
-xhci_setup_generic_chain: first=0xff8460883300 last=0xff8460883180
-xhci_device_generic_start:
-xhci_transfer_insert: qh_pos = 1
-xhci_check_transfer: slot=1 epno=1 remainder=0 status=1
-xhci_check_transfer: slot=1 epno=1 remainder=0 status=1
-xhci_check_transfer: Following next TD
-xhci_check_transfer: slot=1 epno=1 remainder=0 status=1
-xhci_check_transfer: slot=1 epno=1 remainder=0 status=1
-xhci_check_transfer: TD is last
This is not received in the failing case.
Maybe this indicates a lost interrupt or something like that?
In /sys/dev/usb/controller/xhci.c
static void
xhci_interrupt_poll(struct xhci_softc *sc)
Add a printf:
if (i == XHCI_MAX_EVENTS) {
i = 0;
j ^= 1;
/* check for timeout */
if (!--t) {
+ printf(XHCI:
Timeout\n);
break;
}
}
See if what happens.
Also change the xhci.c code to call
xhci_interrupt_poll() two times instead of one.
--HPS
Unfortunately, the condition was never reached.
I've started trying to dtrace xhci(4) function boundaries, and, well
there's a lot of recursion with xhci_interrupt_poll(). However, I
never see that function called from xhci_do_poll(), which is called
from xhci_interrupt() (to catch any lost interrupts according to the
comment).
You may have already told me this, but what does Down reving Protocol
Version from 2 to 0? in the success case on my system? Is this the
USB protocol which is down rev'ed? If so, what USB level is this
flash drive running at?
It is SCSI protocol that down rev'ed, not USB. AFAIK this came from
old SPI era when SCSI protocol version was same for device and
controller, limited by transport type. At this moment, with many
possible transports, I believe this message lost its informativeness.
--
Alexander Motin
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: USB Flash drive problem with 9.0
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-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: USB Flash drive problem with 9.0
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-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: USB Flash drive problem with 9.0
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-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: Recommendations for programming HID in FreeBSD 9
Hi. On 06/01/12 20:10, Engineering wrote: -Original Message- From: Hans Petter Selasky [mailto:hsela...@c2i.net] I think mav @ did some work in that area? Are you sure you cannot use: ... if (id != 0) copyin(ugd-ugd_data,id, 1); error = uhid_set_report(sc, ugd-ugd_report_type, id, NULL, ugd-ugd_data, imin(ugd-ugd_maxlen, size)); break; That's definitely cleaner, using the ugd fields to denote a special case. I'm not sure about the (id != 0) - I'll need to check my specific devices, but something like: Hans is right. That code should do the trick. Last year I've fixed uhid driver to handle multiple report IDs. Even user-level tools are able to do it now. id != 0 should be correct condition. According to HID spec, if device has at least one non-zero report ID, report ID should be included into any transfer. So now uhid driver assumes that report ID should be in the first byte of request, if it found some non-zero ID in descriptor. -- Alexander Motin ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: Recommendations for programming HID in FreeBSD 9
On 06/04/12 01:29, Engineering wrote: if (id != 0) copyin(ugd-ugd_data,id, 1); error = uhid_set_report(sc, ugd-ugd_report_type, id, NULL, ugd-ugd_data, imin(ugd-ugd_maxlen, size)); Hans is right. That code should do the trick. Last year I've fixed uhid driver to handle multiple report IDs. Even user-level tools are able to do it now. id != 0 should be correct condition. According to HID spec, if device has at least one non-zero report ID, report ID should be included into any transfer. So now uhid driver assumes that report ID should be in the first byte of request, if it found some non-zero ID in descriptor. Thanks to all for your help, I have it working, and am very happy to be up to date in BSD. For the record, one of my HID had different report IDs AND different report sizes, so I had to add my hack to send the size for it to work correctly. That should also work fine now. uhid driver only enforces maximal transfer sizes calculated from the descriptor. User can request smaller transfers, specifying size in ugd.ugd_maxlen field. Look at hid_(get|set)_report() functions in lib/libusbhid sources. The bonus with that is that my touchscreen, which has badly ported HID code from the original USB firmware, and does not correctly report its report sizes, can also work with uhid. -- Alexander Motin ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: [usb] Kingston 8Gb is not usable
On 06/26/12 18:41, Hans Petter Selasky wrote: On Tuesday 26 June 2012 14:29:28 Boris Samorodov wrote: I've got a Kingston USB 8Gb stick. It was too noisy (with respect to /var/log/messages) but worked. The system was upgraded today morning: - % uname -a FreeBSD bsam.wart.ru 10.0-CURRENT FreeBSD 10.0-CURRENT #17 r237572: Tue Jun 26 04:22:18 SAMT 2012 b...@bsam.wart.ru:/usr/obj/usr/src/sys/BBX i386 - And the stick is no longer usable: - Jun 26 15:27:40 bsam kernel: ugen7.5: Kingston at usbus7 Jun 26 15:27:40 bsam kernel: umass0: Kingston DT101 II, class 0/0, rev 2.00/1.00, addr 5 on usbus7 Jun 26 15:27:40 bsam kernel: umass0: SCSI over Bulk-Only; quirks = 0x0100 Jun 26 15:27:40 bsam kernel: umass0:11:0:-1: Attached to scbus11 Jun 26 15:27:40 bsam kernel: da0 at umass-sim0 bus 0 scbus11 target 0 lun 0 Jun 26 15:27:40 bsam kernel: da0: Kingston DT101 II 1.00 Removable Direct Access SCSI-2 device Jun 26 15:27:40 bsam kernel: da0: 40.000MB/s transfers Jun 26 15:27:40 bsam kernel: da0: 7634MB (15636304 512 byte sectors: 255H 63S/T 973C) There has been no change in the umass driver, but there has been many changes in the CAM layer. Mav: Any idea? I see no problems in this output. I would enable more debugging with `camcontrol debug -IPp all` before plugging it in to see what's going on. -- Alexander Motin ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: [usb] Kingston 8Gb is not usable
On 06/27/12 11:07, Boris Samorodov wrote: 26.06.2012 20:19, Alexander Motin пишет: I see no problems in this output. I would enable more debugging with `camcontrol debug -IPp all` before plugging it in to see what's going on. Here it is: - sudo: bsam : TTY=pts/5 ; PWD=/home/bsam ; USER=root ; COMMAND=/sbin/camcontrol debug -IPp all kernel: (xpt0:xpt0:0:-1:-1): debugging flags now 61 kernel: ugen7.2: Kingston at usbus7 kernel: umass0: Kingston DT101 II, class 0/0, rev 2.00/1.00, addr 2 on usbus7 kernel: umass0: SCSI over Bulk-Only; quirks = 0x0100 kernel: (noperiph:umass-sim0:0:-1:-1): xpt_async(AC_PATH_REGISTERED) kernel: umass0:11:0:-1: Attached to scbus11 kernel: (probe0:umass-sim0:0:0:0): Periph created kernel: (probe0:umass-sim0:0:0:0): Probe started kernel: (probe0:umass-sim0:0:0:0): Probe PROBE_INVALID to PROBE_INQUIRY kernel: (probe0:umass-sim0:0:0:0): Probe PROBE_INQUIRY to PROBE_SUPPORTED_VPD_LIST kernel: (probe0:umass-sim0:0:0:0): Probe PROBE_SUPPORTED_VPD_LIST to PROBE_DEVICE_ID kernel: (probe0:umass-sim0:0:0:0): Probe PROBE_DEVICE_ID to PROBE_SERIAL_NUM kernel: (probe0:umass-sim0:0:0:0): Probe PROBE_SERIAL_NUM to PROBE_TUR_FOR_NEGOTIATION kernel: (probe0:umass-sim0:0:0:0): xpt_async(AC_FOUND_DEVICE) kernel: (pass4:umass-sim0:0:0:0): Periph created kernel: (da0:umass-sim0:0:0:0): Periph created kernel: (probe0:umass-sim0:0:0:0): Probe PROBE_TUR_FOR_NEGOTIATION to PROBE_DONE kernel: (probe0:umass-sim0:0:0:0): Probe completed kernel: (probe0:umass-sim0:0:0:0): Periph invalidated kernel: (probe0:umass-sim0:0:0:0): Periph destroyed kernel: da0 at umass-sim0 bus 0 scbus11 target 0 lun 0 kernel: da0: Kingston DT101 II 1.00 Removable Direct Access SCSI-2 device kernel: da0: 40.000MB/s transfers kernel: da0: 7634MB (15636304 512 byte sectors: 255H 63S/T 973C) Up to this point everything is fine, but here problems begin. kernel: (da0:umass-sim0:0:0:0): daopen kernel: (da0:umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 0 0 0 1 0 kernel: (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error kernel: (da0:umass-sim0:0:0:0): SCSI status: Check Condition kernel: (da0:umass-sim0:0:0:0): SCSI sense: No sense data present kernel: (da0:umass-sim0:0:0:0): Retrying command (per sense data) kernel: (da0:umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 0 0 0 1 0 kernel: (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error kernel: (da0:umass-sim0:0:0:0): SCSI status: Check Condition kernel: (da0:umass-sim0:0:0:0): SCSI sense: No sense data present kernel: (da0:umass-sim0:0:0:0): Error 5, Retries exhausted kernel: (da0:umass-sim0:0:0:0): daclose kernel: (da0:umass-sim0:0:0:0): SYNCHRONIZE CACHE(10). CDB: 35 0 0 0 0 0 0 0 0 0 kernel: (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error kernel: (da0:umass-sim0:0:0:0): SCSI status: Check Condition kernel: (da0:umass-sim0:0:0:0): SCSI sense: No sense data present kernel: (da0:umass-sim0:0:0:0): Retrying command (per sense data) kernel: (da0:umass-sim0:0:0:0): SYNCHRONIZE CACHE(10). CDB: 35 0 0 0 0 0 0 0 0 0 kernel: (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error kernel: (da0:umass-sim0:0:0:0): SCSI status: Check Condition kernel: (da0:umass-sim0:0:0:0): SCSI sense: No sense data present kernel: (da0:umass-sim0:0:0:0): Error 5, Retries exhausted kernel: (da0:umass-sim0:0:0:0): daopen kernel: (da0:umass-sim0:0:0:0): READ CAPACITY(10). CDB: 25 0 0 0 0 0 0 0 0 0 kernel: (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error kernel: (da0:umass-sim0:0:0:0): SCSI status: Check Condition kernel: (da0:umass-sim0:0:0:0): SCSI sense: No sense data present kernel: (da0:umass-sim0:0:0:0): Retrying command (per sense data) kernel: (da0:umass-sim0:0:0:0): READ CAPACITY(10). CDB: 25 0 0 0 0 0 0 0 0 0 kernel: (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error kernel: (da0:umass-sim0:0:0:0): SCSI status: Check Condition kernel: (da0:umass-sim0:0:0:0): SCSI sense: No sense data present kernel: (da0:umass-sim0:0:0:0): Retrying command (per sense data) kernel: (da0:umass-sim0:0:0:0): READ CAPACITY(10). CDB: 25 0 0 0 0 0 0 0 0 0 kernel: (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error kernel: (da0:umass-sim0:0:0:0): SCSI status: Check Condition kernel: (da0:umass-sim0:0:0:0): SCSI sense: No sense data present kernel: (da0:umass-sim0:0:0:0): Retrying command (per sense data) kernel: (da0:umass-sim0:0:0:0): READ CAPACITY(10). CDB: 25 0 0 0 0 0 0 0 0 0 kernel: (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error kernel: (da0:umass-sim0:0:0:0): SCSI status: Check Condition kernel: (da0:umass-sim0:0:0:0): SCSI sense: No sense data present kernel: (da0:umass-sim0:0:0:0): Retrying command (per sense data) kernel: (da0:umass-sim0:0:0:0): READ CAPACITY(10). CDB: 25 0 0 0 0 0 0 0 0 0 kernel: (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error kernel: (da0:umass-sim0:0:0:0): SCSI status: Check Condition kernel: (da0:umass-sim0:0:0:0): SCSI sense: No sense data present kernel: (da0:umass-sim0:0:0:0): Error 5, Retries exhausted kernel: (da0:umass-sim0:0
Re: [usb] Kingston 8Gb is not usable
On 06/27/12 11:45, Alexander Motin wrote: On 06/27/12 11:07, Boris Samorodov wrote: 26.06.2012 20:19, Alexander Motin пишет: I see no problems in this output. I would enable more debugging with `camcontrol debug -IPp all` before plugging it in to see what's going on. Here it is: - sudo: bsam : TTY=pts/5 ; PWD=/home/bsam ; USER=root ; COMMAND=/sbin/camcontrol debug -IPp all kernel: (xpt0:xpt0:0:-1:-1): debugging flags now 61 kernel: ugen7.2: Kingston at usbus7 kernel: umass0: Kingston DT101 II, class 0/0, rev 2.00/1.00, addr 2 on usbus7 kernel: umass0: SCSI over Bulk-Only; quirks = 0x0100 kernel: (noperiph:umass-sim0:0:-1:-1): xpt_async(AC_PATH_REGISTERED) kernel: umass0:11:0:-1: Attached to scbus11 kernel: (probe0:umass-sim0:0:0:0): Periph created kernel: (probe0:umass-sim0:0:0:0): Probe started kernel: (probe0:umass-sim0:0:0:0): Probe PROBE_INVALID to PROBE_INQUIRY kernel: (probe0:umass-sim0:0:0:0): Probe PROBE_INQUIRY to PROBE_SUPPORTED_VPD_LIST kernel: (probe0:umass-sim0:0:0:0): Probe PROBE_SUPPORTED_VPD_LIST to PROBE_DEVICE_ID kernel: (probe0:umass-sim0:0:0:0): Probe PROBE_DEVICE_ID to PROBE_SERIAL_NUM kernel: (probe0:umass-sim0:0:0:0): Probe PROBE_SERIAL_NUM to PROBE_TUR_FOR_NEGOTIATION kernel: (probe0:umass-sim0:0:0:0): xpt_async(AC_FOUND_DEVICE) kernel: (pass4:umass-sim0:0:0:0): Periph created kernel: (da0:umass-sim0:0:0:0): Periph created kernel: (probe0:umass-sim0:0:0:0): Probe PROBE_TUR_FOR_NEGOTIATION to PROBE_DONE kernel: (probe0:umass-sim0:0:0:0): Probe completed kernel: (probe0:umass-sim0:0:0:0): Periph invalidated kernel: (probe0:umass-sim0:0:0:0): Periph destroyed kernel: da0 at umass-sim0 bus 0 scbus11 target 0 lun 0 kernel: da0: Kingston DT101 II 1.00 Removable Direct Access SCSI-2 device kernel: da0: 40.000MB/s transfers kernel: da0: 7634MB (15636304 512 byte sectors: 255H 63S/T 973C) Up to this point everything is fine, but here problems begin. kernel: (da0:umass-sim0:0:0:0): daopen kernel: (da0:umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 0 0 0 1 0 kernel: (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error kernel: (da0:umass-sim0:0:0:0): SCSI status: Check Condition kernel: (da0:umass-sim0:0:0:0): SCSI sense: No sense data present kernel: (da0:umass-sim0:0:0:0): Retrying command (per sense data) kernel: (da0:umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 0 0 0 1 0 kernel: (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error kernel: (da0:umass-sim0:0:0:0): SCSI status: Check Condition kernel: (da0:umass-sim0:0:0:0): SCSI sense: No sense data present kernel: (da0:umass-sim0:0:0:0): Error 5, Retries exhausted kernel: (da0:umass-sim0:0:0:0): daclose kernel: (da0:umass-sim0:0:0:0): SYNCHRONIZE CACHE(10). CDB: 35 0 0 0 0 0 0 0 0 0 kernel: (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error kernel: (da0:umass-sim0:0:0:0): SCSI status: Check Condition kernel: (da0:umass-sim0:0:0:0): SCSI sense: No sense data present kernel: (da0:umass-sim0:0:0:0): Retrying command (per sense data) kernel: (da0:umass-sim0:0:0:0): SYNCHRONIZE CACHE(10). CDB: 35 0 0 0 0 0 0 0 0 0 kernel: (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error kernel: (da0:umass-sim0:0:0:0): SCSI status: Check Condition kernel: (da0:umass-sim0:0:0:0): SCSI sense: No sense data present kernel: (da0:umass-sim0:0:0:0): Error 5, Retries exhausted kernel: (da0:umass-sim0:0:0:0): daopen kernel: (da0:umass-sim0:0:0:0): READ CAPACITY(10). CDB: 25 0 0 0 0 0 0 0 0 0 kernel: (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error kernel: (da0:umass-sim0:0:0:0): SCSI status: Check Condition kernel: (da0:umass-sim0:0:0:0): SCSI sense: No sense data present kernel: (da0:umass-sim0:0:0:0): Retrying command (per sense data) kernel: (da0:umass-sim0:0:0:0): READ CAPACITY(10). CDB: 25 0 0 0 0 0 0 0 0 0 kernel: (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error kernel: (da0:umass-sim0:0:0:0): SCSI status: Check Condition kernel: (da0:umass-sim0:0:0:0): SCSI sense: No sense data present kernel: (da0:umass-sim0:0:0:0): Retrying command (per sense data) kernel: (da0:umass-sim0:0:0:0): READ CAPACITY(10). CDB: 25 0 0 0 0 0 0 0 0 0 kernel: (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error kernel: (da0:umass-sim0:0:0:0): SCSI status: Check Condition kernel: (da0:umass-sim0:0:0:0): SCSI sense: No sense data present kernel: (da0:umass-sim0:0:0:0): Retrying command (per sense data) kernel: (da0:umass-sim0:0:0:0): READ CAPACITY(10). CDB: 25 0 0 0 0 0 0 0 0 0 kernel: (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error kernel: (da0:umass-sim0:0:0:0): SCSI status: Check Condition kernel: (da0:umass-sim0:0:0:0): SCSI sense: No sense data present kernel: (da0:umass-sim0:0:0:0): Retrying command (per sense data) kernel: (da0:umass-sim0:0:0:0): READ CAPACITY(10). CDB: 25 0 0 0 0 0 0 0 0 0 kernel: (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error kernel: (da0:umass-sim0:0:0:0): SCSI status: Check Condition kernel: (da0:umass-sim0:0:0:0): SCSI sense: No sense data present kernel: (da0:umass-sim0:0:0:0): Error 5
Re: [usb] Kingston 8Gb is not usable
On 06/27/12 12:55, Boris Samorodov wrote: 27.06.2012 12:45, Alexander Motin пишет: Something is wrong there. I think this should not happen: kernel: (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error kernel: (da0:umass-sim0:0:0:0): SCSI status: Check Condition kernel: (da0:umass-sim0:0:0:0): SCSI sense: No sense data present Two questions: 1) what originally caused these errors and 2) why No sense data present. I am not sure whether it is device problem or umass or both. I can't reproduce it with devices I have. Could you also show your old error messages (preferably verbose) to compare? There are messages from the old kernel/world (attached) after the command camcontrol debug -IPp all. The device in not de-attached and is usable. BTW it's the fastest one I own. By verbose did you mean verbose boot? If yes, then I attach verbose-boot.txt with relevant messages. The kernel.old: - % uname -a FreeBSD bsam.wart.ru 10.0-CURRENT FreeBSD 10.0-CURRENT #16 r237055: Thu Jun 14 17:16:43 SAMT 2012 b...@bsam.wart.ru:/usr/obj/usr/src/sys/BBX i386 - Oops, I haven't noticed in your original mail that it was working just on June 14, when most radical changes were already done. The only change after that I see potentially related is r237478. It adds more checks when fetching SCSI sense data, that for some reason are not working in your case. I still can not completely understand why there was no any READ CAPACITY errors reported before, but may be I am missing something. You can try to revert that revision for check. Hans, don't you have any idea why this device may not report sense data or may be residual sense data length (ccb-csio.sense_resid) is not set properly? According to got CAM status 0x8c, umass seems believe that it got sense data, but CAM doesn't count them as valid. -- Alexander Motin ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: [usb] Kingston 8Gb is not usable
On 06/27/12 17:45, Boris Samorodov wrote: 27.06.2012 15:51, Alexander Motin пишет: The only change after that I see potentially related is r237478. It adds more checks when fetching SCSI sense data, that for some reason are not working in your case. I still can not completely understand why there was no any READ CAPACITY errors reported before, but may be I am missing something. You can try to revert that revision for check. Confirm. Reverting this commit alone helps here. Both my system with patched kernel uses /dev/da0 and patched kernel works if the system is booted from the stick. OK. But I am not sure what to do about it. I don't see problem in my code. I believe it is either hardware or umass problem, or both. Though it is a little bit noisy. ;-) Since now I know that it shouldn't here is a question: should I file a PR on this noisiness (i.e. error reporting, etc.)? These are real errors for CAM. There would be no noise if device correctly reported SCSI senses, as drivers are already instructed to not wine about unsupported command codes. But in this case CAM doesn't know what are the errors and prefers to report them. -- Alexander Motin ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: [usb] Kingston 8Gb is not usable
On 06/27/12 18:17, Hans Petter Selasky wrote: On Wednesday 27 June 2012 17:08:29 Alexander Motin wrote: umass problem Hi, Are you verifying the received data length for the SCSI commands reading out various data? Mentioned revision beyond others adds check for the sense data length in case of error. It won't even look into the sense data if reported amount (sense_len - sense_resid) is zero or less then needed. I have no idea how USB calculates resid, but it may be a problem in this case. I think it could be useful to get USB packets trace to see whether it is device doesn't return any sense data, or umass improperly interprets them in this case for some reason. -- Alexander Motin ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: [usb] Kingston 8Gb is not usable
On 06/27/12 18:31, Hans Petter Selasky wrote: On Wednesday 27 June 2012 17:28:30 Alexander Motin wrote: On 06/27/12 18:17, Hans Petter Selasky wrote: On Wednesday 27 June 2012 17:08:29 Alexander Motin wrote: umass problem Hi, Are you verifying the received data length for the SCSI commands reading out various data? Mentioned revision beyond others adds check for the sense data length in case of error. It won't even look into the sense data if reported amount (sense_len - sense_resid) is zero or less then needed. I have no idea how USB calculates resid, but it may be a problem in this case. I think it could be useful to get USB packets trace to see whether it is device doesn't return any sense data, or umass improperly interprets them in this case for some reason. Hi, The residue is part of the 13 status bytes in the SCSI BOT protocol. If this field is zero, the umass driver will compute the residue from the actual data transferred as a workaround. Can't there be an opposite bug -- residue field is equal to the transfer size in which case CAM will think there is no sense data? -- Alexander Motin ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: [usb] Kingston 8Gb is not usable
On 06/27/12 19:26, Hans Petter Selasky wrote: On Wednesday 27 June 2012 18:15:24 Hans Petter Selasky wrote: ERR=STALLED Retrying might not work, until sense is cleared, due to stalled error. MAV: Maybe that failed prevent-allow medium removal left a sense error that needs to be cleared. It should be cleared by fetching sense command. As I was assured by several people, it is SIM (controller driver, umass) obligation to fetch sense and respectively clear it when error detected. But not sure what should umass do if this device STALLs. May be should try to do it also. So far I haven't see any properly fetched sense from it in provided logs. -- Alexander Motin ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: [usb] Kingston 8Gb is not usable
On 27.06.2012 23:08, Hans Petter Selasky wrote: On Wednesday 27 June 2012 19:51:15 Alexander Motin wrote: On 06/27/12 19:26, Hans Petter Selasky wrote: On Wednesday 27 June 2012 18:15:24 Hans Petter Selasky wrote: ERR=STALLED Retrying might not work, until sense is cleared, due to stalled error. MAV: Maybe that failed prevent-allow medium removal left a sense error that needs to be cleared. It should be cleared by fetching sense command. As I was assured by several people, it is SIM (controller driver, umass) obligation to fetch sense and respectively clear it when error detected. But not sure what should umass do if this device STALLs. May be should try to do it also. So far I haven't see any properly fetched sense from it in provided logs. Are you sure? And where should the sense output be sent? Sense output should be (and are now for working devices) sent within reply on the original command returning with the CHECK CONDITION SCSI status. In addition to general status fields there are space for sense data in struct scsiio: sense_data, sense_len and sense_resid fields. -- Alexander Motin ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: [usb] Kingston 8Gb is not usable
On 28.06.2012 09:56, Hans Petter Selasky wrote: On Wednesday 27 June 2012 23:14:43 Alexander Motin wrote: On 27.06.2012 23:08, Hans Petter Selasky wrote: On Wednesday 27 June 2012 19:51:15 Alexander Motin wrote: On 06/27/12 19:26, Hans Petter Selasky wrote: On Wednesday 27 June 2012 18:15:24 Hans Petter Selasky wrote: ERR=STALLED Retrying might not work, until sense is cleared, due to stalled error. MAV: Maybe that failed prevent-allow medium removal left a sense error that needs to be cleared. It should be cleared by fetching sense command. As I was assured by several people, it is SIM (controller driver, umass) obligation to fetch sense and respectively clear it when error detected. But not sure what should umass do if this device STALLs. May be should try to do it also. So far I haven't see any properly fetched sense from it in provided logs. Are you sure? And where should the sense output be sent? Sense output should be (and are now for working devices) sent within reply on the original command returning with the CHECK CONDITION SCSI status. In addition to general status fields there are space for sense data in struct scsiio: sense_data, sense_len and sense_resid fields. I see. UMASS already does the sense like you explain on errors, except if the BULK endpoint is STALL'ed on a READ data. Anyway, I see that the next SCSI command in the queue completes. And also that the previous one was successful. So there should be no sense data to fetch. Even if UMASS gets the sense information, will the upper layers, in this case CAM layer, retry the CAPACITY command, which seems required to workaround a bug the stick's firmware? It depends on sense information (if present). Fatal errors like invalid command code are not retried. Temporal errors like device loading media could be retried many times with some delays between commands, Unknown errors like in this case are usually retried several times, depending on peripheral driver. In this case I see in logs that READ CAPACITY(10) command was unsuccessfully tried 5 times. -- Alexander Motin ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: sdcard read error with nokia n8 as mass storage
On 19.02.2013 09:14, Hans Petter Selasky wrote: On Monday 18 February 2013 22:57:25 Jan Beich wrote: Hans Petter Selasky hsela...@c2i.net writes: On Monday 18 February 2013 07:11:56 Jan Beich wrote: Hans Petter Selasky hsela...@c2i.net writes: On Sunday 17 February 2013 17:24:23 Jan Beich wrote: The phone has 16G of on-board and 16G sdcard memory. FreeBSD 10.0 detects both but only the former can be mounted. And there is no issue mounting the sdcard on Ubuntu or on FreeBSD via iSCSI (fileio). [...] $ usbdump -i usbus7 -s 0 -vvv # on attach http://pastebin.com/mQ472uQJ forgotten linux usbmon dump - http://pastebin.com/Df9Zp6T5 [...] forgotten debug log - http://pastebin.com/NzpSJBRA http://pastebin.com/P9474rw4 # no quirks (via source edit) Why UQ_MSC_NO_SYNC_CACHE is always added for the device? on-board (da0) memory seems to mount/work just fine without + Medium not present is gone. $ usbconfig dump_device_quirks | fgrep 421 empty $ kenv | fgrep usb hw.usb.no_boot_wait=1 hw.usb.umass.debug=-1 Try this quirk: usbconfig -d x.y add_quirk UQ_MSC_NO_INQUIRY http://pastebin.com/4R0MYTUK # UQ_MSC_NO_INQUIRY http://pastebin.com/AGHGiC3n # UQ_MSC_NO_INQUIRY + UQ_MSC_NO_SYNC_CACHE I've tried a few more (at random) with no luck either. http://pastebin.com/RW2cg51S # UQ_MSC_FORCE_SHORT_INQ http://pastebin.com/ahiUvS7f # UQ_MSC_WRONG_CSWSIG http://pastebin.com/Wf6Be9uN # UQ_MSC_IGNORE_RESIDUE http://pastebin.com/0W4pcKmY # UQ_MSC_READ_CAP_OFFBY1 Linux seems to use only CAPACITY_HEURISTICS quirk. Hi, The device fails on READ_10. Maybe this command is not supported. I'm not sure how to reprogram CAM/SCSI layers to use READ_6 instead. CAM DA driver uses shortest possible command, but no shorter then kern.cam.da.X.minimum_cmd_size value, that is 10 by default for umass due to cpi-hba_misc = PIM_NO_6_BYTE set in umass.c. -- Alexander Motin ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: Status of PCIe Hotplug?
On 29.09.2016 02:40, Hans Petter Selasky wrote: > On 09/29/16 11:24, Jan Henrik Sylvester wrote: >> On 09/29/2016 10:17, Hans Petter Selasky wrote: >>> Hi, >>> >>> I created this differential review: >>> >>> https://reviews.freebsd.org/D8070 >>> >>> Jan Henrik: Can you download this patch and try it instead of the one I >>> sent? >>> >>> --HPS >> >> Pulling the naked USB 3.0 ExpressCard without detaching it does not lead >> to a panic anymore. >> >> Anyhow, the scenario that happened frequently on 10.3 for me without a >> panic was pulling the USB 3.0 ExpressCard together with an usb stick. >> That still leads to a panic on 11.0 + D8070: >> >> fault code = supervisor read data, page not present >> instruction pointer= 0x20:0x80ab48ca >> stack pointer= 0x28:0xfe022476ba20 >> frame pointer= 0x28:0xfe022476baa0 >> code segment= base 0x0, limit 0xf, type 0x1b >> = DPL 0, pres 1, long 1, def32 0, gran 1 >> processor eflags= interrupt enabled, resume, IOPL = 0 >> current process= 4 (doneq0) >> trap number = 12 >> panic: page fault >> cpuid = 1 >> KDB: stack backtrace: >> #0 0x80b24107 at kdb_backtrace+0x67 >> #1 0x80ad93e2 at vpanic+0x182 >> #2 0x80ad9253 at panic+0x43 >> #3 0x80fa0d31 at trap_fatal+0x351 >> #4 0x80fa0f23 at trap_pfault+0x1e3 >> #5 0x80fa04cc at trap+0x26c >> #6 0x80f841d1 at calltrap+0x8 >> #7 0x8030a879 at xpt_release_simq+0x79 >> #8 0x8030a649 at xpt_async_process+0x409 >> #9 0x8030b187 at xpt_done_process+0x807 >> #10 0x8030d916 at xpt_done_td+0x146 >> #11 0x80a90055 at fork_exit+0x85 >> #12 0x80f8467e at fork_trampoline+0xe >> > > Hi, > > This panic seems to be an issue within the CAM subsystem. Apparently the > CAM sim detach is not waiting for the release to complete, so functions > inside umass.ko are referred after umass.ko is unloaded. > > imp+mav: Any comments? cam_sim_free() that should be called as part of SIM destruction process waits for all of SIM references to be dropped, that also recursively implies all other references. It worked file last time I tested it, but it was quite a long time ago. I can not say what went wrong here, but I guess that either USB somehow did not wait for cam_sim_free(), or something somewhere did not do reference counting properly, allowing destruction of some still referenced item. -- Alexander Motin ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
