Displaying 2 results from an estimated 2 matches for "xenfb_thread".
2009 Jan 27
13
[Patch] fix xenfb_update_screen bogus rect
...ed by checking/setting info->dirty without dirty_lock.
We need to check/set info->dirty safely.
xenfb_update_screen bogus rect 2147483647 0 2147483647 0
BUG: warning at /root/linux-2.6.18-xen.hg/drivers/xen/fbfront/xenfb.c:240/xenfb_update_screen()
Call Trace:
[<ffffffff8036920e>] xenfb_thread+0x19b/0x2be
[<ffffffff8022730a>] try_to_wake_up+0x33b/0x34c
[<ffffffff80225c3d>] __wake_up_common+0x3e/0x68
[<ffffffff80241e20>] autoremove_wake_function+0x0/0x2e
[<ffffffff80241a75>] keventd_create_kthread+0x0/0x61
[<ffffffff80369073>] xenfb_thread+0x0/0x2be...
2008 Nov 18
0
xenfb issuing notify_remote_via_irq() too early
...mebuffer() -> 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 away (which, depending on the timing, would
perhaps find info->irq still being -1).
There also is a comment right before the creation of the thread: "FIXME
should this be delayed until backe...