[PATCH] Add HID quirks for Akai MIDImix.

:0031.0020: hiddev0: USB HID v1.11 Device [AKAI MIDI Mix] on usb-:00:14.0-2/input0 Adding "usbhid.quirks=0x09e8:0x0031:0x2000" on the kernel command line makes the issues go away. Signed-off-by: Steinar H. Gunderson <sgunder...@bigfoot.com> --- drivers/hid/hid-ids.h

Re: [PATCH] dwc3-exynos: Fix deferred probing storm.

On Fri, May 27, 2016 at 04:26:42PM +0300, Felipe Balbi wrote: >> Sent. As a fix, there's a chance it could go into 4.7, right? > yup, shouldn't be a problem. But only after v4.7-rc1 is tagged. Seemingly v4.7-rc1 is out today (I was surprised at how quick that was). /* Steinar */ -- Homepage:

Re: [PATCH] dwc3-exynos: Fix deferred probing storm.

On Fri, May 27, 2016 at 04:12:59PM +0300, Felipe Balbi wrote: > yes, please do that. Keep in mind, also, that we're still in the middle > of the merge window and nothing will really happen until v4.7-rc1 is > tagged. Sent. As a fix, there's a chance it could go into 4.7, right? /* Steinar */ --

[PATCH v2] dwc3-exynos: Fix deferred probing storm.

cleanup on failure. On my ODROID XU4 system (with Debian's initramfs which doesn't contain the I2C driver), this reduces the number of probe attempts (for each of the two controllers) from more than 2000 to eight. Signed-off-by: Steinar H. Gunderson <se...@google.com> Reviewed-by: Krz

Re: [PATCH] dwc3-exynos: Fix deferred probing storm.

On Fri, May 27, 2016 at 03:23:35PM +0530, Vivek Gautam wrote: > I don't have any concerns with the patch apart from the ones > Krzysztof has already pointed out. > LGTM. Should I repost the patch, or will people just make these commit message changes for me? I guess balbi@ is the right person to

Re: [PATCH] Re: Endless "supply vcc not found, using dummy regulator"

On Fri, May 27, 2016 at 03:02:48PM +0530, Vivek Gautam wrote: > Above mentioned patches were not accepted by the maintainers of generic-phy > and usb. I couldn't get any response on them for quite a long time. So, the > patches could never make it to the mainline. > I can try initiating the entire

Re: [PATCH] Re: Endless "supply vcc not found, using dummy regulator"

On Wed, May 25, 2016 at 07:52:36PM +0200, Steinar H. Gunderson wrote: >> Actually their are some missing patches to tune the usb3 phy. >> >> https://lkml.org/lkml/2014/10/31/266 > This explains why the default networking speed refused to go above > ~300 Mbit/sec! What ha

Re: [PATCH] Re: Endless "supply vcc not found, using dummy regulator"

On Wed, May 25, 2016 at 05:46:51PM +0530, Anand Moon wrote: > Actually their are some missing patches to tune the usb3 phy. > > https://lkml.org/lkml/2014/10/31/266 This explains why the default networking speed refused to go above ~300 Mbit/sec! What happened to the patches, I wonder? /*

[PATCH] dwc3-exynos: Fix deferred probing storm.

cleanup on failure. On my ODROID XU4 system (with Debian's initramfs which doesn't contain the I2C driver), this reduces the number of probe attempts (for each of the two controllers) from more than 2000 to eight. Reported-by: Steinar H. Gunderson <sgunder...@bigfoot.com> Signed-off-by: Ste

[PATCH] Re: Endless "supply vcc not found, using dummy regulator"

