Re: [kbd] [systemd-devel] systemd-vconsole-setup fails very slowly

Re: [kbd] [systemd-devel] systemd-vconsole-setup fails very slowly

[Andy Lutomirski]

On Thu, Jan 22, 2015 at 6:13 PM, Lennart Poettering
<lennart@poettering.net> wrote:
> On Wed, 21.01.15 19:15, Andy Lutomirski (luto@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?

Thanks,
Andy

Re: [kbd] [systemd-devel] systemd-vconsole-setup fails very slowly

[Alexey Gladkov]

23.01.2015 05:29, Andy Lutomirski пишет:
> On Thu, Jan 22, 2015 at 6:13 PM, Lennart Poettering
> <lennart@poettering.net> wrote:
>> On Wed, 21.01.15 19:15, Andy Lutomirski (luto@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?

Sure. I'll add way to turn it off.

By the way, I planning to rewrite the setfont in library. Just like a
loadkeys has been rewritten in to library.

-- 
Rgrds, legion

Re: [kbd] [systemd-devel] systemd-vconsole-setup fails very slowly

[Andy Lutomirski]

On Thu, Jan 22, 2015 at 6:29 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> On Thu, Jan 22, 2015 at 6:13 PM, Lennart Poettering
> <lennart@poettering.net> wrote:
>> On Wed, 21.01.15 19:15, Andy Lutomirski (luto@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)?

--Andy

Re: [kbd] [systemd-devel] systemd-vconsole-setup fails very slowly

[Kay Sievers]

On Wed, Apr 1, 2015 at 8:56 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> On Thu, Jan 22, 2015 at 6:29 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>> On Thu, Jan 22, 2015 at 6:13 PM, Lennart Poettering
>> <lennart@poettering.net> wrote:
>>> On Wed, 21.01.15 19:15, Andy Lutomirski (luto@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.

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.

Kay

Re: [kbd] [systemd-devel] systemd-vconsole-setup fails very slowly

[Andy Lutomirski]

On Wed, Apr 1, 2015 at 12:32 PM, Kay Sievers <kay@vrfy.org> wrote:
> On Wed, Apr 1, 2015 at 8:56 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>> On Thu, Jan 22, 2015 at 6:29 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>>> On Thu, Jan 22, 2015 at 6:13 PM, Lennart Poettering
>>> <lennart@poettering.net> wrote:
>>>> On Wed, 21.01.15 19:15, Andy Lutomirski (luto@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.

>
> 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 (!).

Ideally, I think that setfont would just stop retrying on failure.  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.

--Andy

Re: [kbd] [systemd-devel] systemd-vconsole-setup fails very slowly

[Kay Sievers]

On Wed, Apr 1, 2015 at 9:36 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> On Wed, Apr 1, 2015 at 12:32 PM, Kay Sievers <kay@vrfy.org> wrote:
>> On Wed, Apr 1, 2015 at 8:56 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>>> On Thu, Jan 22, 2015 at 6:29 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>>>> On Thu, Jan 22, 2015 at 6:13 PM, Lennart Poettering
>>>> <lennart@poettering.net> wrote:
>>>>> On Wed, 21.01.15 19:15, Andy Lutomirski (luto@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.

> 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.

Kay

Re: [kbd] [systemd-devel] systemd-vconsole-setup fails very slowly

[Andy Lutomirski]

On Apr 1, 2015 12:56 PM, "Kay Sievers" <kay@vrfy.org> wrote:
>
> On Wed, Apr 1, 2015 at 9:36 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> > On Wed, Apr 1, 2015 at 12:32 PM, Kay Sievers <kay@vrfy.org> wrote:
> >> On Wed, Apr 1, 2015 at 8:56 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> >>> On Thu, Jan 22, 2015 at 6:29 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> >>>> On Thu, Jan 22, 2015 at 6:13 PM, Lennart Poettering
> >>>> <lennart@poettering.net> wrote:
> >>>>> On Wed, 21.01.15 19:15, Andy Lutomirski (luto@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

Re: [kbd] [systemd-devel] systemd-vconsole-setup fails very slowly

[Kay Sievers]

On Wed, Apr 1, 2015 at 10:45 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> On Apr 1, 2015 12:56 PM, "Kay Sievers" <kay@vrfy.org> wrote:

>> 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.

We check the existence of the corresponding /dev/vcs%i, to check if
the tty is allocated where we want to apply the font to. Do these
devices exist on the running machine?

And what does this say?
  grep . /sys/class/tty/tty0/active /sys/class/tty/console/active

Kay

Re: [kbd] [systemd-devel] systemd-vconsole-setup fails very slowly

[Andy Lutomirski]

On Wed, Apr 1, 2015 at 1:53 PM, Kay Sievers <kay@vrfy.org> wrote:
> On Wed, Apr 1, 2015 at 10:45 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>> On Apr 1, 2015 12:56 PM, "Kay Sievers" <kay@vrfy.org> wrote:
>
>>> 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.
>
> We check the existence of the corresponding /dev/vcs%i, to check if
> the tty is allocated where we want to apply the font to. Do these
> devices exist on the running machine?

Yes:

# ls /dev/vcs*
/dev/vcs   /dev/vcs2  /dev/vcs4  /dev/vcsa1  /dev/vcsa3
/dev/vcs1  /dev/vcs3  /dev/vcsa  /dev/vcsa2  /dev/vcsa4

Looking at the code, the vc_screen.c code seems to create those
devices unconditionally.

>
> And what does this say?
>   grep . /sys/class/tty/tty0/active /sys/class/tty/console/active

# grep . /sys/class/tty/tty0/active /sys/class/tty/console/active
/sys/class/tty/tty0/active:tty1
/sys/class/tty/console/active:ttyS0

vcs1 has, roughly:

early console in decompress_kernel
Decompressing Linux... Parsing ELF... done.
Booting the kernel.

Now I'm wondering how that buffer came to be.

In any event, some tracing of the code suggests that I have
vga_video_type == VIDEO_TYPE_CGA, and that fails "if (vga_video_type <
VIDEO_TYPE_EGAM)" in vgacon_font_set.

Indeed, /proc/ioports has:

  03d4-03d5 : cga

and dmesg says:

[    0.000000] Console: colour *CGA 80x25

I don't see this information in sysfs anywhere.  Perhaps checking for
an active console and detecting -EINVAL from vgacon_font_get would
work.

/proc/fb is empty on this VM, so maybe that would help.  Grr, this
stuff is really old and crufty.

The offending qemu command line args appear to be -vga none -display
none.  I assume I have "CGA" because it's the fallback case in
vgacon.c if nothing matches.

--Andy

Re: [kbd] [systemd-devel] systemd-vconsole-setup fails very slowly

[Kay Sievers]

On Wed, Apr 1, 2015 at 11:19 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> On Wed, Apr 1, 2015 at 1:53 PM, Kay Sievers <kay@vrfy.org> wrote:
>> On Wed, Apr 1, 2015 at 10:45 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>>> On Apr 1, 2015 12:56 PM, "Kay Sievers" <kay@vrfy.org> wrote:
>>
>>>> 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.
>>
>> We check the existence of the corresponding /dev/vcs%i, to check if
>> the tty is allocated where we want to apply the font to. Do these
>> devices exist on the running machine?
>
> Yes:
>
> # ls /dev/vcs*
> /dev/vcs   /dev/vcs2  /dev/vcs4  /dev/vcsa1  /dev/vcsa3
> /dev/vcs1  /dev/vcs3  /dev/vcsa  /dev/vcsa2  /dev/vcsa4
>
> Looking at the code, the vc_screen.c code seems to create those
> devices unconditionally.

They should only get created when something accesses the corresponding
tty. deallocvt(1) can kill unused ones and the device nodes should
disappear.

>> And what does this say?
>>   grep . /sys/class/tty/tty0/active /sys/class/tty/console/active
>
> # grep . /sys/class/tty/tty0/active /sys/class/tty/console/active
> /sys/class/tty/tty0/active:tty1
> /sys/class/tty/console/active:ttyS0
>
> vcs1 has, roughly:
>
> early console in decompress_kernel
> Decompressing Linux... Parsing ELF... done.
> Booting the kernel.
>
> Now I'm wondering how that buffer came to be.
>
> In any event, some tracing of the code suggests that I have
> vga_video_type == VIDEO_TYPE_CGA, and that fails "if (vga_video_type <
> VIDEO_TYPE_EGAM)" in vgacon_font_set.
>
> Indeed, /proc/ioports has:
>
>   03d4-03d5 : cga
>
> and dmesg says:
>
> [    0.000000] Console: colour *CGA 80x25
>
> I don't see this information in sysfs anywhere.  Perhaps checking for
> an active console and detecting -EINVAL from vgacon_font_get would
> work.

Hmm, yeah, maybe we could try one of the font-related ioctls to find
out if the driver supports that before we spawn setfont.

> /proc/fb is empty on this VM, so maybe that would help.  Grr, this
> stuff is really old and crufty.
>
> The offending qemu command line args appear to be -vga none -display
> none.  I assume I have "CGA" because it's the fallback case in
> vgacon.c if nothing matches.

Hehe, blast from the past. :) If you give kvm a VGA device, it all works fine?

Kay

Re: [kbd] [systemd-devel] systemd-vconsole-setup fails very slowly

[Andy Lutomirski]

On Wed, Apr 1, 2015 at 2:36 PM, Kay Sievers <kay@vrfy.org> wrote:
> On Wed, Apr 1, 2015 at 11:19 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>> On Wed, Apr 1, 2015 at 1:53 PM, Kay Sievers <kay@vrfy.org> wrote:
>>> On Wed, Apr 1, 2015 at 10:45 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>>>> On Apr 1, 2015 12:56 PM, "Kay Sievers" <kay@vrfy.org> wrote:
>>>
>>>>> 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.
>>>
>>> We check the existence of the corresponding /dev/vcs%i, to check if
>>> the tty is allocated where we want to apply the font to. Do these
>>> devices exist on the running machine?
>>
>> Yes:
>>
>> # ls /dev/vcs*
>> /dev/vcs   /dev/vcs2  /dev/vcs4  /dev/vcsa1  /dev/vcsa3
>> /dev/vcs1  /dev/vcs3  /dev/vcsa  /dev/vcsa2  /dev/vcsa4
>>
>> Looking at the code, the vc_screen.c code seems to create those
>> devices unconditionally.
>
> They should only get created when something accesses the corresponding
> tty. deallocvt(1) can kill unused ones and the device nodes should
> disappear.
>

deallocvt doesn't seem to kill those device nodes for me.

>>> And what does this say?
>>>   grep . /sys/class/tty/tty0/active /sys/class/tty/console/active
>>
>> # grep . /sys/class/tty/tty0/active /sys/class/tty/console/active
>> /sys/class/tty/tty0/active:tty1
>> /sys/class/tty/console/active:ttyS0
>>
>> vcs1 has, roughly:
>>
>> early console in decompress_kernel
>> Decompressing Linux... Parsing ELF... done.
>> Booting the kernel.
>>
>> Now I'm wondering how that buffer came to be.
>>
>> In any event, some tracing of the code suggests that I have
>> vga_video_type == VIDEO_TYPE_CGA, and that fails "if (vga_video_type <
>> VIDEO_TYPE_EGAM)" in vgacon_font_set.
>>
>> Indeed, /proc/ioports has:
>>
>>   03d4-03d5 : cga
>>
>> and dmesg says:
>>
>> [    0.000000] Console: colour *CGA 80x25
>>
>> I don't see this information in sysfs anywhere.  Perhaps checking for
>> an active console and detecting -EINVAL from vgacon_font_get would
>> work.
>
> Hmm, yeah, maybe we could try one of the font-related ioctls to find
> out if the driver supports that before we spawn setfont.
>
>> /proc/fb is empty on this VM, so maybe that would help.  Grr, this
>> stuff is really old and crufty.
>>
>> The offending qemu command line args appear to be -vga none -display
>> none.  I assume I have "CGA" because it's the fallback case in
>> vgacon.c if nothing matches.
>
> Hehe, blast from the past. :) If you give kvm a VGA device, it all works fine?

I just tried it.  setfont succeeds, and the VGA device matches
/dev/vcs's contents.

--Andy

Re: [kbd] [systemd-devel] systemd-vconsole-setup fails very slowly

[Kay Sievers]

On Wed, Apr 1, 2015 at 11:38 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> On Wed, Apr 1, 2015 at 2:36 PM, Kay Sievers <kay@vrfy.org> wrote:

>> They should only get created when something accesses the corresponding
>> tty. deallocvt(1) can kill unused ones and the device nodes should
>> disappear.
>>
>
> deallocvt doesn't seem to kill those device nodes for me.

Seems to work here:

# ls -l /dev/vcs[6789]
crw-rw---- 1 root tty 7, 6 Apr  1 22:21 /dev/vcs6
# cat /dev/tty7
^C
# cat /dev/tty9
^C
# ls -l /dev/vcs[6789]
crw-rw---- 1 root tty 7, 6 Apr  1 22:21 /dev/vcs6
crw-rw---- 1 root tty 7, 7 Apr  1 23:42 /dev/vcs7
crw-rw---- 1 root tty 7, 9 Apr  1 23:42 /dev/vcs9
# deallocvt 7
# ls -l /dev/vcs[6789]
crw-rw---- 1 root tty 7, 6 Apr  1 22:21 /dev/vcs6
crw-rw---- 1 root tty 7, 9 Apr  1 23:42 /dev/vcs9
# deallocvt 9
# ls -l /dev/vcs[6789]
crw-rw---- 1 root tty 7, 6 Apr  1 22:21 /dev/vcs6

>>> The offending qemu command line args appear to be -vga none -display
>>> none.  I assume I have "CGA" because it's the fallback case in
>>> vgacon.c if nothing matches.
>>
>> Hehe, blast from the past. :) If you give kvm a VGA device, it all works fine?
>
> I just tried it.  setfont succeeds, and the VGA device matches
> /dev/vcs's contents.

