[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] console: introduce console=none option
On 26/01/12 16:00, Jan Beulich wrote: >>>> On 26.01.12 at 15:58, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote: >> On 26/01/12 14:41, Jan Beulich wrote: >>>>>> On 26.01.12 at 13:19, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote: >>>> XenServer by default boots without a serial console (buggy hardware >>>> reasons) and dom0 displays a splash screen. Unfortunately, having Xen >>>> writing to the vga text area looks ugly whilst dom0 is trying to set up >>>> non-text mode and display the splash screen. >>>> >>>> We have been using "console=" to prevent this behavior for a while, but >>>> presented herewith is a patch to fix the problem correctly. >>> While I don't mind the patch, I'm completely confused by the description: >>> Where is it that Xen writes to VGA text area after control was passed to >>> Dom0? >>> >>> Jan >> I have not debugged it that much as I was looking for a clean solution >> to our current hack of "console=" (and I have some rather more serious >> deadlock bugs to debug), but it all Xen printk's are going into the VGA >> text area, even after dom0 has started. It is possible that Xen is >> still writing into the text area after dom0 has switched VGA mode, but I >> have no proof of this one way or the other. > Just take a look at vga_endboot() - the output routine gets pointed to > vga_noop_puts() unless vgacon_keep. Beyond that point nothing > can possibly get printed to the VGA text screen, or if it does, then I'd > suspect there's some other change in XenServer that makes it so. > > Jan I have just been debugging this, and found that it got up to my debug message of switching back to vga_noop_puts(). I know that this was called before dom0 started booting, but that it appeared as if it was being written while dom0 was booting It turns out that the problem is that after vesa_endboot zeros the linear framebuffer, it does not call lfb_flush(), meaning that an sfence does not occur, and presumably the actual linear framebuffer still has Xen console text in it when dom0 takes over and sets it up. Hacking an sfence into vesa_endboot() fixes the issue completely. I shall roll a patch using lfb_flush() and post it shortly. -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |