Re: UHCI/EHCI interrupt storm after resume from S3
On 05/03/2013 08:27 AM, Alan Stern wrote: On Tue, 19 Mar 2013, Waskiewicz Jr, Peter P wrote: On 3/18/2013 1:35 PM, Greg KH wrote: On Mon, Mar 18, 2013 at 01:30:47PM -0700, Waskiewicz Jr, Peter P wrote: I have an Atom-based machine (N450) with an ICH8 running Ubuntu LTS 12.04.2. This has the latest updates installed, kernel 3.5.0-23.35. I put the machine into S3, then woke it from the network. After resume, the uhci_hcd and ehci_hcd devices (sharing an interrupt) start flooding interrupts. This continues until the USB driver is reloaded, or I reboot. Is this a known issue? I'm willing to assist debugging, I just wanted to ask if people have seen this yet before I dig into it. If it comes down to building linux-next via git, that's fine, it'll just take about 4 hours on this box to do it. Let me know if there's any additional data folks want to see. Can you see if this happens with the latest 3.8.3 kernel release? If you are stuck using Ubuntu kernels, you need to get support from Canonical, there's nothing we can do with their kernel packages, sorry. Ok, I take back my previous mail that it's ok with 3.8.3. The bug is still there, albeit it's intermittent. After 4-5 suspend/resumes on this box, the ehci_hcd and uhci_hcd (shared fasteoi interrupt) are flooding interrupts. More information: USB controller: Intel ICH8, PCI ID 0x2830 - 0x2836 BIOS: AMI version 080015 Processor: Atom D510 Any other info I can provide if requested. Anything anyone would like me to try, just let me know. While going through old email messages, I found this. Did the problem ever get fixed, or is it still present in the 3.9 kernel? Alan Stern I haven't tried this with 3.9 yet. I will try this once I get back to where the affected hardware is (later tonight). Cheers, -PJ -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Regression: ftdi_sio is slow (since Wed Oct 10 15:05:06 2012)
04.05.2013 00:34, Greg KH пишет: Don't call select for every character :) OK, let me draw an approximate workflow of the setup in question. Lets say we have 3 tty devices, A, B and C. A and B are blazingly fast, while C is a casual usb-serial chip. The app must establish a bidirectional relay between A and C, making sure that the output queue on C never exceeds some margin M. B is used for acknowledges: the next char from A will arrive only after an acknowledge is sent via B. Here's what the app approximately does: 1. select() on A and C for _input only_. 2. relay the char 3. if the char was from A, send ack to B and increment an ack counter (call that counter Q). 4. If Q>N (N is a threshold value that should be below M, currently 14), do TIOCOUTQ ioctl to make sure C is not overflowing, set Q to the value returned by TIOCOUTQ. If Q still above N, stop sending acks to B and do TIOCOUTQ periodically, until Q is below N, then resume the normal operations. 5. goto 1 So that's the workflow, and it used to work perfectly in the past. Now even on step 1, when select returns, there is already a big delay. Not to speak about TIOCOUTQ, a very funny way to query the buffer: the buffer is now entirely flushed while we query it. What exactly is so horrible here that it was deserved to break? How to improve the algo? And no, we can't improve the protocol. For instance, we can't send multiple acks and hope that multiple chars will be received from A - the protocol cannot be changed. Any suggestions? -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Regression: ftdi_sio is slow (since Wed Oct 10 15:05:06 2012)
On Sat, May 04, 2013 at 01:50:42AM +0400, Stas Sergeev wrote: > 04.05.2013 00:34, Greg KH пишет: > > On Fri, May 03, 2013 at 10:27:18PM +0400, Stas Sergeev wrote: > >> 03.05.2013 21:16, Greg KH пишет: [...] > >>> There's no guarantee as to how long select or an ioctl will take, and > >>> now that we have fixed another bug, this device is slower. > >>> > >>> If you change hardware types to use a different usb to serial chip, that > >>> select call might take 4 times as long. Are we somehow supposed to > >>> change the kernel to "fix" that? > >> Previously, the kernel was not calling to a device at all, so > >> select() was independent of the chip, and it was fast. I was > >> not aware you changed that willingly. > > I don't understand, what do you mean by this? Some drivers just return > > the value of an internally held number, and don't query the device. > > > > The only way the FTDI driver can determine if the hardware buffer on the > > chip way out on the end of the USB cable is empty or not, is to query > > it. So the driver now does so. > It does so only for one char. And the query takes longer than > to just xmit that char. So why do you think this even works as > expected? The query takes longer than the transmit at decent baudrates (>=38k) and under the assumption that flow control isn't causing any delays. But you do have a point, and I have been meaning to look into whether the added overhead of checking the hardware buffers could be mitigated by adding wait_until_sent support to usb-serial. This way the we would only query the hardware buffers on tty_wait_until_sent (e.g. at close) and select and TIOCMOUTQ would not suffer. This is also the way things are handled in serial_core. I'll prepare a series which adds wait_until_sent to usb-serial, but I doubt it would be stable material (even if it could get into 3.10). What do you think Greg, is this overhead to chars_in_buffer reason enough to disable it in the stable trees or should we simply fix it in 3.11 (or 3.10)? (The overhead is about 3-400 us per call when the port fifo is empty, which makes chars_in_buffer about 100 times slower on my test system.) Thanks, Johan -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Regression: ftdi_sio is slow (since Wed Oct 10 15:05:06 2012)
04.05.2013 15:15, Johan Hovold пишет: The query takes longer than the transmit at decent baudrates (>=38k) and under the assumption that flow control isn't causing any delays. But you do have a point, and I have been meaning to look into whether the added overhead of checking the hardware buffers could be mitigated by adding wait_until_sent support to usb-serial. This way the we would only query the hardware buffers on tty_wait_until_sent (e.g. at close) and select and TIOCMOUTQ would not suffer. This is also the way things are handled in serial_core. Thanks for taking a look. Indeed, it seems .wait_until_sent is the best candidate for that kind of things, and the patch in question would even match its description be it using .wait_until_sent and not .chars_in_buffer. Please count on testing your patches here when they are ready. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Regression: ftdi_sio is slow (since Wed Oct 10 15:05:06 2012)
On 05/04/2013 07:15 AM, Johan Hovold wrote: On Sat, May 04, 2013 at 01:50:42AM +0400, Stas Sergeev wrote: 04.05.2013 00:34, Greg KH пишет: On Fri, May 03, 2013 at 10:27:18PM +0400, Stas Sergeev wrote: 03.05.2013 21:16, Greg KH пишет: [...] There's no guarantee as to how long select or an ioctl will take, and now that we have fixed another bug, this device is slower. If you change hardware types to use a different usb to serial chip, that select call might take 4 times as long. Are we somehow supposed to change the kernel to "fix" that? Previously, the kernel was not calling to a device at all, so select() was independent of the chip, and it was fast. I was not aware you changed that willingly. I don't understand, what do you mean by this? Some drivers just return the value of an internally held number, and don't query the device. The only way the FTDI driver can determine if the hardware buffer on the chip way out on the end of the USB cable is empty or not, is to query it. So the driver now does so. It does so only for one char. And the query takes longer than to just xmit that char. So why do you think this even works as expected? The query takes longer than the transmit at decent baudrates (>=38k) and under the assumption that flow control isn't causing any delays. But you do have a point, and I have been meaning to look into whether the added overhead of checking the hardware buffers could be mitigated by adding wait_until_sent support to usb-serial. This way the we would only query the hardware buffers on tty_wait_until_sent (e.g. at close) and select and TIOCMOUTQ would not suffer. This is also the way things are handled in serial_core. Agreed. This is the correct solution. I'll prepare a series which adds wait_until_sent to usb-serial, but I doubt it would be stable material (even if it could get into 3.10). What do you think Greg, is this overhead to chars_in_buffer reason enough to disable it in the stable trees or should we simply fix it in 3.11 (or 3.10)? (The overhead is about 3-400 us per call when the port fifo is empty, which makes chars_in_buffer about 100 times slower on my test system.) A better solution for stable would be to set port->drain_delay. It won't help tcdrain() but at least the port won't shutdown on live outbound data. Regards, Peter Hurley -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] usb: gadget/uvc: remove connect/disconnect calls on open/release
Hi,
On 5/3/2013 6:00 PM, Vladimir Zapolskiy wrote:
Hi Laurent,
thank you for the comment.
On 05/03/13 02:05, Laurent Pinchart wrote:
Hi Vladimir,
On Friday 03 May 2013 02:00:29 Vladimir Zapolskiy wrote:
On 05/03/13 01:18, Laurent Pinchart wrote:
On Friday 03 May 2013 01:13:48 Vladimir Zapolskiy wrote:
This change removes redundant calls to uvc_function_connect() and
uvc_function_disconnect() on V4L2 device node open and release.
These two functions attemp to control pull-up on D+ line directly,
however such an action should be performed by an UDC iteself, and
within
the gadget there is no information about current mode of the
controller.
The UDC may be in suspended state, or an OTG controller may be in host
mode, therefore it seems better not to try to forcibly pull-up D+ line
on open() syscall.
OK, but we then need to fix the problem properly. The UVC gadget
must not
appear connected until an application opens the corresponding device.
Likewise, it must disconnect from the bus when the application
closes the
device. How can this be guaranteed properly ?
For better understanding of the issue, could you explain briefly why
do you
prefer to have the gadget not connected to the bus, if device node is
not
opened?
As soon as the gadget will connect to the bus the device will be
enumerated by
the host and bound to a host driver that will query the device using UVC-
specific requests. The userspace application is involved in replying
to those
requests, so it needs to be bound to the device on the gadget side or the
initialization process on the host side will fail.
It might be a flaw in design, if a kernel space component depends on a user
space application to be operable. Also the same scenario seems to be
invalid,
if an application unawared of specific to UVC features of /dev/videoX opens
the device node, e.g.
http://git.kernel.org/cgit/linux/hotplug/udev.git/tree/src/v4l_id/v4l_id.c
or yavta etc. I presume a host should dictate behaviour of device and
gadget
in particular, and not a target's user space application, please correct
me.
About this particular change, as I mentioned in a cover letter an
alternative
approach may be to add sanity checks to .pullup operations for every UDC
driver
(or probably to usb_gadget_connect()), but in this case it is not clear
how UVC
gadget is going to be notified about changes of UDC state, e.g. assume a
test
that /dev/videoX is opened, when OTG is in Host mode, device registration
doesn't happen on open(), and then USB B cable is inserted to the port.
I would appreciate your thoughts.
The whole point of having a user-space application governing the
behavior of UVC webcam gadget as per commands from a UVC host is to plug
the same with a real video capture source driver to provide the video
frames captured from say a camera sensor and route the UVC specific
control requests to a real video capture device by converting the same
to equivalent V4L2 commands.
Let's take an example. Let's say you have a camera sensor that supports
capture in two modes:
1. 640*480, YUV422 (default mode)
2. 640*480, JPEG
Lets say the UVC webcam gadget suggest to the host that it supports
640*480, YUV422 output by default (to be in sync with the
characteristics of the actual capture source).
Now on the Host, some user tries to open the UVC webcam appearing to him
as one /dev/videoX node using the CHEESE application, and he
tries to capture frames in MJPEG format as it is also supported by the
UVC webcam, no before streaming frames this control command should be
routed as a V4L2_S_FMT(640*480, JPEG) command to the V4L2 video capture
driver. This is where the user-space application comes into picture.
Also note that the format is selected from the Host side before the
streaming is started. So, you should not connect to the UDC, unless you
have the user-space application up and running and is present to pass
relevant UVC commands (after converting them to equivalent V4L2
commands) to the video capture driver.
The present design is an interface between two kernel subsystems which
are aware of each other and works fine for most use-cases.
Regards,
Bhupesh
Signed-off-by: Vladimir Zapolskiy
Cc: Laurent Pinchart
---
drivers/usb/gadget/uvc_v4l2.c |5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/usb/gadget/uvc_v4l2.c
b/drivers/usb/gadget/uvc_v4l2.c
index ad48e81..e2b66e1 100644
--- a/drivers/usb/gadget/uvc_v4l2.c
+++ b/drivers/usb/gadget/uvc_v4l2.c
@@ -132,20 +132,15 @@ uvc_v4l2_open(struct file *file)
handle->device =&uvc->video;
file->private_data =&handle->vfh;
-uvc_function_connect(uvc);
return 0;
}
static int
uvc_v4l2_release(struct file *file)
{
-struct video_device *vdev = video_devdata(file);
-struct uvc_device *uvc = video_get_drvdata(vdev);
struct uvc_file_handle *handle =
to_uvc_file_handle(file->private_data);
struct uvc_video *video = handle->device
Re: [PATCH 1/2] usb: gadget/uvc: remove connect/disconnect calls on open/release
On 5/3/2013 2:07 PM, Michael Grzeschik wrote: Hi Laurent, On Fri, May 03, 2013 at 01:20:15AM +0200, Laurent Pinchart wrote: [snip] I'm open to suggestions :-) What features of the userspace application do you think could (and should) be moved to kernelspace ? Many of them are highly application-specific. All UVC_EVENTS beneath STREAMON and STREAMOFF could go into the kernelspace. I have seen such codepath: [1] v4l2_event_queue/* kernelspace */ v4l2_event_dequeue /* kernelspace */ uvc_events_process_setup/* userspace */ uvc_events_process_class/* userspace */ uvc_events_process_streaming/* userspace */ uvc_fill_streaming_control /* userspace */ The codepath [1] is needed to respond with the possible supported streaming capabilities. That information really should come from the uvc_descriptor_header. We already have this information in the kernel, there is no need for redundancy. [2] v4l2_event_queue/* kernelspace */ v4l2_event_dequeue /* kernelspace */ uvc_events_process_data /* userspace */ /* in case of UVC_VS_COMMIT_CONTROL */ uvc_video_set_format/* kernelspace */ uvc_v4l2_do_ioctl /* kernelspace */ The codepath [2] is really odd, as we jump out of the kernel back into the kernel just to gather some information about the requested videoformat by the host. The application itself should call the ioctl VIDIOC_G_FMT on UVC_EVENT_STREAMON and change its videosetup likewise. This should be possible with gstreamer. I currently work on an derived version of the gstv4l2sink -> gstv4l2uvcsink to handle the uvc specialities. Well, its great that you are working on the 'gstv4l2uvcsink' plugin, as the v4l2src and v4l2sink gstreamer pipeline doesn't work out of box of UVC gadget. I have already burned by hands with it :) That's why it I think the UVC gadget test application from Laurent is really good starting point and as and when my patches related to the same are added (see [1]) , it will be able to handle most of the interaction required between a v4L2 based video capture device and UVC v4L2 video output device and even pass USBCV's USB video class tests. [1]. [Test Application PATCH 0/2] UVC gadget test application enhancements. http://comments.gmane.org/gmane.linux.usb.general/84813 And addressing the initial problem with the missing userspace application; The gadget can loose its dependency to it, if the kernel would produce dummy frames with the requested format and switch over to the real streaming data, when opened. I don't think dummy frames appearing at the very start of image data would be much appreciated by a user using a real UVC webcam running Linux. The user would expect real live data as soon as he issues a START_STREAMING command from the USB host side. And for completing doing away with the user-space application, you will have to support the UVC default frame format always, but the user ideally should not be restricted to default format and he can start image capture in other possible image formats supported by underlying video capture source. This would mean we need to have dummy frames for each possible image format and send the same to the Host until the actual streaming starts. Wouldn't that be an overkill? Regards, Bhupesh -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