On Tue, May 24, 2016 at 05:53:34PM +0200, Krzysztof Kozlowski wrote: > exynos->clk = devm_clk_get(dev, "usbdrd30"); > if (IS_ERR(exynos->clk)) { > + // On each error path since here we need to > + // revert work done by dwc3_exynos_register_phys() >

Re: [PATCH] Add support for usbfs zerocopy.

On Wed, Feb 24, 2016 at 02:30:08PM -0500, Sasha Levin wrote: > I'm seeing the following warning while fuzzing: > [ 1595.188189] WARNING: CPU: 3 PID: 26063 at mm/page_alloc.c:3207 > __alloc_pages_nodemask+0x960/0x29e0() > [ 1595.188287] Modules linked in: > [ 1595.188316] CPU: 3 PID: 26063 Comm:

Re: [PATCH v2] Add support for usbfs zerocopy.

On Wed, Feb 03, 2016 at 11:09:16PM +0100, Steinar H. Gunderson wrote: > Trying again; sending v4 as a reply to your email. Did the v4 sending work for you? /* Steinar */ -- Software Engineer, Google Switzerland -- To unsubscribe from this list: send the line "unsubscribe linux-usb"

Re: [PATCH v2] Add support for usbfs zerocopy.

On Thu, Feb 04, 2016 at 11:17:26AM +0100, Bjørn Mork wrote: > Then use Mutt to reply, but include the patch inline instead of > attaching it. I believe this is discussed in the Mutt section of > Documentation/email-clients.txt Thanks; if that works (even though it changes the “From” line and

[PATCH v4] Add support for usbfs zerocopy.

at: http://sundtek.de/support/devio_mmap_v0.4.diff Signed-off-by: Steinar H. Gunderson <se...@google.com> Signed-off-by: Markus Rechberger <mrechber...@gmail.com> Acked-by: Alan Stern <st...@rowland.harvard.edu> --- drivers/usb/core/devi

Re: [PATCH v2] Add support for usbfs zerocopy.

On Wed, Feb 03, 2016 at 01:23:17PM -0800, Greg Kroah-Hartman wrote: > Attachments don't work, you know better than that :( Since I've now been bitten by this several times: Is there any sort of best practice for integrating git with MUAs? What I'm doing right now is cut-and-paste from mutt to get

Re: [PATCH v2] Add support for usbfs zerocopy.

On Thu, Feb 04, 2016 at 12:15:50AM +0200, Felipe Balbi wrote: >> Since I've now been bitten by this several times: Is there any sort of best >> practice for integrating git with MUAs? What I'm doing right now is >> cut-and-paste from mutt to get the to/cc/in-reply-to headers right, and >> that's

Re: [PATCH v2] Add support for usbfs zerocopy.

On Mon, Jan 25, 2016 at 09:03:57AM +0100, Steinar H. Gunderson wrote: > I did git rebase --ignore-date HEAD^ just to reset the date. Sending it as an > attachment just to be sure. Hi Greg, Did this work for you? Is there anything else I should do to this patch? /* Steinar */ -- So

Re: [PATCH v2] Add support for usbfs zerocopy.

t as an attachment just to be sure. /* Steinar */ -- Software Engineer, Google Switzerland >From e56d9235b343c5e70061e977639cc7dddeae8164 Mon Sep 17 00:00:00 2001 From: "Steinar H. Gunderson" <se...@google.com> Date: Mon, 25 Jan 2016 09:02:34 +0100 Subject: [PATCH v3] Add s

Re: [PATCH] Add support for usbfs zerocopy.

On Wed, Jan 06, 2016 at 04:22:12PM +0100, Peter Stuge wrote: >>> Our interface for zero copy reads/writes is O_DIRECT, and that requires >>> not special memory allocation, just proper alignment. >> But that assumes you are using I/O using read()/write(). There's no way you >> can shoehorn USB

Re: [PATCH] Add support for usbfs zerocopy.

On Tue, Jan 05, 2016 at 10:49:49PM -0800, Christoph Hellwig wrote: > This is a completely broken usage of the mmap interface. if you use > mmap on a device file you must use the actual mmap for the data > transfer. Really? V4L does exactly the same thing, from what I can see. It's just a way of

Re: [PATCH] Add support for usbfs zerocopy.

On Tue, Jan 05, 2016 at 04:11:43PM -0800, Greg Kroah-Hartman wrote: >> Add a new interface for userspace to preallocate memory that can be >> used with usbfs. This gives two primary benefits: > Please 'version' your patches, so that I have a chance to figure out > what patch is what, and what

[PATCH v2] Add support for usbfs zerocopy.

at: http://sundtek.de/support/devio_mmap_v0.4.diff Signed-off-by: Steinar H. Gunderson <se...@google.com> Signed-off-by: Markus Rechberger <mrechber...@gmail.com> Acked-by: Alan Stern <st...@rowland.harvard.edu> --- drivers/usb/core/devi

[PATCH] Add support for usbfs zerocopy.

at: http://sundtek.de/support/devio_mmap_v0.4.diff Signed-off-by: Steinar H. Gunderson <se...@google.com> Signed-off-by: Markus Rechberger <mrechber...@gmail.com> Acked-by: Alan Stern <st...@rowland.harvard.edu> --- drivers/usb/core/devi

Re: Does vm_operations_struct require a .owner field?

On Tue, Jan 05, 2016 at 04:31:09PM -0500, Alan Stern wrote: > Thank you. So it looks like I was worried about nothing. > > Steinar, you can remove the try_module_get/module_put lines from your > patch. Also, the list_del() and comment in usbdev_release() aren't > needed -- at that point we

Re: [PATCH] Add support for usbfs zerocopy.

On Mon, Jan 04, 2016 at 01:42:06AM +0100, Markus Rechberger wrote: > Don't expect anyone else seriously testing this interface aside of me > and Steinar. FWIW, I got an email from the OpenKinect people, who are (as far as I know) currently testing the patch together with my libusb-1.0 patch. It

[PATCH] Add support for usbfs zerocopy.

at: http://sundtek.de/support/devio_mmap_v0.4.diff Signed-off-by: Steinar H. Gunderson <se...@google.com> Signed-off-by: Markus Rechberger <mrechber...@gmail.com> Acked-by: Alan Stern <st...@rowland.harvard.edu> --- drivers/usb/core/devi

Re: [PATCH] Add support for usbfs zerocopy.

On Fri, Dec 25, 2015 at 01:36:44PM -0500, Alan Stern wrote: > That's okay; lots of drivers do this and people expect it. It also > reduces the total amount of code. Okay, fixed. > > > > + mem = usb_alloc_coherent(ps->dev, size, GFP_KERNEL, > > > > _handle); > > > Shouldn't this be

Re: [PATCH] Add support for usbfs zerocopy.

On Fri, Dec 25, 2015 at 09:50:50AM +0100, Oliver Neukum wrote: > > + ret = usbfs_increase_memory_usage(size + sizeof(struct usb_memory)); > > + if (ret) { > > + module_put(THIS_MODULE); > > + return ret; > > + } > > Could you do the error handling in

[PATCH] Add support for usbfs zerocopy.

at: http://sundtek.de/support/devio_mmap_v0.4.diff Signed-off-by: Steinar H. Gunderson <se...@google.com> Signed-off-by: Markus Rechberger <mrechber...@gmail.com> Acked-by: Alan Stern <st...@rowland.harvard.edu> --- drivers/usb/core/devi

Re: [PATCH] Add support for usbfs zerocopy.

On Tue, Dec 22, 2015 at 10:38:57AM -0500, Alan Stern wrote: > Steinar, you can look at those if you want to. But I really don't > think anything more is needed other than the try_module_get and > module_put calls. At least, the Linux Device Drivers book doesn't > mention anything else. OK.

Re: [PATCH] Add support for usbfs zerocopy.

On Tue, Dec 15, 2015 at 03:32:45PM +, David Laight wrote: > That still isn't entirely correct. > > Someone with more knowledge than either of us has needs to sort out > how to handle this properly. This discussion sort of stalled. Short of actually becoming a kernel VM expert (not very

Re: [PATCH] Add support for usbfs zerocopy.

Software Engineer, Google Switzerland >From 659c4025a0e182a1a205fc4d945a68b8cb3602f0 Mon Sep 17 00:00:00 2001 From: "Steinar H. Gunderson" <se...@google.com> Date: Thu, 26 Nov 2015 01:19:13 +0100 Subject: [PATCH] Add support for usbfs zerocopy. To: Greg Kroah-Hartman <gre...@linuxfound

[PATCH] Add support for usbfs zerocopy.

at: http://sundtek.de/support/devio_mmap_v0.4.diff Signed-off-by: Steinar H. Gunderson <se...@google.com> Signed-off-by: Markus Rechberger <mrechber...@gmail.com> Acked-by: Alan Stern <st...@rowland.harvard.edu> --- drivers/usb/core/devi

Re: [PATCH] Add support for usbfs zerocopy.

On Wed, Dec 09, 2015 at 09:29:20AM -0500, Greg Kroah-Hartman wrote: > Shouldn't there also be some sort of documentation update with this > patch as well, so that people know of the new functionality we are > adding? I can write documentation if you can point me to a reasonable place. /* Steinar

Re: [PATCH] Add support for usbfs zerocopy.

On Wed, Dec 09, 2015 at 10:39:35AM -0500, Alan Stern wrote: >> I can write documentation if you can point me to a reasonable place. > The only documentation I know of for usbfs is a dreadfully out-of-date > section in Documentation/DocBook/usb.tmpl. I don't volunteer to get your documentation in

Re: Infrastructure for zerocopy I/O

On Tue, Dec 08, 2015 at 05:01:46PM -0500, Alan Stern wrote: > I don't see anything else to change. You can submit this to Greg KH > and add: > > Acked-by: Alan Stern Great! How do I submit? Just do git send-email to some address? Do you know what the status is for

Re: Infrastructure for zerocopy I/O

cleaner. Done. /* Steinar */ >From 03318604cc6ad9def451784da407e6fcd6af4705 Mon Sep 17 00:00:00 2001 From: "Steinar H. Gunderson" <se...@google.com> Date: Thu, 26 Nov 2015 01:19:13 +0100 Subject: [PATCH] Add support for usbfs zerocopy. Add a new interface for userspace to preallocate memory that

Re: Infrastructure for zerocopy I/O

num_sgs = 0; >> +} > Braces aren't needed. Went to the dentist to take them off. > It looks odd repeating the "if (as->usbm)" test like this. You can merge > the stuff here into the "else" clause of the preceding code. Merged. Updated patch below. /* Stein

Re: Infrastructure for zerocopy I/O

On Sun, Dec 06, 2015 at 01:06:08AM +0100, Steinar H. Gunderson wrote: > I'll try to update your patch with the other suggestions tomorrow. Thanks! Here we are. Lightly tested, I believe all comments should be addressed. /* Steinar */ >From 73833276a4f359c35edffc2a741dba57f2e82a12 Mon Sep

Re: Infrastructure for zerocopy I/O

> } else { > usbm = iter; > usbm->urb_use_count++; > } > break; > } > > (That's with the file's convention for continuation lines.) Do

