Re: Can not free irq 0

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>> After enabling the RTC support, I have recompiled the kernel and try
>> to use the irq 8. But, it seems that the 'irq_request()' can not
>> register my hangler.
>
> isn't that 8 occupied by rtc? and it might be occupied
> exclusively....a.k.a you can put more handler there

The irq 8 is really occupied by rtc and its initial flags is set as
IRQF_DISABLED. At the beginning, I think the irq's registration is
invoked in drivers/char/rtc.c, but this is not really the case. Then,
I have to find where the registration is done. I modified the
request_irq() to the other function name, and compiled the kernel.
Checking the error messages from gcc I found that the actual
registration is done in drivers/rtc/rtc-cmos.c like this:

                retval = request_irq(rtc_irq, rtc_cmos_int_handler,
                                IRQF_DISABLED, dev_name(&cmos_rtc.rtc->dev),
                                cmos_rtc.rtc);

It is obviously that the irq8 (rtc_irq == 8) is not permitted to be
shared with other interrupt handlers. So, I changed IRQF_DISABLED to
IRQF_SHARED, recompiled the kernel, installed it, and then reboot.
After my module inserted, I get the following messages:

root [ ~ ]# cat /proc/interrupts
           CPU0
  0:        150    XT-PIC-XT        timer
  1:          8    XT-PIC-XT        i8042
  2:          0    XT-PIC-XT        cascade
  5:       2871    XT-PIC-XT        eth0
  6:          3    XT-PIC-XT        floppy
  8:        132    XT-PIC-XT        rtc0, myinterrupt
  9:          0    XT-PIC-XT        acpi
 10:          0    XT-PIC-XT        uhci_hcd:usb2
 11:         45    XT-PIC-XT        ioc0, ehci_hcd:usb1
 12:        116    XT-PIC-XT        i8042
 14:       2016    XT-PIC-XT        ide0
 15:         48    XT-PIC-XT        ide1
NMI:          0   Non-maskable interrupts
LOC:      14033   Local timer interrupts
SPU:          0   Spurious interrupts
PMI:          0   Performance monitoring interrupts
PND:          0   Performance pending work
RES:          0   Rescheduling interrupts
CAL:          0   Function call interrupts
TLB:          0   TLB shootdowns
TRM:          0   Thermal event interrupts
THR:          0   Threshold APIC interrupts
MCE:          0   Machine check exceptions
MCP:          8   Machine check polls

The 'rtc0' and 'myinterrupt' share the irq8 really. Then, I executed
the test program from Documentation/rtc.txt to activate some periodic
interrupts from the rtc, and found that the handler of 'myinterrupt'
invoked several times by its output to /var/log/messages.

But I don't think this is an ideal solution to share irq owing to the
modification to kernel code directly. So, I wonder whether there is
any EXPORTed funciton which can modify the flags of an existing
interrupt handler.

2011/8/28 Mulyadi Santosa <mulyadi.santosa@xxxxxxxxx>:
> Hi...
>
> On Sun, Aug 28, 2011 at 03:59, Parmenides <mobile.parmenides@xxxxxxxxx> wrote:
>>> are you really sure? in my system (laptop with core duo cpu) it is
>>> increased by around 1000-2000 every 2 seconds and AFAIK it is using
>>> HPET.
>>>
>> Yes. How can I see the timer is i8253 or HPET? I just found 'timer' in
>> terms of the output of 'cat /proc/interrupts'.
>
> try dumping the output of
> "/sys/devices/system/clocksource/clocksource*/current_clocksource"
>
>>> So maybe IMO free_irq() is causing your cpu referencing null
>>> instruction...that might be due to free_irq is not checking whether it
>>> is safe to delete a handler....
>>>
>
> --
> regards,
>
> Mulyadi Santosa
> Freelance Linux trainer and consultant
>
> blog: the-hydra.blogspot.com
> training: mulyaditraining.blogspot.com
>

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux