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 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
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 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 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 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 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 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 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 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 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
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 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
>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 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
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 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 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 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 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 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
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
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
101 - 123 of 123 matches
Mail list logo
