"Ночные" сборки KolibriOS
-
mutex_unlock проще объявить не меняющей edx, тем более что в ветке kolibri-acpi Serge поправил код. Намного опаснее ситуация с mutex_lock, которая иногда меняет edx - в принципе конвенция вызова gcc fastcall, которой следует mutex_lock, это разрешает, но не все правки r2129 это учитывают.Сделаем мир лучше!
Все равно падает ZEROCONF
З.Ы. К тому же падают KFM, KFAR и Eolite при попытке прочитать /bdX/X/ диски, раньше чем соответствующие директории были прочитаны как /hdX/X/
UPD. Впрочем последнее произошло с ревизий 2112-2113.
З.Ы. К тому же падают KFM, KFAR и Eolite при попытке прочитать /bdX/X/ диски, раньше чем соответствующие директории были прочитаны как /hdX/X/
UPD. Впрочем последнее произошло с ревизий 2112-2113.
Проблемы в socket.inc я поправила в r2147. Проблемы с доступом через BIOS ни к моим изменениям, ни к r2129 отношения не имеют, падение происходит в v86_exc_c.exit.
Сделаем мир лучше!
Спасибо, теперь буду ждать реакции Сергея.
каким образом ядро узнает что добавленый диск не является копиеей уже существующего диска в списке дисков ядра? (какие критерии - пояснение для DummyMouse)CleverMouse wrote:ilya, любой добавленный диск уникален
Через какое ID ядро обращается к диску который сидит на каком нибудь контроллере (типа IDE или друой) ? Каким образом драйвер или ядро узнают это ID? В какое время?
Жду ответов, так как они непосредственно влияют на API
Mario
Исправил /bd/ в 2149.
Исправил /bd/ в 2149.
Спасибо. Теперь порядок.
Вот такая вот ошибочка (во всех ФМ). Кстати, при обращении к определённым файлам на флешке комп зависает, чего не было до этого. Причина в последних изменениях, если что могу потестить... через 4 дня.
Из хаоса в космос
Всё проще - ошибка возникает при попытке запуска непрограммы, например, menu.dat. Код ошибки должен был бы быть 31, вроде бы.
Из хаоса в космос
Исправил.
С ревизии 2129 сломана процедура kernel_free в trunk/core/heap.inc
Столкнулся при вызове функции 15.1 - старый кусок памяти выделенный под фоновое изображение не возвращается системе. Хорошо заметно на больших по размеру изображениях. В результате постоянная утечка памяти.
Столкнулся при вызове функции 15.1 - старый кусок памяти выделенный под фоновое изображение не возвращается системе. Хорошо заметно на больших по размеру изображениях. В результате постоянная утечка памяти.
Mario В последней ревизии тоже ?
Ядро 2157. Открываем в KIV картинку, начинаем кликать кнопку установки фона и можно наблюдать, например, в GMON, как утекает память.
Ночная сборка 2161.
Ночная сборка 2161.
Исправил.
Спасибо. Теперь порядок.
Who is online
Users browsing this forum: No registered users and 12 guests