search for: take_over_console

...probably unrelated, but things I''d like to clean up nonetheless. I have a Xen guest instance running my Xen0 kernel. When it boots I get: Jul 29 01:31:37 loki kernel: fb0: VGA16 VGA frame buffer device Jul 29 01:31:37 loki kernel: c48c9dd3 Jul 29 01:31:37 loki kernel: [<c01b6ddc>] take_over_console+0x63/0x389 Jul 29 01:31:37 loki kernel: [<c48c92f4>] fbcon_takeover+0x5c/0x8a [fbcon] Jul 29 01:31:37 loki kernel: [<c4853231>] init_module+0x56/0x5a [fbcon] Jul 29 01:31:37 loki kernel: [<c012b5ca>] sys_init_module+0xf1/0x1e9 Jul 29 01:31:37 loki kernel: [<c0108c10>] sy...

...bit padding field, which has the nice effect of EVTCHN_VALID() yielding false for irq -1.) The call tree which we could (and actually always should) get into that state is xenfb_probe() -> register_framebuffer() -> fbcon_event_notify() -> fbcon_fb_registered() -> fbcon_takeover() -> take_over_console() -> bind_con_driver() -> visual_init() -> fbcon_init() -> xenfb_set_par(). Since xenfb_probe() calls register_framebuffer() before kthread_run() and xenfb_connect_backend(), xenfb_thread() should find info->resize_dpy always set to 1, and hence always go into xenfb_do_resize() right...

...r) is: -> #1 (console_lock){+.+.+.}: [<ffffffff81090a61>] __lock_acquire+0x3a1/0xb60 [<ffffffff810916ea>] lock_acquire+0x5a/0x70 [<ffffffff810407a7>] console_lock+0x77/0x80 [<ffffffff812c6d84>] register_con_driver+0x34/0x140 [<ffffffff812c84e9>] take_over_console+0x29/0x60 [<ffffffff8126e76b>] fbcon_takeover+0x5b/0xb0 [<ffffffff81272bb5>] fbcon_event_notify+0x715/0x820 [<ffffffff810693a5>] notifier_call_chain+0x55/0x110 [<ffffffff810697d7>] __blocking_notifier_call_chain+0x67/0xc0 [<ffffffff81069841>] blocki...