On Fri, Sep 14, 2012 at 04:30:15PM -0400, Alan Stern wrote: > 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. Right, the host should start returning TDs with a protocol error as soon as the device violates the three strikes rule for a scheduled transfer. I've never seen these 30 second delays on any hosts I've tested under, so I'm wondering if it's a host hardware issue. > > 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. Yes, I'll agree that seems odd. Ok, working backwards here: > > [ 2972.104144] usb 6-2: USB disconnect, device number 6 This means usb_disconnect() in drivers/usb/core/hub.c is called. However, I don't see the "unregistering device" printk, or the "unregistering interface" printk. Ajay, did you run `sudo dmesg -n 8` to make sure you captured all debugging levels? Can you please send me the full log, for both the working case and the non-working case? Sarah Sharp -- 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
