1

I want to trigger hardware interrupts as described in the book Linux Device Drivers by connecting pins 9 and 10 with a wire. I tried that but apparently there's no interrupt beeing triggered:

cat /proc/interrupts:

 7:          0    XT-PIC  parport0

Now I wonder why's that? Kernel modules are loaded:

parport_pc             26004  0
parport                35239  2 ppdev,parport_pc

In the book it says interrupts have to be enabled, but that's the case when the module is loaded, right?

Any ideas what I could do?

|improve this question
1

Just connecting the pins will not generate an interrupt. According to the document you referenced you need to write some data to pin 9 which has a short to pin 10 to generate the interrupt. Quote from your referenced document:

Pin 9 is the most significant bit of the parallel data byte. If you write binary data to /dev/short0, you generate several interrupts. Writing ASCII text to the port won't generate any interrupts, though, because the ASCII character set has no entries with the top bit set.

|improve this answer
  • 1
    Thanks for the hint, should read properly.. m( Well, I did that but it didn't work. In detail I loaded the module insmod short and mknoded /dev/short0, after that I wrote binary junk to /dev/short0 by doing cat /sbin/* > /dev/short0 while I had pin 9 and 10 connected, but no interrupts occured. – JohnnyFromBF May 27 '15 at 15:40
0

Why do people find it so hard to read kernel code? :P.

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/char/ppdev.c

Seriously, it's common for devices to only be activated when they're needed - when userspace opens them. Example:

If you look at ppdev.c, you'll see it presents an API where the parport is "claimed" (though not necessarily exclusively?!). Only then does it call pp_enable_irq(). (I first looked at open() and saw the comment there).

I dunno whether that's the precise reason here, but it shows the flaw in your assumption :).

|improve this answer
  • Ok then this seems different with char devices. In the case of e1000 the module itself seems to enable irqs while booting. – JohnnyFromBF May 27 '15 at 14:50
  • Maybe we're looking at different things. e1000 enables the irq in e1000_open(), not e1000_probe(). Does the kernel really start the network interface running, without an address, without prompting by userspace? It's at least possible to shut it down, and in that case the irq is disabled. – sourcejedi May 27 '15 at 15:44
  • Hmm, at least e1000_open() and thus e1000_irq_enable() gets called before /dev/kmsg is created, since the printk() I put into e1000_open() is not available in dmesg. – JohnnyFromBF May 27 '15 at 16:03
  • no, dmesg logs from the start, at least you should see stuff like ACPI and then the PCI bus initialization, which has to happen before driving PCI devices :) ...I can't see what I could have missed. – sourcejedi May 27 '15 at 19:39
  • Surprised me too when I learnt it (and I don't know why it's "the correct way"), but: makelinux.net/ldd3/chp-10-sect-2 "The correct place to call request_irq is when the device is first opened, before the hardware is instructed to generate interrupts. The place to call free_irq is the last time the device is closed, after the hardware is told not to interrupt the processor any more. The disadvantage of this technique is that you need to keep a per-device open count so that you know when interrupts can be disabled." – sourcejedi May 27 '15 at 19:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.