[lkml]   [2004]   [Oct]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Probable module bug in linux-2.6.5-1.358
On Thu, 7 Oct 2004, Arjan van de Ven wrote:

> On Thu, Oct 07, 2004 at 08:26:22AM -0400, Richard B. Johnson wrote:
>> On Thu, 7 Oct 2004, Arjan van de Ven wrote:
>>> On Thu, Oct 07, 2004 at 08:01:47AM -0400, Richard B. Johnson wrote:
>>>> Also, when this driver is running, transferring large volumes
>>>> of data, the kernel decides that there have been too many interrupts, and
>>>> does:
>>>> Message from syslogd@chaos at Wed Oct 6 21:22:57 2004 ...
>>>> chaos kernel: Disabling IRQ #18
>>>> This, in spite of the fact that interrupts occur only when
>>>> DMA completion happens and new data are available, i.e.,
>>>> one interrupt every 16 megabytes of data transferred.
>>>> Who decided that it had a right to disable my interrupt????
>>> the kernel did because you don't return the proper value for "I handled the
>>> IRQ" from your ISR.
>> Do you know what that value is? I can't find it. I just returned 0
>> and it worked for awhile.
> IRQ_HANDLED is you handled the irq, IRQ_NONE if you didn't
>> The kernel calls cleanup_module() and the printk() shows that it
>> was truly called.
> I fail to find where you declare module_exit() in your sources

Well I don't. Is it now required? What does it do? If I put
in module_exit() and have it execute cleanup_module(), it
barfs badly. Do I just make a dummy module_exit() that
does nothing? Does this mean that unregister_chrdev() didn't
really happen until module_exit() is called?

Dick Johnson
Penguin : Linux version 2.6.5-1.358-noreg on an i686 machine (5537.79 BogoMips).
Note 96.31% of all statistics are fiction.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:06    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean