Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #176974 > unrolled thread

Early boot became slower

Back to article view | Back to linux.debian.user

Contents

  Early boot became slower Mattia Oss <mais.toast@gmail.com> - 2017-01-24 17:20 +0100
    Re: Early boot became slower Sven Joachim <svenjoac@gmx.de> - 2017-01-24 17:40 +0100
      Re: Early boot became slower Mattia Oss <mais.toast@gmail.com> - 2017-01-24 18:10 +0100
        Re: Early boot became slower Mattia Oss <mais.toast@gmail.com> - 2017-01-25 16:30 +0100
          Re: Early boot became slower Sven Joachim <svenjoac@gmx.de> - 2017-01-25 20:40 +0100
            Re: Early boot became slower Mattia Oss <mais.toast@gmail.com> - 2017-01-26 18:50 +0100
              Re: Early boot became slower Felix Miata <mrmazda@earthlink.net> - 2017-01-26 20:20 +0100
                Re: Early boot became slower Mattia Oss <mais.toast@gmail.com> - 2017-01-27 01:40 +0100
                  Re: Early boot became slower Felix Miata <mrmazda@earthlink.net> - 2017-01-27 10:20 +0100
                    Re: Early boot became slower Mattia Oss <mais.toast@gmail.com> - 2017-01-27 18:00 +0100
                      Re: Early boot became slower Felix Miata <mrmazda@earthlink.net> - 2017-01-27 19:10 +0100
                      Re: Early boot became slower Lisi Reisz <lisi.reisz@gmail.com> - 2017-01-27 20:20 +0100
                        Early boot became slower Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.com> - 2017-01-30 10:10 +0100
                          Re: Early boot became slower Felix Miata <mrmazda@earthlink.net> - 2017-01-30 11:30 +0100
                            Early boot became slower Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.com> - 2017-01-30 23:50 +0100
                              Re: Early boot became slower Felix Miata <mrmazda@earthlink.net> - 2017-01-31 01:00 +0100
                              Re: Early boot became slower David Wright <deblis@lionunicorn.co.uk> - 2017-01-31 04:00 +0100
                                Re: Early boot became slower deloptes <deloptes@gmail.com> - 2017-01-31 18:30 +0100
                      Re: Early boot became slower deloptes <deloptes@gmail.com> - 2017-01-27 22:10 +0100
                        Re: Early boot became slower Mattia Oss <mais.toast@gmail.com> - 2017-01-28 18:20 +0100
                          Re: Early boot became slower deloptes <deloptes@gmail.com> - 2017-01-28 23:00 +0100
                          Re: Early boot became slower Felix Miata <mrmazda@earthlink.net> - 2017-01-28 23:10 +0100
              Re: Early boot became slower deloptes <deloptes@gmail.com> - 2017-01-26 20:50 +0100

Page 1 of 2  [1] 2  Next page →

#176974 — Early boot became slower

Hi all,

since linux-image-4.8.0-2-amd64 the early phase of my booting process
became slower (~10 secs). I think that it has to do with the
framebuffer. This is the only relevant difference in dmesg:

4.8.0-1-amd64:
simple-framebuffer simple-framebuffer.0: framebuffer at 0xe0000000, 0x7e9000 bytes, mapped to 0xffffc1e201000000
simple-framebuffer simple-framebuffer.0: format=x8r8g8b8, mode=1920x1080x32, linelength=7680
simple-framebuffer simple-framebuffer.0: fb0: simplefb registered!
fb: switching to radeondrmfb from simple

4.9.0-1-amd64:
vesafb: framebuffer at 0xe0000000, mapped to 0xffffb23701800000, using 8128k, total 8128k
vesafb: mode is 1920x1080x32, linelength=7680, pages=0
vesafb: scrolling: redraw
vesafb: Truecolor: size=0:8:8:8, shift=0:16:8:0
fb: switching to radeondrmfb from VESA VGA

I see that CONFIG_FB_SIMPLE is not set anymore. Is that a reason for
that? Any way to fix this without recompiling?


Thanks in advance,
Mattia

