Board.KolibriOS.org

Official KolibriOS board
It is currently Fri May 24, 2019 6:17 pm

All times are UTC+03:00




Post new topic  Reply to topic  [ 16 posts ]  Go to page 1 2 Next
Author Message
PostPosted: Sun Dec 16, 2007 12:55 am 
Offline

Joined: Sun Dec 16, 2007 12:43 am
Posts: 15
Ребята, всем привет, может я не по теме, но думаю тут много профессионалов, прошу подсказать - настраиваю таймер, на большую частоту:
; Повышение частоты таймера
xor ax, ax
mov al, 00110110b ; канал 0, режим 3, вид операции 3, счёт двоичный
out 43h, al
;!!!!!!!!!!!!!!!!!
mov ax, 02 ; значение фиксатора 2
;!!!!!!!!!!!!!!!!!
out 40h, al
mov al, ah
out 40h, al

Если ЗНАЧЕНИЕ ФИКСАТОРА где то примерно 100, то всё работает :). Как только ставлю маленькое значение, так сразу получаю нарушение общей защиты. Обьясните мне пожалуйста этот момент :)
Креплю код, в котором происходитит такое "чудо", и ещё, у меня там вывод ошибочного селектора вроде не правильно выводится, подскажите ;) а то уже голова кругом %)


Attachments:
File comment: мой подопытный кролик ;)
rabbit.rar [13.43 KiB]
Downloaded 301 times
Top
   
PostPosted: Sun Dec 16, 2007 2:52 pm 
Offline
Kernel Developer
User avatar

Joined: Mon Nov 28, 2005 8:00 pm
Posts: 1601
Хе-хе, к нам уже с васма идут :D
По теме: рекомендую вместо tasm/masm использовать fasm. В fasm'е iret означает то, что он и должен означать, а в tasm и masm в 32-битном режиме нужно писать iretd

_________________
Ушёл к умным, знающим и культурным людям.


Top
   
PostPosted: Sun Dec 16, 2007 8:49 pm 
Offline

Joined: Sun Dec 16, 2007 12:43 am
Posts: 15
diamond, спасибо за совет, но, во первых, он не по теме, во вторых, как ты пипой не крути, ирет получишь ты, пофиг iret или iretd, у меня бит D во всег дескрипторах означает 32-й режим, когда iret, то это значит что он работает с 32-ми данными тчк.
То что в коде моём ошибок куча, то такое. А вот почему выбивает искл13, при быстро возбуждающемся таймере????????????


Top
   
PostPosted: Sun Dec 16, 2007 9:03 pm 
Offline
Kernel Developer
User avatar

Joined: Mon Nov 28, 2005 8:00 pm
Posts: 1601
Фактически в исходнике написан iretw - при компиляции добавляется префикс изменения разрядности операнда 66h. Поскольку iretw считает, что ситуация 16-битная, то, с её точки зрения, стек выглядит так:
dw old_ip
dw old_cs
dw old_flags
А на самом деле там
dd old_eip
dd MOVZX(old_cs)
dd old_eflags
Следовательно, она пытается вернуться к селектору HIWORD(old_eip) = 0, что, естественно, приводит к #GP.


Top
   
PostPosted: Sun Dec 16, 2007 9:23 pm 
Offline

Joined: Sun Dec 16, 2007 12:43 am
Posts: 15
diamond, там с самого начала написано - сегмент кода, 32 разрядный, seg_code32 segment use32. код команды iret = CF, у тебя что фасм ставит префикс??? Нафиг префикс??? Чё ты придумал??? Не в этом ошибка :) Спасибо за твою внимательность и за желание помочь :)


Top
   
PostPosted: Mon Dec 17, 2007 1:01 am 
Offline
Kernel Developer
User avatar

Joined: Mon Nov 28, 2005 8:00 pm
Posts: 1601
Нет, не фасм - он такое не скомпилит. masm (которым я компилил 1.asm) действительно в use32-сегментах ставит префикс перед iret. Но в 1.exe действительно iret идёт без всяких префиксов, так что этот вариант отпадает.
А тестировалось случайно не под Bochs? Почему такое происходит под Bochs, я могу объяснить, а под qemu и VMWare 1.exe работает...


Top
   
PostPosted: Mon Dec 17, 2007 1:43 am 
Offline
Kernel Developer
User avatar

Joined: Mon Nov 28, 2005 8:00 pm
Posts: 1601
Проверил на реальной машине - Bochs оказался прав... #GP с кодом ошибки, указывающим на индекс 0x27 в IDT. Иными словами, происходит IRQ7, а поскольку для него обработчика в IDT нет, то процессор выкручивается как может.
Теперь почему это происходит.
http://lib.e-hard.ru/book/1/page/118.html
Quote:
В любом случае сигнал запроса аппаратного прерывания IRQx должен удерживаться генерирующей его схемой, по крайней мере, до цикла подтверждения прерывания процессором — именно в этот момент PIC определяет самый приоритетный незамаскированный запрос и по нему формирует вектор. Если к этому моменту запрос окажется снятым, источник прерывания корректно идентифицирован не будет, и контроллер сообщит ложный вектор прерывания (spurious interrupt), соответствующий его входу с максимальным номером (IRQ7 для первого контроллера и IRQ15 для второго). Обычно периферийные устройства строят так, что сигнал запроса сбрасывается при обращении программы обслуживания прерывания к соответствующим регистрам адаптера, так что ложных прерываний возникать не должно.

Хроника событий:
1) Запрещаются прерывания. (Кстати, переключение графического режима лучше бы делать в самом начале, потому что 0-я функция int 10h вполне может их временно разрешать...)
2) При перепрограммировании таймера ему указывается режим 3 - генерация прямоугольных импульсов. Что в переводе на русский означает: когда счётчик доходит до нуля, микросхема попеременно посылает высокий уровень сигнала и низкий уровень сигнала.
3) Таймер начинает эти импульсы подавать в большом количестве. Контроллер прерываний запоминает, что кто-то подал сигнал.
4) Но процессору не до них. Прерывания запрещены, причём довольно долгое время (переключение в PM быстро не делается).
5) И вот процессор разрешает прерывания. Контроллер прерываний заявляет процессору "прерывание пришло!" Процессор отвечает: "ну-ну... что за прерывание-то?" Контроллер смотрит на устройства... и видит, что везде уровень сигнала низкий (ибо микросхема таймера уже успела всё сбросить, а остальные даже и не рыпались). Контроллер:"(про себя) Опа! Интересно, что это было? Ладно, надо что-то ответить, процессор ждёт... (процессору) получай: IRQ7, вектор 27h"
6) Процессор (про себя): "странный какой-то вектор... чё там в IDT? ах, нули? Я отказываюсь работать в таких условиях! Вот вам! #GP(27h*8 + 3)!"

_________________
Ушёл к умным, знающим и культурным людям.


Top
   
PostPosted: Mon Dec 17, 2007 1:11 pm 
Offline

Joined: Sun Dec 16, 2007 12:43 am
Posts: 15
Спасибо за инфу, буду думать! Тестировал на мсдосе ;) . Сразу возникает вопрос - если так, так это получается, если, подключить устройство, очень быстрое, например, которое будет подавать сигналы с частотой в 10 Мгц, то фиг можно будет их быстро обработать? Получается их можно обработать с частотой таймера?


Top
   
PostPosted: Mon Dec 17, 2007 1:37 pm 
Offline
Kernel Developer
User avatar

Joined: Mon Nov 28, 2005 8:00 pm
Posts: 1601
Quote:
если, подключить устройство, очень быстрое, например, которое будет подавать сигналы с частотой в 10 Мгц, то фиг можно будет их быстро обработать?

10 миллионов прерываний в секунду?! Зачем столько?
Для передачи данных совершенно необязательно генерировать прерывание после каждого байта. Практически все устройства общаются пакетами: есть новый пакет - генерируем IRQ, а обработчик разбирается, что произошло, сколько байт в пакете и т.п.

Если
а) процессор очень быстрый,
б) обработчик соответствующего устройству прерывания очень быстрый,
в) прерывания никогда не запрещаются надолго,
то обработка даже прерываний, приходящих с очень высокой частотой, возможна. Но если хотя бы одно из требований не выполнено (а это так практически наверняка), то некоторые сигналы будут неизбежно теряться. Насколько это фатально - зависит от устройства. Микросхема таймера в режиме 3 может успеть сбросить сигнал, и тогда одно прерывание будет потеряно, а вместо него поступит IRQ7 (между прочим, обычное IRQ, его тоже можно обрабатывать). В случае, когда устройство держит высокий уровень, просто при этом потеряется одно прерывание.