Re: Infrastructure for zerocopy I/O

tand. You want to populate usbm (by calling find_memory_area()) unconditionally, also for control transfers? I can't see offhand another way to call it only once during the function, save for a bool that says if we called it or not. New patch attached. Note that I haven't had the chance to r

Re: Infrastructure for zerocopy I/O

On Sat, Dec 05, 2015 at 05:12:03PM -0500, Alan Stern wrote: > To tell the truth, I'm not sure whether it would be a problem or not. > That's why I said it "may" not be a good idea. Fair enough. >>> You don't really need to do it earlier. An unnecessary calculation of >>> num_sgs won't hurt.

Re: Infrastructure for zerocopy I/O

On Thu, Dec 03, 2015 at 04:31:35PM -0500, Alan Stern wrote: >> Seemingly controller is already a pointer, so the & is redundant. No idea why >> it didn't crash plain out. Fixing that, I can allocate, although I have some >> other bug causing an oops somewhere else. > Ah, an easy mistake to miss.

Re: Infrastructure for zerocopy I/O

On Fri, Dec 04, 2015 at 01:29:05AM +0100, Steinar H. Gunderson wrote: > I must be doing something wrong, because I don't seem to get any frames > from my video capture, and when I close the application, I get a slowpath > warning: OK, the slowpath warning is a red herring -- it's just

