Actually, it's a stock kernel ported to Coldfire. You might classify
that as custom. I think that the problem may actually be inside of
the FEC driver for the Coldfire CPU. It looks to be that the
fec_rx_handler is what's being run from tasklet_action when the
problem occurs. The FEC driver is responsible for scheduling the
tasklet after a hardware interrupt takes place. Maybe there's a race
condition of some sort in the driver itself. I am still
investigating.
On 10/25/07, Mohammad M Molla <merajul_i@xxxxxxxxx> wrote:
> TASKLET_STATE_SCHED is set when tasklet is scheduled using tasklet_schedule
> or tasklet_hi_schedule and clear only when the tasklet starts its execution.
>
> Are you using some customized kernel or stock kernel? I believe there should
> not be this bug in stock kernel.
>
> - Meraj
>
> Tony Mouawad <tonym.ace@xxxxxxxxx> wrote:
> Very good.
>
> Now I'm trying to figure out why this tasklet_action() code path ends
> up calling BUG(). This is a very intermittent problem and seemingly
> impossible to reproduce.
>
> 404 if(!test_and_clear_bit(TASKLET_STATE_SCHED, &t->state))
> 405 BUG();
>
> It's obvious that 404 will result in false if the TASKLET_STATE_SCHED
> bit was not set. The question is what possibilities are there for
> TASKLET_STATE_SCHED bit to not be set yet the tasklet was scheduled to
> execute? Is it possible that the tasklet was scheduled to execute and
> before execution, somehow the TASKLET_STATE_SCHED bit was reset?
>
> On 10/23/07, Mohammad M Molla wrote:
> > Its a bit strange that the passed parameter is not used.
> >
> > Looking carefully at the code what I understood is, inside the while
> > loop, tasklets are processed one by one from the temporary list. Look
> > at the continue, which actually skips the last part of the loop.
> >
> > Whenver, tasklet_trylock fails, before returning, the function
> > actually merges any remaining entries on the list that it could not
> > proceed with __get_cpu_var(tasklet_vec).list which may or may not be
> > empty at that time for future processing.
> >
> >
> > - Meraj
> >
> >
> >
> > On 10/23/07, Tony Mouawad wrote:
> > > What is the purpose of the parameter "struct softirq_action *a" being
> > > passed into tasklet_action() since it doesn't appear to be used
> > > anywhere in the function?
> > >
> > > How does the list in __get_cpu_var(tasklet_vec).list get populated?
> > > It looks like at the top of the tasklet_action() call the list is set
> > > to empty and at the bottom __get_cpu_var(tasklet_vec).list is assigned
> > > to the next element of a temporary list ( t->next ). Is it possible
> > > for __get_cpu_var(tasklet_vec).list to get populated during a call to
> > > tasklet_action() or is what I am seeing just a NULL assignment to
> > > t->next ?
> > >
> > >
> > > On 10/22/07, Tony Mouawad wrote:
> > > > Hello,
> > > >
> > > > I'm trying to get a handle on a problem that is occuring inside of a
> > > > call to tasklet_action(). Can someone explain a bit about what line
> > > > 404 is doing ( and the function itself ) in the following code? It
> > > > seems that the OS is intermittently resulting in a false result on
> > > > line 404 and then executing line 405 which ultimately halts the
> > > > kernel.
> > > >
> > > > Regards,
> > > > Tony
> > > >
> > > >
> > > > 388 static void tasklet_action(struct softirq_action *a)
> > > > 389 {
> > > > 390 struct tasklet_struct *list;
> > > > 391
> > > > 392 local_irq_disable();
> > > > 393 list = __get_cpu_var(tasklet_vec).list;
> > > > 394 __get_cpu_var(tasklet_vec).list = NULL;
> > > > 395 local_irq_enable();
> > > > 396
> > > > 397 while (list) {
> > > > 398 struct tasklet_struct *t = list;
> > > > 399
> > > > 400 list = list->next;
> > > > 401
> > > > 402 if (tasklet_trylock(t)) {
> > > > 403 if (!atomic_read(&t->count)) {
> > > > 404 if
> > > > (!test_and_clear_bit(TASKLET_STATE_SCHED, &t->state))
> > > > 405 BUG();
> > > > 406 t->func(t->data);
> > > > 407 tasklet_unlock(t);
> > > > 408 continue;
> > > > 409 }
> > > > 410 tasklet_unlock(t);
> > > > 411 }
> > > > 412
> > > > 413 local_irq_disable();
> > > > 414 t->next = __get_cpu_var(tasklet_vec).list;
> > > > 415 __get_cpu_var(tasklet_vec).list = t;
> > > > 416 __raise_softirq_irqoff(TASKLET_SOFTIRQ);
> > > > 417 local_irq_enable();
> > > > 418 }
> > > > 419 }
> > > >
> > >
> > > --
> > > To unsubscribe from this list: send an email with
> > > "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
> > > Please read the FAQ at http://kernelnewbies.org/FAQ
> > >
> > >
> >
> >
> > --
> >
> > Meraj
> >
>
> --
> To unsubscribe from this list: send an email with
> "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
> Please read the FAQ at http://kernelnewbies.org/FAQ
>
>
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
