Hi,
On Fri, Oct 26, 2018 at 7:38 AM Hal Emmerich wrote:
>
>
> From 04fbf78e4e569bf872f1ffcb0a6f9b89569dc913 Mon Sep 17 00:00:00 2001
> From: Hal Emmerich
> Date: Thu, 19 Jul 2018 21:48:08 -0500
> Subject: [PATCH] usb: dwc2: disable power_down on rockchip devices
>
> The bug would let the usb co
On Mon, 8 Apr 2019, Bollinger, Seth wrote:
> > On Apr 8, 2019, at 1:59 PM, Alan Stern
> > mailto:st...@rowland.harvard.edu>> wrote:
>
> > No, that trace did not show any failure. Did you see the corresponding
> > error messages in the kernel log while you were collecting the trace?
> > Maybe yo
> On Apr 8, 2019, at 1:59 PM, Alan Stern
> mailto:st...@rowland.harvard.edu>> wrote:
> No, that trace did not show any failure. Did you see the corresponding
> error messages in the kernel log while you were collecting the trace?
> Maybe you can try again.
I’m certain the last trace I sent shou
On Mon, 8 Apr 2019, Bollinger, Seth wrote:
> On Apr 8, 2019, at 12:23 PM, Alan Stern
> mailto:st...@rowland.harvard.edu>> wrote:
>
> The two big-endian numbers at the end of this line are the logical
> block address of the device's last block and the logical block size in
> bytes. Thus the devi
> To help verify this, can you send a similar usbmon trace on the server
> showing what happens when the EOVERFLOW error occurs? The debug
> messages in your April 6 email don't contain all the detailed
> information.
I verified this one contains the odd read.
80007326d540 3844505987 S Ci:
On Apr 8, 2019, at 12:23 PM, Alan Stern
mailto:st...@rowland.harvard.edu>> wrote:
The two big-endian numbers at the end of this line are the logical
block address of the device's last block and the logical block size in
bytes. Thus the device claims to have 512-byte blocks.
I suspect you have r
On Mon, 8 Apr 2019, Bollinger, Seth wrote:
> On Apr 8, 2019, at 9:33 AM, Alan Stern
> mailto:st...@rowland.harvard.edu>> wrote:
>
> In theory, the device should report a block size of 1024. Does it
> actually do this? A usbmon trace (on the host) showing what happens
> when the device is first
On Apr 8, 2019, at 9:33 AM, Alan Stern
mailto:st...@rowland.harvard.edu>> wrote:
In theory, the device should report a block size of 1024. Does it
actually do this? A usbmon trace (on the host) showing what happens
when the device is first plugged in will provide the answer. Can you
collect on
On Apr 8, 2019, at 9:33 AM, Alan Stern
mailto:st...@rowland.harvard.edu>> wrote:
So no disagreement; in both cases the maxpacket values are 1024.
Clearly this will not work if a Scatter-Gather component has length
3584.
In fact, this bug has nothing at all to do with VHCI. You would
observe the
On Mon, 8 Apr 2019, Bollinger, Seth wrote:
> On Apr 6, 2019, at 11:08 AM, Alan Stern
> mailto:st...@rowland.harvard.edu>> wrote:
>
> Can you provide the "lsusb -v" output for the storage device as shown
> on both computers? I want to see if the server and the client disagree
> on the maxpacket
On Apr 6, 2019, at 11:08 AM, Alan Stern
mailto:st...@rowland.harvard.edu>> wrote:
Can you provide the "lsusb -v" output for the storage device as shown
on both computers? I want to see if the server and the client disagree
on the maxpacket sizes for the bulk endpoints. The key is that 3584 is
a
On Fr, 2019-04-05 at 17:09 +0200, Linus K. wrote:
> Hi,
> I recently submitted this bug to https://bugzilla.kernel.org/ and was
> redirected here.
Hi,
does your kernel have
commit df3aa13c7bbb307e172c37f193f9a7aa058d4739
Author: Oliver Neukum
Date: Wed Sep 5 17:56:46 2018 +0200
Rever
> >
> > Andrzej, would you tell us why you introduce refcnt for driver's
> > configfs opts? And why it is needed to judge for "store" operation?
> >
>
> The reason is that a function can be linked to more than one configuration.
> Imagine
> this sequence: you create a function, set its paramete
13 matches
Mail list logo
