umass problem.

[bland-2]

Hi,

I can reproduce this reliably with simple dd if=/dev/da0. At the end
external USB drive turns off the lights (tough it still spinning) and
system fall into the state where it is impossible to reboot it cleanly. I
can get drive back only after full power cycle (simple reboot is not
enough). Using same drive under moderate load seems mostly to work. It also
is used to work under 7.2.

Anyone have an idea what this could be?

Oct 19 22:58:12 hub kernel: umass0:umass_transfer_start: transfer index =
4
Oct 19 22:58:12 hub kernel: umass0:umass_t_bbb_data_read_callback:
max_bulk=131072, data_rem=65536
Oct 19 22:58:12 hub kernel: umass0:umass_t_bbb_data_read_callback:
max_bulk=131072, data_rem=0
Oct 19 22:58:12 hub kernel: umass0:umass_transfer_start: transfer index =
8
Oct 19 22:58:12 hub kernel: umass0:umass_bbb_dump_csw: CSW 5737: sig =
0x53425355 (valid), tag = 0x00001669, res = 0, status = 0x00 (good)
Oct 19 22:58:12 hub kernel: umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO:
cmd: 0x28, flags: 0x40, 10b cmd/65536b data/32b sense
Oct 19 22:58:12 hub kernel: umass0:umass_bbb_dump_cbw: CBW 5738: cmd = 10b
(0x28000000c500...), data = 65536b, lun = 0, dir = in
Oct 19 22:58:12 hub kernel: umass0:umass_transfer_start: transfer index =
4
Oct 19 22:58:12 hub kernel: umass0:umass_t_bbb_data_read_callback:
max_bulk=131072, data_rem=65536
Oct 19 22:58:12 hub kernel: umass0:umass_t_bbb_data_read_callback:
max_bulk=131072, data_rem=0
Oct 19 22:58:12 hub kernel: umass0:umass_transfer_start: transfer index =
8
Oct 19 22:58:12 hub kernel: umass0:umass_bbb_dump_csw: CSW 5738: sig =
0x53425355 (valid), tag = 0x0000166a, res = 0, status = 0x00 (good)
Oct 19 22:58:12 hub kernel: umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO:
cmd: 0x28, flags: 0x40, 10b cmd/65536b data/32b sense
Oct 19 22:58:12 hub kernel: umass0:umass_bbb_dump_cbw: CBW 5739: cmd = 10b
(0x28000000c580...), data = 65536b, lun = 0, dir = in
Oct 19 22:58:12 hub kernel: umass0:umass_transfer_start: transfer index =
4
Oct 19 22:58:12 hub kernel: umass0:umass_t_bbb_data_read_callback:
max_bulk=131072, data_rem=65536
Oct 19 22:59:15 hub kernel: umass0:umass_transfer_start: transfer index =
5
Oct 19 22:59:15 hub kernel: umass0:umass_transfer_start: transfer index =
8
Oct 19 22:59:15 hub kernel: umass0:umass_t_bbb_status_callback: Failed to
read CSW: USB_ERR_STALLED, try 0
Oct 19 22:59:15 hub kernel: umass0:umass_transfer_start: transfer index =
5
Oct 19 22:59:15 hub kernel: umass0:umass_transfer_start: transfer index =
8
Oct 19 22:59:15 hub kernel: umass0:umass_t_bbb_status_callback: Failed to
read CSW: USB_ERR_STALLED, try 1
Oct 19 22:59:15 hub kernel: umass0:umass_tr_error: transfer error,
USB_ERR_STALLED -> reset
Oct 19 22:59:15 hub kernel: umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO:
cmd: 0x28, flags: 0x40, 10b cmd/65536b data/32b sense
Oct 19 22:59:15 hub kernel: umass0:umass_t_bbb_reset1_callback: BBB reset!
Oct 19 22:59:20 hub kernel: umass0:umass_tr_error: transfer error,
USB_ERR_TIMEOUT -> reset
Oct 19 22:59:20 hub kernel: umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO:
cmd: 0x28, flags: 0x40, 10b cmd/65536b data/32b sense
Oct 19 22:59:20 hub kernel: umass0:umass_t_bbb_reset1_callback: BBB reset!
Oct 19 22:59:26 hub kernel: umass0:umass_tr_error: transfer error,
USB_ERR_TIMEOUT -> reset
Oct 19 22:59:26 hub kernel: umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO:
cmd: 0x28, flags: 0x40, 10b cmd/65536b data/32b sense
Oct 19 22:59:26 hub kernel: umass0:umass_t_bbb_reset1_callback: BBB reset!
Oct 19 22:59:31 hub kernel: umass0:umass_tr_error: transfer error,
USB_ERR_TIMEOUT -> reset
Oct 19 22:59:31 hub kernel: umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO:
cmd: 0x28, flags: 0x40, 10b cmd/65536b data/32b sense
Oct 19 22:59:31 hub kernel: umass0:umass_t_bbb_reset1_callback: BBB reset!
Oct 19 22:59:37 hub kernel: umass0:umass_tr_error: transfer error,
USB_ERR_TIMEOUT -> reset