Re: Infrastructure for zerocopy I/O

On Thu, Dec 03, 2015 at 10:37:27AM -0500, Alan Stern wrote: >> FWIW, I tried against >dev->bus->controller, and it didn't give me any >> error messages, but still returns NULL. > I'm at a loss. Seemingly controller is already a pointer, so the & is redundant. No idea why it didn't crash plain

Re: Infrastructure for zerocopy I/O

On Thu, Dec 03, 2015 at 10:18:20PM +0100, Steinar H. Gunderson wrote: > But you still think usb_alloc_coherent() is the better way to go? Should be > easy enough to change, just let me know. I must be doing something wrong, because I don't seem to get any frames from my video capture, and

Re: Infrastructure for zerocopy I/O

On Wed, Dec 02, 2015 at 10:54:52AM -0500, Alan Stern wrote: >> [ 28.796244] DMAR: Allocating domain for 2-2 failed > I don't know what the reason is for that. It may be that your kernel > isn't configured to allocate as much coherent memory as you are asking > for. We'll have to

Re: Infrastructure for zerocopy I/O

On Thu, Dec 03, 2015 at 12:51:14AM +0100, Steinar H. Gunderson wrote: > I'm thinking; maybe should the memory not be allocated against the USB > device, but against the controller it hangs on? (Note that it complains about > allocating the _domain_, not the memory itself.) Do you know

Re: Infrastructure for zerocopy I/O

rather defeats the > purpose of zerocopy! See previous comment on this. :-) >> +if (remap_pfn_range(vma, vma->vm_start, >> +virt_to_phys(usbm->mem) >> PAGE_SHIFT, >> +size, vma->vm_page_prot) < 0) >> +

