Vincent Pelletier <plr.vincent@xxxxxxxxx> writes: >> I couldn't reproduce that "no CRC" >> issue with debian kernel's .config > > I did not diff recently my .config with debian's. I think I based it on > Debian's 4.2 and then let it evolve "naturally" following vanilla. > I checked all diffs against Debian's 4.8 and reduced it a lot (mostly > new drivers which I did not enable). Doing so, I discovered that I > somehow did not have "CONFIG_MODVERSIONS" set at all (not even the > "is not set" comment). > > 4.9-rc7 is done building, there is no warning about CRC anymore - > I'm not sure whether this comes from rc7 or MODVERSIONS. I can check if > you think it is valuable. At 4.9-rc7, MODVERSIONS was marked as BROKEN. It might fix that issue. Well, anyway, it doesn't matter anymore. > Resulting kernel booted successfully once, but I must do several more > tries before being able to tell if it reliably does so. > I also want to check rc7 without your patches, to compare boot failure > rate. > > For reference, the I pushed the source I built in > https://github.com/vpelletier/linux/tree/ts651_4.9-rc7 > Please do check I did not do mistakes when resolving conflicts (the 2 > last commits). Your ts651_4.9-rc7 (latest commit) is broken somehow. The following incremental patch for ts651_4.9-rc7 is to fix it. With this, xhci will become same with mine. Thanks. -- OGAWA Hirofumi <hirofumi@xxxxxxxxxxxxxxxxxx> --- drivers/usb/host/xhci-mem.c | 2 +- drivers/usb/host/xhci-ring.c | 16 +++++----------- 2 files changed, 6 insertions(+), 12 deletions(-) diff -puN drivers/usb/host/xhci-ring.c~ts651_4.9-rc7-fix drivers/usb/host/xhci-ring.c --- linux/drivers/usb/host/xhci-ring.c~ts651_4.9-rc7-fix 2016-11-29 01:58:29.103923074 +0900 +++ linux-hirofumi/drivers/usb/host/xhci-ring.c 2016-11-29 02:02:48.958281665 +0900 @@ -327,16 +327,9 @@ static int xhci_abort_cmd_ring(struct xh xhci_dbg(xhci, "Abort command ring\n"); - temp_64 = xhci_read_64(xhci, &xhci->op_regs->cmd_ring); - xhci->cmd_ring_state = CMD_RING_STATE_ABORTED; + reinit_completion(&xhci->stop_completion); - /* - * Writing the CMD_RING_ABORT bit should cause a cmd completion event, - * however on some host hw the CMD_RING_RUNNING bit is correctly cleared - * but the completion event in never sent. Use the cmd timeout timer to - * handle those cases. Use twice the time to cover the bit polling retry - */ - xhci_mod_cmd_timer(xhci, 2 * XHCI_CMD_DEFAULT_TIMEOUT); + temp_64 = xhci_read_64(xhci, &xhci->op_regs->cmd_ring); xhci_write_64(xhci, temp_64 | CMD_RING_ABORT, &xhci->op_regs->cmd_ring); @@ -357,6 +350,7 @@ static int xhci_abort_cmd_ring(struct xh xhci_halt(xhci); return -ESHUTDOWN; } + /* * Writing the CMD_RING_ABORT bit should cause a cmd completion event, * however on some host hw the CMD_RING_RUNNING bit is correctly cleared @@ -1318,7 +1312,7 @@ void xhci_handle_command_timeout(struct /* command timeout on stopped ring, ring can't be aborted */ xhci_dbg(xhci, "Command timeout on stopped ring\n"); - complete_all(&xhci->stop_completion); + xhci_handle_stopped_cmd_ring(xhci, xhci->current_cmd); spin_unlock_irqrestore(&xhci->lock, flags); return; } @@ -1359,7 +1353,7 @@ static void handle_cmd_completion(struct /* If CMD ring stopped we own the trbs between enqueue and dequeue */ if (cmd_comp_code == COMP_CMD_STOP) { - xhci_handle_stopped_cmd_ring(xhci, cmd); + complete_all(&xhci->stop_completion); return; } diff -puN drivers/usb/host/xhci-mem.c~ts651_4.9-rc7-fix drivers/usb/host/xhci-mem.c --- linux/drivers/usb/host/xhci-mem.c~ts651_4.9-rc7-fix 2016-11-29 02:01:48.178963612 +0900 +++ linux-hirofumi/drivers/usb/host/xhci-mem.c 2016-11-29 02:02:02.341037706 +0900 @@ -1796,7 +1796,7 @@ void xhci_mem_cleanup(struct xhci_hcd *x int size; int i, j, num_ports; - cancel_delayed_work_sync(&xhci->cmd_timer);; + cancel_delayed_work_sync(&xhci->cmd_timer); /* Free the Event Ring Segment Table and the actual Event Ring */ size = sizeof(struct xhci_erst_entry)*(xhci->erst.num_entries); _ -- 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
