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
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
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
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 larry.fin...@lwfinger.net
Date: Sat Mar 21 15:16:05 2015 -0500
rtlwifi: Fix IOMMU
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
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 18 April 2015 at 12:10, Dorian Gray yourfavourite...@gmail.com wrote:
On 17 April 2015 at 22:06, Konrad Rzeszutek Wilk konrad.w...@oracle.com
wrote:
On Fri, Apr 17, 2015 at 05:14:20PM +0200, Dorian Gray wrote:
On 16 April 2015 at 20:42, Konrad Rzeszutek Wilk konrad.w...@oracle.com
wrote:
On 17 April 2015 at 22:06, Konrad Rzeszutek Wilk konrad.w...@oracle.com wrote:
On Fri, Apr 17, 2015 at 05:14:20PM +0200, Dorian Gray wrote:
On 16 April 2015 at 20:42, Konrad Rzeszutek Wilk konrad.w...@oracle.com
wrote:
And easier way is to compile the kernel with CONFIG_DMA_API_DEBUG
and
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
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
On 16 April 2015 at 18:57, Dorian Gray yourfavourite...@gmail.com wrote:
On 16 April 2015 at 16:24, Suman Tripathi stripa...@apm.com 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
On 16 April 2015 at 20:42, Konrad Rzeszutek Wilk konrad.w...@oracle.com 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/
On Fri, Apr 17, 2015 at 05:14:20PM +0200, Dorian Gray wrote:
On 16 April 2015 at 20:42, Konrad Rzeszutek Wilk konrad.w...@oracle.com
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
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
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
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,
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
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
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've been using
On 16 April 2015 at 16:15, Alan Stern st...@rowland.harvard.edu 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
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 (hardware)
On 16 April 2015 at 20:42, Konrad Rzeszutek Wilk konrad.w...@oracle.com 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
On Thu, Apr 16, 2015 at 06:57:46PM +0200, Dorian Gray wrote:
On 16 April 2015 at 16:15, Alan Stern st...@rowland.harvard.edu 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
26 matches
Mail list logo