Обработчик прерывания по IRQ 0, 8

Доброго дня.)

Занялся изучением вопроса установки собственных обработчиков прерываний. Написал простенькую программу. В ней всё работает, но, когда я пытаюсь выполнить:
insmod Mod_1.ko // в которой:

   N_irq = 0; //или 8; 0 - timer, 8 - rtc
   if (request_irq (N_irq, My_interrupt,
   IRQF_SHARED|IRQF_TIMER, "My_IRQ0", &D_irq)) return -1;

То на консоли вижу:

insmod: ERROR: could not insert module Mod_1.ko: Operation not permitted
dmesg показывает:
genirq: Flags mismatch irq 0. 00014200 (My_IRQ0) vs. 00015a20 (timer)

Как я понял, мне отказывают в регистрации обработчика из-за несоответствия флагов, отсюда вопросы:
1) На IRQ0 или 8 - невозможно впринципе написать обработчик из-за монопольного использования линии текущим обработчиком?
2) Если написать возможно, то, наверное, нужны другие IRQF флаги?

Пользование тегами code/console крайне желательно

"Aether" написал:

1) На IRQ0 или 8 - невозможно впринципе написать обработчик из-за монопольного использования линии текущим обработчиком?

да, по идее раздельное использование прерываний для разных устройств на x86 возможно только в рамках pci...

"Aether" написал:

2) Если написать возможно, то, наверное, нужны другие IRQF флаги?

FYI: arch/x86/kernel/time.c

  static struct irqaction irq0  = {
      .handler = timer_interrupt,
      .flags = IRQF_DISABLED | IRQF_NOBALANCING | IRQF_IRQPOLL | IRQF_TIMER,
      .name = "timer"
  };

а если глянуть /proc/interrupts
[console] CPU0 CPU1 CPU2 CPU3
0: 19 0 0 0 IO-APIC-edge timer
...
8: 4 1 0 0 IO-APIC-edge rtc0
...
LOC: 751701606 790091571 867486481 745563970 Local timer interrupts
...
[/console]
то этих прерываний окажется как-то мало... не уверен до конца, что же ядро на самом деле использует для найминга... по идее должен использоваться hpet, он должен был бы эмулировать rtc и старый таймер и слать прерывания через них или занять отдельное прерывание... а ни того ни другого не видно... есть ещё внутренние прерывания APIC'а — вот их похоже и используют...

Недостатки постараюсь учесть)

Да, покопался и вот, что выяснил:
[console]genirq: Flags mismatch irq 0. 00014200 (My_IRQ0) vs. 00015a20 (timer)[/console]
перед скобками и стоят, собственно, флаги IRQF, определённые в файле linux/interrupt.h.
Так вот, я разложил 00015a20, и оказалось, что стандартный обработчик IRQ0 - timer содержит флаг IRQF_DISABLED, то есть по сути он выполняет роль заглушки. Отсюда, также и следствие - счёт не идёт. Я проверил на стареньком Celeron 233 /proc/interrupts, там таймер скачет десятками тысяч.
Покопался далее, выяснил, что за системный счёт теперь отвечает APIC, и его тики подсчитываются, как у Вас и написано, в LOC (local timer).

В итоге, решил задачу, посредством включения timer.h, задав функцией setup_timer таймер и его обработчик. Тем не менее, хотел бы научиться, как можно использовать тики APIC более прямым образом? Мда, одни вопросы решаются, другие появляются.)

"Aether" написал:

Так вот, я разложил 00015a20, и оказалось, что стандартный обработчик IRQ0 - timer содержит флаг IRQF_DISABLED, то есть по сути он выполняет роль заглушки

не правильно понимаешь: IRQF_DISABLED — это «запретить прерывания при входе в обработчик»... если верить этому, то сейчас это делается для всех обработчиков, а флаг оставлен для совместимости...

"Aether" написал:

В итоге, решил задачу, посредством включения timer.h, задав функцией setup_timer таймер и его обработчик. Тем не менее, хотел бы научиться, как можно использовать тики APIC более прямым образом?

это всем хотелось бы, только вот сил на разработку собственного девайса под x86 ни у кого не хватает....

IRQF_DISABLED, да, понял, похоже, не верно.

Fat-Zer написал:

это всем хотелось бы, только вот сил на разработку собственного девайса под x86 ни у кого не хватает....

Есть предложение использовать другую платформу?

Кстати, обратил внимание - используя таймер на малых интервалах (1-2мс) наблюдается отклонение времени исполнения фактического от запрошенного, и оно растёт, если систему нагрузить, то есть фактически, без использования механизма прерываний невозможно обеспечить высокую чёткость работы. Конечно, это не всегда требуется, но, когда, например, производишь измерения, то, опоздав на пару мс, можно упустить актуальный результат.(

"Aether" написал:

тати, обратил внимание - используя таймер на малых интервалах (1-2мс) наблюдается отклонение времени исполнения фактического от запрошенного

hrtimer'ы пробовал?

"Aether" написал:

Есть предложение использовать другую платформу?

как вариант arm, можно даже пишечку — на ней можно с прерываниями по GPIO поиграться...

Нет, таймеры высокого разрешения не пробовал. Но, результат, думаю будет похожим, просто удастся засечь отставание от выполнения более точно)))

Пишечка - это PIC? Если да, то это тема ближайшего рассмотрения, точнее начинаю изучать PIC16F1454. Вопросы тоже имеются, нужна консультация.

"Aether" написал:

Пишечка - это PIC? Если да, то это тема ближайшего рассмотрения, точнее начинаю изучать PIC16F1454. Вопросы тоже имеются, нужна консультация

не... raspberry Pi... pic'и для линукса маловаты...

Спасибо, в будущем, думаю, стоит обратить внимание - цена, действительно, доступная.