Board.KolibriOS.org

Official KolibriOS board
It is currently Sun Dec 08, 2019 7:01 am

All times are UTC+03:00




Post new topic  Reply to topic  [ 52 posts ]  Go to page Previous 1 2 3 4 Next
Author Message
PostPosted: Thu Jul 04, 2013 3:55 pm 
Offline
Kernel Developer
User avatar

Joined: Thu Sep 03, 2009 1:52 pm
Posts: 1621
Serge wrote:
Хак писала Вероника. Имхо в этом случае лучше включить APIC, пусть это и требует некоторых телодвижений.

Я тоже так думаю, но при текущем уровне развития системы это не вариант - даже если считать инструкцию по включению APIC очевидной, она таки требует, чтобы система могла хоть как-то загрузиться.
Mario_r4 wrote:
Меня смущает процедура irq_serv в файле core/irq.inc. Пришлось убрать:

Это зря.
Mario_r4 wrote:
а также добавить:

Вот это правильно.

_________________
Сделаем мир лучше!


Top
   
PostPosted: Thu Jul 04, 2013 4:03 pm 
Offline
Kernel Developer

Joined: Sun Feb 10, 2013 12:37 pm
Posts: 2329
CleverMouse wrote:
Mario_r4 wrote:
Меня смущает процедура irq_serv в файле core/irq.inc. Пришлось убрать:

Это зря.

Можно расширенное толкование?

_________________
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!


Top
   
PostPosted: Thu Jul 04, 2013 4:48 pm 
Offline
Kernel Developer
User avatar

Joined: Thu Sep 03, 2009 1:52 pm
Posts: 1621
Mario_r4, весь этот хак предназначен для случая "драйвер устройства повесил обработчик на прерывание A, а устройство генерирует прерывание Б". Если управляющему коду приходит прерывание Б и все драйверы, сидящие на Б, говорят "нет, это не моё прерывание", то управляющий код начинает опрашивать всех-всех-всех с остальных прерываний, вдруг кто сознается. Очевидно, что для корректной работы этого механизма нужно, чтобы драйверы не врали в ответ на вопрос "твоё ли это прерывание?" Но некоторые врут, поэтому их нужно исключать при опросах.

Первая часть исключений, с "jz .fail", отвечает за то, чтобы не начинать опрос, если обработчик прерывания А говорит, что прерывание не его, хотя на самом деле оно его: таким свойством обладают А=6, 14, 15 - все они врут в отрицательную сторону. Поэтому отсюда 14 и 15 убирать нельзя, пока нет нормального обработчика.

Вторая часть исключений, с "jz .try_next_irq", отвечает за то, чтобы игнорировать обработчик прерывания Б, который говорит, что прерывание его, хотя на самом деле оно не его. Это как раз legacy ISA, Б=1, 12, где нет возможности проверить, действительно ли прерывание пришло от нужного источника. И сюда 14 и 15 добавить можно, если уж обработчик всегда говорит, что это его прерывание.

_________________
Сделаем мир лучше!


Top
   
PostPosted: Fri Jul 05, 2013 12:44 am 
Offline
Kernel Developer

Joined: Sun Feb 10, 2013 12:37 pm
Posts: 2329
CleverMouse wrote:
Поэтому отсюда 14 и 15 убирать нельзя, пока нет нормального обработчика.

Что подразумевается под "нормальным обработчиком"?
Я пока сделал так:
Spoiler: Show
Code:
hdd_irq14:
        pushfd
        cli
        pushad
        mov     [irq14_func], hdd_irq_null
        mov     dx, [IDEContrRegsBaseAddr]
        mov     al, 0
        out     dx, al
        popad
        popfd
        mov     al, 1
align 4
hdd_irq_null:
        ret
;-----------------------------------------------------------------------------
align 4
hdd_irq15:
        pushfd
        cli
        pushad
        mov     [irq15_func], hdd_irq_null
        mov     dx, [IDEContrRegsBaseAddr]
        add     dx, 8
        mov     al, 0
        out     dx, al
        popad
        popfd
        mov     al, 1
        ret
;-----------------------------------------------------------------------------

Оба назначаются через:
Code:
   stdcall attach_int_handler, 14, hdd_irq14, 0
   stdcall attach_int_handler, 15, hdd_irq15, 0

И мне, к сожалению, так и никто не прояснил, какие данные передаются через третий параметр (где сейчас 0).

_________________
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!


Top
   
PostPosted: Fri Jul 05, 2013 1:41 am 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Quote:
И мне, к сожалению, так и никто не прояснил, какие данные передаются через третий параметр
Quote:
Третий параметр может быть любым. Ядро передаёт его в установленный обработчик прерывания. Удобно передавать указатель на данные контроллера.


Top
   
PostPosted: Fri Jul 05, 2013 2:15 am 
Offline
Kernel Developer

Joined: Sun Feb 10, 2013 12:37 pm
Posts: 2329
Serge wrote:
Третий параметр может быть любым. Ядро передаёт его в установленный обработчик прерывания. Удобно передавать указатель на данные контроллера.

Виноват - провтыкал...

_________________
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!


Top
   
PostPosted: Fri Jul 05, 2013 8:36 pm 
Offline
Kernel Developer
User avatar

Joined: Thu Sep 03, 2009 1:52 pm
Posts: 1621
Mario_r4 wrote:
Что подразумевается под "нормальным обработчиком"?

Обработчик, регистрируемый через attach_int_handler. Если таковой есть, но всегда возвращает единицу, то добавлять в часть А сравнения с 14,15 можно, но бессмысленно - они никогда не сработают.

_________________
Сделаем мир лучше!


Top
   
PostPosted: Fri Jul 05, 2013 10:07 pm 
Offline
Kernel Developer