Ah, nice.

If we figure out some dummy font-related call to check if the kernel
supports font handling at all, we could just add that to
vconsole-setup, I guess.

Kay

Re: [kbd] [systemd-devel] systemd-vconsole-setup fails very slowly

[Andy Lutomirski]

On Wed, Apr 1, 2015 at 2:47 PM, Kay Sievers <kay@vrfy.org> wrote:
> On Wed, Apr 1, 2015 at 11:38 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>> On Wed, Apr 1, 2015 at 2:36 PM, Kay Sievers <kay@vrfy.org> wrote:
>
>>> They should only get created when something accesses the corresponding
>>> tty. deallocvt(1) can kill unused ones and the device nodes should
>>> disappear.
>>>
>>
>> deallocvt doesn't seem to kill those device nodes for me.
>
> Seems to work here:
>
> # ls -l /dev/vcs[6789]
> crw-rw---- 1 root tty 7, 6 Apr  1 22:21 /dev/vcs6
> # cat /dev/tty7
> ^C
> # cat /dev/tty9
> ^C
> # ls -l /dev/vcs[6789]
> crw-rw---- 1 root tty 7, 6 Apr  1 22:21 /dev/vcs6
> crw-rw---- 1 root tty 7, 7 Apr  1 23:42 /dev/vcs7
> crw-rw---- 1 root tty 7, 9 Apr  1 23:42 /dev/vcs9
> # deallocvt 7
> # ls -l /dev/vcs[6789]
> crw-rw---- 1 root tty 7, 6 Apr  1 22:21 /dev/vcs6
> crw-rw---- 1 root tty 7, 9 Apr  1 23:42 /dev/vcs9
> # deallocvt 9
> # ls -l /dev/vcs[6789]
> crw-rw---- 1 root tty 7, 6 Apr  1 22:21 /dev/vcs6

Aha.  It seems that I have something holding tty1-tty4 open.  I'll fix
that on my end.  Will that make vconsole-setup stop calling setfont?
If so, that will indirectly solve my problem.  (Although... I don't
see why the presence or absence of in-use vts should affect font
loading.  Also, it seems like vcs1 shows up no matter what I do.)

>
>>>> The offending qemu command line args appear to be -vga none -display
>>>> none.  I assume I have "CGA" because it's the fallback case in
>>>> vgacon.c if nothing matches.
>>>
>>> Hehe, blast from the past. :) If you give kvm a VGA device, it all works fine?
>>
>> I just tried it.  setfont succeeds, and the VGA device matches
>> /dev/vcs's contents.
>
> Ah, nice.
>
> If we figure out some dummy font-related call to check if the kernel
> supports font handling at all, we could just add that to
> vconsole-setup, I guess.
>
> Kay



-- 
Andy Lutomirski
AMA Capital Management, LLC

Re: [kbd] [systemd-devel] systemd-vconsole-setup fails very slowly

[Kay Sievers]

On Thu, Apr 2, 2015 at 12:00 AM, Andy Lutomirski <luto@amacapital.net> wrote:
> On Wed, Apr 1, 2015 at 2:47 PM, Kay Sievers <kay@vrfy.org> wrote:
>> On Wed, Apr 1, 2015 at 11:38 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>>> On Wed, Apr 1, 2015 at 2:36 PM, Kay Sievers <kay@vrfy.org> wrote:
>>
>>>> They should only get created when something accesses the corresponding
>>>> tty. deallocvt(1) can kill unused ones and the device nodes should
>>>> disappear.
>>>>
>>>
>>> deallocvt doesn't seem to kill those device nodes for me.
>>
>> Seems to work here:
>>
>> # ls -l /dev/vcs[6789]
>> crw-rw---- 1 root tty 7, 6 Apr  1 22:21 /dev/vcs6
>> # cat /dev/tty7
>> ^C
>> # cat /dev/tty9
>> ^C
>> # ls -l /dev/vcs[6789]
>> crw-rw---- 1 root tty 7, 6 Apr  1 22:21 /dev/vcs6
>> crw-rw---- 1 root tty 7, 7 Apr  1 23:42 /dev/vcs7
>> crw-rw---- 1 root tty 7, 9 Apr  1 23:42 /dev/vcs9
>> # deallocvt 7
>> # ls -l /dev/vcs[6789]
>> crw-rw---- 1 root tty 7, 6 Apr  1 22:21 /dev/vcs6
>> crw-rw---- 1 root tty 7, 9 Apr  1 23:42 /dev/vcs9
>> # deallocvt 9
>> # ls -l /dev/vcs[6789]
>> crw-rw---- 1 root tty 7, 6 Apr  1 22:21 /dev/vcs6
>
> Aha.  It seems that I have something holding tty1-tty4 open.  I'll fix
> that on my end.  Will that make vconsole-setup stop calling setfont?

Oh, no. That was just in reply to the "vc_screen.c code seems to create those
devices unconditionally". These devices should all be fully dynamic,
handled inside the kernel. It will not influence the setfont behavior
of vconsole-setup.

To fix your issue, setfont should be changed, or we find and add some
dummy font-related ioctl to vconsole-setup, to check if setfont would
fail anyway on the current VT and we skip it.

Kay

Re: [kbd] [systemd-devel] systemd-vconsole-setup fails very slowly

[Alexey Gladkov]

01.04.2015 21:56, Andy Lutomirski пишет:
> On Thu, Jan 22, 2015 at 6:29 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>> On Thu, Jan 22, 2015 at 6:13 PM, Lennart Poettering
>> <lennart@poettering.net> wrote:
>>> On Wed, 21.01.15 19:15, Andy Lutomirski (luto@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?

I answered:

http://lists.altlinux.org/pipermail/kbd/2015-January/000512.html

once again:

Sure. I'll add way to turn it off.

By the way, I planning to rewrite the setfont in library. Just like a
loadkeys has been rewritten in to library.

-- 
Rgrds, legion

Re: [kbd] [systemd-devel] systemd-vconsole-setup fails very slowly

[Alexey Gladkov]

23.01.2015 05:29, Andy Lutomirski пишет:
> 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?

Andy, can you check master branch ?

http://git.altlinux.org/people/legion/packages/kbd.git

-- 
Rgrds, legion

Re: [kbd] [systemd-devel] systemd-vconsole-setup fails very slowly

[Andy Lutomirski]

On Mon, Apr 6, 2015 at 2:48 PM, Alexey Gladkov <gladkov.alexey@gmail.com> wrote:
> 23.01.2015 05:29, Andy Lutomirski пишет:
>> 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?
>
> Andy, can you check master branch ?
>
> http://git.altlinux.org/people/legion/packages/kbd.git

Seems to work for me (i.e. it fails immediately in my setup).  Thanks!

--Andy

>
> --
> Rgrds, legion
>



-- 
Andy Lutomirski
AMA Capital Management, LLC