On Fri, 14 Sep 2012, Sarah Sharp wrote: > On Fri, Sep 14, 2012 at 09:41:12AM -0400, Alan Stern wrote: > > On Fri, 14 Sep 2012, Ajay Gupta wrote: > > > > > Aborting URBs from within HCD after device disconnect is appropriate. right? > > > > Not really. The HCD shouldn't need to pay attention to the connect > > status while handling URBs. > > > > Instead, the HCD should abort URBs when they fail because the device > > doesn't send any packets. This could happen because of a disconnect, > > or it could happen because the device's firmware has crashed. The > > cause doesn't matter. > > Alan, by HCD, do you mean host controller driver, or the host hardware? > I'm getting a bit confused here. :) Well, both really. The hardware should get a low-level error when the device fails to respond, and when the driver sees the error it should complete the URB accordingly. I don't know if "abort" is the right word; maybe "fault" or "exception" would be better. Whatever you call it, the end result should be that when the device is unplugged, any URBs in flight should complete very quickly. > What exactly would you have me do in the xHCI driver that's different > from its current behavior? I don't know what changes xhci-hcd needs. But earlier in this thread Ajay posted a log that seemed to show an URB being submitted right around the same time the device was unplugged (maybe a little before, maybe a little after), and 30 seconds later the URB was still in progress. Here's what he wrote: > =============== Non Working case ================ > [ 2971.576389] Port Status Change Event for port 2 > [ 2971.576487] [E.f2d0c480. <=== URB submitted but no error. > [ 2971.585007] get port status, actual port 1 status = 0x4202c0 > [ 2971.585079] Get port status returned 0x4102c0 > [ 2971.585178] clear port connect change, actual port 1 status = 0x4002c0 > [ 2971.585213] clear port link state change, actual port 1 status = 0x2c0 > [ 2971.640030] get port status, actual port 1 status = 0x2d1 > [ 2971.640031] Get port status returned 0x2d1 > [ 2971.696029] get port status, actual port 1 status = 0x2d1 > [ 2971.696031] Get port status returned 0x2d1 > [ 2971.900031] get port status, actual port 1 status = 0x2d1 > [ 2971.900034] Get port status returned 0x2d1 > [ 2972.060480] Port Status Change Event for port 2 > [ 2972.104039] get port status, actual port 1 status = 0x2802a0 > [ 2972.104041] Get port status returned 0x3002a0 > [ 2972.104079] clear port reset change, actual port 1 status = 0x802a0 > [ 2972.104108] clear port warm(BH) reset change, actual port 1 status = 0x2a0 > [ 2972.104138] clear port link state change, actual port 1 status = 0x2a0 > [ 2972.104144] usb 6-2: USB disconnect, device number 6 > > <=== 30 seconds gap ==== > > > [ 3002.080058] Cancel URB f2d0c480, dev 2, ep 0x81, starting at offset > 0x337ad060 <== SCSI layer cancelling URB after 30 seconds > [ 3002.080063]// Ding dong! > [ 2972.060569] Stopped on Transfer TRB > [ 3002.080817] Removing canceled TD starting at 0x337ad060 (dma). > [ 3002.080820] Finding segment containing stopped TRB. > [ 3002.080822] Finding endpoint context > [ 3002.080823] Finding segment containing last TRB in TD. > [ 3002.080825] Cycle state = 0x0 > [ 3002.080827] New dequeue segment = f71628f0 (virtual) > [ 3002.080828] New dequeue pointer = 0x337ad070 (DMA) > [ 3002.080831] Set TR Deq Ptr cmd, new deq seg = f71628f0 (0x337ad000 > dma), new deq ptr = f37ad070 (0x337ad070 dma), new cycle = 0 > > ================================================= That doesn't seem right. 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
