оборачивается тем что kacpid с аппетитом кушает процессор (у него кстати NICE -5)
впрочем по дате видно что последний раз подобное счастье привалило 21 сентября,
после чего было назначено лечение в виде acpi_osi=Linux , как ни странно, помогло
ну, с одной стороны поломали сенсоры в 31 ом ядре. но гугль лично мине помог и заюзав другой модуль под асус я в итоге получил более точные данные от сенсоров (остальным не так сильно повезло)
2. еще важны изменения в алсе , но у гентушников эти проблемы можно просто решить
3 черт меня дернул заюзать ACCEPT_KEYWORDS (вроде так) , вот тепреь больше зависим от нового ядра (никаких проблем с удев"ом или еще чем не наблюдалось при сборке)
$ uname -a Linux anTaRes[CLD] 2.6.31 #5 PREEMPT Fri Sep 11 09:31:14 EEST 2009 x86_64 AMD Athlon(tm) 64 Processor 3500+ AuthenticAMD GNU/Linux
Здесь, в принципе, как раз все понятно: тогда и железяк столько не надо было поддерживать. И исходников было не 300 мегабайт. Может, стабильный ядреный API это нонсенс, но, например, отрефакторив свой драйвер, без поллитры остальной код шерстить как-то страшно даже...
А когда меняется вообще инфраструктура для семейства устройств, типа того же USB или SCSI... Песня... > а почему я должна читать коммиты и выбирать оттуда патчи? неужели ядро до сих пор пишут красноглазые пионеры в сарае на коленке?
С багами, которые вылазят -- я бы сказал "лучше бы его и дальше писали эти самые пионеры". Пионер понимает, что он маленький человек, и строить структуру-хрен-поймешь не станет. Ему с этим работать, простите. И зачастую он сильно заинтересован, чтобы работало, потому что он не железки впаривает, а, например, музыкант или врач по основной профессии и ему железка как инструмент нужна. IBM же, Intel'у какому-нить это видится по-другому -- отдел уволим, отдел наймем, подумашь важность, главное, чтобы железяки продавались и контракты подписывались.
Ух ты. Вот за это я бы разрабам что-то обрезал -- kernel_lock.c с версии еще 2.6.26 на помойку хотят выбросить, но из-за таких авторов криворуких, не спешащих починить свои подсистемы и драйвера, и не выбрасывают. :-(
>> а почему я не могу просто взять ванильное ядро? почему мне нужно расчитывать на то , что кто-то будет исправлять за Л.Торвальдсом Г.Кроа-Хартманном?
а смысл? например: мне нужен regular security audit, app armor, reiser4, bootsplash (а не тупой busybox бубунты со товарищи) - и я это имею как в .27, так и в .30, а ежели чего надо и влом самому фиксить - "пинаю" товарищей из SuSE/Novell ещё со стадии тестирования ядра для нового релиза дистрибутива. аналогично и с ПО. сравнивая SuSE-.27 с vanilla .30 не вижу преимуществ у .30 (ибо самому влом патчить на предмет apparmor), а по скорости и т.д. - оно вроде как одинаково. >> Кто там кстати майнтейнер подсистемы ACPI ?
где-то с 2003-го года это Len Brown (lenb-гав-kernel-дот-org) (vim MAINTAINERS) - что мешает нормально и конструктивно обсудить недоразумения, а не выставлять претензии на ЛОР-е? >> Можно вполне понять К.Коливаса, который просто взял и выкинул планировщик и переписал заново ) Еще бы ACPI также )
вполне, но тот же bfs у меня не дал никакого ощутимого выигрыша перед cfq, чтобы регулярно заморачиваться с пересборкой.
У меня другое железо, и упса этого нет. Не могу я за Сильви репорты слать, за них же ж и отвечать надо :-)
Но вполне понятно, что там не так: драйвер делает разлочку ядра, не залочив его, или разлочивает на один раз больше. Кто это делает - не знаю, не умею я этти упсы читать, и бэктрейса не видно.
а в багзилле ядра вообще читают багрепорты? а то я повесила 2 бага в gcc (пусть не с идеальным оформлением) и 1 в вайн, мне кажется что нигде вообще их даже не смотрели...
Сильви, так всегда. Мне до сих пор приходят письма с предолжением подтвердить баг из КДЕшной рассылки. Хотя запостил я их пол года назад. А штук двадцать вообще никто не смотрел.
Придётся подождать. Либо откатиться на рабочее ядро..
Лучше бы ты их писал - скорее всего о подобных багах ещё не знают. Часть исправят быстро, ещё часть - в течении пары месяцев. А оставшееся.. ную польза точно будет)