Hi David!
I got what you meant. Sorry, it seems I misled you with my modified logs. But anyway the behaviour of g_file_storage gadget and pxa2xx_udc driver is the same as if I use only standard output or even without any debugging output at all.
Ok, here are the log messages with debug level turned to DBG_VERY_NOISY:
--------------------------------------------------------------------------------
<6>pxa2xx_udc: version 14-Dec-2003
<7>pxa2xx_udc: IRQ 4 (pio only)
<7>g_file_storage gadget-lun0: open backing file: /app/storage
<6>g_file_storage gadget: File-backed Storage Gadget, version: 20 October 2004
<6>g_file_storage gadget: Number of LUNs=1
<6>g_file_storage gadget-lun0: ro=0, file: /app/storage
<7>g_file_storage gadget: transport=Bulk-only (x50)
<7>g_file_storage gadget: protocol=Transparent SCSI (x06)
<7>g_file_storage gadget: VendorID=x0525, ProductID=xa4a5, Release=x0303
<7>g_file_storage gadget: removable=0, stall=1, buflen=16384
<7>g_file_storage gadget: I/O thread pid: 158
<7>udc: registered gadget driver 'g_file_storage'
<7>udc: host EP0_IDLE, uicr FF.FE, usir 00.00, ufnr 47.74
<7>udc: udccr 03 = uda ude
<7>udc: udccfr 84 = aren acm
<7>udc: ep0 driver 'g_file_storage'
<7>udc: udccs0 EP0_IDLE 00 =
<7>udc: ep0 IN 0/0, OUT 0/0
<7>udc: USB suspend
<7>udc: USB resume
<7>udc: USB reset start
********************************************* ... Skipped ... *********************************************
<7>udc: irq 00.01
<7>udc: irq 00.01
<7>udc: irq 00.04
<7>udc: read ep2out-bulk c3, 31 bytes/S req c03d34e0 31/64
<7>g_file_storage gadget: bulk-out, length 31:
<7> 0: 55 53 42 43 d0 65 60 81 24 00 00 00 80 00 06 12
<7> 10: 00 00 00 24 00 00 00 00 00 00 00 00 00 00 00
<7>g_file_storage gadget: SCSI command: INQUIRY; Dc=6, Di=36; Hc=6, Hi=36
<7>g_file_storage gadget: bulk-in, length 36:
<7> 0: 00 00 02 02 1f 00 00 00 4c 69 6e 75 78 20 20 20
<7> 10: 46 69 6c 65 2d 53 74 6f 72 20 47 61 64 67 65 74
<7> 20: 30 33 30 33
<7>udc: ep1in-bulk queue req c03d34a0, len 36 buf c03ec000
<7>udc: wrote ep1in-bulk 36 bytes/L/S 0 left c03d34a0
<7>g_file_storage gadget: bulk-in, length 13:
<7> 0: 55 53 42 53 d0 65 60 81 00 00 00 00 00
<7>udc: ep1in-bulk queue req c03d3520, len 13 buf c03f0000
<7>udc: wrote ep1in-bulk 13 bytes/L/S 0 left c03d3520
<7>udc: ep2out-bulk queue req c03d34e0, len 64 buf c03ec000
<7>udc: irq 00.04
<7>udc: read ep2out-bulk c3, 31 bytes/S req c03d34e0 31/64
<7>g_file_storage gadget: bulk-out, length 31:
<7> 0: 55 53 42 43 d0 65 60 81 fc 00 00 00 80 00 0a 23
<7> 10: 00 00 00 00 00 00 00 fc 00 00 00 00 00 00 00
<7>g_file_storage gadget: SCSI command: READ FORMAT CAPACITIES; Dc=10, Di=252; Hc=10, Hi=252
<7>g_file_storage gadget: bulk-in, length 0:
<7>udc: ep1in-bulk queue req c03d34a0, len 0 buf c03ec000
<7>udc: wrote ep1in-bulk 0 bytes/L/S 0 left c03d34a0
<7>g_file_storage gadget: bulk-in set halt
<7>udc: ep1in-bulk halt
<7>g_file_storage gadget: sending command-failure status
<7>g_file_storage gadget: sense data: SK x06, ASC x29, ASCQ x00; info x0
<7>g_file_storage gadget: bulk-in, length 13:
<7> 0: 55 53 42 53 d0 65 60 81 fc 00 00 00 01
<7>udc: ep1in-bulk queue req c03d3520, len 13 buf c03f0000
<7>udc: wrote ep1in-bulk 13 bytes/L/S 0 left c03d3520
<7>udc: ep2out-bulk queue req c03d34e0, len 64 buf c03ec000
********************************************* Long pause here ~5...10s. No log output (added by me after copying the log) *********************************************
<7>udc: USB reset start
<7>g_file_storage gadget: bulk-out, length 0:
<7>g_file_storage gadget: bulk_out_complete --> -108, 0/31
<7>g_file_storage gadget: disconnect or port reset
<7>g_file_storage gadget-lun0: fdatasync -> 0
<7>g_file_storage gadget: reset config
<7>g_file_storage gadget: reset interface
<7>udc: pxa2xx_ep_disable, ep1in-bulk not enabled
<7>udc: pxa2xx_ep_disable, ep2out-bulk not enabled
<6>udc: USB reset
<7>udc: irq 00.01
<7>udc: SETUP 80.06 v0100 i0000 l0040
<7>g_file_storage gadget: ep0-setup, length 8:
<7> 0: 80 06 00 01 00 00 40 00
<7>g_file_storage gadget: get device descriptor
<7>udc: ep0 queue req c03d38e0, len 18 buf c0f5b8a0
<7>udc: ep0in 16 bytes 2 left c03d38e0
<7>udc: ep0start IN, 00/00
<7>udc: irq 00.01
<7>udc: ep0in 2 bytes 0 left c03d38e0
<7>g_file_storage gadget: ep0-in, length 18:
<7> 0: 12 01 00 02 00 00 00 10 25 05 a5 a4 03 03 01 02
<7> 10: 03 01
<7>udc: irq 00.01
<7>udc: USB reset start
<7>g_file_storage gadget: disconnect or port reset
<7>g_file_storage gadget-lun0: fdatasync -> 0
<6>udc: USB reset
<7>udc: irq 00.01
<7>udc: SETUP 80.06 v0100 i0000 l0012
<7>g_file_storage gadget: ep0-setup, length 8:
<7> 0: 80 06 00 01 00 00 12 00
<7>g_file_storage gadget: get device descriptor
<7>udc: ep0 queue req c03d38e0, len 18 buf c0f5b8a0
<7>udc: ep0in 16 bytes 2 left c03d38e0
<7>udc: ep0start IN, 00/00
<7>udc: irq 00.01
<7>udc: ep0in 2 bytes 0 left c03d38e0
<7>g_file_storage gadget: ep0-in, length 18:
<7> 0: 12 01 00 02 00 00 00 10 25 05 a5 a4 03 03 01 02
<7> 10: 03 01
<7>udc: irq 00.01
<7>udc: irq 00.01
<7>udc: irq 00.01
<7>udc: SETUP 80.06 v0200 i0000 l0009
<7>g_file_storage gadget: ep0-setup, length 8:
<7> 0: 80 06 00 02 00 00 09 00
<7>g_file_storage gadget: get configuration descriptor
<7>udc: ep0 queue req c03d38e0, len 9 buf c0f5b8a0
<7>udc: ep0in 9 bytes 0 left c03d38e0
<7>udc: ep0start short IN, 00/02
<7>g_file_storage gadget: ep0-in, length 9:
<7> 0: 09 02 20 00 01 01 00 c0 01
<7>udc: irq 00.01
<7>udc: irq 00.01
<7>udc: irq 00.01
<7>udc: SETUP 00.09 v0001 i0000 l0000
<7>g_file_storage gadget: ep0-setup, length 8:
<7> 0: 00 09 01 00 00 00 00 00
<7>g_file_storage gadget: set configuration
<7>udc: ep0start defer, 00/00
<7>g_file_storage gadget: set interface 0
<7>udc: enabled ep1in-bulk
<7>udc: enabled ep2out-bulk
<6>g_file_storage gadget: full speed config #1
<7>udc: ep0 queue req c03d38e0, len 0 buf c0f5b8a0
<7>udc: ep0 config ack
<7>udc: ep2out-bulk queue req c03d3520, len 64 buf c03ec000
<7>udc: irq 00.04
<7>udc: read ep2out-bulk c3, 31 bytes/S req c03d3520 31/64
<7>g_file_storage gadget: bulk-out, length 31:
<7> 0: 55 53 42 43 d0 65 60 81 fc 00 00 00 80 00 0a 23
<7> 10: 00 00 00 00 00 00 00 fc 00 00 00 00 00 00 00
<7>g_file_storage gadget: SCSI command: READ FORMAT CAPACITIES; Dc=10, Di=252; Hc=10, Hi=252
<7>g_file_storage gadget: bulk-in, length 0:
<7>udc: ep1in-bulk queue req c03d3560, len 0 buf c03ec000
<7>udc: wrote ep1in-bulk 0 bytes/L/S 0 left c03d3560
<7>g_file_storage gadget: bulk-in set halt
<7>udc: ep1in-bulk halt
<7>g_file_storage gadget: sending command-failure status
<7>g_file_storage gadget: sense data: SK x06, ASC x29, ASCQ x00; info x0
<7>g_file_storage gadget: bulk-in, length 13:
<7> 0: 55 53 42 53 d0 65 60 81 fc 00 00 00 01
<7>udc: ep1in-bulk queue req c03d3120, len 13 buf c03f0000
<7>udc: wrote ep1in-bulk 13 bytes/L/S 0 left c03d3120
<7>udc: ep2out-bulk queue req c03d3520, len 64 buf c03ec000
********************************************* Long pause here ~5...10s. No log output (same as before) *********************************************
<7>udc: USB reset start <7>g_file_storage gadget: bulk-out, length 0: <7>g_file_storage gadget: bulk_out_complete --> -108, 0/31 <7>g_file_storage gadget: disconnect or port reset <7>g_file_storage gadget-lun0: fdatasync -> 0 <7>g_file_storage gadget: reset config
--------------------------------------------------------------------------------
As I told above, if I turn off all debug output I have the same result.
And question is: is it any ability to check that Windows has sent the next packet?
Are there any tools (SW) to check USB traffic on Windows host? (for instance, like tcpdump in network).
I just want to be shure that the next packet after "READ FORMAT CAPACITIES" was issued by Windows host.
Vlad Trukhin
David Brownell wrote:
On Tuesday 11 January 2005 8:13 am, Alan Stern wrote:
On Tue, 11 Jan 2005, Vladimir Trukhin wrote:
This extra wakeup must be from the completion of the previous bulk-in message.
g_file_storage gadget: get_next_command: wait for next packet (time: 7806.73421 s):Okay, that looks normal.
udc: pxa2xx_udc: pxa2xx_udc_irq: not RST (time: 7806.78041 s): <------ !!!!!!!
Actually it doesn't. The message isn't "standard" (built into the driver) ... and that IRQ handling logic is _very_ timing sensitive. (Yes, and much more painful to debug than usual... especially since there are chip errata lurking there, several of which Intel claims have been fixed since early chiprevs. Not so!)
That is, putting long debug printks into that driver will regularly cause things to break ... for a variety of hard-to-describe reasons.
It's very possible that some of the failures being seen here are happening only because of these excessively long debug messages.
If you absolutely must use printks to debug IRQ paths in that driver, get used to messages that encode all the important stuff in single characters ... or, in special cases, a few more. And even then, be prepared to watch the driver change behavior very significantly when you remove one of those printks...
- Dave
<...>
udc: pxa2xx_udc: pxa2xx_ep_queue: insert into queue (time: 7806.80195 s):Either Windows didn't send a packet or else the PXA didn't interrupt when the packet was received. The second is more likely. Could this be related to the endpoint halt that occurs earlier? True, that halt is for the bulk-in endpoint, not the bulk-out. And you said that this works okay with a Linux host, which will also provoke a bulk-in endpoint halt.
g_file_storage gadget: get_next_command: after start_transfer (time: 7806.80226 s):
g_file_storage gadget: get_next_command: wait for next packet (time: 7806.80257 s):
g_file_storage gadget: get_next_command: wakeup (time: 7806.80291 s):
g_file_storage gadget: get_next_command: wait for next packet (time: 7806.80320 s):
<------------- No Interrupts!!!
Does somebody have an idea why interrupts may not happen?Not me; I don't know anything about the pxa2xx_udc driver. Maybe someone else does.
Alan Stern
------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
