ly-functional device speed is High Speed (480Mbps)
bU1DevExitLat 10 micro seconds
bU2DevExitLat2047 micro seconds
Device Status: 0x000c
(Bus Powered)
U1 Enabled
U2 Enabled
--
Mark Lord
Real-Time Remedies Inc.
ml...@pobox.com
to system's
> USB host controller.
Thank-you, Mario.
So.. why are we enabling the r8153 (USB-ethernet) workaround on this WD15 dock?
The discussion back in 2017 was that only the TB15/TB16 were affected by
the XHCI overruns it produces?
--
Mark Lord
Real-Time Remedies Inc.
ml...@pobox.com
On 2019-01-07 1:46 a.m., Kai Heng Feng wrote:
>
> Do you happen to use a Dell system? We can do some test here.
Yes. It is a Dell XPS 13 9360 i7-8550U notebook,
with the Dell WD15 USB-C dock.
--
Mark Lord
Real-Time Remedies Inc.
ml...@pobox.com
On 2019-01-06 11:09 p.m., Kai Heng Feng wrote:
>
>
>> On Jan 7, 2019, at 05:16, Mark Lord wrote:
>>
>> On 2019-01-06 4:13 p.m., Mark Lord wrote:
>>> On 2019-01-06 2:14 p.m., Kai Heng Feng wrote:>> On Jan 5, 2019, at 10:14
>>> PM, Mark Lord
>
On 2019-01-06 4:13 p.m., Mark Lord wrote:
> On 2019-01-06 2:14 p.m., Kai Heng Feng wrote:>> On Jan 5, 2019, at 10:14 PM,
> Mark Lord
> wrote:
> ..
>>> There is even now a special hack in the upstream r8152.c to attempt to
>>> detect
>>> a Dell TB16
On 2019-01-06 2:14 p.m., Kai Heng Feng wrote:>> On Jan 5, 2019, at 10:14 PM,
Mark Lord
wrote:
..
>> There is even now a special hack in the upstream r8152.c to attempt to detect
>> a Dell TB16 dock and disable RX Aggregation in the driver to prevent such
>> issues.
&g
On 2019-01-05 9:14 a.m., Mark Lord wrote:
> A couple of years back, I reported data corruption resulting from
> a change in kernel 3.16 which enabled hardware checksums in the r8152 driver.
> This was happening on an embedded system that was using a r8152 USB dongle.
>
> At the ti
.0.
>From this I conclude that the workaround is not 100% complete yet.
--
Mark Lord
Real-Time Remedies Inc.
ml...@pobox.com
524280U
+#define COALESCE_SUPER 8500U
+#define COALESCE_HIGH 25000U
+#define COALESCE_SLOW 52428U
The RTL_VER_02 chip that I was using does not support interrupt coalescing
in the driver [see the rtl8152_set_coalesce() function]. So that workaround
would not help here.
On 16-12-08 10:23 PM, Hayes Wang wrote:
> Mark Lord
>
> I find an issue about autosuspend, and it may result in the same
> problem with you. I don't sure if this is helpful to you, because
> it only occurs when enabling the autosuspend.
Thanks. I am using ASIX adapters
On 16-11-25 09:22 AM, Greg KH wrote:
> On Fri, Nov 25, 2016 at 07:41:42AM -0500, Mark Lord wrote:
>> On 16-11-25 07:34 AM, Mark Lord wrote:
>>> On 16-11-25 04:53 AM, Greg KH wrote:
>>>> Note, there are "cheap" USB monitors that can be quite handy an
On 16-11-25 04:52 AM, Hayes Wang wrote:
..
> What is the value of /sys/bus/usb/devices/.../power/control ?
That entry does not exist -- power control is completely
disabled on this board.
Good try, though -- USB power control still causes me trouble
on PCs with mice and remote controls. But not
On 16-11-25 04:53 AM, Greg KH wrote:
> On Thu, Nov 24, 2016 at 10:49:33PM -0500, Mark Lord wrote:
>> There is no possibility for them to be used for anything other than
>> USB receive buffers, for this driver only. Nothing in the driver
>> or kernel ever writes to those
On 16-11-25 01:51 AM, Hayes Wang wrote:
>
> Forgive me. I provide wrong information. This is about RTL8153, not RTL8152.
No problem. Thanks for trying though.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordo
On 16-11-25 07:34 AM, Mark Lord wrote:
> On 16-11-25 04:53 AM, Greg KH wrote:
>> Note, there are "cheap" USB monitors that can be quite handy and that work
>> on Linux:
>> http://www.totalphase.com/products/beagle-usb12/
>
> USD$455/each in quantity,
On 16-11-25 04:53 AM, Greg KH wrote:
> Note, there are "cheap" USB monitors that can be quite handy and that work on
> Linux:
> http://www.totalphase.com/products/beagle-usb12/
USD$455/each in quantity, vs. USD$8 for the USB ethernet dongle.
--
To unsubscribe from this list: send the line
On 16-11-25 01:11 AM, Hayes Wang wrote:
> Mark Lord [mailto:ml...@pobox.com]
..
>> If that "return 0" statement is ever executed, doesn't it result
>> in the loss/leak of a buffer?
>
> They would be found back by calling rtl_start_rx(), when the rx
> is rest
rites to those buffers after initial allocation,
and only the driver and USB host controller ever have pointers to the buffers.
--
Mark Lord
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
On 16-11-24 02:00 PM, Greg KH wrote:
> On Thu, Nov 24, 2016 at 01:34:08PM -0500, Mark Lord wrote:
>> One thought: bulk data streams are byte streams, not packets.
>> Scheduling on the USB bus can break up larger transfers across
>> multiple in-kernel buffers. A "real&
On 16-11-24 01:42 PM, Greg KH wrote:
>
> Have you tried using usbmon?
This system is running rootfs over NFS, so usbmon
isn't realistically going to be usable in that scenario
without a lot of reconfiguration of the setup (which in itself
might obscure the original problem).
There is a hardware U
On 16-11-24 01:34 PM, Mark Lord wrote:
>From tracing through the powerpc arch code, this is the buffer that
> is being directly DMA'd into. And the USB layer does an invalidate_dcache
> on that entire buffer before initiating the DMA (confirmed via printk).
Slight co
On 16-11-24 12:11 PM, David Miller wrote:
> From: Mark Lord
> Date: Thu, 24 Nov 2016 11:43:53 -0500
>
>> So even if this were a platform memory coherency issue, one should
>> still never see ASCII data at the beginning of an rx buffer.
>
> I'm not so convinced,
On 16-11-24 11:43 AM, Mark Lord wrote:
..
But how does this ASCII data end up at offset zero of the rx buffer??
Not possible -- this isn't even stale data, because only an rx_desc could
be at that offset in that buffer.
Answering my own question here, I suspect it ends up there as a resu
On 16-11-24 11:21 AM, David Miller wrote:
From: Hayes Wang
Date: Thu, 24 Nov 2016 13:26:55 +
I don't think the garbage results from our driver or device.
This is my impression with what has been presented so far as well.
It's not garbage.
The latest run with the debug code I posted her
On 16-11-24 08:26 AM, Hayes Wang wrote:
..
Besides, it doesn't seem to occur for all platforms. I have
tested the iperf more than 26 hours, and it still works fine.
I think I would get the same result on x86 or x86_64 platform.
..
x86 has near fully-coherent memory, so it is the "easy" platform
On 16-11-23 02:29 PM, Mark Lord wrote:
On 16-11-23 10:12 AM, Hayes Wang wrote:
Mark Lord [ml...@pobox.com]
[...]
What does this code do:
static void r8153_set_rx_early_size(struct r8152 *tp)
{
u32 mtu = tp->netdev->mtu;
u32 ocp_data = (agg_buf_sz - mtu - VLAN_ET
On 16-11-23 10:12 AM, Hayes Wang wrote:
Mark Lord [ml...@pobox.com]
[...]
What does this code do:
static void r8153_set_rx_early_size(struct r8152 *tp)
{
u32 mtu = tp->netdev->mtu;
u32 ocp_data = (agg_buf_sz - mtu - VLAN_ETH_HLEN - VLAN_HLEN) / 4;
ocp_write_w
;}
How is ocp_data used by the hardware?
Shouldn't the calculation also include sizeof(rx_desc) in there somewhere?
Thanks
--
Mark Lord
Real-Time Remedies Inc.
ml...@pobox.com
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord
On 16-11-18 07:03 AM, Mark Lord wrote:
On 16-11-18 02:57 AM, Hayes Wang wrote:
..
Besides, the maximum data length which the RTL8152 would send to
the host is 16KB. That is, if the agg_buf_sz is 16KB, the host
wouldn't split it. However, you still see problems for it.
How does the RT
st lengths/ranges before accessing the actual buffer,
and everything should begin working reliably.
Cheers
--
Mark Lord
Real-Time Remedies Inc.
ml...@pobox.com
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kerne
On 16-11-17 09:14 AM, Mark Lord wrote:
..
Using coherent buffers (non-cacheable, allocated with usb_alloc_coherent),
Note that the same behaviour also happens with the original kmalloc'd buffers.
I can get it to fail extremely regularly by simply reducing the buffer size
(agg_buf_sz)
On 16-11-13 03:34 PM, Mark Lord wrote:
>
> The system I use it with is a 32-bit ppc476, with non-coherent RAM,
> and using 16KB page sizes.
>
> The dongle instantly becomes a lot more reliable when r8152.c is updated
> to use usb_alloc_coherent() for URB buffers, rather than k
or a day or two a week,
and it takes a few hours to do a good test as to whether something helps or not.
I'll continue to poke at it as time and New Ideas permit.
New Ideas welcome!
--
Mark Lord
Real-Time Remedies Inc.
ml...@pobox.com
--
To unsubscribe from this list: send the line "unsu
rocess huge unreal packet sizes here.
I've had to patch it to reject "packets" larger than the configured MRU.
--
Mark Lord
Real-Time Remedies Inc.
ml...@pobox.com
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord..
On 14-02-04 05:55 PM, Mark Lord wrote:
> On 14-02-04 03:11 PM, Sarah Sharp wrote:
>> Hi Mark and David,
>>
>> Can you test the following two patches against 3.13?
>>
>> Please make sure the adapter works when it's plugged directly into a USB
>> 3.0 p
ilable in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git
> 3.13-td-changes-reverted
>
> for you to fetch changes up to 4327645d0e03dad2e2ec4480cb43f30a2d1a6d20:
I tested against the git tree (rather than patching 3.13.x).
Seems to work fine
I
controller other than the NEC chip (and some Intel chips) causes instability,
in particular when using the AMD and VIA chips.
Right now, Linux USB3 has a very bad reputation -- buggy and unstable.
If there's a bug we/you know about, then let's get it fixed.
It could help some of those a
rather the drivers and design of parts of the kernel.
Cheers
--
Mark Lord
Real-Time Remedies Inc.
ml...@pobox.com
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
once the problems are solved outside of the main tree.
--
Mark Lord
Real-Time Remedies Inc.
ml...@pobox.com
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 14-01-30 06:26 PM, Sarah Sharp wrote:
> On Thu, Jan 30, 2014 at 05:20:40PM -0500, Mark Lord wrote:
>> On 14-01-30 04:41 PM, Sarah Sharp wrote:
>>>
>>> Mark and David, can you pull the 3.13-td-changes-reverted branch again,
>>> and see if the latest patch fi
expected, this works just fine.
--
Mark Lord
Real-Time Remedies Inc.
ml...@pobox.com
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
gt; For example, what will you do if a driver submits an SG list containing
> 300 elements, each 3 bytes long?
Allocate a contiguous (bounce) buffer and copy the fragments to/from it?
--
Mark Lord
Real-Time Remedies Inc.
ml...@pobox.com
--
To unsubscribe from this list: send the line
side port works flawlessly.
The MS-Windows driver has a workaround of some sort, but we don't.
Cheers
--
Mark Lord
Real-Time Remedies Inc.
ml...@pobox.com
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
ot all that bad either.
My ax88179 dongle (yes, that one, using ax88179_178a.ko)
manages very close to 1gbit/sec throughput even without SG,
and without a huge cpu tax either.
SG done Right will make it better eventually. I can wait.
Cheers
--
Mark Lord
Real-Time Remedies Inc.
ml...@pobox
On 14-01-30 02:54 PM, Paul Zimmerman wrote:
>
> Can you give a pointer to where we could buy one of these devices? I
> would like to test this with our (Synopsys) xHCI controller as well.
>
newegg.com, item N82E16817659005
--
Mark Lord
Real-Time Remedies Inc.
ml...@pobox.com
--
To
when the USB
> 3.0 device falls back to USB 2.0 speeds under xHCI, it works.
Could be due to something related to the max URB length:
USB 2.0 High-Speed: max URB length 512.
USB 3.0 Super-Speed: max URB length 1024.
Cheers
--
Mark Lord
Real-Time Remedies Inc.
ml...@pobox.com
--
To unsubscribe f
On 14-01-28 11:30 PM, Mark Lord wrote:
> On 14-01-28 03:30 PM, Sarah Sharp wrote:
> ..
>> Can you please pull this branch, which contains a 3.13 kernel with
>> David's patch reverted, and test whether your USB ethernet device works
>> or fails?
>
> Fails.
ble check to see if vanilla 3.13 works or fails.
Okay, will try that before bed.
--
Mark Lord
Real-Time Remedies Inc.
ml...@pobox.com
log.gz
Description: GNU Zip compressed data
/* Accept arbitrarily long scatter-gather lists */
> - hcd->self.sg_tablesize = ~0;
> + hcd->self.sg_tablesize = 31;
>
> /* support to build packet from discontinuous buffers */
> hcd->self.no_sg_constraint = 1;
>
> Sadly it didn't fix the problem. Did I get the patch right?
That sounds almost as if the old version is still being loaded/run,
possibly from the initramfs image?
--
Mark Lord
Real-Time Remedies Inc.
ml...@pobox.com
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
CSI command.
Is there not a block layer / scheduler tunable for max sg entries or something?
--
Mark Lord
Real-Time Remedies Inc.
ml...@pobox.com
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 13-12-16 04:21 PM, Sarah Sharp wrote:
> On Fri, Dec 06, 2013 at 11:10:29PM -0500, Mark Lord wrote:
>> On 13-12-06 10:25 AM, Greg Kroah-Hartman wrote:
>>> On Fri, Dec 06, 2013 at 12:55:23AM -0500, Mark Lord wrote:
>>>> On 13-12-02 04:42 PM, Greg Kroah-Hartman wrote:
On 13-12-06 10:25 AM, Greg Kroah-Hartman wrote:
> On Fri, Dec 06, 2013 at 12:55:23AM -0500, Mark Lord wrote:
>> On 13-12-02 04:42 PM, Greg Kroah-Hartman wrote:
>>> On Mon, Dec 02, 2013 at 12:49:08PM -0800, Sarah Sharp wrote:
>>>> The
On 13-12-02 04:42 PM, Greg Kroah-Hartman wrote:
> On Mon, Dec 02, 2013 at 12:49:08PM -0800, Sarah Sharp wrote:
>> The following changes since commit c24cb6c8b501ebdf1aacec7960110a9741a45ced:
>>
>> Merge tag 'fixes-for-v3.13-rc2' of
>> git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into
est. I will Cc you on the pull
> request and patch, which should be sent out today.
Super, exactly what we need, thanks!
--
Mark Lord
Real-Time Remedies Inc.
ml...@pobox.com
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...
On 13-12-02 04:30 AM, David Laight wrote:
>> From: Mark Lord
>> Sent: 30 November 2013 02:59
>> To: Sarah Sharp; David Laight
>> Cc: David Miller; eric.duma...@gmail.com; ming@canonical.com;
>> net...@vger.kernel.org; linux-
>> u...@vger.kernel.org
>>
On 13-11-19 08:44 AM, Mark Lord wrote:
> On 13-11-19 05:04 AM, David Laight wrote:
>>
>> Which changes did you revert?
>
> Just the bits that changed how the headroom/tailroom sizes
> were checked and adjusted. See attachment for the revert patch
> I am using here. My
On 12-07-11 06:53 PM, Mark Lord wrote:
> Add USB identifiers for MCE compatible I/R transceivers from Twisted Melon.
>
> Signed-off-by: Mark Lord
> ---
> Mauro, please queue this up for inclusion in linux-3.6.
> Patch is also attached to bypass emailer mangling.
> Thanks.
&
Add USB identifiers for MCE compatible I/R transceivers from Twisted Melon.
Signed-off-by: Mark Lord
---
Mauro, please queue this up for inclusion in linux-3.6.
Patch is also attached to bypass emailer mangling.
Thanks.
--- linux-3.5-rc6/drivers/media/rc/mceusb.c 2012-07-07 20:23
58 matches
Mail list logo