[toc] | [next] | [standalone]

#176980

On 2017-01-24 17:13 +0100, Mattia Oss wrote:

> since linux-image-4.8.0-2-amd64 the early phase of my booting process
> became slower (~10 secs). I think that it has to do with the
> framebuffer. This is the only relevant difference in dmesg:
>
> 4.8.0-1-amd64:
> simple-framebuffer simple-framebuffer.0: framebuffer at 0xe0000000, 0x7e9000 bytes, mapped to 0xffffc1e201000000
> simple-framebuffer simple-framebuffer.0: format=x8r8g8b8, mode=1920x1080x32, linelength=7680
> simple-framebuffer simple-framebuffer.0: fb0: simplefb registered!
> fb: switching to radeondrmfb from simple
>
> 4.9.0-1-amd64:
> vesafb: framebuffer at 0xe0000000, mapped to 0xffffb23701800000, using 8128k, total 8128k
> vesafb: mode is 1920x1080x32, linelength=7680, pages=0
> vesafb: scrolling: redraw
> vesafb: Truecolor: size=0:8:8:8, shift=0:16:8:0
> fb: switching to radeondrmfb from VESA VGA
>
> I see that CONFIG_FB_SIMPLE is not set anymore. Is that a reason for
> that?

Apparently the handover to the KMS framebuffer from simplefb does not
work for all drivers[1].

> Any way to fix this without recompiling?

Try not to load vesafb in the first place.  Which bootloader do you use?

Cheers,
       Sven


1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822575

[toc] | [prev] | [next] | [standalone]

#176982

On Tue, Jan 24, 2017 at 05:36:58PM +0100, Sven Joachim wrote:
> On 2017-01-24 17:13 +0100, Mattia Oss wrote:
> > I see that CONFIG_FB_SIMPLE is not set anymore. Is that a reason for
> > that?
> 
> Apparently the handover to the KMS framebuffer from simplefb does not
> work for all drivers[1].

Thanks for the info.

> > Any way to fix this without recompiling?
> 
> Try not to load vesafb in the first place.  Which bootloader do you use?

I use grub2. I tried the "text" kernel parameter: it works but it
obviously isn't what I was looking for.


> 1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822575
> 

[toc] | [prev] | [next] | [standalone]

#176997

On Tue, Jan 24, 2017 at 05:59:42PM +0100, Mattia Oss wrote:
> On Tue, Jan 24, 2017 at 05:36:58PM +0100, Sven Joachim wrote:
> > On 2017-01-24 17:13 +0100, Mattia Oss wrote:
> > > Any way to fix this without recompiling?
> > 
> > Try not to load vesafb in the first place.  Which bootloader do you use?
> 
> I use grub2. I tried the "text" kernel parameter: it works but it
> obviously isn't what I was looking for.

I tried with video=vesafb:off but it doesn't seem to work. I've 
recompiled the kernel without vesafb but I get a blank screen (only at 
the early phase). 
I'm open to any suggestion...

[toc] | [prev] | [next] | [standalone]

#177001

On 2017-01-25 16:26 +0100, Mattia Oss wrote:

> On Tue, Jan 24, 2017 at 05:59:42PM +0100, Mattia Oss wrote:
>> On Tue, Jan 24, 2017 at 05:36:58PM +0100, Sven Joachim wrote:
>> > On 2017-01-24 17:13 +0100, Mattia Oss wrote:
>> > > Any way to fix this without recompiling?
>> > 
>> > Try not to load vesafb in the first place.  Which bootloader do you use?
>> 
>> I use grub2. I tried the "text" kernel parameter: it works but it
>> obviously isn't what I was looking for.
>
> I tried with video=vesafb:off but it doesn't seem to work. I've 
> recompiled the kernel without vesafb but I get a blank screen (only at 
> the early phase). 

Does GRUB_GFXPAYLOAD_LINUX=text in /etc/default/grub help?  Don't forget
to run update-grub after changing that file.

> I'm open to any suggestion...

I usually put the graphics driver in the initramfs to load it as early
as possible.