Re: Infrastructure for zerocopy I/O

On Thu, Nov 26, 2015 at 01:26:32AM +0100, Steinar H. Gunderson wrote: >> There are numerous smaller issues: The allocated memory needs to be >> charged against usbfs_memory_usage > I'll fix this. Fixed in updated patch (attached). > I'll fix this, too. Also fixed. Now als

Re: Infrastructure for zerocopy I/O

On Wed, Nov 25, 2015 at 10:29:53AM -0500, Alan Stern wrote: > I want to see a modified version of your patch. Several things need to > be changed or fixed, but the major change needs to be the way memory is > allocated. It should be done as part of the mmap system call, not as a > separate

Re: Infrastructure for zerocopy I/O

ted memory > rather than just at the beginning I'll fix this, too. > , and so on. Clarification appreciated ;-) /* Steinar */ -- Homepage: https://www.sesse.net/ >From 2bb0f7b91d41de0cbd1e8984612252d101fbb2ca Mon Sep 17 00:00:00 2001 From: "Steinar H. Gunderson" <se...@googl

Re: Infrastructure for zerocopy I/O

On Mon, Nov 16, 2015 at 03:22:06PM -0500, Alan Stern wrote: > Check that userspace requested zerocopy (otherwise the user > program might try to access other data stored in the same cache > lines as the buffer while the I/O is in progres); Needed for send only, right? For

Re: Infrastructure for zerocopy I/O

On Tue, Nov 17, 2015 at 07:17:31PM +0100, Markus Rechberger wrote: > 1. the memset on isochronous transfers to empty the buffers in order > to avoid leaking raw memory to userspace (this costs a lot on intel > Atoms and is also noticeable on other systems). > > 2. the memory fragmentation. Seems

Re: Infrastructure for zerocopy I/O

On Tue, Nov 17, 2015 at 02:07:58PM -0500, Alan Stern wrote: > Is there an API for allocating user memory below 4 GB? Would a new > MMAP flag be acceptable? MAP_32BIT (to mmap) can seemingly do this, but from the man page, it sounds more like a kludge than anything else. /* Steinar */ --

Re: Infrastructure for zerocopy I/O

