Excuse me, that's "cat /proc/kmsg". /proc/kmsg acts like a fifo.
Kent Forschmiedt Wildseed, Ltd. http://www.wildseed.com -----Original Message----- From: Kent Forschmiedt Sent: Wednesday, January 12, 2005 2:30 PM To: 'David Brownell'; linux-usb-devel@lists.sourceforge.net Cc: Alan Stern; Vladimir Trukhin Subject: RE: [linux-usb-devel] g_file_storage and Windows - problem in connection on pxa255 It helps if you do this: echo 0 >/proc/sys/kernel/printk tail -f /proc/kmsg Kent Forschmiedt Wildseed, Ltd. http://www.wildseed.com -----Original Message----- From: David Brownell [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 12, 2005 2:24 PM To: linux-usb-devel@lists.sourceforge.net Cc: Alan Stern; Vladimir Trukhin Subject: Re: [linux-usb-devel] g_file_storage and Windows - problem in connection on pxa255 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): > > > > udc: pxa2xx_udc: pxa2xx_udc_irq: not RST (time: 7806.78041 > > s): <------ !!!!!!! > > Okay, that looks normal. 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): > > 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!!! > > 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. > > > 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 ------------------------------------------------------- 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
