Greg KH wrote: >>> This patch takes the route of forcibly polling the hcd device to drain >>> the urb queue and initiate the bulk write call backs. >>> >>> NOTE this patch is not signed off, it is a question of what is the >>> right way to do this? >>> >> This patch is highly questionable. >> > > I agree. > > That is why there is no signed-off on this patch. It is an RFC/EXPERIMENTAL because it is not clear how to fix the problem. See below for more discussion. >> Is the idea to force the HCD to search for completed URBs before the >> host controller has issued a completion interrupt? Wouldn't it be >> better instead to use more URBs? >> >> Besides, why should there be too many outstanding transmit URBs? A >> normal serial debugging port running at 115200 baud can transmit no >> more than 12 bytes per ms. You should be able to surpass that using >> only three URBs! In fact, if you buffer up to 8 bytes per URB then >> with only two URBs you could send 64 bytes per ms, which is equivalent >> to 640000 baud. Do you really need to go more than (say) ten times >> faster than that? >> > > Yeah, something seems wrong here. > > Jason, why is this really needed? With your ring buffer, you shouldn't > need this at all anymore. > > Or if you do, just bump up the number outstanding urbs that are > possible. Or the urb buffer size. > > The URB queue has to be unacceptably large to make it work correctly (>4000) The issue here stems from the register_console() function. As a part of the registration with register_console, the usb_debug device driver gets a huge flood of printk backlog. Because the urb queue is not that deep we loose valuable printk logs. I would very much like a way to force it to work correctly. To answer Alan's question, the rs232 uart drivers don't process the printk back log asynchronously. It is a direct write to the hardware (see serial8250_console_putchar - drivers/serial/8250.c). That is why there is no problem with lost printk data in the case of the uart drivers. I could find no obvious safe way do to this synchronously with the USB api, which is why I put together some way to "force it to work" with the poll hook until we can figure out the right way to do this. The mechanism for a console write is not the same as the standard tty service, or at least that is the way it is today in the kernel. Essentially I am seeking a synchronous write and wait for the usb serial drivers when used as a system console. Right now in the usb serial API there is no distinction between a console write and a tty write. Perhaps that is what needs to change, to allow for some synchronous behavior in usb_console_write()? The usb_debug driver is not the only usb serial device that loses data from the printk backlog, the ftdi_sio driver suffers the same problem. Jason. -- 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
