lkml.org 
[lkml]   [2002]   [Mar]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Raising an disabled tasklet / VC/KBD initialization bug.

> For some reason vc_init executed in init order after kbd_init
> (they are both indirectly called via __initcall so it can happen)
> vc_init does a tasklet_schedule for the keyboard tasklet in
> set_leds. The keyboard tasklet had not been enabled yet because kbd_init
> didn't execute.
> Result was an raised tasklet that wasn't enabled. schedule was called
> and ran the softirqs. tasklet_action always tried to execute it, but
> returned on the non zero count. The tasklet was still active. ksoftirqd
> noticed that and executed do_softirq again -> endless loop.

Really good spotting.

> For now I just removed the set_leds() call in reset_terminal to work around
> it. The real fix would be either to add an mechanism to support raising
> of disabled tasklets properly or make sure kbd_init and vc_init have defined
> init order and the first always executes before the second.

I'm working on a fix right now. As gor calling kbd_init before vc_init
that is a bad idea as all keyboard drivers are being moved over to the
input api. Plus the console system will soon support hotplug of devices.
The proper fix is to test the kam flag in struct vc_data. Will send a
patch to be included in the dave jones tree.



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

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