is working stable
(uptime 6hrs and counting).
Thank you Konrad (and everyone else involved) for helping me out to
pinpoint the actual culprit.
Jake
On 18 April 2015 at 21:59, Dorian Gray wrote:
> On 18 April 2015 at 12:10, Dorian Gray wrote:
>> On 17 April 2015 at 22:06, Konrad Rzesz
On 18 April 2015 at 21:59, Dorian Gray yourfavourite...@gmail.com wrote:
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
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:
>>> &g
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
>> >
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
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 val
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 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 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 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 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
14 matches
Mail list logo
