On Sun, Apr 19, 2015 at 05:43:18PM +0200, Dorian Gray wrote:
> I think the case is closed.
> Now that I know it's not USB, but wireless driver, I looked through
> the new k3.19.5's changelog and saw this:
>
>
> commit b943e69d33fac1e5f6db57868e061096b0aae67a
> Author: Larry Finger
> Date: Sat
I think the case is closed.
Now that I know it's not USB, but wireless driver, I looked through
the new k3.19.5's changelog and saw this:
commit b943e69d33fac1e5f6db57868e061096b0aae67a
Author: Larry Finger
Date: Sat Mar 21 15:16:05 2015 -0500
rtlwifi: Fix IOMMU mapping leak in AP mode
On 18 April 2015 at 12:10, Dorian Gray wrote:
> On 17 April 2015 at 22:06, Konrad Rzeszutek Wilk
> wrote:
>> On Fri, Apr 17, 2015 at 05:14:20PM +0200, Dorian Gray wrote:
>>> On 16 April 2015 at 20:42, Konrad Rzeszutek Wilk
>>> wrote:
>>> > And easier way is to compile the kernel with CONFIG_DM
On 17 April 2015 at 22:06, Konrad Rzeszutek Wilk wrote:
> On Fri, Apr 17, 2015 at 05:14:20PM +0200, Dorian Gray wrote:
>> On 16 April 2015 at 20:42, Konrad Rzeszutek Wilk
>> wrote:
>> > And easier way is to compile the kernel with CONFIG_DMA_API_DEBUG
>> > and then load the attached module.
>> >
On Fri, Apr 17, 2015 at 05:14:20PM +0200, Dorian Gray wrote:
> On 16 April 2015 at 20:42, Konrad Rzeszutek Wilk
> wrote:
> > And easier way is to compile the kernel with CONFIG_DMA_API_DEBUG
> > and then load the attached module.
> >
> > That should tell you who and what else is holding on the bu
On 16 April 2015 at 20:42, Konrad Rzeszutek Wilk wrote:
> And easier way is to compile the kernel with CONFIG_DMA_API_DEBUG
> and then load the attached module.
>
> That should tell you who and what else is holding on the buffers.
Ok, I have compiled 3.19.4 w/ CONFIG_DMA_API_DEBUG=y + the module
On 16 April 2015 at 18:57, Dorian Gray wrote:
> On 16 April 2015 at 16:24, Suman Tripathi wrote:
>> Try increasing the SWIOTLB size to 128MB .Default is 64MB.
>
> Ok, so I'm back to k3.18.7 (default in the latest Fatdog), although
> I'm not sure what should be the exact value of swiotlb boot para
On 16 April 2015 at 20:42, Konrad Rzeszutek Wilk wrote:
> And easier way is to compile the kernel with CONFIG_DMA_API_DEBUG
> and then load the attached module.
>
> That should tell you who and what else is holding on the buffers.
Thanks, this will be my next step then, right after I'm done with
On Thu, Apr 16, 2015 at 06:57:46PM +0200, Dorian Gray wrote:
> On 16 April 2015 at 16:15, Alan Stern wrote:
> > This appears to be a problem with the IOMMU or SWIOTLB subsystems, not
> > the USB subsystem. I have CC'ed the appropriate mailing lists.
>
> Thanks, I'm far from being a kernel expert
On 16 April 2015 at 16:15, Alan Stern wrote:
> This appears to be a problem with the IOMMU or SWIOTLB subsystems, not
> the USB subsystem. I have CC'ed the appropriate mailing lists.
Thanks, I'm far from being a kernel expert, so was expecting it could
be wrong subsection.
On 16 April 2015 at
On 04/16/2015 07:15 AM, Alan Stern wrote:
> On Thu, 16 Apr 2015, Dorian Gray wrote:
>
>> I have tested the following kernel versions:
>> - 3.18.4, 3.18.6, 3.18.7, 3.19.4 [all affected]
>> - 3.17.1 [unaffected]
>> - 3.17.8 [probably the last unaffected version; I'm using it currently]
>>
>> Also, I'
On Thu, 16 Apr 2015, Dorian Gray wrote:
> I have tested the following kernel versions:
> - 3.18.4, 3.18.6, 3.18.7, 3.19.4 [all affected]
> - 3.17.1 [unaffected]
> - 3.17.8 [probably the last unaffected version; I'm using it currently]
>
> Also, I've been using the very same configuration (hardware
On Thu, 16 Apr 2015, Dorian Gray wrote:
> I have tested the following kernel versions:
> - 3.18.4, 3.18.6, 3.18.7, 3.19.4 [all affected]
> - 3.17.1 [unaffected]
> - 3.17.8 [probably the last unaffected version; I'm using it currently]
>
> Also, I've been using the very same configuration (hardwar
13 matches
Mail list logo
