August 29th, 2011

404

bisect

... Внезапно упрощается, потому что в 3.0-rc6 проблемы ещё не было 6.9-7.2 Вт, что после выключения винта как раз в 6.1 и превращается.

Теперь вопрос: а проблема вообще в ядре? Я помню, оно меня что-то про APCI4 спрашивало при конфигурации.

Сейчас для чистоты эксперимента ещё раз стабильное 3.0 соберу, если там при дефолтных ответах на новые фичи PM будет низким, значит, нужно в опциях разбираться (и значит, что в onieric кривой конфиг, т.к. я начинал с дефолтного тестинга убунты - с 3.0.8).

PS Я так и не разобрался с устройством каталогов на kernel.org. Насколько я понял, они физически копируют репозиторий для каждой стабильной ветки. Потому что я не нашёл стабильных фиксов в основном дереве и не нашёл фиксов "соседних" версий в стабильных репозиториях для отдельных версий.

Так что: wget http://www.kernel.org/pub/linux/kernel/v3.0/linux-3.0.3.tar.bz2 -O -|tar -xjf -


PPS Кстати, я подумал о передключателе раскладки и решил оставить все три (Caps, Alt-Shift, Ctrl-Shift). Если оно с хоткеями инкскейпа/rdesktop драться не будет, так и оставлю.
404

bisect

Итого, вердикт: 3.0-rc6 бага не содержит, 3.0.3 - однозначно содержит (собирал с одинаковым конфигом). У 3.0.3 потребление 13.5Вт, и это не бага с чтением регистров - потребление вполне ощущается как весьма тёплый воздух из кулера (в сравнении с совершенно прохладным при 6Вт у 3.0-rc6 и более ранних).

Теперь нужно собрать 3.0 (из develop ветки) - это укажет по каким коммитам нужно шариться - фиксов stable или между rc6 - 3.0.


PS Потребление по мере остановки компонент падает примерно как в старых версиях, но почти в два раза больше - у обычной оно падает с 7.5 до 6.2-6.0, а тут - с 14.5 до 13.4-13.6Вт. Кулер тоже затихает, но воздух идёт явно теплее.
404

онгоинг Carnival Phantasm

Часть до опенинга была настолько охренительная, что я хотел уже писать all hail, то опенинг совсем дейтсимовский, так что я совсем в сомнениях. Только шафтовские точеченые бэкграунды чуть-чуть заметны.

Ещё странно напрягает количество сейю, пересекающееся с Гиассом.


Дальше там, конечно, не тупой дейтсим начинается (кстати, после ore tachi tsubasa ga nai говорить "тупой дейтсим" даже как-то и неприлично), какая-то художественная активность есть, но особо не впечатляет.

Если бы у них были бы более хардкорные шутки, не важно, анимешные, или, там игровые, было бы веселее. А пока несколько плоско, по стилю близко к неотаканутым сериям Macademi Wasshoi.
404

тезукизм

ARR тут разродилось первой серией skyers 5. (1971). Очень остро ощущается тедзукизм того времени. Хотя уже (вроде бы) семидесятые, но пластика всё местами всё ещё избыточна. Местами уже нет, естественная экономия приводит к выкидыванию мусора в фреймах, но анимация движений всё ещё основывается на последовательности кадров.

... Кстати, любопытно, потому что в своё время наруто так сильно поразил общественность именно невероятно тщательной пластикой движений, что было крайне нехарактерно для того времени (примерно 2000ый, вроде?) - почти вся анимация 90ых строилась на полном отказе от лишей пластики, на описании движения через его окружение (реакции, лица, эмоции, последствия и т.д.).

Таким образом, в тот момент в Наруте слились два направления - показ и "результата" (великолепные в застывшей динамике позы) - и показ самой динамики, самой анимации.

Но как показывает сравнение современного диснея с современным аниме - стиллфреймы лучше, чем пластика без них. (или я тут слишком субъективен?). Пластика при плохих still frame'ах или в их отсутствие теряется, размазывается. И совершенно не важно, сколько кадров в движении, если зрителю не показали смысла - то движение потеряно.

Кстати, skyers5 - как раз очень интересный переходный момент - местами пихают динамику, местами держат статику с стилфреймами. Немного беспорядочно, правда.
404

powersave && linux

Итак:

3.0.0-rc6 - проблемы нет
3.0 - проблема есть.

Обе ветки из девелоп-ветки (в стабильных ситуация такая: 2.6.39 проблемы нет, 3.0 - есть, в 3.1-rc3 проблема есть).

Суть проблемы: двухкратное поедание электричества в standby.

Перед началом шарения по коммитам остаётся таг 3.0-rc7. Думаю, там будет коммитов 200 между версиями, это меньше 8 итераций для бинарного дерева...
404

bisect

Отлично, баги нет в 3.0-rc7, она появилась где-то между 3.0-rc7 и 3.0 (релизом).

Таким образом, мы имеем весьма ограниченный набор коммитов.


commit: 620917de59eeb934b9f8cf35cc2d95c1ac8ed0fc - простановка тэга 3.0-rc7, коммит 02f8c6aee8df3cdc935e9bdd4f2d020306035dbe - тег 3.0.

git log v3.0-rc7..v3.0 --pretty=%H|wc -l
189

двоичный логарифм - 5.2, то есть с 5-6 попытки я точно уткнусь в нужный мне коммит...

ЗЫ Мельком глянул на экран - 5.9Вт. Внезапно, новый рекорд. (за разумный рекорд не засчитывается, потому что я ничего специально не тюнил).

PPS Если что, это ещё будет отличным упражнением по real-life git.


Начало bisect (не знаю, то ли имеется в виду в git bisect):

git log v3.0-rc7..v3.0 --oneline|head -n $((189/2))|tail -n 1
4d2b295 ACPI, APEI, HEST, Detect duplicated hardware error source ID

Ща поставлю собираться (надеюсь, оно там, в промежутках, собирабельное).

ЗЗЗЗЫ прочитал-таки про git bisect, кажется, это оно, заканчиваем шелл-эквилибристику.
404

(no subject)

Пока собирал бисектовый образ, сумел подвесить GPU:

[ 5217.220147] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung
[ 5217.220168] [drm] capturing error event; look for more information in /debug/dri/0/i915_error_state
[ 5217.241814] [drm:i915_wait_request] *ERROR* i915_wait_request returns -11 (awaiting 2177323 at 2177317, next 2177324)


Я это делал на 3.0-rc7, так что жаловаться на глючное... (железо/драйвера?) явно не приходится...

Что радует - при зависшем GPU работает переключение в фреймбуфер (и обратно!). Картинга в гуе не двигается, конечно, но и не уходит в непонятное чёрное...

Итак, первый бисект: бага есть - 14.3Вт (то есть добавили её в первую половину коммитов). Возможно, стоит посмотреть на это глазками... там есть какой-то коммит "pm-fixes", возможно, дело в нём. Пробую собрать предшествующий ему...