Re: HEAD memsticks broken? [USB/CAM Problems?]
On 20.02.2013 17:43, Alexander Motin wrote: On 16.02.2013 12:07, Joel Dahl wrote: On 14-02-2013 20:37, Joel Dahl wrote: On 12-02-2013 8:51, Hans Petter Selasky wrote: On Monday 11 February 2013 23:21:05 Joel Dahl wrote: On 10-02-2013 0:09, Joel Dahl wrote: On 09-02-2013 20:28, Alexander Motin wrote: How long ago that HEAD was built? Could you get full dmesg? I don't think that PREVENT ALLOW MEDIUM REMOVAL should cause device drop. No sense data present also doesn't look right. As I mentioned earlier, I've tried several HEAD snapshots. Just a quick update on this: I've built quite a few releases now and managed to track down the problem to somewhere between r235789 and r237855. It'll probably take me another day or two before I know which commit actually broke it. Hi, I don't see any relevant USB+UMASS patches for your issue in this interval, but many patches in the SCSI/CAM area. I finally found it. A r237477 memstick boots fine. A r237478 memstick does not. 237478 is the following commit by mav@: r237478 | mav | 2012-06-23 14:32:53 +0200 (Sat, 23 Jun 2012) | 3 lines Add scsi_extract_sense_ccb() -- wrapper around scsi_extract_sense_len(). It allows to remove number of duplicate checks from several places. So, mav@ haven't replied yet so I did some more investigation. I collected all the USB sticks I had in the office (5 in total, all Kingston but different size and models) and tried a memstick installation with each stick. Turns out r237478 only breaks memstick installation in combination with certain USB sticks: # Works: da0: Kingston DataTraveler 2.0 1.00 Removable Direct Access SCSI-2 device da0: 40.000MB/s transfers da0: 7664MB (15695872 512 byte sectors: 255H 63S/T 977C) da0: Kingston DataTraveler 2.0 PMAP Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 1906MB (3903488 512 byte sectors: 255H 63S/T 242C) # Does not work: da0: Kingston DataTraveler G3 1.00 Removable Direct Access SCSI-2 device da0: 40.000MB/s transfers da0: 15295MB (31324160 512 byte sectors: 255H 63S/T 1949C) da0: Kingston DataTraveler G3 1.00 Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 3690MB (7557704 512 byte sectors: 255H 63S/T 470C) da0: Kingston DataTraveler G3 1.00 Removable Direct Access SCSI-2 device da0: 40.000MB/s transfers da0: 1905MB (3903264 512 byte sectors: 255H 63S/T 242C) It seems that only USB sticks labeled as Kingston DataTraveler G3 are affected by r237478 (in my limited testing, at least). This particular model is what you get if you buy the cheapest Kingston model on the market right now. I've reviewed that change once more and I see no flaws in it. My only guess is that it changes something innocent or unrelated in request order that confuses flash firmware, making it stuck and return errors without SCSI sense information. In log provided I see that when device first detected, it normally reports its size. But later, possibly after some command (SYNCHRONIZE CACHE?, PREVENT ALLOW MEDIUM REMOVAL?), it starts to behave wrong. Wrong answer to another READ CAPACITY request causes got CAM status 0xXX message and following device loss. Unfortunately I can't reproduce the problem. All USB sticks I have are working fine without any problems with HEAD system. If I could, I would try to log all commands sent to the stick to find one after which problem begins. Commands could be logged either on CAM layer by running `camcontrol debug -IPpc all` before plugging stick in and `camcontrol debug off` after (you may want to do it in single-user mode or without syslog running to avoid logging activity on other CAM disks), or probably somehow on umass layer, or with usbdump on raw USB layer (in last case some more knowledge will be needed to interpret result). I've analyzed the stick behavior on your system and got to conclusion that problem is not in mentioned revision r237478 itself. This revision fixes some points of too relaxed checks for sense data. At r237477, when umass reported error on PREVENT ALLOW MEDIUM REMOVAL command, it also falsely reported sense data presence. That command was sent by daprevent(), trying to lock the tray of the removable device. Because of relaxed check, it handled those fake responses as successful completion, and tried to unlock tray on device close. That unlock command somehow restored device consciousness and made it to work further. After r237478 the error is no longer hidden, and unlock command is not sent (because lock command has failed). After that, both SYNCHRONIZE CACHE(10) and READ CAPACITY(10) commands return only errors. While SYNCHRONIZE CACHE(10) errors are not significant, errors on READ CAPACITY(10) cause device destruction. Experiment shown that enabling DA_Q_NO_PREVENT quirk for this stick
Re: HEAD memsticks broken? [USB/CAM Problems?]
On 16.02.2013 12:07, Joel Dahl wrote: On 14-02-2013 20:37, Joel Dahl wrote: On 12-02-2013 8:51, Hans Petter Selasky wrote: On Monday 11 February 2013 23:21:05 Joel Dahl wrote: On 10-02-2013 0:09, Joel Dahl wrote: On 09-02-2013 20:28, Alexander Motin wrote: How long ago that HEAD was built? Could you get full dmesg? I don't think that PREVENT ALLOW MEDIUM REMOVAL should cause device drop. No sense data present also doesn't look right. As I mentioned earlier, I've tried several HEAD snapshots. Just a quick update on this: I've built quite a few releases now and managed to track down the problem to somewhere between r235789 and r237855. It'll probably take me another day or two before I know which commit actually broke it. Hi, I don't see any relevant USB+UMASS patches for your issue in this interval, but many patches in the SCSI/CAM area. I finally found it. A r237477 memstick boots fine. A r237478 memstick does not. 237478 is the following commit by mav@: r237478 | mav | 2012-06-23 14:32:53 +0200 (Sat, 23 Jun 2012) | 3 lines Add scsi_extract_sense_ccb() -- wrapper around scsi_extract_sense_len(). It allows to remove number of duplicate checks from several places. So, mav@ haven't replied yet so I did some more investigation. I collected all the USB sticks I had in the office (5 in total, all Kingston but different size and models) and tried a memstick installation with each stick. Turns out r237478 only breaks memstick installation in combination with certain USB sticks: # Works: da0: Kingston DataTraveler 2.0 1.00 Removable Direct Access SCSI-2 device da0: 40.000MB/s transfers da0: 7664MB (15695872 512 byte sectors: 255H 63S/T 977C) da0: Kingston DataTraveler 2.0 PMAP Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 1906MB (3903488 512 byte sectors: 255H 63S/T 242C) # Does not work: da0: Kingston DataTraveler G3 1.00 Removable Direct Access SCSI-2 device da0: 40.000MB/s transfers da0: 15295MB (31324160 512 byte sectors: 255H 63S/T 1949C) da0: Kingston DataTraveler G3 1.00 Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 3690MB (7557704 512 byte sectors: 255H 63S/T 470C) da0: Kingston DataTraveler G3 1.00 Removable Direct Access SCSI-2 device da0: 40.000MB/s transfers da0: 1905MB (3903264 512 byte sectors: 255H 63S/T 242C) It seems that only USB sticks labeled as Kingston DataTraveler G3 are affected by r237478 (in my limited testing, at least). This particular model is what you get if you buy the cheapest Kingston model on the market right now. I've reviewed that change once more and I see no flaws in it. My only guess is that it changes something innocent or unrelated in request order that confuses flash firmware, making it stuck and return errors without SCSI sense information. In log provided I see that when device first detected, it normally reports its size. But later, possibly after some command (SYNCHRONIZE CACHE?, PREVENT ALLOW MEDIUM REMOVAL?), it starts to behave wrong. Wrong answer to another READ CAPACITY request causes got CAM status 0xXX message and following device loss. Unfortunately I can't reproduce the problem. All USB sticks I have are working fine without any problems with HEAD system. If I could, I would try to log all commands sent to the stick to find one after which problem begins. Commands could be logged either on CAM layer by running `camcontrol debug -IPpc all` before plugging stick in and `camcontrol debug off` after (you may want to do it in single-user mode or without syslog running to avoid logging activity on other CAM disks), or probably somehow on umass layer, or with usbdump on raw USB layer (in last case some more knowledge will be needed to interpret result). -- Alexander Motin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEAD memsticks broken? [USB/CAM Problems?]
On 14-02-2013 20:37, Joel Dahl wrote: On 12-02-2013 8:51, Hans Petter Selasky wrote: On Monday 11 February 2013 23:21:05 Joel Dahl wrote: On 10-02-2013 0:09, Joel Dahl wrote: On 09-02-2013 20:28, Alexander Motin wrote: How long ago that HEAD was built? Could you get full dmesg? I don't think that PREVENT ALLOW MEDIUM REMOVAL should cause device drop. No sense data present also doesn't look right. As I mentioned earlier, I've tried several HEAD snapshots. Just a quick update on this: I've built quite a few releases now and managed to track down the problem to somewhere between r235789 and r237855. It'll probably take me another day or two before I know which commit actually broke it. Hi, I don't see any relevant USB+UMASS patches for your issue in this interval, but many patches in the SCSI/CAM area. I finally found it. A r237477 memstick boots fine. A r237478 memstick does not. 237478 is the following commit by mav@: r237478 | mav | 2012-06-23 14:32:53 +0200 (Sat, 23 Jun 2012) | 3 lines Add scsi_extract_sense_ccb() -- wrapper around scsi_extract_sense_len(). It allows to remove number of duplicate checks from several places. So, mav@ haven't replied yet so I did some more investigation. I collected all the USB sticks I had in the office (5 in total, all Kingston but different size and models) and tried a memstick installation with each stick. Turns out r237478 only breaks memstick installation in combination with certain USB sticks: # Works: da0: Kingston DataTraveler 2.0 1.00 Removable Direct Access SCSI-2 device da0: 40.000MB/s transfers da0: 7664MB (15695872 512 byte sectors: 255H 63S/T 977C) da0: Kingston DataTraveler 2.0 PMAP Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 1906MB (3903488 512 byte sectors: 255H 63S/T 242C) # Does not work: da0: Kingston DataTraveler G3 1.00 Removable Direct Access SCSI-2 device da0: 40.000MB/s transfers da0: 15295MB (31324160 512 byte sectors: 255H 63S/T 1949C) da0: Kingston DataTraveler G3 1.00 Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 3690MB (7557704 512 byte sectors: 255H 63S/T 470C) da0: Kingston DataTraveler G3 1.00 Removable Direct Access SCSI-2 device da0: 40.000MB/s transfers da0: 1905MB (3903264 512 byte sectors: 255H 63S/T 242C) It seems that only USB sticks labeled as Kingston DataTraveler G3 are affected by r237478 (in my limited testing, at least). This particular model is what you get if you buy the cheapest Kingston model on the market right now. -- Joel ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEAD memsticks broken? [USB/CAM Problems?]
On 12-02-2013 8:51, Hans Petter Selasky wrote: On Monday 11 February 2013 23:21:05 Joel Dahl wrote: On 10-02-2013 0:09, Joel Dahl wrote: On 09-02-2013 20:28, Alexander Motin wrote: How long ago that HEAD was built? Could you get full dmesg? I don't think that PREVENT ALLOW MEDIUM REMOVAL should cause device drop. No sense data present also doesn't look right. As I mentioned earlier, I've tried several HEAD snapshots. Just a quick update on this: I've built quite a few releases now and managed to track down the problem to somewhere between r235789 and r237855. It'll probably take me another day or two before I know which commit actually broke it. Hi, I don't see any relevant USB+UMASS patches for your issue in this interval, but many patches in the SCSI/CAM area. I finally found it. A r237477 memstick boots fine. A r237478 memstick does not. 237478 is the following commit by mav@: r237478 | mav | 2012-06-23 14:32:53 +0200 (Sat, 23 Jun 2012) | 3 lines Add scsi_extract_sense_ccb() -- wrapper around scsi_extract_sense_len(). It allows to remove number of duplicate checks from several places. -- Joel ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEAD memsticks broken? [USB/CAM Problems?]
On 10-02-2013 0:09, Joel Dahl wrote: On 09-02-2013 20:28, Alexander Motin wrote: How long ago that HEAD was built? Could you get full dmesg? I don't think that PREVENT ALLOW MEDIUM REMOVAL should cause device drop. No sense data present also doesn't look right. As I mentioned earlier, I've tried several HEAD snapshots. Just a quick update on this: I've built quite a few releases now and managed to track down the problem to somewhere between r235789 and r237855. It'll probably take me another day or two before I know which commit actually broke it. -- Joel ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEAD memsticks broken? [USB/CAM Problems?]
On Monday 11 February 2013 23:21:05 Joel Dahl wrote: On 10-02-2013 0:09, Joel Dahl wrote: On 09-02-2013 20:28, Alexander Motin wrote: How long ago that HEAD was built? Could you get full dmesg? I don't think that PREVENT ALLOW MEDIUM REMOVAL should cause device drop. No sense data present also doesn't look right. As I mentioned earlier, I've tried several HEAD snapshots. Just a quick update on this: I've built quite a few releases now and managed to track down the problem to somewhere between r235789 and r237855. It'll probably take me another day or two before I know which commit actually broke it. Hi, I don't see any relevant USB+UMASS patches for your issue in this interval, but many patches in the SCSI/CAM area. --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEAD memsticks broken? [USB/CAM Problems?]
On 09-02-2013 8:32, Joel Dahl wrote: Hi, I suspect something is broken with memsticks built from HEAD. I noticed that I couldn't boot the latest HEAD (amd64) memstick snapshot on two machines (Lenovo X220 and HP ProLiant ML350 G5). Trying snapshots from the FreeBSD.org FTP or allbsd.org makes no difference. I compared output from booting RELENG_9 and HEAD: RELENG_9: ugen2.3: Kingston at usbus2 umass0: Kingston DataDtraveler G3, class 0/0, rev 2.00/1.00, addr 3 on usbus2 umass0: SCSI over Bulk-Only; quirks = 0x0100 umass0:4:0:-1: Attached to scbus4 da0 at umass-sim0 bus 0 scbus4 target 0 lun 0 da0: Kingston DataTraveler G3 1.00 Removable Direct Access SCSI-2 device ??? da0: 40.000MB/s transfers da0: 1905MB (3903264 512 byte sectors: 255H 63S/T 24SC) (da0-umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 0 0 0 1 0 (da0-umass-sim0:0:0:0): CAM status: SCSI Status Error (da0-umass-sim0:0:0:0): SCSI status: Check Condition (da0-umass-sim0:0:0:0): SCSI sense: No sense data present (da0-umass-sim0:0:0:0): Retrying command (per sense data) SNIP LOTS OF REDUNDANT OUTPUT SNIP LOTS OF REDUNDANT OUTPUT SNIP LOTS OF REDUNDANT OUTPUT Root mount waiting for: usbus2 ugen2.4: Lenovo at usbus2 Trying to mount root from ufs:/dev/ufs/FreeBSD_Install [ro,noatime]... Starting file system checks: /dev/ufs/FreeBSD_Install: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ufs/FreeBSD_Install: clean, 43155 free (507 frags, 5331 blocks, 0.1% fragmentation) Mounting local file systems:. and it works. HEAD: ugen2.3: Kingston at usbus2 umass0: Kingston DataDtraveler G3, class 0/0, rev 2.00/1.00, addr 3 on usbus2 umass0: SCSI over Bulk-Only; quirks = 0x0100 umass0:5:0:-1: Attached to scbus5 da0 at umass-sim0 bus 0 scbus5 target 0 lun 0 da0: Kingston DataTraveler G3 1.00 Removable Direct Access SCSI-0 device ?? da0: 40.000MB/s transfers da0: 3690MB (7557704 512 byte sectors: 255H 63S/T 470SC) (da0-umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 0 0 0 1 0 (da0-umass-sim0:0:0:0): CAM status: SCSI Status Error (da0-umass-sim0:0:0:0): SCSI status: Check Condition (da0-umass-sim0:0:0:0): SCSI sense: No sense data present (da0-umass-sim0:0:0:0): Retrying command (per sense data) SNIP LOTS OF REDUNDANT OUTPUT SNIP LOTS OF REDUNDANT OUTPUT SNIP LOTS OF REDUNDANT OUTPUT (da0-umass-sim0:0:0:0): Error 5, Retries exhausted (da0-umass-sim0:0:0:0): got CAM status 0x8c (da0-umass-sim0:0:0:0): fatal error, failed to attach to device (da0-umass-sim0:0:0:0): lost device - 0 outstanding, 4 refs (da0-umass-sim0:0:0:0): removing device entry ugen2.4: Lenovo at usbus2 Trying to mount root from ufs:/dev/ufs/FreeBSD_Install [ro,noatime]... mountroot: waiting for device /dev/ufs/FreeBSD_Install ... Mounting from ufs:/dev/ufs/FreeBSD_Install failed with error 19. BOOM -- Joel ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEAD memsticks broken? [USB/CAM Problems?]
On Saturday 09 February 2013 10:26:59 Joel Dahl wrote: On 09-02-2013 8:32, Joel Dahl wrote: Hi, I suspect something is broken with memsticks built from HEAD. I noticed that I couldn't boot the latest HEAD (amd64) memstick snapshot on two machines (Lenovo X220 and HP ProLiant ML350 G5). Trying snapshots from the FreeBSD.org FTP or allbsd.org makes no difference. I compared output from booting RELENG_9 and HEAD: RELENG_9: ugen2.3: Kingston at usbus2 umass0: Kingston DataDtraveler G3, class 0/0, rev 2.00/1.00, addr 3 on usbus2 umass0: SCSI over Bulk-Only; quirks = 0x0100 umass0:4:0:-1: Attached to scbus4 da0 at umass-sim0 bus 0 scbus4 target 0 lun 0 da0: Kingston DataTraveler G3 1.00 Removable Direct Access SCSI-2 device ??? da0: 40.000MB/s transfers da0: 1905MB (3903264 512 byte sectors: 255H 63S/T 24SC) (da0-umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 0 0 0 1 0 (da0-umass-sim0:0:0:0): CAM status: SCSI Status Error (da0-umass-sim0:0:0:0): SCSI status: Check Condition (da0-umass-sim0:0:0:0): SCSI sense: No sense data present (da0-umass-sim0:0:0:0): Retrying command (per sense data) SNIP LOTS OF REDUNDANT OUTPUT SNIP LOTS OF REDUNDANT OUTPUT SNIP LOTS OF REDUNDANT OUTPUT Root mount waiting for: usbus2 ugen2.4: Lenovo at usbus2 Trying to mount root from ufs:/dev/ufs/FreeBSD_Install [ro,noatime]... Starting file system checks: /dev/ufs/FreeBSD_Install: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ufs/FreeBSD_Install: clean, 43155 free (507 frags, 5331 blocks, 0.1% fragmentation) Mounting local file systems:. and it works. HEAD: ugen2.3: Kingston at usbus2 umass0: Kingston DataDtraveler G3, class 0/0, rev 2.00/1.00, addr 3 on usbus2 umass0: SCSI over Bulk-Only; quirks = 0x0100 umass0:5:0:-1: Attached to scbus5 da0 at umass-sim0 bus 0 scbus5 target 0 lun 0 da0: Kingston DataTraveler G3 1.00 Removable Direct Access SCSI-0 device ?? da0: 40.000MB/s transfers da0: 3690MB (7557704 512 byte sectors: 255H 63S/T 470SC) (da0-umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 0 0 0 1 0 (da0-umass-sim0:0:0:0): CAM status: SCSI Status Error (da0-umass-sim0:0:0:0): SCSI status: Check Condition (da0-umass-sim0:0:0:0): SCSI sense: No sense data present (da0-umass-sim0:0:0:0): Retrying command (per sense data) SNIP LOTS OF REDUNDANT OUTPUT SNIP LOTS OF REDUNDANT OUTPUT SNIP LOTS OF REDUNDANT OUTPUT (da0-umass-sim0:0:0:0): Error 5, Retries exhausted (da0-umass-sim0:0:0:0): got CAM status 0x8c (da0-umass-sim0:0:0:0): fatal error, failed to attach to device (da0-umass-sim0:0:0:0): lost device - 0 outstanding, 4 refs (da0-umass-sim0:0:0:0): removing device entry ugen2.4: Lenovo at usbus2 Trying to mount root from ufs:/dev/ufs/FreeBSD_Install [ro,noatime]... mountroot: waiting for device /dev/ufs/FreeBSD_Install ... Mounting from ufs:/dev/ufs/FreeBSD_Install failed with error 19. Hi, You can try to set the no-synchronize cache quirk in sys/dev/usb/quirk/usb_quirk.c for your device. I'm not sure if it helps, but else I suspect it is not an USB issue. --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEAD memsticks broken? [USB/CAM Problems?]
On 09.02.2013 12:15, Hans Petter Selasky wrote: On Saturday 09 February 2013 10:26:59 Joel Dahl wrote: On 09-02-2013 8:32, Joel Dahl wrote: Hi, I suspect something is broken with memsticks built from HEAD. I noticed that I couldn't boot the latest HEAD (amd64) memstick snapshot on two machines (Lenovo X220 and HP ProLiant ML350 G5). Trying snapshots from the FreeBSD.org FTP or allbsd.org makes no difference. I compared output from booting RELENG_9 and HEAD: RELENG_9: ugen2.3: Kingston at usbus2 umass0: Kingston DataDtraveler G3, class 0/0, rev 2.00/1.00, addr 3 on usbus2 umass0: SCSI over Bulk-Only; quirks = 0x0100 umass0:4:0:-1: Attached to scbus4 da0 at umass-sim0 bus 0 scbus4 target 0 lun 0 da0: Kingston DataTraveler G3 1.00 Removable Direct Access SCSI-2 device ??? da0: 40.000MB/s transfers da0: 1905MB (3903264 512 byte sectors: 255H 63S/T 24SC) (da0-umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 0 0 0 1 0 (da0-umass-sim0:0:0:0): CAM status: SCSI Status Error (da0-umass-sim0:0:0:0): SCSI status: Check Condition (da0-umass-sim0:0:0:0): SCSI sense: No sense data present (da0-umass-sim0:0:0:0): Retrying command (per sense data) SNIP LOTS OF REDUNDANT OUTPUT SNIP LOTS OF REDUNDANT OUTPUT SNIP LOTS OF REDUNDANT OUTPUT Root mount waiting for: usbus2 ugen2.4: Lenovo at usbus2 Trying to mount root from ufs:/dev/ufs/FreeBSD_Install [ro,noatime]... Starting file system checks: /dev/ufs/FreeBSD_Install: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ufs/FreeBSD_Install: clean, 43155 free (507 frags, 5331 blocks, 0.1% fragmentation) Mounting local file systems:. and it works. HEAD: ugen2.3: Kingston at usbus2 umass0: Kingston DataDtraveler G3, class 0/0, rev 2.00/1.00, addr 3 on usbus2 umass0: SCSI over Bulk-Only; quirks = 0x0100 umass0:5:0:-1: Attached to scbus5 da0 at umass-sim0 bus 0 scbus5 target 0 lun 0 da0: Kingston DataTraveler G3 1.00 Removable Direct Access SCSI-0 device ?? da0: 40.000MB/s transfers da0: 3690MB (7557704 512 byte sectors: 255H 63S/T 470SC) (da0-umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 0 0 0 1 0 (da0-umass-sim0:0:0:0): CAM status: SCSI Status Error (da0-umass-sim0:0:0:0): SCSI status: Check Condition (da0-umass-sim0:0:0:0): SCSI sense: No sense data present (da0-umass-sim0:0:0:0): Retrying command (per sense data) SNIP LOTS OF REDUNDANT OUTPUT SNIP LOTS OF REDUNDANT OUTPUT SNIP LOTS OF REDUNDANT OUTPUT (da0-umass-sim0:0:0:0): Error 5, Retries exhausted (da0-umass-sim0:0:0:0): got CAM status 0x8c (da0-umass-sim0:0:0:0): fatal error, failed to attach to device (da0-umass-sim0:0:0:0): lost device - 0 outstanding, 4 refs (da0-umass-sim0:0:0:0): removing device entry ugen2.4: Lenovo at usbus2 Trying to mount root from ufs:/dev/ufs/FreeBSD_Install [ro,noatime]... mountroot: waiting for device /dev/ufs/FreeBSD_Install ... Mounting from ufs:/dev/ufs/FreeBSD_Install failed with error 19. Hi, You can try to set the no-synchronize cache quirk in sys/dev/usb/quirk/usb_quirk.c for your device. I'm not sure if it helps, but else I suspect it is not an USB issue. How long ago that HEAD was built? Could you get full dmesg? I don't think that PREVENT ALLOW MEDIUM REMOVAL should cause device drop. No sense data present also doesn't look right. -- Alexander Motin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEAD memsticks broken? [USB/CAM Problems?]
On 09-02-2013 20:28, Alexander Motin wrote: How long ago that HEAD was built? Could you get full dmesg? I don't think that PREVENT ALLOW MEDIUM REMOVAL should cause device drop. No sense data present also doesn't look right. As I mentioned earlier, I've tried several HEAD snapshots. This is booting a r246472 memstick. I currently have no way to get a full dmesg, but I have hand-typed the last parts below: usbus0: 480Mbps High Speed USB v2.0 usbus1: 5.0Gbps Super Speed USB v3.0 usbus2: 480Mbps High Speed USB v2.0 ugen0.1: Intel at usbus0 uhub0: Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1 on usbus0 ugen1.1: 0x1033 at usbus1 uhub1: 0x1033 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1 on usbus1 ugen2.1: Intel at usbus2 uhub2: Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1 on usbus2 ses0 at ahciem0 bus 0 scbus3 target 0 lun 0 ses0: AHCI SGPIO Enclosure 1.00 0001 SEMB S-E-S 2.00 device ses0: SEMB SES Device ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: Intel SSDSA2BW160G3L 4PC1LE05 ATA-8 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 152627MB (312581808 512 byte sectors: 1H 63S/T 16383C) ada0: Previously was known as ad4 SMP: AP CPU #1 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #2 Launched! Timecounter TSC-low frequency 1395499430 Hz quality 1000 WARNING: WITNESS option enabled, expect reduced performance. uhub1: 4 ports with 4 removable, self powered Root mount waiting for: usbus2 usbus0 uhub0: 3 ports with 3 removable, self powered uhub2: 3 ports with 3 removable, self powered ugen0.2: vendor 0x8087 at usbus0 uhub3: vendor 0x8087 product 0x0024, class 9/0, rev 2.00/0.00, addr 2 on usbus0 ugen2.2: vendor 0x8087 at usbus2 uhub4: vendor 0x8087 product 0x0024, class 9/0, rev 2.00/0.00, addr 2 on usbus2 Root mount wating for: usbus2 usbus0 ugen0.4: Broadcom Corp at usbus0 ugen0.5: Chicony Electronics Cp,. Ltd. at usbus0 ugen2.3: Kingston at usbus2 umass0: Kingston DataTraveler G3, class 0/0, rev 2.00/1.00, addr 3 on usbus2 umass0: SCSI over BUlk-Only; quirks = 0x0100 umass0:5:0:-1: Attached to scbus5 da0 at umass-sim0 bus 0 scbus5 target 0 lun 0 da0: Kingston DataTraveler G3 1.00 Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 3690MB (7557704 512 byte sectors: 255H 63S/T 470C) (da0:umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 00 00 00 01 00 (da0:umass-sim0:0:0:0): CAM status: Auto-Sense Retrieval Failed (da0:umass-sim0:0:0:0): Error 5, Unretryable error (da0:umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 00 00 00 01 00 (da0:umass-sim0:0:0:0): CAM status: Auto-Sense Retrieval Failed (da0:umass-sim0:0:0:0): Error 5, Unretryable error (da0:umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 00 00 00 01 00 (da0:umass-sim0:0:0:0): CAM status: Auto-Sense Retrieval Failed (da0:umass-sim0:0:0:0): Error 5, Unretryable error (da0:umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 00 00 00 01 00 (da0:umass-sim0:0:0:0): CAM status: Auto-Sense Retrieval Failed (da0:umass-sim0:0:0:0): Error 5, Unretryable error (da0:umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 00 00 00 01 00 (da0:umass-sim0:0:0:0): CAM status: Auto-Sense Retrieval Failed (da0:umass-sim0:0:0:0): Error 5, Unretryable error (da0:umass-sim0:0:0:0): SYNCHRONIZE CACHE(10). CDB: 35 00 00 00 00 00 00 00 00 00 (da0:umass-sim0:0:0:0): CAM status: Auto-Sense Retrieval Failed (da0:umass-sim0:0:0:0): Error 5, Unretryable error (da0:umass-sim0:0:0:0): got CAM status 0x50 (da0:umass-sim0:0:0:0): fatal error, failed to attach to device (da0:umass-sim0:0:0:0): lost device - 0 outstanding, 4 refs (da0:umass-sim0:0:0:0): removing device entry Root mount waiting for: usbus2 ugen2.4: Lenovo at usbus2 Trying to mount root from ufs:/dev/ufs/FreeBSD_Install [ro, noatime]... mountroot: waiting for device /dev/ufs/FreeBSD_Install ... Mounting from ufs:/dev/ufs/FreeBSD_Install failed with error 19. mountroot I can probably take a couple of pictures of the entire dmesg, if that would be of any interest. -- Joel ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