On Tue, Nov 17, 2015 at 02:13:49PM -0500, Alan Stern wrote: > But what other way of allocating memory is there? For my part, GPU memory versus malloc(). (You can ask OpenGL to permanently map up a chunk of GPU memory for you into userspace, but you have no guarantees as of if it's DMA-able. But

Re: Infrastructure for zerocopy I/O

On Tue, Nov 17, 2015 at 03:01:39PM -0500, Alan Stern wrote: >> On Tue, Nov 17, 2015 at 02:07:58PM -0500, Alan Stern wrote: >>> Is there an API for allocating user memory below 4 GB? Would a new >>> MMAP flag be acceptable? >> MAP_32BIT (to mmap) can seemingly do this, but from the man page, it

Re: Infrastructure for zerocopy I/O

On Tue, Nov 17, 2015 at 03:16:55PM -0500, Alan Stern wrote: >>> But what other way of allocating memory is there? >> For my part, GPU memory versus malloc(). (You can ask OpenGL to permanently >> map up a chunk of GPU memory for you into userspace, but you have no >> guarantees as of if it's

Re: Page allocation failure

On Mon, Nov 16, 2015 at 01:49:50AM +0100, Steinar H. Gunderson wrote: > Just so we're on the same page, I cleaned up the patch I'm now using, and I'm > attaching it here. You said the next step would be changing the memory > allocation interface; I guess I could give it a shot, but I doub

Re: Infrastructure for zerocopy I/O

On Mon, Nov 16, 2015 at 01:29:58PM -0500, Alan Stern wrote: > A proposed patch has been posted > (http://marc.info/?l=linux-usb=144763502829452=2), but I'm not > convinced that it is the best approach. For instance, it always tries > to get contiguous pages and so is vulnerable to memory

Re: Infrastructure for zerocopy I/O

On Mon, Nov 16, 2015 at 07:55:45PM +0100, Christoph Hellwig wrote: >> A proposed patch has been posted >> (http://marc.info/?l=linux-usb=144763502829452=2), but I'm not >> convinced that it is the best approach. For instance, it always tries >> to get contiguous pages and so is vulnerable to

Re: Page allocation failure

ies involved. /* Steinar */ -- Homepage: https://www.sesse.net/ >From 4cf27fbf8000eb6a5ea75c87cd6315ed82d0 Mon Sep 17 00:00:00 2001 From: "Steinar H. Gunderson" <se...@google.com> Date: Mon, 16 Nov 2015 01:36:38 +0100 Subject: [PATCH] Add support for usbfs zerocopy. This is essential

Re: Page allocation failure

On Sat, Nov 14, 2015 at 12:09:38PM -0500, Alan Stern wrote: > And you probably couldn't use GPU memory for this purpose because (I > assume) the USB host controller wouldn't be able to access it via DMA. I guess that depends a bit; on my particular system, I'm using an Intel GPU, so memory is

Re: Page allocation failure

On Fri, Nov 13, 2015 at 12:00:53AM +0100, Steinar H. Gunderson wrote: > Interesting. I hacked libusb to get the fd. Then I did USBDEVFS_ALLOC_MEMORY, > which succeeded (well, as soon as I filled mem.size before calling), > then mmap on it as described (which also succeeded), and everythin

Re: Page allocation failure

On Fri, Nov 13, 2015 at 10:38:54AM -0500, Alan Stern wrote: >> So, in general I think it's good news, although I don't fully understand why >> I still need the kernel-to-userspace copy for isochronous transfer. > Maybe you can add some debugging to copy_user_enhanced_fast_string(). > Add a flag,

Re: Page allocation failure

On Fri, Nov 13, 2015 at 11:24:39AM -0500, Alan Stern wrote: >> What exactly am I looking for, beyond the stack trace the kernel already >> gives me? > Find out where copy_user_enhanced_fast_string is being called from, and > using that information, figure out why it was called. That will tell >

Re: Page allocation failure

On Fri, Nov 13, 2015 at 06:50:27PM +0100, Steinar H. Gunderson wrote: > The stack trace is simple enough, although I fear there's some inlining going > on: OK, I guess since copy_user_enhanced_fast_string is an assembler function, the unwinding doesn't work properly. I added a dump

Re: Page allocation failure

On Fri, Nov 13, 2015 at 03:20:56PM -0500, Alan Stern wrote: >> I tried just not setting as->userbuffer if usbm == NULL, and lo and behold, >> it actually seems to help. > In fact, there's no need to call copy_urb_data_to_user at all if the > buffer lies in the mmap'ed area. usbm != NULL is meant

Re: Page allocation failure

On Fri, Nov 13, 2015 at 04:02:48PM -0500, Alan Stern wrote: >> So what is the road from here? I guess the original questions about cache >> coherency still apply, and that this is what I'm seeing in dmesg. > What questions? It should be obvious that the user program should not > touch the buffer

Re: Page allocation failure

On Thu, Nov 12, 2015 at 05:08:32PM -0500, Alan Stern wrote: > You're right; I got the two patch sets mixed up. Considering that it > was written a couple of years ago, you'll probably have to do some work > to get it to apply to the current kernel. Let me know if you need any > help. There

Re: Page allocation failure

On Fri, Nov 13, 2015 at 12:00:53AM +0100, Steinar H. Gunderson wrote: > I guess I should either add some debug printks or else see if there's > anything in the snooping that can help me track it down. Interestingly enough, I get this at startup: [ 3316.681227] x86/PAT: app:4154 map pfn RAM

Re: Page allocation failure

On Mon, Nov 02, 2015 at 11:48:36AM -0500, Alan Stern wrote: > Order 7? Maybe you're trying to put too much data into a single > transfer and encountering problems with memory fragmentation. Try > using more frequent, smaller transfers. I tried going down to 128 kB; it still happens (and if I go

Re: Overly conservative xHCI bandwidth estimation

On Fri, Nov 06, 2015 at 08:52:52AM +0800, Lu, Baolu wrote: >> I reproduced the U1/U2 disconnect issues several times. I didn't try the >> issue of not enough bandwidth for two devices. > Can you please try the not enough bandwidth issue? It doesn't work. I can use one card (it takes 3-4 tries to

Re: Overly conservative xHCI bandwidth estimation

On Thu, Nov 05, 2015 at 04:12:24PM +0800, Lu, Baolu wrote: > 1) apply the attached patch on top the latest kernel. > 2) build and install the kernel. > 3) boot your machine with the new kernel. Do you want this on top of Alan's LPM-disabling patch or on a clean 4.3.0 tree? > 4) insert one

Re: Overly conservative xHCI bandwidth estimation

On Fri, Nov 06, 2015 at 08:24:15AM +0800, Lu, Baolu wrote: > Yeah, sorry about it. > > 1) apply the attached patch on top the latest clean kernel. > 2) build and install the kernel. > 3) boot your machine with the new kernel. > 4) insert one Blackmagic Design device into USB3 root port. > 5)

