On Thu, 3 Apr 2014, vichy wrote: > hi all: > I list my environment as below: > 1. Arm platform with ehci support > 2. plug in NTFS USB HD and play movie > 3. plug out device suddenly. > > I found there will be possibly that driver will reset port even there > is no device connected. > I purposely add below code in ehci-hub.c when we try to do port reset > @@ -1173,7 +1173,12 @@ static int ehci_hub_control ( > ehci_writel(ehci, temp, status_reg); > + dbg_port (ehci, "in port reset sequence, > GetStatus", wIndex + 1, temp); > + > break; > > and I found driver will reset even device is disconnected like below log: > (I also attach full log in the mail) > tntfs info: NTFS volume version 3.1 (cluster_size 4096, PAGE_CACHE_SIZE 4096). > Platform-ehci Platform-ehci.0: detected XactErr len 19456/20480 retry 1 > hub 4-0:1.0: state 7 ports 1 chg 0000 evt 0002 > hub 4-0:1.0: port 1, status 0000, change 0001, 12 Mb/s > Platform-ehci Platform-ehci.0: port 1 reset > Platform-ehci Platform-ehci.0: in port reset sequence, GetStatus > port:1 status 000100 0 ACK sig=se0 RESET > usb 4-1: USB disconnect, device number 20 > Platform-ehci Platform-ehci.0: port 1 reset error -110 > Platform-ehci Platform-ehci.0: port 1 reset error -110 > Platform-ehci Platform-ehci.0: port 1 reset error -110 > Platform-ehci Platform-ehci.0: port 1 reset error -110 > Platform-ehci Platform-ehci.0: port 1 reset error -110 > hub 4-0:1.0: hub_port_status failed (err = -32) > hub 4-0:1.0: port_wait_reset: err = -32 > hub 4-0:1.0: port 1 not enabled, trying reset again... > .................... > > > My questions are: > 1. from the log the reason why port reset shows is > test_bit(US_FLIDX_DISCONNECTING, &us->dflags) failed in usb_stor_port_reset > (in the log, I purposely dump_stack in usb_reset_and_verify_device) > Why even "USB disconnect" show, the "US_FLIDX_DISCONNECTING" is not > set up in time? Your log contains the explanation: > Platform-ehci Platform-ehci.0: port 1 reset This is where the reset starts. > Platform-ehci Platform-ehci.0: in port reset sequence, GetStatus > port:1 status 000100 0 ACK sig=se0 RESET > usb 4-1: USB disconnect, device number 20 And this is where US_FLIDX_DISCONNECTING gets set -- after the reset has already begun. > 2. shall we add below determination before port reset? > --- a/linux-3.8.2/drivers/usb/host/ehci-hub.c > ++ b/linux-3.8.2/drivers/usb/host/ehci-hub.c > @@ -1139,6 +1139,9 @@ static int ehci_hub_control ( > case USB_PORT_FEAT_RESET: > if (temp & PORT_RESUME) > goto error; > + > + if (!(temp & PORT_CONNECT)) > + goto disconnect; > /* line status bits may report this as low speed, > * which can be fine if this root hub has a > * transaction translator built in. We could add this, but it's not a big deal. The real question is why did this happen: > hub 4-0:1.0: hub_port_status failed (err = -32) hub_port_status should not return an error. It should have returned valid data, and the port status should have shown that the device was disconnected. Can you figure out why hub_port_status didn't work? 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
