On Tue, Jan 5, 2016 at 4:57 PM, Alan Stern wrote:
> On Tue, 5 Jan 2016, David Laight wrote:
>
>> From: Steinar H. Gunderson [mailto:se...@google.com]
>> > Sent: 26 November 2015 00:19
>>
>> There is still a problem with this code, not sure how to fix it.
>>
>> ...
>> > +static void dec_usb_memory_
On Mon, Jan 4, 2016 at 1:06 AM, Greg Kroah-Hartman
wrote:
> On Mon, Jan 04, 2016 at 12:54:57AM +0100, Markus Rechberger wrote:
>> I would appreciate if this thing could speed up a little bit. We have
>> implemented our previous mmap support into some embedded systems
>> howe
I would appreciate if this thing could speed up a little bit. We have
implemented our previous mmap support into some embedded systems
however we need to update quite a few systems if we are going to
support the current mmap version.
It's taking 2 months already for this small change.
When I did t
hat area
.. it never worked and even totally crashes some systems.
While that linux issue is known for a long time it just seems like
it's accepted already.
Either come up with a solution or just add this patch so we can make use of it!
Best Regards
Markus
On Wed, Nov 18, 2015 at 11:55 PM, Marku
By the way QNAP NAS systems are shipped with a 64bit kernel but a
32bit system environment.
Those systems support USB 2.0 and USB 3.0.
You can expect any kind of combination out there.
On Wed, Nov 18, 2015 at 7:23 PM, Bjørn Mork wrote:
> "Steinar H. Gunderson" writes:
>> On Tue, Nov 17, 2015 a
On Wed, Nov 18, 2015 at 3:02 PM, Christoph Hellwig wrote:
> On Tue, Nov 17, 2015 at 02:07:58PM -0500, Alan Stern wrote:
>> If we really want to do zerocopy I/O then we should not use a bounce
>> buffer. But the only way to avoid bounce buffers may be to give user
>> programs a way of allocating m
PM, Alan Stern wrote:
> On Tue, 17 Nov 2015, Steinar H. Gunderson wrote:
>
>> 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
ormal users raw access to USB devices as well
nowadays.
On Tue, Nov 17, 2015 at 7:42 PM, Steinar H. Gunderson
wrote:
> 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
There are 2 problems with the current implementation:
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 like recent systems hav
On Tue, Feb 11, 2014 at 7:45 PM, Greg KH wrote:
> On Tue, Feb 11, 2014 at 07:29:47PM +0100, Markus Rechberger wrote:
>> On Mon, Feb 10, 2014 at 12:15 AM, Robert Hancock
>> wrote:
>> > On 08/02/14 03:00 AM, Markus Rechberger wrote:
>> >>
>> >&g
On Mon, Feb 10, 2014 at 12:15 AM, Robert Hancock wrote:
> On 08/02/14 03:00 AM, Markus Rechberger wrote:
>>
>> On Tue, Feb 4, 2014 at 10:31 AM, David Laight
>> wrote:
>>>
>>> From: Markus Rechberger
>>>>>>
>>>>>> Dec 27
oblem is in the usbcore.
On Sat, Feb 8, 2014 at 10:00 AM, Markus Rechberger
wrote:
> On Tue, Feb 4, 2014 at 10:31 AM, David Laight wrote:
>> From: Markus Rechberger
>>> >> Dec 27 23:23:50 solist kernel: [ 36.118245] xhci_hcd :00:14.0:
>>> >> ERROR Tran
On Tue, Feb 4, 2014 at 10:31 AM, David Laight wrote:
> From: Markus Rechberger
>> >> Dec 27 23:23:50 solist kernel: [ 36.118245] xhci_hcd :00:14.0:
>> >> ERROR Transfer event TRB DMA
>> ptr
>> >
>> > These messages might be harmless. T
Hi Sarah,
On Mon, Jan 20, 2014 at 8:35 PM, Sarah Sharp
wrote:
> Hi Markus,
>
> I'm the xHCI driver maintainer, and it helps to Cc me on USB 3.0 bug
> reports.
>
> On Sat, Dec 28, 2013 at 07:24:20AM +0100, Markus Rechberger wrote:
>> just received following log sni
Did you trace the i2c messages on the bus? This seems like papering
the actual bug.
USB 3.0 is a disaster with Linux, maybe your hardware or your
controller driver is not okay?
There are other bugreports out there which are USB 3.0 related, some
of our customers reported that since 3.6.0 is okay w
, Dec 27, 2013 at 8:59 PM, Markus Rechberger
wrote:
> Seems like DH87RL was working with 3.2.0-55-generic-pae unfortunately
> we don't have such a board for testing and customer patience is
> limited to bisect the kernel.
>
> Does anyone have a clue what modification could have kill
pport.
On Fri, Dec 27, 2013 at 6:18 PM, Markus Rechberger
wrote:
> I just got another USB 3.0 bugreport, the entire system crashed. That
> particular customer already filed a bugreport in November 2013 that
> his system is in a bad state when using some USB 2.0 media devices
> which eve
to be a disaster with Linux 3.6.12.
The affected board is an Intel DH87RL board.
On Wed, Dec 25, 2013 at 8:18 AM, Markus Rechberger
wrote:
> A customer using a device with USBDEVFS is reporting following
> backtrace (it seems to be a rather generic issue related to linux usb
> 3.0 i
A customer using a device with USBDEVFS is reporting following
backtrace (it seems to be a rather generic issue related to linux usb
3.0 in general):
According to him this problem is reproducible as soon as he starts the
data transfer, is there anything known about that?
He is using 3.12.0-031200-
On Fri, Oct 4, 2013 at 10:34 PM, Alan Stern wrote:
> On Fri, 4 Oct 2013, Markus Rechberger wrote:
>
>> > The biggest problem is that your proc_alloc_memory() routine doesn't
>> > call usbfs_increase_memory_usage(). Without that, there's nothing to
>>
On Fri, Oct 4, 2013 at 8:41 PM, Alan Stern wrote:
> On the whole this seems reasonable. There are a few stylistic things
> that could be cleaned up (missing blank lines after variable
> declarations, for example, and other checkpatch issues), but they are
> minor.
>
> Why do you constantly comput
On Mon, Sep 30, 2013 at 5:12 PM, Markus Rechberger
wrote:
> On Mon, Sep 30, 2013 at 4:59 PM, Alan Stern wrote:
>> On Mon, 30 Sep 2013, Markus Rechberger wrote:
>>
>>> to explain why Isochronous makes such a difference, the kernel driver
>>> doesn't do
On Mon, Sep 30, 2013 at 4:59 PM, Alan Stern wrote:
> On Mon, 30 Sep 2013, Markus Rechberger wrote:
>
>> to explain why Isochronous makes such a difference, the kernel driver
>> doesn't do the memset anymore for each urb packet.
>> However that patch addresses mul
On Mon, Sep 30, 2013 at 1:26 PM, Markus Rechberger
wrote:
> On Mon, Sep 30, 2013 at 5:51 AM, Marcel Holtmann wrote:
>> Hi Markus,
>>
>>>>>>>> Do you have a userspace test program that we can use to verify that
>>>>>>>> this
>&
On Mon, Sep 30, 2013 at 5:51 AM, Marcel Holtmann wrote:
> Hi Markus,
>
>>> Do you have a userspace test program that we can use to verify that this
>>> does work, and that others can use to run on some different platforms to
>>> verify that this is actually faster?
>>>
>>
>
On Sun, Sep 29, 2013 at 9:58 PM, Alan Stern wrote:
> On Sun, 29 Sep 2013, Markus Rechberger wrote:
>
>> >> > Do you have a userspace test program that we can use to verify that this
>> >> > does work, and that others can use to run on some different plat
On Sun, Sep 29, 2013 at 9:01 PM, Greg KH wrote:
> On Sun, Sep 29, 2013 at 07:32:56PM +0200, Markus Rechberger wrote:
>> On Sun, Sep 29, 2013 at 5:14 PM, Greg KH wrote:
>> > On Sun, Sep 29, 2013 at 04:02:56PM +0200, Markus Rechberger wrote:
>> >> This patch adds m
On Sun, Sep 29, 2013 at 5:22 PM, Greg KH wrote:
> On Sun, Sep 29, 2013 at 01:51:58PM +0200, Markus Rechberger wrote:
>> I searched with google, obviously no one is using USBFS/userspace USB
>> drivers that intensive as we do because (streaming 6mb for DVB or 20mb
>> for Analo
On Sun, Sep 29, 2013 at 4:24 PM, Ming Lei wrote:
> On Sun, Sep 29, 2013 at 10:02 PM, Markus Rechberger
> wrote:
>> This patch adds memory mapping support to USBFS for isochronous and bulk
>> data transfers, it allows to pre-allocate usb transfer buffers.
>>
>> The
On Sun, Sep 29, 2013 at 5:14 PM, Greg KH wrote:
> On Sun, Sep 29, 2013 at 04:02:56PM +0200, Markus Rechberger wrote:
>> This patch adds memory mapping support to USBFS for isochronous and bulk
>> data transfers, it allows to pre-allocate usb transfer buffers.
>>
>> The
t)
http://sundtek.de/support/devio_mmap_v0.4.diff
Signed-off-by: Markus Rechberger
diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c
index 737e3c1..a32fb70 100644
--- a/drivers/usb/core/devio.c
+++ b/drivers/usb/core/devio.c
@@ -69,6 +69,7 @@ struct dev_state {
spinlock_t lock;
On Sun, Sep 29, 2013 at 2:07 PM, Ming Lei wrote:
> On Sun, Sep 29, 2013 at 7:51 PM, Markus Rechberger
> wrote:
>
>>
>> I agree, but here not only small buffers are the problem, also latency.
>>
>> I will send another patch version which overrides the SG transfer
On Sun, Sep 29, 2013 at 5:10 AM, Alan Stern wrote:
> On Sun, 29 Sep 2013, Markus Rechberger wrote:
>
>> to follow up I know why it doesn't happen anymore because customers
>> are using a kernel module which does optimized transfers and
>> pre-allocated the URBs and t
On Sat, Sep 28, 2013 at 8:52 PM, Markus Rechberger
wrote:
> On Sat, Sep 28, 2013 at 8:28 PM, Markus Rechberger
> wrote:
>> On Sat, Sep 28, 2013 at 7:43 PM, Alan Stern
>> wrote:
>>> On Sat, 28 Sep 2013, Markus Rechberger wrote:
>>>
>>>> >>
On Sat, Sep 28, 2013 at 8:28 PM, Markus Rechberger
wrote:
> On Sat, Sep 28, 2013 at 7:43 PM, Alan Stern wrote:
>> On Sat, 28 Sep 2013, Markus Rechberger wrote:
>>
>>> >> My next step would be to eliminate the kmallocs/kfrees for the single
>>> >> ur
On Sat, Sep 28, 2013 at 7:43 PM, Alan Stern wrote:
> On Sat, 28 Sep 2013, Markus Rechberger wrote:
>
>> >> My next step would be to eliminate the kmallocs/kfrees for the single
>> >> urbs (just by allocating the urbs with the same mechanism and passing
>> &
On Sat, Sep 28, 2013 at 5:17 PM, Alan Stern wrote:
> On Sat, 28 Sep 2013, Markus Rechberger wrote:
>
>> How about the initial patch, is it okay so far?
>
> I haven't had time to look through it yet.
>
>> There's a settopbox manufacturer who pushed it to his
On Sat, Sep 28, 2013 at 3:45 PM, Alan Stern wrote:
> On Sat, 28 Sep 2013, Markus Rechberger wrote:
>
>> > Actually I observed both throughput and cpu utilization can be improved
>> > with the 4GB of DMA limit on either 32bit arch or 64bit arch, wrt. direct
>> &g
On Sat, Sep 28, 2013 at 4:39 AM, Ming Lei wrote:
> On Sat, Sep 28, 2013 at 10:29 AM, Alan Stern
> wrote:
>> On Sat, 28 Sep 2013, Ming Lei wrote:
>>
>>> On Wed, Sep 25, 2013 at 3:12 AM, Markus Rechberger
>>> wrote:
>>> > This patch adds memory m
On Thu, Sep 26, 2013 at 2:13 AM, Greg KH wrote:
> On Tue, Sep 24, 2013 at 09:12:39PM +0200, Markus Rechberger wrote:
>> This patch adds memory mapping support to USBFS for isochronous and bulk
>> data transfers, it allows to pre-allocate usb transfer buffers.
>
> Doe
On Thu, Sep 26, 2013 at 5:17 AM, Markus Rechberger
wrote:
> On Thu, Sep 26, 2013 at 2:13 AM, Greg KH wrote:
>> On Tue, Sep 24, 2013 at 09:12:39PM +0200, Markus Rechberger wrote:
>>> This patch adds memory mapping support to USBFS for isochronous and bulk
>>> data
On Thu, Sep 26, 2013 at 2:13 AM, Greg KH wrote:
> On Tue, Sep 24, 2013 at 09:12:39PM +0200, Markus Rechberger wrote:
>> This patch adds memory mapping support to USBFS for isochronous and bulk
>> data transfers, it allows to pre-allocate usb transfer buffers.
>
> Does libusb
On Tue, Sep 24, 2013 at 9:12 PM, Markus Rechberger
wrote:
> This patch adds memory mapping support to USBFS for isochronous and bulk
> data transfers, it allows to pre-allocate usb transfer buffers.
>
> The CPU usage decreases 1-2% on my 1.3ghz U7300 notebook when
> transferring
Y
* Clearing allocated memory
Signed-off-by: Markus Rechberger
diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c
index 737e3c1..584253b 100644
--- a/drivers/usb/core/devio.c
+++ b/drivers/usb/core/devio.c
@@ -69,6 +69,7 @@ struct dev_state {
spinlock_t lock;/*
On Fri, Sep 20, 2013 at 5:57 AM, Alan Stern wrote:
> On Fri, 20 Sep 2013, Markus Rechberger wrote:
>
>> to comment it by myself, memory should be cleared for not exposing
>> uncleared memory to userspace
>> and usbmem should be checked if(!mem), if(!usbmem). It will b
On Fri, Sep 20, 2013 at 1:57 AM, Markus Rechberger
wrote:
>
> This patch adds memory mapping support to USBFS for isochronous and bulk data
> transfers, it allows to pre-allocate usb transfer buffers.
> I guess some things can be made a little bit nicer here so any feedback is
>
Hi,
did anyone already take care about:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg55641.html
the fix seems to paper the issue although it happened with other
people too now, so I wonder if there's any progress in that area?
thanks & have a nice Christmas,
Markus
On Dec 23, 2007 8:24 AM,
47 matches
Mail list logo