Joined: Sun Feb 10, 2013 12:37 pm
Posts: 2329
CleverMouse wrote:
добавлять в часть А сравнения с 14,15 можно, но бессмысленно - они никогда не сработают.

Сейчас код выглядит так:
Spoiler: Show
Code:
; There is at least one configuration with one device which generates IRQ
; that is not the same as it should be according to PCI config space.
; For that device, the handler is registered at wrong IRQ.
; As a workaround, when nobody acknowledges the generated IRQ,
; try to ask all other registered handlers; if some handler acknowledges
; the IRQ this time, relink it to the current IRQ list.
; To make this more reliable, for every handler keep number of times
; that it has acknowledged an IRQ, and assume that handlers with at least one
; acknowledged IRQ are registered properly.
; Note: this still isn't 100% correct, because two IRQs can fire simultaneously,
; the better way would be to find the correct IRQ, but I don't know how to do
; this in that case.
; Also, [fdc_irq_func], [irq14_func], [irq15_func] could process interrupt
; but do not return whether they did it, so just ignore IRQs 6, 14, 15.
        cmp     ebp, 6
        jz      .fail
        cmp     ebp, 14
        jz      .fail
        cmp     ebp, 15
        jz      .fail
        push    ebp
        xor     ebp, ebp
.try_other_irqs:
        cmp     ebp, [esp]
        jz      .try_next_irq
        cmp     ebp, 1
        jz      .try_next_irq
        cmp     ebp, 12
        jz      .try_next_irq
        cmp     ebp, 14
        jz      .try_next_irq
        cmp     ebp, 15
        jz      .try_next_irq
        lea     esi, [irqh_tab+ebp*8]
        mov     ebx, esi
.try_next_handler:

Следует ли понимать что "часть А" это:
Spoiler: Show
Code:
        cmp     ebp, 14
        jz      .fail
        cmp     ebp, 15
        jz      .fail

Если так, то этот код там был до меня и на мое сообщение:
Spoiler: Show
Mario_r4 wrote:
Меня смущает процедура irq_serv в файле core/irq.inc
Пришлось убрать:
Code:
        cmp     ebp, 14
        jz      .fail
        cmp     ebp, 15
        jz      .fail


Было замечание:
Spoiler: Show
CleverMouse wrote:
Mario_r4 wrote:
Меня смущает процедура irq_serv в файле core/irq.inc. Пришлось убрать:

Это зря.

Как следует понимать эти два противоречащих друг другу утверждения?

_________________
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!


Top
   
PostPosted: Fri Jul 05, 2013 10:11 pm 
Offline
Kernel Developer
User avatar

Joined: Thu Sep 03, 2009 1:52 pm
Posts: 1621
Извини, на тот момент я не поняла, что обработчик, зарегистрированный через attach_int_handler, уже есть. Тогда всё в порядке.

_________________
Сделаем мир лучше!


Top
   
PostPosted: Fri Jul 05, 2013 10:13 pm 
Offline
Kernel Developer

Joined: Sun Feb 10, 2013 12:37 pm
Posts: 2329
Еще раз уточню, чтобы избежать непоняток - следует ли удалить:
Code:
        cmp     ebp, 14
        jz      .fail
        cmp     ebp, 15
        jz      .fail

из текущего кода?

_________________
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!


Last edited by Mario_r4 on Fri Jul 05, 2013 10:14 pm, edited 1 time in total.

Top
   
PostPosted: Fri Jul 05, 2013 10:13 pm 
Offline
Kernel Developer
User avatar

Joined: Thu Sep 03, 2009 1:52 pm
Posts: 1621
Да.

_________________
Сделаем мир лучше!


Top
   
PostPosted: Sat Jul 06, 2013 1:23 am 
Offline
Kernel Developer

Joined: Sun Feb 10, 2013 12:37 pm
Posts: 2329
Есть ли смысл перевести на attach_int_handler также обработчик IRQ6?

_________________
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!


Top
   
PostPosted: Sat Jul 06, 2013 9:04 am 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Mario_r4
Да.


Top
   
PostPosted: Sat Jul 06, 2013 2:40 pm 
Offline
Kernel Developer

Joined: Sun Feb 10, 2013 12:37 pm
Posts: 2329
SVN r.3771 - динамическая установка обработчика прерывания Floppy - IRQ6, через attach_int_handler.

Как всегда не обошлось без сюрпризов. Ревизия связанная с новым шедулером сломала работу с флопиком. Почему-то в самый не продходящий момент гасится двигатель флопика и все кирдык. Временно закомментировал в kernel.asm
Spoiler: Show
Code:
proc osloop_has_work?
        cmp     [osloop_nonperiodic_work], 0
        jnz     .yes
        call    stack_handler_has_work?
        jnz     .yes
;        call    check_fdd_motor_status_has_work?
;        jnz     .yes
        call    check_ATAPI_device_event_has_work?
        jnz     .yes
        call    check_lights_state_has_work?
        jnz     .yes
        call    check_timers_has_work?
        jnz     .yes
.no:
        xor     eax, eax
        ret
.yes:
        xor     eax, eax
        inc     eax
        ret
endp

После этого флопик работает нормально. Сразу предупреждаю - это не идеальное решение и автор шедулера может предложить (и я уверен что предложит), что то более подходящее. Заткнул проблему как сумел.

_________________
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!


Top
   
PostPosted: Mon Jul 08, 2013 1:10 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Рестарт ядра снова виснет. Пишет установка обработчиков IDE и всё. Причем у меня установлен AHCI, и контроллеров IDE нет.


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

All times are UTC+03:00


Who is online

Users browsing this forum: No registered users and 2 guests


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:  
cron
Powered by phpBB® Forum Software © phpBB Limited