Сообщения об ошибках не помещенные в Bugzilla
-
А ничего удивительного - никто ее и не использовал с момента внедрения.
Микробаг в MTDBG: при первом запуске программы первый нажатый символ всегда воспринимается как пробел. Дальше все норм.
ушёл...
всем привет)
сразу оффтоп
спасибо всем разработчикам за колибри!
когда накрылась вЕнда, мне срочно понадобилось вытащить с жесткого образ. убунта-лайвСД отказалась грузиться, ничем не обосновывая. а с помощью колибри скопировал нужный образ с нтфс на флешку. правда, 600-мегабайтный файл качался больше часа))
а теперь про баги:
когда загружаю колибри с лайв сд и потом смотрю свои файлы (музычку) на нтфс то половина папок не отображается о_0
причем в непонятной последовательности - часть с русским названием, часть с англ.
а еще я зашел посмотреть фотки - коммандер файлы видит. перезагрузился - не видит! нету говорит там файлов.
с чего бы это??
сразу оффтоп
спасибо всем разработчикам за колибри!
когда накрылась вЕнда, мне срочно понадобилось вытащить с жесткого образ. убунта-лайвСД отказалась грузиться, ничем не обосновывая. а с помощью колибри скопировал нужный образ с нтфс на флешку. правда, 600-мегабайтный файл качался больше часа))
а теперь про баги:
когда загружаю колибри с лайв сд и потом смотрю свои файлы (музычку) на нтфс то половина папок не отображается о_0
причем в непонятной последовательности - часть с русским названием, часть с англ.
а еще я зашел посмотреть фотки - коммандер файлы видит. перезагрузился - не видит! нету говорит там файлов.
с чего бы это??
Технически, в текущем ядре с NTFS были замечены глюки с именами, содержащими букву 'Ё' (ну и вообще с символами, не входящими в 26*2 букв латинского алфавита и 32*2 букв русского алфавита без 'Ё'). До фикса руки у меня пока не дошли.
Вопрос с исчезновением после перезагрузки более интересный... у меня два варианта: в первом между загрузками Колибри была загрузка винды, которая по каким-то причинам решила перестроить B-дерево индекса этой папки, и в новой структуре глюк с Ё проявился; во втором предполагается, что диск ATA, виден и как /hd*, и как /bd*, важные данные папки оказались за пределом 128Г, и в одном случае первое чтение папки было через /bd-интерфейс (корректно обрабатывающий размеры до 2Т), а в другом - через /hd-интерфейс (неправильно обрабатывающий данные после границы 128Г).
Вопрос с исчезновением после перезагрузки более интересный... у меня два варианта: в первом между загрузками Колибри была загрузка винды, которая по каким-то причинам решила перестроить B-дерево индекса этой папки, и в новой структуре глюк с Ё проявился; во втором предполагается, что диск ATA, виден и как /hd*, и как /bd*, важные данные папки оказались за пределом 128Г, и в одном случае первое чтение папки было через /bd-интерфейс (корректно обрабатывающий размеры до 2Т), а в другом - через /hd-интерфейс (неправильно обрабатывающий данные после границы 128Г).
Ушёл к умным, знающим и культурным людям.
отвергаю первое подозрение diamond-a.
перезагрузки в винду не было, так как Колибри была единственной рабочей ОС на ноуте).
а вот второе вполне может быть.
папка с фотками - 1,49 GB (1 600 740 642 bytes), 537 файлов.
диск забит на 257 гб. уважаемый diamond, вы хотите сказать что половина данных может не открыться?
косяк появился при загрузке Колибри с лайвСД. Я скопировал пару фоток, потом перезагрузился и Колибри перестала их видеть.
постараюсь повторить баг и снять скрин
перезагрузки в винду не было, так как Колибри была единственной рабочей ОС на ноуте).
а вот второе вполне может быть.
папка с фотками - 1,49 GB (1 600 740 642 bytes), 537 файлов.
диск забит на 257 гб. уважаемый diamond, вы хотите сказать что половина данных может не открыться?
косяк появился при загрузке Колибри с лайвСД. Я скопировал пару фоток, потом перезагрузился и Колибри перестала их видеть.
постараюсь повторить баг и снять скрин
Last edited by Muxto on Thu Apr 29, 2010 9:09 pm, edited 1 time in total.
а еще Колибри не захотела увидеть 4-й раздел жесткого диска с фат32 (остальные три - нтфс).
хотя грузится с него))
хотя грузится с него))
Ранние версии интерфейса ATA (он же IDE) для номера сектора использовали 28 бит, что при стандартном размере сектора 512 байт составляет 128 Гб. В более поздних версиях появилось расширение LBA48, позволяющее задавать 48-битный номер сектора. Но Колибри про это расширение ничего не знает, так что за границей 128Г прочесть самостоятельно ничего не сможет.
Однако про это расширение знает BIOS. Что, во-первых, позволяет проводить загрузку, а во-вторых, позволяет Колибри таки читать диск и после 128Г через BIOS-интерфейс.
На уровне пользователя это выглядит, как будто один физический диск раздваивается на два одинаковых /hdN и /bdM. Тем не менее при размерах >128Г первый (с данными после этой границы) работает неправильно, а второй - правильно. (Собственно, поэтому второй и не вырубается, обнаружив первый.) Впрочем, есть ещё нюанс: дисковый кеш у двух устройств совпадает, так что правильность чтения зависит от того, через какой интерфейс впервые были прочитаны данные. Кстати, поскольку при детекте разделов сначала проверяются /hd-диски, то разделы за пределом 128Г не будут обнаружены и на /bd-дисках.
Однако про это расширение знает BIOS. Что, во-первых, позволяет проводить загрузку, а во-вторых, позволяет Колибри таки читать диск и после 128Г через BIOS-интерфейс.
На уровне пользователя это выглядит, как будто один физический диск раздваивается на два одинаковых /hdN и /bdM. Тем не менее при размерах >128Г первый (с данными после этой границы) работает неправильно, а второй - правильно. (Собственно, поэтому второй и не вырубается, обнаружив первый.) Впрочем, есть ещё нюанс: дисковый кеш у двух устройств совпадает, так что правильность чтения зависит от того, через какой интерфейс впервые были прочитаны данные. Кстати, поскольку при детекте разделов сначала проверяются /hd-диски, то разделы за пределом 128Г не будут обнаружены и на /bd-дисках.
Ушёл к умным, знающим и культурным людям.
Не удалось повторить.Nasarus wrote:Микробаг в MTDBG: при первом запуске программы первый нажатый символ всегда воспринимается как пробел. Дальше все норм.
Ушёл к умным, знающим и культурным людям.
UPD: Правильный вызов сисфункции 68.23 отправляет ядро со всей системой в Тартарары и анабиоз.
ушёл...
Все верно, необходимо в файле memory.inc в обработчике 68 сис функции
Заменить это stdcall shmem_close, eсx
на это
mov ebx,ecx
stdcall shmem_close, ebx
Это я ошибся, когда переписывал 68 сис. функцию.
Code: Select all
.23:
cmp ecx, OS_BASE
jae .fail
mov ebx,ecx
stdcall shmem_close, ebx
на это
mov ebx,ecx
stdcall shmem_close, ebx
Это я ошибся, когда переписывал 68 сис. функцию.
Я не могу изменить, у меня нет SVN-аккаунта =(Все верно, необходимо в файле memory.inc в обработчике 68 сис функции
ушёл...
Дождись вечера, если никто раньше меня не исправит - поправлю на SVN.Nasarus wrote:Я не могу изменить, у меня нет SVN-аккаунта =(Все верно, необходимо в файле memory.inc в обработчике 68 сис функции
<Lrz>
Странно.. Исправил memory.inc, как ты посоветовал. Перекомпилировал ядро, записал его в образ, запустился - ядро опять зависло (
Странно.. Исправил memory.inc, как ты посоветовал. Перекомпилировал ядро, записал его в образ, запустился - ядро опять зависло (
ушёл...
Вышли пример приложения, которое подвешивает систему
Who is online
Users browsing this forum: No registered users and 1 guest