: kernelnewbies@nl.linux.org
Subject: Re: interrupt/tasklet issue in custom driver on recent kernels
For posterity, I've finally solved this issue. It ended up having
nothing to do with the interrupts/tasklets themselves. The driver uses
ioremap() to get hold of some reserved memory, and it seems
On Mon, Sep 28, 2009 at 11:10 AM, Mulyadi Santosa
wrote:
> On Mon, Sep 28, 2009 at 2:32 PM, Jason Nymble wrote:
>> 2.6.25 Changelog :
>> commit 9af993a92623e022c176459fa6607a564b9a7eaf
>> Author: Ingo Molnar
>> Date: Wed Jan 30 13:34:09 2008 +0100
>>
>> x86: make ioremap() UC by default
>>
On Mon, Sep 28, 2009 at 2:32 PM, Jason Nymble wrote:
> 2.6.25 Changelog :
> commit 9af993a92623e022c176459fa6607a564b9a7eaf
> Author: Ingo Molnar
> Date: Wed Jan 30 13:34:09 2008 +0100
>
> x86: make ioremap() UC by default
>
> Yes! A mere 120 c_p_a() fixing and rewriting patches later,
>
2.6.25 Changelog :
commit 9af993a92623e022c176459fa6607a564b9a7eaf
Author: Ingo Molnar
Date: Wed Jan 30 13:34:09 2008 +0100
x86: make ioremap() UC by default
Yes! A mere 120 c_p_a() fixing and rewriting patches later,
we are now confident that we can enable UC by default for
i
just learned something new: cacheline ping pong.
http://everything2.com/index.pl?node_id=1382347
http://lwn.net/Articles/176024/
and the details is perhaps best described here:
http://www.patentstorm.us/patents/5713004/claims.html
what happened is the write-back/through cacheline control is i
On Sun, Sep 27, 2009 at 1:48 AM, Mulyadi Santosa
wrote:
> Hi
>
> On 9/26/09, Peter Teoh wrote:
>> sorry for being a busy body:-)but hope i can contribute my 2cts...
>>
>> On Fri, Sep 25, 2009 at 12:54 PM, Mulyadi Santosa
>> wrote:
>>> On 9/25/09, Jason Nymble wrote:
For posteri
Hi
On 9/26/09, Peter Teoh wrote:
> sorry for being a busy body:-)but hope i can contribute my 2cts...
>
> On Fri, Sep 25, 2009 at 12:54 PM, Mulyadi Santosa
> wrote:
>> On 9/25/09, Jason Nymble wrote:
>>> For posterity, I've finally solved this issue. It ended up having
>>> nothing t
sorry for being a busy body:-)but hope i can contribute my 2cts...
On Fri, Sep 25, 2009 at 12:54 PM, Mulyadi Santosa
wrote:
> On 9/25/09, Jason Nymble wrote:
>> For posterity, I've finally solved this issue. It ended up having
>> nothing to do with the interrupts/tasklets themselves. The
On 9/25/09, Jason Nymble wrote:
> For posterity, I've finally solved this issue. It ended up having
> nothing to do with the interrupts/tasklets themselves. The driver uses
> ioremap() to get hold of some reserved memory, and it seems from about
> 2.6.25 onwards or so this defaults to ioremap_noca
For posterity, I've finally solved this issue. It ended up having
nothing to do with the interrupts/tasklets themselves. The driver uses
ioremap() to get hold of some reserved memory, and it seems from about
2.6.25 onwards or so this defaults to ioremap_nocache(), so our driver
was doing me
How about this:
use "top" to confirm which process is the one causing the 100% CPU
utilization? Then enter "echo t > /proc/sysrq-trigger" to generate a
stack trace dump of all the kernel threads. It should overflow your
dmesg buffer, so look into /var/log/messages for the complete trace.
And i
On 09 Sep 2009, at 3:47 PM, Mulyadi Santosa wrote:
Hi Jason...
On Wed, Sep 9, 2009 at 3:39 PM, Jason Nymble
wrote:
Hi,
Background: We use a custom kernel driver module for our PCIe
device which
processes bulk data between the host and the card. The card issues
MSI
interrupts at up to 2
Hi Jason...
On Wed, Sep 9, 2009 at 3:39 PM, Jason Nymble wrote:
> Hi,
>
> Background: We use a custom kernel driver module for our PCIe device which
> processes bulk data between the host and the card. The card issues MSI
> interrupts at up to 20kHz to the host, and the driver interrupt routine
>
13 matches
Mail list logo