Re: Overly conservative xHCI bandwidth estimation

On Fri, Nov 06, 2015 at 08:39:28AM +0800, Lu, Baolu wrote: > Have you set CONFIG_PM? Yes. CONFIG_PM=y. > Can you reproduce the problem with this kernel? I reproduced the U1/U2 disconnect issues several times. I didn't try the issue of not enough bandwidth for two devices. /* Steinar */ --

Re: Overly conservative xHCI bandwidth estimation

On Mon, Nov 02, 2015 at 04:00:42PM -0500, Alan Stern wrote: > That commit was included in (approximately) the 4.1.5 or later stable > kernel, and it is included in 4.2. You should be able to put one of > those on a bootable USB stick. I tried going down this route. After some back and forth, I

Re: Overly conservative xHCI bandwidth estimation

On Mon, Nov 02, 2015 at 11:04:42AM -0500, Alan Stern wrote: > To make your life easier, here's a patch which blacklists these two > devices for Link Power Management. Please let me know if it works > okay. OK, this worked brilliantly. I can now use both cards at the same time, and I also see

Re: Overly conservative xHCI bandwidth estimation

On Mon, Nov 02, 2015 at 01:28:09PM -0500, Alan Stern wrote: >> Thanks for testing. I will submit the patch in two weeks, when the >> current merge window closes. > Or maybe not. This may not be the best way to solve the problem, since > you found that the two video cards worked okay with one

Re: Overly conservative xHCI bandwidth estimation

On Mon, Nov 02, 2015 at 11:04:42AM -0500, Alan Stern wrote: > To make your life easier, here's a patch which blacklists these two > devices for Link Power Management. Please let me know if it works > okay. Thanks! I'll give it a shot. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To

Re: Page allocation failure

On Mon, Nov 02, 2015 at 11:48:36AM -0500, Alan Stern wrote: > Order 7? Maybe you're trying to put too much data into a single > transfer and encountering problems with memory fragmentation. Try > using more frequent, smaller transfers. Yes, my transfers are rather big; 512 kB or so. (They used

Re: Overly conservative xHCI bandwidth estimation

On Mon, Nov 02, 2015 at 03:32:46PM -0500, Alan Stern wrote: > You don't need 4.3. Anything released within the last few years > will contain the LPM code. According to the bisect, the patch that broke it was from June this year (2d2a316765d956bc5cb6bb367b2ec52ca59ab8e9), so it would really seem

Re: Overly conservative xHCI bandwidth estimation

On Mon, Nov 02, 2015 at 02:38:41PM -0500, Alan Stern wrote: >> Note that the two controllers were running different kernels. The one that >> worked had a kernel before LPM was turned on, I believe. > Oh. Can you try running a more recent kernel on that computer? Does > it fail with the same

Page allocation failure

Hello again, I am (still) using libusb-1.0 to drive an USB 3.0 video card. After I turned off power management (see previous emails :-) ) it seems stable, but after running something like 5–6 hours, I seem to get problems on URB submission: [82029.656250] nageru: page allocation failure:

Re: Overly conservative xHCI bandwidth estimation

On Wed, Oct 21, 2015 at 09:49:16AM +0800, Lu, Baolu wrote: > I could spend some time on this issue a week later. > I'd like to check whether there is any bugs in the driver itself. > Otherwise, blacklist this specific device for LPM. I don't know if anything happened here, but if you need

Re: Overly conservative xHCI bandwidth estimation

On Wed, Oct 21, 2015 at 10:29:11AM -0400, Alan Stern wrote: >> Is there such a blacklist already, where I can add the devices (there are two >> distinct IDs behaving identically) and see if it helps? > There is a blacklist, but it does not affect LPM. See > drivers/usb/core/quirks.c and

Re: Overly conservative xHCI bandwidth estimation

On Wed, Oct 21, 2015 at 09:49:16AM +0800, Lu, Baolu wrote: > I could spend some time on this issue a week later. > I'd like to check whether there is any bugs in the driver itself. > Otherwise, blacklist this specific device for LPM. Is there such a blacklist already, where I can add the devices

Re: Overly conservative xHCI bandwidth estimation