Top
   
PostPosted: Wed Dec 26, 2007 4:12 am 
Offline

Joined: Sun Dec 16, 2007 12:43 am
Posts: 15
diamond, а ведь не может быть IRQ7, оно у меня запрещено, при настройке кПр-й:

mov al, 11111100b ; OCW1, 0 - разрешено прерывание, 1 - запрещено
out 21h, al

mov al, 11111111b ; OCW1, маска
out 0A1h, al

окроме таймера и клавиатуры прерываний больше нет тчк

Есть такой, кто скажет правду???


Top
   
PostPosted: Wed Dec 26, 2007 5:31 am 
Offline

Joined: Wed Dec 26, 2007 5:09 am
Posts: 214
Diamond

Бесполезно пытаться объяснять человеку, который не желает тратить время на тщательное изучение документации...

0136
Quote:
diamond, а ведь не может быть IRQ7, оно у меня запрещено, при настройке кПр-й

Для особых интеллектуалов повторяю цитату, приведённую Диамондом:

Quote:
В любом случае сигнал запроса аппаратного прерывания IRQx должен удерживаться генерирующей его схемой, по крайней мере, до цикла подтверждения прерывания процессором — именно в этот момент PIC определяет самый приоритетный незамаскированный запрос и по нему формирует вектор. Если к этому моменту запрос окажется снятым, источник прерывания корректно идентифицирован не будет, и контроллер сообщит ложный вектор прерывания (spurious interrupt), соответствующий его входу с максимальным номером (IRQ7 для первого контроллера и IRQ15 для второго)


А теперь, на всякий случай, ещё и своими словами: если контроллер прерываний получает от процессора сигнал, по которому он должен сообщить процессору вектор, и в этот момент обнаруживается, что никаких активных запросов прерываний от устройств уже нет (запросы были сброшены до того, как были обработаны), контроллер всегда сообщает вектор с наибольшим номером. И никакое маскирование от этого не спасает, потому что маскирование блокирует входящие линии IRQ, а не внутренние схемы контроллера прерываний.

Так что читайте, дорогой осеписатель, документацию, и читайте внимательно.


Top
   
PostPosted: Thu Dec 27, 2007 6:01 pm 
Offline

Joined: Sun Dec 16, 2007 12:43 am
Posts: 15
привет, точно, сделал IRQ7, и оно возникает %). И нафиг такое железо глючное в комп поставили? 8) Ладно, всем спасибо.


Top
   
PostPosted: Fri Dec 28, 2007 10:24 am 
Offline

Joined: Wed Dec 26, 2007 5:09 am
Posts: 214
0136 wrote:
привет, точно, сделал IRQ7, и оно возникает %). И нафиг такое железо глючное в комп поставили? 8) Ладно, всем спасибо.


Претензии -- к дегенератам из Интела, которые придумали самые уродские в мире 8-, 16- и 32-разрядные процессоры. Пальму первенства в 64-разрядном сегменте у них отобрали идиоты из АМД.

Кстати, от знания того, что возникает IRQ7, проблема не исчезает: надо делать так, чтоб оно не возникало, а значит -- корректно программировать и таймер, и контроллер прерываний, и обработчик прерывания от таймера (и, вероятно, не только от него), чтобы прерывания всегда обрабатывались вовремя.


Top
   
PostPosted: Fri Dec 28, 2007 6:12 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Никаких глюков там нет. Контроллер хранит все запросы на прерывания пока его не перепрограммируют, так что сначала надо замаскировать прерывания в контроллере. Кстати современные чипсеты в случае ошибки генерируют только IRQ7.


Top
   
PostPosted: Sat Dec 29, 2007 8:52 pm 
SII wrote:
Претензии -- к дегенератам из Интела, которые придумали самые уродские в мире 8-, 16- и 32-разрядные процессоры

Наши быдлокодеры используют Cyrix?


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 16 posts ]  Go to page 1 2 Next

All times are UTC+03:00


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Limited