On Fri, 25 Mar 2011, Arvid Brodin wrote:
> Sorry about my sloppy language. :) I'm not exactly sure what happens, but the
> symptoms is the cp (or sync) never returns and cannot be terminated by ctrl-c.
> The usb analyzer shows one NAKed IN transfer every 9 micro-seconds, or
> thereabouts. I also get this:
>
> INFO: task scsi_eh_0:491 blocked for more than 120 seconds.
> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> scsi_eh_0 D 9028ba06 0 491 2 0x00000000
> Stack: (0x93ed7eb8 to 0x93ed8000)
> 7ea0: 93ed6000 9028bd3c
> 7ec0: 90025178 9028bd3c 93ed7f1c 93df9630 93df962c 7fffffff 00000002 ffffe000
> ...
> Call trace:
> [<9028bd3c>] schedule_timeout+0x14/0x170
> [<9028bc12>] wait_for_common+0xaa/0x10c
> [<9028bcec>] wait_for_completion+0xc/0x14
> [<901b674e>] command_abort+0x7a/0xa0
> [<9018a4aa>] scsi_try_to_abort_cmd+0x1e/0x22
> [<9018b976>] scsi_error_handler+0xda/0x29c
> [<9003d612>] kthread+0x5c/0x76
> [<9002d894>] do_exit+0x0/0x524
>
> no locks held by scsi_eh_0/491.
That's normal for a hung system. Of course, the real question is why
is it hanging? Probably a bug in the isp176x driver.
> I've read the EHCI spec (or large parts anyhow) but I'm having trouble
> translating it to the ISP176x (which of course aren't EHCI controllers).
> If I understand correctly, the EHCI has the complete schedule (queue heads
> and all) in HW memory. That's not the case with the ISP176x. Instead, the
> queue is managed by software, and only when a qtd is actually due for
> transfer, its "head" ("ptd", Proprietary Transfer Descriptor) is written
> to the HW. The hardware then transfers the qtd and signals the SW with an
> interrupt when done. If the device NAKs, the ISP176x retries until its
> NakCnt is zero. It's then up to the SW to reload the NakCnt from RL and
> re-schedule the ptd. It's also possible to set NakCnt and RL to zero to
> make the controller retry forever without signalling (apparently used for
> periodic transfers).
>
> The problem arises when the device NAKs indefinitely, which makes the (my)
> software never return the urb to the usb core. I simply don't know how to
> decide when to give up (and of course, if the HW retries forever, I have no
> chance to give up)!
You don't have to decide when to give up; the decision is already made
for you by other parts of the kernel. The URB that is stuck, waiting
for the IN transfer to complete, should get unlinked after 30 seconds
of inactivity. It sounds like the isp176x driver isn't unlinking the
URB properly.
> There's no asynchronous schedule to restart, and even
> if there was, section 4.8.4.1 of the EHCI spec has no "way out" as far as
> I can see - it says to reload the NakCnt fields and try again on schedule
> restart.
Right. But of course, the controller should _stop_ trying after the
URB is unlinked. The same is true of the isp176x driver.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
