Bug 3249

Summary: Possible bug in acpi_os_install_interrupt_handler
Product: ACPI Reporter: Christian Lupien (lupien)
Component: Config-InterruptsAssignee: Luming Yu (luming.yu)
Status: REJECTED DUPLICATE    
Severity: normal    
Priority: P2    
Hardware: i386   
OS: Linux   
Kernel Version: 2.6.7 Subsystem:
Regression: --- Bisected commit-id:
Bug Depends on:    
Bug Blocks: 2934    

Description Christian Lupien 2004-08-20 02:53:57 UTC 
Software Environment: kernel 2.6.7 +swsusp2+ acpi
Problem Description:
Will reading the code to find a a problem with gpe events on my system , I found
a possible bug with the way interupt handlers are installed. 

The interupts are installed with acpi_os_install_interrupt_handler (in osl.c).
This is used by acpi_ev_install_sci_handler (events/evsci.c) to install a
handler for sci interupts and it could also be called for another interupt pin
for extra gpe blocks (acpi_ev_get_gpe_xrupt_block in events/evgpeblk.c).

The way the handler is installed (using the global variable acpi_irq_handler in
osl.c) I think that if the second handler is installed this will overwrite the
first one.

Note that I don't have such a second handler so I don't know if this is really a
problem. I just find this weird.
Comment 1 Len Brown 2004-09-02 19:17:45 UTC 
i haven't seen the 2nd handler used before either,
so if we had a bug here it wouldn't surprise me.
ie. maybe a bug in dead code...
Comment 2 Shaohua 2004-11-14 21:25:55 UTC 
This isn't a bug. acpi_ev_get_gpe_xrupt_block will check if the new IRQ == 
fadt.sci. If yes, no new handler is registered.
Comment 3 Shaohua 2004-11-14 21:28:49 UTC 
I should have mentioned there is no extra interrupt registered in current 
Linux. If yes, mattheiu Willox's patch will fix it.
I'm sorry, this is a potential bug.
Comment 4 Luming Yu 2004-12-06 06:13:21 UTC 

*** This bug has been marked as a duplicate of 2934 ***
Comment 5 Luming Yu 2004-12-06 06:15:31 UTC 
Yes, this is addressed by 2934, So close it as  rejected duplicate.