Thanks,
Alexander.

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

[Alexander Nedotsukov-2]

Well I do. This is a regression in EHCI driver introduced along the new
usb stack. Please review patch attached.

Thanks,
Alexander.

On Tue, 20 Oct 2009 10:53:36 +0900, Alexander Nedotsukov
<bland@...> wrote:
> Hi,
>
> I can reproduce this reliably with simple dd if=/dev/da0. At the end
> external USB drive turns off the lights (tough it still spinning) and
> system fall into the state where it is impossible to reboot it cleanly.
I
> can get drive back only after full power cycle (simple reboot is not
> enough). Using same drive under moderate load seems mostly to work. It
also
> is used to work under 7.2.
>
> Anyone have an idea what this could be?


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

[Hans Petter Selasky]

On Friday 06 November 2009 05:52:48 Alexander Nedotsukov wrote:
> Well I do. This is a regression in EHCI driver introduced along the new
> usb stack. Please review patch attached.
>
> Thanks,
> Alexander.

Hi,

Your patch looks good.

I will go through it later today.

One little issue. There is no callout_drain() call for the new callout. Look
for existing callout_drain() calls for the pcd timer.

--HPS

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

[Hans Petter Selasky]

On Friday 06 November 2009 05:52:48 Alexander Nedotsukov wrote:
> Well I do. This is a regression in EHCI driver introduced along the new
> usb stack. Please review patch attached.
>
> Thanks,
> Alexander.
>

Hi,

Your patch has been committed to USB P4 with some modifications. Please test!

http://p4web.freebsd.org/chv.cgi?CH=170302

--HPS

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

[bland-2]

Hans,

It works. Perhaps you need to adjust debug output of ehci_poll_timeout
() but otherwise it is fine.
Just curious, is there is no way to detect lost interrupt in new usb  
stack quickly or check in the old one was not correct anyway?

Thanks,
Alexander.

On 07.11.2009, at 9:09, Hans Petter Selasky wrote:

> On Friday 06 November 2009 05:52:48 Alexander Nedotsukov wrote:
>> Well I do. This is a regression in EHCI driver introduced along the  
>> new
>> usb stack. Please review patch attached.
>>
>> Thanks,
>> Alexander.
>>
>
> Hi,
>
> Your patch has been committed to USB P4 with some modifications.  
> Please test!
>
> http://p4web.freebsd.org/chv.cgi?CH=170302
>
> --HPS
>
> _______________________________________________
> freebsd-current@... mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe@...
> "

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

[Hans Petter Selasky]

On Sunday 08 November 2009 14:24:39 Alexander Nedotsukov wrote:
> Just curious, is there is no way to detect lost interrupt in new usb  
> stack quickly or check in the old one was not correct anyway?

Hi,

The check might not be correct, because new jobs can be queued immediately
after the interrupt, and in that case it is not correct to check of the number
of jobs is zero.

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