# echo radeon >> /etc/initramfs-tools/modules
# update-initramfs -u

Cheers,
       Sven

[toc] | [prev] | [next] | [standalone]

#177014

On Wed, Jan 25, 2017 at 08:33:16PM +0100, Sven Joachim wrote:
> On 2017-01-25 16:26 +0100, Mattia Oss wrote:
> 
> > On Tue, Jan 24, 2017 at 05:59:42PM +0100, Mattia Oss wrote:
> >> I use grub2. I tried the "text" kernel parameter: it works but it
> >> obviously isn't what I was looking for.
> >
> > I tried with video=vesafb:off but it doesn't seem to work. I've 
> > recompiled the kernel without vesafb but I get a blank screen (only at 
> > the early phase). 
> 
> Does GRUB_GFXPAYLOAD_LINUX=text in /etc/default/grub help?  Don't forget
> to run update-grub after changing that file.

Yes as mentioned above this works but I have HUGE characters.

> > I'm open to any suggestion...
> 
> I usually put the graphics driver in the initramfs to load it as early
> as possible.
> 
> # echo radeon >> /etc/initramfs-tools/modules
> # update-initramfs -u

Thanks for the suggestions. I tried it but still got a blank screen.
At this point I think I'll stay with GRUB_GFXPAYLOAD_LINUX=text. 
At least it's fast.

[toc] | [prev] | [next] | [standalone]

#177016

Mattia Oss composed on 2017-01-26 18:47 (UTC+0100):

> On Wed, Jan 25, 2017 at 08:33:16PM +0100, Sven Joachim wrote:

>> Does GRUB_GFXPAYLOAD_LINUX=text in /etc/default/grub help?  Don't forget
>> to run update-grub after changing that file.

> Yes as mentioned above this works but I have HUGE characters.

For the boot menu, or after?

If after, what gfxchip do you have, maybe something other than NVidia, AMD/ATI 
or Intel? Use 'lspci | grep VGA' or 'inxi -c0 -G' to report here.

Are the "HUGE characters" the same size as you find on the vttys after booting? 
If so, there are a couple of things you could try if you'd rather have smaller 
text characters.

To test, hit the "e" key while your Grub selection is up, then append either any 
of the following before proceeding to boot:

vga=788
vga=791
vga=794
video=1024x768
video=1152x864
video=1280x1024
video=1440x900
video=1600x900
video=1680x1050
video=1920x1080
video=1920x1200

Others are possible, as above is not an exhaustive list.

Grub will report vga= is deprecated, but nevertheless the kernel will at least 
briefly use smaller characters than those used in video BIOS 80x25 mode.

Video= tells the kernel to use the specified mode for the KMS framebuffers. Pick 
a mode that matches your display's native resolution to get the smallest 
possible text.

If one of the above produce a result you like, you can reconfigure Grub to 
include the appendage permanently via /etc/default/grub and regenerating Grub's 
boot menu.
-- 
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

  Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

[toc] | [prev] | [next] | [standalone]

#177021

On Thu, Jan 26, 2017 at 02:18:36PM -0500, Felix Miata wrote:
> 
> For the boot menu, or after?

To clarify I uploaded some videos (sorry for the crappy quality :/ )

linux-image-4.8.0-1-amd64:
https://goo.gl/TsXUBB

This was the last kernel with fast boot. In /etc/default/grub I had:
GRUB_GFXMODE=1920x1080
GRUB_GFXPAYLOAD_LINUX=keep

Since linux-image-4.8.0-2-amd64 the boot process is slower.
linux-image-4.9.0-1-amd64:
https://goo.gl/buOcpj

ok it's not that slow but I think the difference is quite visible.
I said that the problem may be the framebuffer (vesafb/simplefb) only
because this was the only big difference in the 2 dmesg. But it can be
anything.

This is what I used for the moment.
linux-image-4.9.0-1-amd64 with GRUB_GFXPAYLOAD_LINUX=text:
https://goo.gl/16MJgc

