On Apr 1, 2015 12:56 PM, "Kay Sievers" <k...@vrfy.org> wrote: > > On Wed, Apr 1, 2015 at 9:36 PM, Andy Lutomirski <l...@amacapital.net> wrote: > > On Wed, Apr 1, 2015 at 12:32 PM, Kay Sievers <k...@vrfy.org> wrote: > >> On Wed, Apr 1, 2015 at 8:56 PM, Andy Lutomirski <l...@amacapital.net> > >> wrote: > >>> On Thu, Jan 22, 2015 at 6:29 PM, Andy Lutomirski <l...@amacapital.net> > >>> wrote: > >>>> On Thu, Jan 22, 2015 at 6:13 PM, Lennart Poettering > >>>> <lenn...@poettering.net> wrote: > >>>>> On Wed, 21.01.15 19:15, Andy Lutomirski (l...@amacapital.net) wrote: > >>>>> > >>>>>> Hi all- > >>>>>> > >>>>>> When running virtme (a simple vm gadget) on Fedora 21, the slowest > >>>>>> part of bootup by far appears to be systemd-vconsole-setup: > >>>>>> > >>>>>> # time /usr/lib/systemd/systemd-vconsole-setup > >>>>>> putfont: PIO_FONT trying ... > >>>>>> ................... > >>>>>> setfont: putfont: 512,8x16: failed: -1 > >>>>>> putfont: PIO_FONT: Invalid argument > >>>>>> /usr/bin/setfont failed with error code 71. > >>>>> > >>>>> setfont is not part of systemd, we just invoke it. If that fails, this > >>>>> is a problem somewhere between the VM, the kernel and console-tools. > >>>>> > >>>> > >>>> Aha -- I missed that systemd-vconsole-setup calls setfont. I can > >>>> trigger the same problem by just typing setfont. For whatever reason, > >>>> my other Fedora 21 computer only has this problem if I type setfont > >>>> and not if I run systemd-vconcole-setup. > >>>> > >>>>> My uneducated guess is that your virtual machine boots up with a > >>>>> non-graphical console, and the tool thus tries to upload the fonts > >>>>> into the good old VGA hw text mode glyph tables, and qemu is very slow > >>>>> at that... Or something like that. > >>>> > >>>> setfont is doing this: > >>>> > >>>> nanosleep({0, 250000000}, NULL) = 0 > >>>> ioctl(3, PIO_FONT, 0xfbc010) = -1 EINVAL (Invalid argument) > >>>> write(2, ".", 1.) = 1 > >>>> nanosleep({0, 250000000}, NULL) = 0 > >>>> ioctl(3, PIO_FONT, 0xfbc010) = -1 EINVAL (Invalid argument) > >>>> write(2, ".", 1.) = 1 > >>>> nanosleep({0, 250000000}, NULL) = 0 > >>>> ioctl(3, PIO_FONT, 0xfbc010) = -1 EINVAL (Invalid argument) > >>>> write(2, ".", 1.) = 1 > >>>> nanosleep({0, 250000000}, NULL) = 0 > >>>> ioctl(3, PIO_FONT, 0xfbc010) = -1 EINVAL (Invalid argument) > >>>> write(2, ".", 1.) = 1 > >>>> nanosleep({0, 250000000}, NULL) = 0 > >>>> ioctl(3, PIO_FONT, 0xfbc010) = -1 EINVAL (Invalid argument) > >>>> write(2, ".", 1.) = 1 > >>>> > >>>> This thing has only a serial console: > >>>> > >>>> # cat /proc/consoles > >>>> ttyS0 -W- (EC a) 4:64 > >>>> > >>>> setfont does this: > >>>> > >>>> /* we allow ourselves to hang here for ca 5 seconds, xdm may > >>>> be playing tricks on us. */ > >>>> while ((loop++ < 20) && (i = ioctl(fd, PIO_FONT, buf))) > >>>> { > >>>> if (loop <= 1) > >>>> fprintf(stderr, "putfont: PIO_FONT trying ...\n"); > >>>> else > >>>> fprintf(stderr, "."); > >>>> usleep(250000); > >>>> } > >>>> fprintf(stderr, "\n"); > >>>> > >>>> Alexey, would it make sense to remove this loop or to add a way to turn > >>>> it off? > >>> > >>> Ping, everyone? > >>> > >>> This issue still exists. AFAICT systemd is relying on a really old > >>> tool, that that really old tool (setfont) is sometimes delaying boot > >>> by a very large amount. Can we either fix the tool (Alexey) or stop > >>> using it (systemd people)? > >> > >> Hmm, why is the "vm gadget" you run configuring a custom console font > >> at all? If there is no custom font specified in t he config, systemd > >> will not run setfont. > > > > It's not intentionally configuring a custom font, but it might be > > inheriting Fedora's settings. > > Ideally, /etc/vconsole.conf does not even exist in a default setup. It > is only needed for foreign language keyboard support or more exotic > font requirements. > > >> Or did you mean to have vconsole-setup detect that it should not even > >> try to run setfont? Not sure how to find that out. > >> > >> I don't really see how vconsole-setup could get rid of calling setfont > >> from systemd, it is needed in many setups. > > > > vconsole-setup could set the font itself instead of using setfont if > > setfont can't be configured or fixed not to keep retrying for five > > seconds (!). > > It is a rather complex logic which would need to be duplicated in > systemd. We so far have avoided it, because the kernel VC font and > keymaps are so conceptually limited, that it does not really make > sense to build a modern system on top of it. > > If systemd gets advanvced console support with systemd-consoled, > we need full unicode support, high-dpi display support, display hotplug, > ..., all things the kernel's vc stuff will never give us. That is why we rely > on setfont and loadkeys for now. > > > Ideally, I think that setfont would just stop retrying on failure. > > Right, that sounds like a simple and sensible fix.
Too bad no one from the kbd list has replied :( > > > Or > > perhaps all of this could go through udev or some other mechanism that > > doesn't try to set the font until the device actually exists. But the > > console system is weird and may be that's hard. > > The devices should be always there, /dev/tty1-15. It looks like the > driver behind the ttys seems not to accept the font and return EINVAL. > Not sure if udev could make a difference here. > > Do you have an idea why the VM does not accept the custom font? If > that is something obvious, and we can detect it, we could make > vconsole-setup check for it. But then again, fixing setfont seems like > the obvious fix here. I assume it's because the VM has no graphical console at all. --Andy _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel