Messages in this thread | | | Date | Mon, 4 Mar 2002 09:35:14 -0800 (PST) | From | James Simmons <> | Subject | Re: 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/
| |