> If after, what gfxchip do you have, maybe something other than NVidia,
> AMD/ATI or Intel? Use 'lspci | grep VGA' or 'inxi -c0 -G' to report here.

00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller (rev 06)
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Hawaii XT / Grenada XT [Radeon R9 290X/390X]

> Video= tells the kernel to use the specified mode for the KMS framebuffers.
> Pick a mode that matches your display's native resolution to get the
> smallest possible text.
> 
> If one of the above produce a result you like, you can reconfigure Grub to

I tried with video=1920x1080 but there's no difference. 

[toc] | [prev] | [next] | [standalone]

#177029

Mattia Oss composed on 2017-01-27 01:34 (UTC+0100):

> On Thu, Jan 26, 2017 at 02:18:36PM -0500, Felix Miata wrote:

>> For the boot menu, or after?

> To clarify I uploaded some videos (sorry for the crappy quality :/ )

You haven't answered my question.

> linux-image-4.8.0-1-amd64:
> https://goo.gl/TsXUBB

> This was the last kernel with fast boot. In /etc/default/grub I had:
> GRUB_GFXMODE=1920x1080
> GRUB_GFXPAYLOAD_LINUX=keep

> Since linux-image-4.8.0-2-amd64 the boot process is slower.
> linux-image-4.9.0-1-amd64:
> https://goo.gl/buOcpj

> ok it's not that slow but I think the difference is quite visible.
> I said that the problem may be the framebuffer (vesafb/simplefb) only
> because this was the only big difference in the 2 dmesg. But it can be
> anything.

> This is what I used for the moment.
> linux-image-4.9.0-1-amd64 with GRUB_GFXPAYLOAD_LINUX=text:
> https://goo.gl/16MJgc

None of those play for me. The resolution on the initial screens is so poor that 
I can't make out anything useful except to suggest to remove quiet the splash= 
parameter from the cmdline (or change it to splash=0) and see what happens 
without the graphical background or the output supression.

>> If after, what gfxchip do you have, maybe something other than NVidia,
>> AMD/ATI or Intel? Use 'lspci | grep VGA' or 'inxi -c0 -G' to report here.

> 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller (rev 06)
> 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Hawaii XT / Grenada XT [Radeon R9 290X/390X]

I don't have any AMD gfx that new around here. I have the same Intel gfx as you 
on my newest machine and no problem with any kernel going back all the way to 
when the machine was brand new going on two years ago.

>> Video= tells the kernel to use the specified mode for the KMS framebuffers.
>> Pick a mode that matches your display's native resolution to get the
>> smallest possible text.

>> If one of the above produce a result you like, you can reconfigure Grub to

> I tried with video=1920x1080 but there's no difference.

On those initial video screens I see no evidence of any "huge" characters.
-- 
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

  Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

[toc] | [prev] | [next] | [standalone]

#177037

On Fri, Jan 27, 2017 at 04:14:57AM -0500, Felix Miata wrote:
> Mattia Oss composed on 2017-01-27 01:34 (UTC+0100):
> 
> > On Thu, Jan 26, 2017 at 02:18:36PM -0500, Felix Miata wrote:
> 
> > > For the boot menu, or after?
> 
> > To clarify I uploaded some videos (sorry for the crappy quality :/ )
> 
> You haven't answered my question.

Well, apparently you haven't seen my videos. Anyway: right after the
grub menu.

> None of those play for me. The resolution on the initial screens is so poor

This sentence doesn't make sense. Did you play them or not?
They are 1920x1080 with h264 codec in a Matroska container. I think
that's pretty standard. Which player did you use?

By the way, the point of the videos was to show the entity of the
slowdown and, most importantly, WHEN this occurs. Not to show the output.
If you need the kernel output I will provide it by other means, but
certainly not in a video.

> that I can't make out anything useful except to suggest to remove quiet the
> splash= parameter from the cmdline (or change it to splash=0) and see what
> happens without the graphical background or the output supression.

I don't have the splash or quiet parameter in grub (are you using
ubuntu?) but if I use GRUB_TERMINAL=console or GRUB_GFXPAYLOAD_LINUX=text 
I get a super fast and super ugly output. This can be seen in the 3rd
video. And that's what I'm using right now.

Anyway thanks for the effort, much appreciated. :)

[toc] | [prev] | [next] | [standalone]

#177043

Mattia Oss composed on 2017-01-27 17:56 (UTC+0100):

> On Fri, Jan 27, 2017 at 04:14:57AM -0500, Felix Miata wrote:

>> Mattia Oss composed on 2017-01-27 01:34 (UTC+0100):

>> > On Thu, Jan 26, 2017 at 02:18:36PM -0500, Felix Miata wrote:

>> > > For the boot menu, or after?

>> > To clarify I uploaded some videos (sorry for the crappy quality :/ )

>> You haven't answered my question.

> Well, apparently you haven't seen my videos. Anyway: right after the
> grub menu.

>> None of those play for me. The resolution on the initial screens is so poor

> This sentence doesn't make sense. Did you play them or not?

I clicked the links. The browser opened them, meaning I saw that they were 
videos in whatever player the browser chose to try, and was able to see their 
first frames display. Clicking play produced error messages instead of playback.

> They are 1920x1080 with h264 codec in a Matroska container. I think
> that's pretty standard. Which player did you use?

I chose no player. Normally I don't click anonymous links. I clicked your links 
anyway. I don't watch videos on a PC. That's what I have TVs for. If I click a 
link to a video and it won't play, that's the end of it. I don't try to figure 
out why.

When I ask for information on a mailing list, it's information I want, not a 
video. I have no patience for digging information out of a video.

> I don't have the splash or quiet parameter in grub (are you using
> ubuntu?)
Rarely. I multiboot all my machines with various combinations of Wheezy, Jessie, 
Stretch, Sid, AntiX, openSUSE, Fedora, Mageia, and rarely, Mint, Kubuntu, CentOS 
or Gentoo. All my boot stanzas omit quiet and most contain splash=0. Plymouth is 
only installed on installations where its removal would strip it down into an 
unusable state (e.g. Mageia).

> but if I use GRUB_TERMINAL=console or GRUB_GFXPAYLOAD_LINUX=text
> I get a super fast and super ugly output. This can be seen in the 3rd
> video.
If the video plays. A single image would suffice to answer my question about 
"huge" characters if you cannot find words to do so.
-- 
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

  Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

[toc] | [prev] | [next] | [standalone]

#177048

On Friday 27 January 2017 16:56:32 Mattia Oss wrote:
> This can be seen in the 3rd
> video.

By you.  Not by me - nor apparently by Felix.

Lisi

[toc] | [prev] | [next] | [standalone]

#177129

Mattia Oss:

> This can be seen in the 3rd video.
>
Lisi Reisz:

> By you. Not by me - nor apparently by Felix.
>

It's really simple.  It's the same size monitor.  The "normal" 
characters are high resolution 24-bit colour graphics mode with 8*16 
pixel glyphs, giving 240 columns by 67 rows.  The "huge" characters are 
VGA text mode at 80 columns by 25 rows, giving glyphs that are in effect 
more than 24*32 pixels.

As for why graphics mode has slowed down going from simple-framebuffer 
to vesafb, consider this and its implications:

> vesafb: scrolling: redraw
>

[toc] | [prev] | [next] | [standalone]

#177131

Jonathan de Boyne Pollard composed on 2017-01-30 08:45 (UTC):

> It's really simple.  It's the same size monitor.  The "normal"
> characters are high resolution 24-bit colour graphics mode with 8*16
> pixel glyphs, giving 240 columns by 67 rows.  The "huge" characters are
> VGA text mode at 80 columns by 25 rows, giving glyphs that are in effect
> more than 24*32 pixels.

At what point exactly within either of those videos does 80 by 25 appear? All I 
saw anywhere appeared to be in the vicinity of 240 by 67.

Is there something simpler than 'echo $ROWS $COLUMNS' or 'tput lines';'tput 
cols' to show the row and column count on a vtty one is using? Fbset leaves that 
info out of its report.
-- 
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

  Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

