lkml.org 
[lkml]   [2000]   [Feb]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subjectbottom half's bug introduced in 2.3.43
Hi,

I'm posting this again since I didn't get an answer for the problem
and also because now I have better information.

As the subject states the problem appeared with kernel 2.3.43,
and it seems to affect SMP machines only (well at least no report
yet involving UP).

Basically a task queued in the tq_immediate queue is never run
and seems to stay in the queue forever. I debugged the driver side
with this piece of code:

int emu10k1_timer_irqhandler(struct sblive_hw *sb_hw)
{
struct emu_timer *timer;
struct tq_struct *t;
unsigned long flags;

spin_lock(&sb_hw->timer_lock);

timer = sb_hw->timer;
while (timer != NULL)
{
t = timer->task;
DPD(2,"task (b) %p %ld %p %p\n",t->next, t->sync, t->routine,
t->data);
queue_task(timer->task, &tq_immediate);
DPD(2,"task (a) %p %ld %p %p\n",t->next, t->sync, t->routine,
t->data);
mark_bh(IMMEDIATE_BH);
timer = timer->next;
}

spin_unlock(&sb_hw->timer_lock);

return CTSTATUS_SUCCESS;
}

timer->lock just protects the timer linked list and DPD() is just a macro that
resolves to printk().

The output in kernel >= 2.3.43 after a reboot was:

task (a) c315ac60 00000000 0 c8833b08 c315a5e0
task (b) c315ac60 00000000 1 c8833b08 c315a5e0
task (a) c315ac60 00000000 0 c8833b08 c315a5e0
task (b) c315ac60 00000000 1 c8833b08 c315a5e0
task (a) c315ac60 00000000 1 c8833b08 c315a5e0
task (b) c315ac60 00000000 1 c8833b08 c315a5e0
....

after unloading/loading the module:

task (a) c1a7d640 00000000 0 c8833b08 c1a7d680
task (b) c1a7d640 c315ac60 1 c8833b08 c1a7d680
task (a) c1a7d640 c315ac60 1 c8833b08 c1a7d680
task (b) c1a7d640 c315ac60 1 c8833b08 c1a7d680
task (a) c1a7d640 c315ac60 1 c8833b08 c1a7d680
task (b) c1a7d640 c315ac60 1 c8833b08 c1a7d680
task (a) c1a7d640 c315ac60 1 c8833b08 c1a7d680
task (b) c1a7d640 c315ac60 1 c8833b08 c1a7d680

The task is definitely being added to the queue and staying there...

I have also checked the kernel source and the only other driver
(in my configuration) using the tq_immediate task queue is the floppy
disk which indeed stops working after running my driver.
Just using the floppy doesn't seem to trigger the problem and by
reducing the interrupt rate to 0.02s in my driver I only saw the problem after
about 20 interrupts. The usual interrupt rate is about 0.01s and can
go as high as 0.7ms.

In kernel 2.3.42 the output is similar to the first lines above, the sync bit
is reset and the bottom half runs normally (under the same conditions).


So, any one knows what happened going from kernel 2.3.42 to 2.3.43 that can
cause
this? Any help would be appreciated, and I'm also willing to help debug this.

Regards,

Rui Sousa

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:56    [W:0.047 / U:0.860 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site