1

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

Занялся изучением вопроса установки собственных обработчиков прерываний. Написал простенькую программу. В ней всё работает, но, когда я пытаюсь выполнить:
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 крайне желательно

2

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

 Консоль:
           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
...

то этих прерываний окажется как-то мало... не уверен до конца, что же ядро на самом деле использует для найминга... по идее должен использоваться hpet, он должен был бы эмулировать rtc и старый таймер и слать прерывания через них или занять отдельное прерывание... а ни того ни другого не видно... есть ещё  внутренние прерывания APIC'а — вот их похоже и используют...

95% процентов проблем находятся между клавиатурой и стулом.

3

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

Да, покопался и вот, что выяснил:

 Консоль:
genirq: Flags mismatch irq 0. 00014200 (My_IRQ0) vs. 00015a20 (timer)

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

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

4

Aether пишет:

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

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

Aether пишет:

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

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

95% процентов проблем находятся между клавиатурой и стулом.

5

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

Fat-Zer пишет:

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

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

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

6

Aether пишет:

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

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

Aether пишет:

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

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

95% процентов проблем находятся между клавиатурой и стулом.

7

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

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

8

Aether пишет:

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

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

95% процентов проблем находятся между клавиатурой и стулом.

9

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