[toc] | [prev] | [next] | [standalone]

#177143

Felix Miata:

> At what point exactly within either of those videos does 80 by 25 
> appear? All I saw anywhere appeared to be in the vicinity of 240 by 67.
>

I think that I have put my finger on the source of your perplexity.  
Remember where M. Oss said the following?

Mattia Oss:

> This can be seen in the 3rd video.
>

There's a third video, and it appears in the third video. It's 
definitely 80*25 VGA text mode in that third video. And just as M. Oss 
said, the text in the third video scrolls fairly briskly and the 
characters are ...


Mattia Oss:

> HUGE characters.
>
... as one would expect with 80 columns by 25 rows on a widescreen 
display of that size.

Now M. Oss and all of you get to play with the different ways that the 
VESA driver can do scrolling. (-:

[toc] | [prev] | [next] | [standalone]

#177148

Jonathan de Boyne Pollard composed on 2017-01-30 22:31 (UTC):

> Felix Miata composed:

>> At what point exactly within either of those videos does 80 by 25
>> appear? All I saw anywhere appeared to be in the vicinity of 240 by 67.

> I think that I have put my finger on the source of your perplexity.
> Remember where M. Oss said the following?

> Mattia Oss:

>> This can be seen in the 3rd video.

> There's a third video, and it appears in the third video. It's
> definitely 80*25 VGA text mode in that third video. And just as M. Oss
> said, the text in the third video scrolls fairly briskly and the
> characters are ...

> Mattia Oss:

>> HUGE characters.

> ... as one would expect with 80 columns by 25 rows on a widescreen
> display of that size.

Now that I've seen that...

> Now M. Oss and all of you get to play with the different ways that the
> VESA driver can do scrolling. (-:

...I reread OP's thread posts and see he has yet to provide us a look at 
/proc/cmdline from a boot that produces (huge text) 80x25 mode. I would like to 
see that before I consider whether to respond further.
-- 
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

  Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

[toc] | [prev] | [next] | [standalone]

#177151

On Mon 30 Jan 2017 at 22:31:28 (+0000), Jonathan de Boyne Pollard wrote:
> Felix Miata:
> 
> >At what point exactly within either of those videos does 80 by 25
> >appear? All I saw anywhere appeared to be in the vicinity of 240
> >by 67.
> 
> I think that I have put my finger on the source of your perplexity.
> Remember where M. Oss said the following?
> 
> Mattia Oss:
> 
> >This can be seen in the 3rd video.
> 
> There's a third video, and it appears in the third video. It's
> definitely 80*25 VGA text mode in that third video.

Yes, there were three videos originally, viz.

16199062 goo-1-line-7-boot-4.8.0-1-amd64.mkv
15994161 goo-2-line-1-boot-4.9.0-1-amd64.mkv
10878351 goo-3-line-1-boot-text-4.9.0-1-amd64.mkv

(though I guess the precise lengths my depend on the software used to
download them?)

But that only translated to two youtube videos, viz.

4587493 you-1-line-7-linux-image-4.8.0-1-amd64.bootvideo-NLWB7FyV7jU.mp4
5927576 you-2-line-4-linux-image-4.8.0-2-amd64.bootvideo-Nc1lgpdgaxQ.mp4

I don't see a low-res period in either of the latter. I suspect the
OP didn't bother with the third video, notwithstanding the discussion
about it. Should I take it that the "HUGE" characters are just a
result of a period at 640x480 resolution?

> And just as M.
> Oss said, the text in the third video scrolls fairly briskly and the
> characters are ...
> 
> Mattia Oss:
> 
> >HUGE characters.
> >
> ... as one would expect with 80 columns by 25 rows on a widescreen
> display of that size.
> 
> Now M. Oss and all of you get to play with the different ways that
> the VESA driver can do scrolling. (-:

But if the OP intended people to attend only to the rate at which
lines appear on the screen, then posting videos at 1920x1080 was
a waste of time for many, because the rate at which the video runs
is a function of the power of the recipient's computer. None of mine
are able to run these videos at all smoothly.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#177182

David Wright wrote:

> a waste of time for many, because the rate at which the video runs
> is a function of the power of the recipient's computer. None of mine
> are able to run these videos at all smoothly

you must be kidding

[toc] | [prev] | [next] | [standalone]

#177053

Mattia Oss wrote:

> 
> Anyway thanks for the effort, much appreciated. :)

Perhaps you should check your plymouth install/setup. I am not ubuntu user.
I was able to see the videos and still, you are shaking and the video is
out of focus, so one can not see where it hangs. I guess it is
trying/hanging intializing the frame buffer. Perhaps you enable timestamp
for boot if not enabled and check your log files to see where it spends
much of the time. I think this is doable with systemd as well, but I am not
very knowledgable how this devil works exactly.

If you have read the changelog to the new 4.9. kernel you should have
noticed that a lot of fixes against intel video driver were pushed. Perhaps
you experience some slow down because one of them and perhaps there is a
fix if you read the documentation of the driver. So a possible solution
would be to check parameters passed to the driver /etc/modprobe.d/...
or you have to create/set the options.

regards

[toc] | [prev] | [next] | [standalone]

#177074

On Fri, Jan 27, 2017 at 10:06:09PM +0100, deloptes wrote:
> Mattia Oss wrote:
> 
> > 
> > Anyway thanks for the effort, much appreciated. :)
> 
> Perhaps you should check your plymouth install/setup. I am not ubuntu user.

[I reply here for everybody]

First of all: ok, uploading to google drive wasn't a good idea. My bad,
apologies. I made new videos and uploaded to youtube, I'll post the links.

But first let me clarify one thing because I fear that there is a big
misunderstanding here: there's no problem with the kernel per se, it
doesn't hang, there are no errors. It just prints the output slowly, or
at least slower than before. I *think* that's related to the framebuffer
(and at this point I'm fairly certain it is, will explain later).

So the point of the videos was *not* to show you the output but to show
you *where* the slowdown occurs: right after the kernel starts.
That's why the quality is not high (ok, maybe also because I suck making
videos...).

So for the ones still interested I'll post some more infos.

Since the problem started with linux-image-4.8.0-2-amd64 I'll compare
4.8.0-1 and 4.8.0-2.

Videos:
4.8.0-1 (fast):
https://www.youtube.com/watch?v=NLWB7FyV7jU

4.8.0-2 (slow):
https://www.youtube.com/watch?v=Nc1lgpdgaxQ

Kernel logs:
4.8.0-1:
https://github.com/maistoast/share/blob/master/kernel/log/4.8.0-1/dmesg_4.8.0-1-amd64

4.8.0-2:
https://github.com/maistoast/share/blob/master/kernel/log/4.8.0-2/dmesg_4.8.0-2-amd64

This is the diff of both changelogs:
https://github.com/maistoast/share/blob/master/kernel/cl/linux-image-4.8.0-amd64-changelog.linux.diff

I saw some reference to radeon but I didn't find anything really useful.

I tried, I think, every suggestions you all gave me. If I don't post
the results it's because it didn't work. For example, plymouth (I don't
have it installed), various kernel options (vga, video, splash, etc...).

BUT, I made a progress. :)
I installed linux-source-4.9 and compiled the kernel with the 4.8.0-1
config. The result: it boots fast! :)

This is the kernel log of the custom kernel:
https://github.com/maistoast/share/blob/master/kernel/log/4.9.2/dmesg_4.9.2--bymattia

As you can see it uses simplefb and not vesafb. I'm quite sure that this
is the problem. As Sven Joachim pointed out, the Debian devs disabled
simplefb because it has problems with KMS framebuffer. Reading the link
he provided they disabled the X86_SYSFB and FB_SIMPLE options to fix
some bugs. I think there's no solution for me because these options are
not enabled in the Debian kernel anymore.. :/ 

Se either I use a custom kernel, or I keep my sweet fat characters with
the Debian kernel.

Thanks,
Mattia.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web