On Mon, Sep 28, 2015 at 02:32:13PM +0200, Steinar H. Gunderson wrote: > Just so that it doesn't get lost: I've reported issues with this specific > device and LPM not too long ago. It's entirely possible that the device > somehow is broken, although it works in Windows 7/8/10 and OS X, fr

Re: Overly conservative xHCI bandwidth estimation

On Mon, Sep 28, 2015 at 03:24:04PM +0300, Mathias Nyman wrote: > Driver will tell the latency value to the host controller, when a exit > latency time is set the host will know that the link is power managed, and > host will start to schedule additional PING TP transfers to the device to > wake

Re: Overly conservative xHCI bandwidth estimation

On Fri, Sep 25, 2015 at 10:12:51PM +0200, Steinar H. Gunderson wrote: > I have no idea whatsoever how this breaks bandwidth management, but seemingly > it does. To verify; I built 4.3rc-2 with CONFIG_PM=n, and it can drive both cards without problems whatwoever. So there's something about

Re: Overly conservative xHCI bandwidth estimation

On Fri, Sep 25, 2015 at 10:26:23AM -0400, Alan Stern wrote: >> Does this mean I have a long bisect ahead of me? > In the absence of any better suggestions, that's the most > straightforward way to get an answer. Three hours of bisecting (actually three bisects; I found a git bug along the way

Re: Overly conservative xHCI bandwidth estimation

On Thu, Sep 24, 2015 at 03:35:10PM +0200, Krzysztof Opasiak wrote: >> No. The 2nd altset is 2.16, the 4th altset is 1.04. Unless my calculations >> are wrong. > How do you do your calculations? Like I said in my initial email: >>> The interface of each card has two relevant alternates, 2 and 4.

Re: Overly conservative xHCI bandwidth estimation

On Thu, Sep 24, 2015 at 03:09:55PM +0200, Krzysztof Opasiak wrote: > But still the problem may exist. Is the 2.16 GBit bandwidth for 4th altset? No. The 2nd altset is 2.16, the 4th altset is 1.04. Unless my calculations are wrong. > Remember that according to USB spec not whole bandwidth can be

Re: Overly conservative xHCI bandwidth estimation

On Thu, Sep 24, 2015 at 02:09:41PM +0200, Krzysztof Opasiak wrote: > Let's start from the beginning. Your device use ISO endpoints which means > that host allocates specific amount of bandwidth on the bus. More over, > interfaces in your devices has many alternate settings. Probably each of > them

Re: Overly conservative xHCI bandwidth estimation

On Thu, Sep 24, 2015 at 10:17:19AM -0400, Alan Stern wrote: > However, none of this answers the question of why you can use both > cards on a different machine but not on yours. It comes down to the > implementations of the xHCI controller chips. In USB-3, bandwidth > allocation is handled by

Re: Overly conservative xHCI bandwidth estimation

On Thu, Sep 24, 2015 at 11:22:57AM -0400, Alan Stern wrote: >> I assume there's no way I can lie to the chip? Like, if I know for a fact >> that the card will send less data than the alternate claims (like, >> I'm using a video mode that will require only a few hundred megabits/second >> in

Re: Overly conservative xHCI bandwidth estimation

On Thu, Sep 24, 2015 at 02:33:06PM -0700, Paul Zimmerman wrote: > IIRC, at least some of the Intel controllers require the bandwidth > calculations to be done by the xHCI driver, instead of doing it > themselves in hardware. Perhaps you're tripping over a bug in the xHCI > driver? Mathias is

Re: Overly conservative xHCI bandwidth estimation

On Fri, Sep 25, 2015 at 12:42:22AM +0200, Steinar H. Gunderson wrote: > I downgraded to Debian's 3.16 kernel. Both cards came up without a hitch. > But I only seem to get frames back from the second one. ...and after a quick app fix, I have capture from both cards. Does this mean I have

Re: Overly conservative xHCI bandwidth estimation

On Wed, Sep 23, 2015 at 10:08:05PM +0200, Steinar H. Gunderson wrote: > I've tried on another machine and it works fine there, so my code should, > at least on the surface of it, be fine. PLOT TWIST: I downgraded to Debian's 3.16 kernel. Both cards came up without a hitch. But I only seem

Re: Overly conservative xHCI bandwidth estimation

On Thu, Sep 24, 2015 at 04:46:22PM -0400, Alan Stern wrote: > It does. Grep for max_burst in drivers/usb/host/x*.c to see where it > gets used. (Note that in a couple of places involving USB-2 devices, > the code uses max_burst where it really means multiplicity.) OK, so this is very curious.

  1   2   >