Re: [usb] Kingston 8Gb is not usable
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) 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:0:0): got CAM status 0x8c kernel: (da0:umass-sim0:0:0:0): fatal error, failed to attach
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:
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/168743: commit references a PR
The following reply was made to PR usb/168743; it has been noted by GNATS.
From: dfil...@freebsd.org (dfilter service)
To: bug-follo...@freebsd.org
Cc:
Subject: Re: usb/168743: commit references a PR
Date: Wed, 27 Jun 2012 11:02:49 + (UTC)
Author: mav
Date: Wed Jun 27 11:02:35 2012
New Revision: 237637
URL: http://svn.freebsd.org/changeset/base/237637
Log:
MFC r237398:
In camisr() clear CAM_SIM_ON_DONEQ flag after camisr_runqueue() purged SIM
done queue. Clearing it before caused extra SIM queueing in some cases.
It was invisible during normal operation, but during USB device unplug and
respective SIM destruction it could keep pointer on SIM without having
counted reference and as result crash the system by use afer free.
PR: usb/168743
Modified:
stable/9/sys/cam/cam_xpt.c
Directory Properties:
stable/9/sys/ (props changed)
Modified: stable/9/sys/cam/cam_xpt.c
==
--- stable/9/sys/cam/cam_xpt.c Wed Jun 27 10:07:29 2012(r237636)
+++ stable/9/sys/cam/cam_xpt.c Wed Jun 27 11:02:35 2012(r237637)
@@ -4990,8 +4990,8 @@ camisr(void *dummy)
while ((sim = TAILQ_FIRST(queue)) != NULL) {
TAILQ_REMOVE(queue, sim, links);
CAM_SIM_LOCK(sim);
- sim-flags = ~CAM_SIM_ON_DONEQ;
camisr_runqueue(sim-sim_doneq);
+ sim-flags = ~CAM_SIM_ON_DONEQ;
CAM_SIM_UNLOCK(sim);
}
mtx_lock(cam_simq_lock);
___
svn-src-...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
___
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/168743: commit references a PR
The following reply was made to PR usb/168743; it has been noted by GNATS.
From: dfil...@freebsd.org (dfilter service)
To: bug-follo...@freebsd.org
Cc:
Subject: Re: usb/168743: commit references a PR
Date: Wed, 27 Jun 2012 11:04:18 + (UTC)
Author: mav
Date: Wed Jun 27 11:04:04 2012
New Revision: 237638
URL: http://svn.freebsd.org/changeset/base/237638
Log:
MFC r237398:
In camisr() clear CAM_SIM_ON_DONEQ flag after camisr_runqueue() purged SIM
done queue. Clearing it before caused extra SIM queueing in some cases.
It was invisible during normal operation, but during USB device unplug and
respective SIM destruction it could keep pointer on SIM without having
counted reference and as result crash the system by use afer free.
PR: usb/168743
Modified:
stable/8/sys/cam/cam_xpt.c
Directory Properties:
stable/8/sys/ (props changed)
Modified: stable/8/sys/cam/cam_xpt.c
==
--- stable/8/sys/cam/cam_xpt.c Wed Jun 27 11:02:35 2012(r237637)
+++ stable/8/sys/cam/cam_xpt.c Wed Jun 27 11:04:04 2012(r237638)
@@ -4944,8 +4944,8 @@ camisr(void *dummy)
while ((sim = TAILQ_FIRST(queue)) != NULL) {
TAILQ_REMOVE(queue, sim, links);
CAM_SIM_LOCK(sim);
- sim-flags = ~CAM_SIM_ON_DONEQ;
camisr_runqueue(sim-sim_doneq);
+ sim-flags = ~CAM_SIM_ON_DONEQ;
CAM_SIM_UNLOCK(sim);
}
mtx_lock(cam_simq_lock);
___
svn-src-...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
___
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 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
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. 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.)? -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve ___ 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/169461: [ugen] USB2 high-speed device detected as full speed
On Tuesday 26 June 2012 22:37:48 lini...@freebsd.org wrote: Old Synopsis: USB2 high-speed device detected as full speed New Synopsis: [ugen] USB2 high-speed device detected as full speed Responsible-Changed-From-To: freebsd-amd64-freebsd-usb Responsible-Changed-By: linimon Responsible-Changed-When: Tue Jun 26 20:37:18 UTC 2012 Responsible-Changed-Why: reclassify. http://www.freebsd.org/cgi/query-pr.cgi?pr=169461 ___ 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 Hi, Please check with pciconf -lv that all EHCI PCI devices have a driver attached. Also check that: sysctl hw.usb.ehci.no_hs Is not set. Have you tried all ports? --HPS ___ 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/169461: [ugen] USB2 high-speed device detected as full speed
The following reply was made to PR usb/169461; it has been noted by GNATS. From: Hans Petter Selasky hsela...@c2i.net To: freebsd-usb@freebsd.org Cc: lini...@freebsd.org, freebsd-am...@freebsd.org, freebsd-gnats-sub...@freebsd.org Subject: Re: usb/169461: [ugen] USB2 high-speed device detected as full speed Date: Wed, 27 Jun 2012 16:51:48 +0200 On Tuesday 26 June 2012 22:37:48 lini...@freebsd.org wrote: Old Synopsis: USB2 high-speed device detected as full speed New Synopsis: [ugen] USB2 high-speed device detected as full speed Responsible-Changed-From-To: freebsd-amd64-freebsd-usb Responsible-Changed-By: linimon Responsible-Changed-When: Tue Jun 26 20:37:18 UTC 2012 Responsible-Changed-Why: reclassify. http://www.freebsd.org/cgi/query-pr.cgi?pr=169461 ___ 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 Hi, Please check with pciconf -lv that all EHCI PCI devices have a driver attached. Also check that: sysctl hw.usb.ehci.no_hs Is not set. Have you tried all ports? --HPS ___ 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 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? BTW: You could try: usbconfig -d X.Y reset Not sure if it helps. --HPS ___ 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 Wednesday 27 June 2012 17:17:02 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? BTW: You could try: usbconfig -d X.Y reset Not sure if it helps. --HPS Another idea for Mav: Maybe you need to query more than the descriptor length? Typically you would query 255 bytes, and then the USB memory stick will return the actual length of the descriptor. Remember some devices have picky limits around 255 bytes on USB descriptor sizes. --HPS ___ 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 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. --HPS ___ 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 Wednesday 27 June 2012 17:33:45 Alexander Motin wrote:
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?
Hi,
Then you need to check using usbdump -i usbusX -s 65536 - what is
actually going on there.
Usually the USB device does not zero-pad any SCSI data.
Code looks like this:
residue = UGETDW(sc-csw.dCSWDataResidue);
if ((!residue) || (sc-sc_quirks IGNORE_RESIDUE)) {
residue = (sc-sc_transfer.data_len -
sc-sc_transfer.actlen);
}
if (residue sc-sc_transfer.data_len) {
DPRINTF(sc, UDMASS_BBB, truncating residue from %d
to %d bytes\n, residue, sc-
sc_transfer.data_len);
residue = sc-sc_transfer.data_len;
}
--HPS
___
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 Wednesday 27 June 2012 17:58:57 Boris Samorodov wrote: 27.06.2012 19:36, Hans Petter Selasky пишет: Then you need to check using usbdump -i usbusX -s 65536 - what is actually going on there. I'm using the unpatched kernel (i.e. stock r237572). There is no /dev/ad*. I use usbconfig -d 7.5 reset and here is the log for the quoted command (attached). Hi, A quick analysis. Read CAPACITY (0x0a 0x25 ): 19:44:42.626128 usbus7.5 SUBM-BULK-EP=0002,SPD=HIGH,NFR=1,SLEN=32,IVAL=0 frame[0] WRITE 31 bytes 55 53 42 43 04 00 00 00 08 00 00 00 80 00 0A 25 |USBC...%| 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -- |... | Returns 8-bytes: 19:44:42.626359 usbus7.5 DONE-BULK- EP=0081,SPD=HIGH,NFR=1,SLEN=8,IVAL=0,ERR=0 frame[0] READ 8 bytes 00 EE 97 4F 00 00 02 00 -- -- -- -- -- -- -- -- |...O| Then suddenly read CAPACITY: 19:44:42.630014 usbus7.5 SUBM-BULK-EP=0002,SPD=HIGH,NFR=1,SLEN=32,IVAL=0 frame[0] WRITE 31 bytes 55 53 42 43 0E 00 00 00 08 00 00 00 80 00 0A 25 |USBC...%| 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -- |... | Returns zero-bytes. That is a memstick bug! Probably CAM layer could retry one more time in that case?? 19:44:42.630231 usbus7.5 DONE-BULK- EP=0081,SPD=HIGH,NFR=1,SLEN=0,IVAL=0,ERR=STALLED frame[0] READ 0 bytes --HPS ___ 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 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. --HPS ___ 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/169461: [ugen] USB2 high-speed device detected as full speed
The following reply was made to PR usb/169461; it has been noted by GNATS. From: Fridtjof Busse fridt...@fbunet.de To: bug-follo...@freebsd.org Cc: Subject: Re: usb/169461: [ugen] USB2 high-speed device detected as full speed Date: Wed, 27 Jun 2012 18:36:39 +0200 --Apple-Mail=_DE60D4D1-74B4-4406-AA4F-A9056C0052BC Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii pciconf output attached. --Apple-Mail=_DE60D4D1-74B4-4406-AA4F-A9056C0052BC Content-Disposition: attachment; filename=pciconf.txt Content-Type: text/plain; name=pciconf.txt Content-Transfer-Encoding: quoted-printable hostb0@pci0:0:0:0: class=3D0x06 card=3D0x1609103c = chip=3D0x96011022 rev=3D0x00 hdr=3D0x00 vendor =3D 'Advanced Micro Devices [AMD]' device =3D 'RS880 Host Bridge' class =3D bridge subclass =3D HOST-PCI pcib1@pci0:0:1:0: class=3D0x060400 card=3D0x1609103c = chip=3D0x9602103c rev=3D0x00 hdr=3D0x01 vendor =3D 'Hewlett-Packard Company' class =3D bridge subclass =3D PCI-PCI pcib2@pci0:0:6:0: class=3D0x060400 card=3D0x1609103c = chip=3D0x96061022 rev=3D0x00 hdr=3D0x01 vendor =3D 'Advanced Micro Devices [AMD]' device =3D 'RS780 PCI to PCI bridge (PCIE port 2)' class =3D bridge subclass =3D PCI-PCI ahci0@pci0:0:17:0: class=3D0x010601 card=3D0x1609103c = chip=3D0x43911002 rev=3D0x40 hdr=3D0x00 vendor =3D 'ATI Technologies Inc' device =3D 'SB7x0/SB8x0/SB9x0 SATA Controller [AHCI mode]' class =3D mass storage subclass =3D SATA ohci0@pci0:0:18:0: class=3D0x0c0310 card=3D0x1609103c = chip=3D0x43971002 rev=3D0x00 hdr=3D0x00 vendor =3D 'ATI Technologies Inc' device =3D 'SB7x0/SB8x0/SB9x0 USB OHCI0 Controller' class =3D serial bus subclass =3D USB ehci0@pci0:0:18:2: class=3D0x0c0320 card=3D0x1609103c = chip=3D0x43961002 rev=3D0x00 hdr=3D0x00 vendor =3D 'ATI Technologies Inc' device =3D 'SB7x0/SB8x0/SB9x0 USB EHCI Controller' class =3D serial bus subclass =3D USB ohci1@pci0:0:19:0: class=3D0x0c0310 card=3D0x1609103c = chip=3D0x43971002 rev=3D0x00 hdr=3D0x00 vendor =3D 'ATI Technologies Inc' device =3D 'SB7x0/SB8x0/SB9x0 USB OHCI0 Controller' class =3D serial bus subclass =3D USB ehci1@pci0:0:19:2: class=3D0x0c0320 card=3D0x1609103c = chip=3D0x43961002 rev=3D0x00 hdr=3D0x00 vendor =3D 'ATI Technologies Inc' device =3D 'SB7x0/SB8x0/SB9x0 USB EHCI Controller' class =3D serial bus subclass =3D USB none0@pci0:0:20:0: class=3D0x0c0500 card=3D0x = chip=3D0x43851002 rev=3D0x42 hdr=3D0x00 vendor =3D 'ATI Technologies Inc' device =3D 'SBx00 SMBus Controller' class =3D serial bus subclass =3D SMBus atapci0@pci0:0:20:1: class=3D0x01018a card=3D0x1609103c = chip=3D0x439c1002 rev=3D0x40 hdr=3D0x00 vendor =3D 'ATI Technologies Inc' device =3D 'SB7x0/SB8x0/SB9x0 IDE Controller' class =3D mass storage subclass =3D ATA isab0@pci0:0:20:3: class=3D0x060100 card=3D0x1609103c = chip=3D0x439d1002 rev=3D0x40 hdr=3D0x00 vendor =3D 'ATI Technologies Inc' device =3D 'SB7x0/SB8x0/SB9x0 LPC host controller' class =3D bridge subclass =3D PCI-ISA pcib3@pci0:0:20:4: class=3D0x060401 card=3D0x = chip=3D0x43841002 rev=3D0x40 hdr=3D0x01 vendor =3D 'ATI Technologies Inc' device =3D 'SBx00 PCI to PCI Bridge' class =3D bridge subclass =3D PCI-PCI ohci2@pci0:0:22:0: class=3D0x0c0310 card=3D0x1609103c = chip=3D0x43971002 rev=3D0x00 hdr=3D0x00 vendor =3D 'ATI Technologies Inc' device =3D 'SB7x0/SB8x0/SB9x0 USB OHCI0 Controller' class =3D serial bus subclass =3D USB ehci2@pci0:0:22:2: class=3D0x0c0320 card=3D0x1609103c = chip=3D0x43961002 rev=3D0x00 hdr=3D0x00 vendor =3D 'ATI Technologies Inc' device =3D 'SB7x0/SB8x0/SB9x0 USB EHCI Controller' class =3D serial bus subclass =3D USB hostb1@pci0:0:24:0:class=3D0x06 card=3D0x = chip=3D0x12001022 rev=3D0x00 hdr=3D0x00 vendor =3D 'Advanced Micro Devices [AMD]' device =3D 'Family 10h Processor HyperTransport Configuration' class =3D bridge subclass =3D HOST-PCI hostb2@pci0:0:24:1:class=3D0x06 card=3D0x = chip=3D0x12011022 rev=3D0x00 hdr=3D0x00 vendor =3D 'Advanced Micro Devices [AMD]' device =3D 'Family 10h Processor Address Map' class =3D bridge subclass =3D HOST-PCI hostb3@pci0:0:24:2:class=3D0x06 card=3D0x = chip=3D0x12021022 rev=3D0x00 hdr=3D0x00 vendor =3D 'Advanced Micro Devices [AMD]' device =3D 'Family 10h Processor DRAM Controller' class =3D bridge
Re: usb/169461: [ugen] USB2 high-speed device detected as full speed
The following reply was made to PR usb/169461; it has been noted by GNATS.
From: Hans Petter Selasky hsela...@c2i.net
To: bug-follo...@freebsd.org
Cc:
Subject: Re: usb/169461: [ugen] USB2 high-speed device detected as full speed
Date: Wed, 27 Jun 2012 18:42:47 +0200
On Wednesday 27 June 2012 18:35:11 Fridtjof Busse wrote:
Hi,
thanks for your reply, please find the pciconf attached.
Am 27.06.2012 um 08:55 schrieb Hans Petter Selasky:
Hi,
pciconf -lv
--HPS
Hi,
Your EHCI hardware is quirked and has known issues:
sys/dev/usb/controller/ehci_pci.c
switch (pci_get_vendor(self)) {
case PCI_EHCI_VENDORID_ATI:
/* SB600 and SB700 EHCI quirk */
switch (pci_get_device(self)) {
case 0x4386:
ehci_pci_ati_quirk(self, 0);
break;
case 0x4396:
ehci_pci_ati_quirk(self, 1);
break;
default:
break;
}
break;
Do you see a QUIRK printout in dmesg?
Maybe you can also need to try setting quirks in /boot/loader.conf:
hw.usb.ehci.lostintrbug: 0
hw.usb.ehci.iaadbug: 0
--HPS
___
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/169461: [ugen] USB2 high-speed device detected as full speed
The following reply was made to PR usb/169461; it has been noted by GNATS. From: Fridtjof Busse fridt...@fbunet.de To: bug-follo...@freebsd.org Cc: Subject: Re: usb/169461: [ugen] USB2 high-speed device detected as full speed Date: Wed, 27 Jun 2012 19:10:23 +0200 Do you see a QUIRK printout in dmesg? Only this line: umass0: SCSI over Bulk-Only; quirks =3D 0x0100 Maybe you can also need to try setting quirks in /boot/loader.conf: =20 hw.usb.ehci.lostintrbug: 0 hw.usb.ehci.iaadbug: 0 =20 I set the configuration in /boot/loader.conf, but no change after = reboot. Still less than 1MB/s write speed. ___ 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 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. umass has a reset mechanism for clearing the stall. But it will significantly make umass more complicated. --HPS ___ 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
