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: [usb] Kingston 8Gb is not usable
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. Hi, 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? --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"
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 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? --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 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 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] 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 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 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: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 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 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: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 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
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] 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 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: at usbus7 kernel: umass0: 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: 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:0:0): got CAM status 0x8c kernel: (da0
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: at usbus7 kernel: umass0: 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: 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:0:0): got CAM status 0x8c kernel: (da0:umass-sim0:0:0:0): fatal error, failed to
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: at usbus7 kernel: umass0: 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: 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 to device kernel: (da0:umass-sim0:0:0:0): Periph invalidated kernel: (da0:umass-sim
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: at usbus7 Jun 26 15:27:40 bsam kernel: umass0: 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: 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 Tuesday 26 June 2012 14:29:28 Boris Samorodov wrote: > Hi! > > 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: at usbus7 > Jun 26 15:27:40 bsam kernel: umass0: 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: 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) Hi, There has been no change in the umass driver, but there has been many changes in the CAM layer. Mav: Any idea? --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"
[usb] Kingston 8Gb is not usable
Hi! 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: at usbus7 Jun 26 15:27:40 bsam kernel: umass0: 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: 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) Jun 26 15:27:40 bsam kernel: (da0:umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 0 0 0 1 0 Jun 26 15:27:40 bsam kernel: (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error Jun 26 15:27:40 bsam kernel: (da0:umass-sim0:0:0:0): SCSI status: Check Condition Jun 26 15:27:40 bsam kernel: (da0:umass-sim0:0:0:0): SCSI sense: No sense data present Jun 26 15:27:40 bsam kernel: (da0:umass-sim0:0:0:0): Retrying command (per sense data) Jun 26 15:27:40 bsam kernel: (da0:umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 0 0 0 1 0 Jun 26 15:27:40 bsam kernel: (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error Jun 26 15:27:40 bsam kernel: (da0:umass-sim0:0:0:0): SCSI status: Check Condition Jun 26 15:27:40 bsam kernel: (da0:umass-sim0:0:0:0): SCSI sense: No sense data present Jun 26 15:27:40 bsam kernel: (da0:umass-sim0:0:0:0): Error 5, Retries exhausted Jun 26 15:27:40 bsam kernel: (da0:umass-sim0:0:0:0): SYNCHRONIZE CACHE(10). CDB: 35 0 0 0 0 0 0 0 0 0 Jun 26 15:27:40 bsam kernel: (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error Jun 26 15:27:40 bsam kernel: (da0:umass-sim0:0:0:0): SCSI status: Check Condition Jun 26 15:27:40 bsam kernel: (da0:umass-sim0:0:0:0): SCSI sense: No sense data present Jun 26 15:27:40 bsam kernel: (da0:umass-sim0:0:0:0): Retrying command (per sense data) Jun 26 15:27:40 bsam kernel: (da0:umass-sim0:0:0:0): SYNCHRONIZE CACHE(10). CDB: 35 0 0 0 0 0 0 0 0 0 Jun 26 15:27:40 bsam kernel: (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error Jun 26 15:27:40 bsam kernel: (da0:umass-sim0:0:0:0): SCSI status: Check Condition Jun 26 15:27:40 bsam kernel: (da0:umass-sim0:0:0:0): SCSI sense: No sense data present Jun 26 15:27:40 bsam kernel: (da0:umass-sim0:0:0:0): Error 5, Retries exhausted Jun 26 15:27:40 bsam kernel: (da0:umass-sim0:0:0:0): got CAM status 0x8c Jun 26 15:27:40 bsam kernel: (da0:umass-sim0:0:0:0): fatal error, failed to attach to device Jun 26 15:27:40 bsam kernel: (da0:umass-sim0:0:0:0): lost device - 0 outstanding, 4 refs Jun 26 15:27:40 bsam kernel: (da0:umass-sim0:0:0:0): removing device entry - The previous kernel/world was from Jun 14. The last 5 lines didn't occur and the disk /dev/da* was usable. Quirks were the same. -- 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"
