Исходное сообщение
"Выпущен второй кандидат в релизы ядра Linux 3.9" Отправлено pavlinux, 13-Мрт-13 05:03
РедХат поломал фреймбуферную консоль, закрывая глюки systemd!!! commit b6f84cb8ce3aa61f0b9ee8e72f8a0b5a3003cd9c Author: Dave Airlie <airlied@redhat.com> Date:   Thu Jan 24 16:12:41 2013 +1000     fbcon: don't lose the console font across generic->chip driver switch          commit ae1287865f5361fa138d4d3b1b6277908b54eac9 upstream.          If grub2 loads efifb/vesafb, then when systemd starts it can set the console     font on that framebuffer device, however when we then load the native KMS     driver, the first thing it does is tear down the generic framebuffer driver.          The thing is the generic code is doing the right thing, it frees the font     because otherwise it would leak memory. However we can assume that if you     are removing the generic firmware driver (vesa/efi/offb), that a new driver     *should* be loading soon after, so we effectively leak the font.          However the old code left a dangling pointer in vc->vc_font.data and we     can now reuse that dangling pointer to load the font into the new     driver, now that we aren't freeing it. [сообщение отредактировано модератором]

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	> РедХат поломал фреймбуферную консоль, закрывая глюки systemd!!! > commit b6f84cb8ce3aa61f0b9ee8e72f8a0b5a3003cd9c > Author: Dave Airlie <airlied@redhat.com> > Date: Thu Jan 24 16:12:41 2013 +1000 > fbcon: don't lose the console font across generic->chip > driver switch > commit ae1287865f5361fa138d4d3b1b6277908b54eac9 upstream. > If grub2 loads efifb/vesafb, then when systemd starts > it can set the console > font on that framebuffer device, however when we > then load the native KMS > driver, the first thing it does is tear > down the generic framebuffer driver. > The thing is the generic code is doing > the right thing, it frees the font > because otherwise it would leak memory. However we > can assume that if you > are removing the generic firmware driver (vesa/efi/offb), that > a new driver > *should* be loading soon after, so we effectively > leak the font. > However the old code left a dangling pointer > in vc->vc_font.data and we > can now reuse that dangling pointer to load > the font into the new > driver, now that we aren't freeing it. > [сообщение отредактировано модератором]
	Введите код, изображенный на картинке: