merge 925167 918800
thanks
On Sat, Apr 27, 2019 at 03:12:35PM +0200, Steinar H. Gunderson wrote:
> Now I have; I rebuilt the Debian kernel with
>
> USB=y
> USB_XHCI_HCD=y
> CONFIG_USB_XHCI_PLATFORM=y
>
> and the NIC still comes up at 480M. So, no go.
Correction: A
On Wed, Apr 24, 2019 at 01:25:54PM +0200, Steinar H. Gunderson wrote:
> I have the same problem with the ODROID XU4, which also includes a dwc3 and
> an 8152 (it's probably dwc3-specific; the driver has been problematic
> before). I haven't checked whether CONFIG_USB_XHCI_PLATF
On Sat, Feb 02, 2019 at 01:39:06PM +0100, Benjamin Drung wrote:
> The Odroid HC1 ARM board contains a JMicron JMS578 USB 3.0 to SATA
> Bridge and a Realtek Gbps Ethernet device connected to an USB 3.0 host.
> The SATA bridge works correctly at USB 3.0 speed, but the Ethernet
> controller operates o
: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
---
drivers/hid/hid-ids.h | 3 +++
drivers/hid/usbhid/hi
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: htt
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 */
--
o
fix 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
Reviewed-by: Krzysztof Kozlows
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 r
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
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
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?
/* Steina
o
fix 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
Signed-off-by: Steinar H. Gunderso
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()
>
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: sy
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"
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 such
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 su
e found at:
http://sundtek.de/support/devio_mmap_v0.4.diff
Signed-off-by: Steinar H. Gunderson
Signed-off-by: Markus Rechberger
Acked-by: Alan Stern
---
drivers/usb/core/devio.c | 227 +-
include/uapi/linux/usbdevice_fs.h | 1 +
2 files ch
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
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
ing it 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"
Date: Mon, 25 Jan 2016 09:02:34 +0100
Subject: [PATCH v3] 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 isoch
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 a
e found at:
http://sundtek.de/support/devio_mmap_v0.4.diff
Signed-off-by: Steinar H. Gunderson
Signed-off-by: Markus Rechberger
Acked-by: Alan Stern
---
drivers/usb/core/devio.c | 227 +-
include/uapi/linux/usbdevice_fs.h | 1 +
2 files ch
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 chang
e found at:
http://sundtek.de/support/devio_mmap_v0.4.diff
Signed-off-by: Steinar H. Gunderson
Signed-off-by: Markus Rechberger
Acked-by: Alan Stern
---
drivers/usb/core/devio.c | 227 +-
include/uapi/linux/usbdevice_fs.h | 1 +
2 files ch
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 know
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 se
e found at:
http://sundtek.de/support/devio_mmap_v0.4.diff
Signed-off-by: Steinar H. Gunderson
Signed-off-by: Markus Rechberger
Acked-by: Alan Stern
---
drivers/usb/core/devio.c | 238 ++
include/uapi/linux/usbdevice_fs.h | 1 +
2 files ch
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,
> > > > &dma_handle);
> > > Shouldn't this be GF
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 a
e found at:
http://sundtek.de/support/devio_mmap_v0.4.diff
Signed-off-by: Steinar H. Gunderson
Signed-off-by: Markus Rechberger
Acked-by: Alan Stern
---
drivers/usb/core/devio.c | 238 ++
include/uapi/linux/usbdevice_fs.h | 1 +
2 files ch
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. I'
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 likely
Software Engineer, Google Switzerland
>From 659c4025a0e182a1a205fc4d945a68b8cb3602f0 Mon Sep 17 00:00:00 2001
From: "Steinar H. Gunderson"
Date: Thu, 26 Nov 2015 01:19:13 +0100
Subject: [PATCH] Add support for usbfs zerocopy.
To: Greg Kroah-Hartman
Cc: linux-usb@vger.kernel.org,mrechb
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
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
e found at:
http://sundtek.de/support/devio_mmap_v0.4.diff
Signed-off-by: Steinar H. Gunderson
Signed-off-by: Markus Rechberger
Acked-by: Alan Stern
---
drivers/usb/core/devio.c | 230 +-
include/uapi/linux/usbdevice_fs.h | 1 +
2 files ch
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 the LPM blacklisting patch
cleaner.
Done.
/* Steinar */
>From 03318604cc6ad9def451784da407e6fcd6af4705 Mon Sep 17 00:00:00 2001
From: "Steinar H. Gunderson"
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 can be
used with usbfs. This gives
ow inverted.
>> +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
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 Mo
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.
>>
usbm = ERR_PTR(-EINVAL);
> } else {
> usbm = iter;
> usbm->urb_use_count++;
> }
> break;
> }
>
> (That's with the fi
be needed in the rest of this routine, but
> nothing that requires additional review comments.
This part I don't understand. 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 du
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. B
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&#x
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,
On Thu, Dec 03, 2015 at 10:37:27AM -0500, Alan Stern wrote:
>> FWIW, I tried against &ps->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 plai
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
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 investigate
>usb_use_count);
>> kfree(isopkt);
>> kfree(dr);
>> if (as)
> You have to change processcompl(). The copy_urb_data() call isn't
> needed when zerocopy is being used -- in fact, it rather defeats the
> purpose of zerocopy!
See previous comment on this. :-)
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
within the allocated 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. G
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 ioc
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 DMA-ab
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 so
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 */
--
Homepa
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 ty
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 l
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 recei
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&m=144763502829452&w=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
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&m=144763502829452&w=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 frag
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 s
oubt I would
understand the subtleties involved.
/* Steinar */
--
Homepage: https://www.sesse.net/
>From 4cf27fbf8000eb6a5ea75c87cd6315ed82d0 Mon Sep 17 00:00:00 2001
From: "Steinar H. Gunderson"
Date: Mon, 16 Nov 2015 01:36:38 +0100
Subject: [PATCH] Add support for usbfs zerocopy.
This i
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 shar
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
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
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
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
>
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,
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
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 pf
On Thu, Nov 12, 2015 at 11:16:06PM +0100, Steinar H. Gunderson 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.
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 we
On Thu, Nov 12, 2015 at 02:42:09PM -0500, Alan Stern wrote:
> You could try getting a "zerocopy" patch to work. See this thread:
>
> http://marc.info/?l=linux-usb&m=140431709523840&w=2
I'll have a look. But given that I do isochronous, it sounds like the patch
in that thread won't work? (A
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
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 g
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 */
--
Home
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) wait
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 Blackm
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
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
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 "Not
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 xHCI
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 no
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 uns
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 t
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: order:
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 informat
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 include/l
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 (
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/
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 the
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
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 :-/
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
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
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 probab
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 - 100 of 123 matches
Mail list logo
