Raising an disabled tasklet / VC/KBD initialization bug.
Hallo,
I just ran into the following situation on x86-64 on 2.4.17. I think 2.5 has the same problem.
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.
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.
Comments?
-Andi
Quoted 4 lines
of disabled tasklets properly or make sure
kbd_initandvc_inithave defined init order and the first always executes before the second.Comments?
Oh this explains several non x86 reports. Yes We need to fix the link order
Quoted 7 lines
Quoted 5 lines
of disabled tasklets properly or make sure
kbd_initandvc_inithave defined init order and the first always executes before the second.Comments?
Oh this explains several non x86 reports. Yes We need to fix the link order
Better fix is to test the kam flag in struct vc_data. Will send patch.
Quoted 10 lines
For some reason
vc_initexecuted in init order afterkbd_init(they are both indirectly called via__initcallso it can happen)vc_initdoes atasklet_schedulefor the keyboard tasklet inset_leds. The keyboard tasklet had not been enabled yet becausekbd_initdidn't execute.
Result was an raised tasklet that wasn't enabled. schedule was called and ran the softirqs.tasklet_actionalways tried to execute it, but returned on the non zero count. The tasklet was still active. ksoftirqd noticed that and executeddo_softirqagain -> endless loop.
Really good spotting.
Quoted 4 lines
For now I just removed the
set_leds()call inreset_terminalto work around it. The real fix would be either to add an mechanism to support raising of disabled tasklets properly or make surekbd_initandvc_inithave 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.