Re: "No irq handler for vector" problem

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

 



>> Stared some more into the interrupt code. I think Robert was on the right
>> track, but I did not see the tree in the forest.
>>
>> The scenario he described can actually happen and yes, we should deactivate
>> the interrupt after the synchronize_hardirq() and not before. Tentative fix
>> below.
>>
>> Thanks,
>>
>> 	tglx
>>
>> 8<-------------
>> --- a/kernel/irq/autoprobe.c
>> +++ b/kernel/irq/autoprobe.c
>> @@ -90,7 +90,7 @@ unsigned long probe_irq_on(void)
>>   			/* It triggered already - consider it spurious. */
>>   			if (!(desc->istate & IRQS_WAITING)) {
>>   				desc->istate &= ~IRQS_AUTODETECT;
>> -				irq_shutdown(desc);
>> +				irq_shutdown_and_deactivate(desc);
>>   			} else
>>   				if (i < 32)
>>   					mask |= 1 << i;
>> @@ -127,7 +127,7 @@ unsigned int probe_irq_mask(unsigned lon
>>   				mask |= 1 << i;
>>
>>   			desc->istate &= ~IRQS_AUTODETECT;
>> -			irq_shutdown(desc);
>> +			irq_shutdown_and_deactivate(desc);
>>   		}
>>   		raw_spin_unlock_irq(&desc->lock);
>>   	}
>> @@ -169,7 +169,7 @@ int probe_irq_off(unsigned long val)
>>   				nr_of_irqs++;
>>   			}
>>   			desc->istate &= ~IRQS_AUTODETECT;
>> -			irq_shutdown(desc);
>> +			irq_shutdown_and_deactivate(desc);
>>   		}
>>   		raw_spin_unlock_irq(&desc->lock);
>>   	}
>> --- a/kernel/irq/chip.c
>> +++ b/kernel/irq/chip.c
>> @@ -314,6 +314,12 @@ void irq_shutdown(struct irq_desc *desc)
>>   		}
>>   		irq_state_clr_started(desc);
>>   	}
>> +}
>> +
>> +
>> +void irq_shutdown_and_deactivate(struct irq_desc *desc)
>> +{
>> +	irq_shutdown(desc);
>>   	/*
>>   	 * This must be called even if the interrupt was never started up,
>>   	 * because the activation can happen before the interrupt is
>> --- a/kernel/irq/cpuhotplug.c
>> +++ b/kernel/irq/cpuhotplug.c
>> @@ -116,7 +116,7 @@ static bool migrate_one_irq(struct irq_d
>>   		 */
>>   		if (irqd_affinity_is_managed(d)) {
>>   			irqd_set_managed_shutdown(d);
>> -			irq_shutdown(desc);
>> +			irq_shutdown_and_deactivate(desc);
>>   			return false;
>>   		}
>>   		affinity = cpu_online_mask;
>> --- a/kernel/irq/internals.h
>> +++ b/kernel/irq/internals.h
>> @@ -82,6 +82,7 @@ extern int irq_activate_and_startup(stru
>>   extern int irq_startup(struct irq_desc *desc, bool resend, bool force);
>>
>>   extern void irq_shutdown(struct irq_desc *desc);
>> +extern void irq_shutdown_and_deactivate(struct irq_desc *desc);
>>   extern void irq_enable(struct irq_desc *desc);
>>   extern void irq_disable(struct irq_desc *desc);
>>   extern void irq_percpu_enable(struct irq_desc *desc, unsigned int cpu);
>> --- a/kernel/irq/manage.c
>> +++ b/kernel/irq/manage.c
>> @@ -13,6 +13,7 @@
>>   #include <linux/module.h>
>>   #include <linux/random.h>
>>   #include <linux/interrupt.h>
>> +#include <linux/irqdomain.h>
>>   #include <linux/slab.h>
>>   #include <linux/sched.h>
>>   #include <linux/sched/rt.h>
>> @@ -1699,6 +1700,7 @@ static struct irqaction *__free_irq(stru
>>   	/* If this was the last handler, shut down the IRQ line: */
>>   	if (!desc->action) {
>>   		irq_settings_clr_disable_unlazy(desc);
>> +		/* Only shutdown. Deactivate after synchronize_irq() */
>>   		irq_shutdown(desc);
>>   	}
>>
>> @@ -1768,6 +1770,14 @@ static struct irqaction *__free_irq(stru
>>   		 * require it to deallocate resources over the slow bus.
>>   		 */
>>   		chip_bus_lock(desc);
>> +		/*
>> +		 * There is no interrupt on the fly anymore. Deactivate it
>> +		 * completely.
>> +		 */
>> +		raw_spin_lock_irqsave(&desc->lock, flags);
>> +		irq_domain_deactivate_irq(&desc->irq_data);
>> +		raw_spin_unlock_irqrestore(&desc->lock, flags);
>> +
>>   		irq_release_resources(desc);
>>   		chip_bus_sync_unlock(desc);
>>   		irq_remove_timings(desc);
>> @@ -1855,7 +1865,7 @@ static const void *__cleanup_nmi(unsigne
>>   	}
>>
>>   	irq_settings_clr_disable_unlazy(desc);
>> -	irq_shutdown(desc);
>> +	irq_shutdown_and_deactivate(desc);
>>
>>   	irq_release_resources(desc);
>>
>>
>>
>>
> Hi,
>
> It significantly decreased appearance of the problem log (at least in my tests),
> But unfortunately, the problem still exists.
>
> Regards,
>      Michael.

I tried it as well, and unfortunately, the error messages are still 
there. I'm seeing, what you're doing, and theoretically it should fix 
the problem, but something is still wrong. Let me try to check on my 
board, what is happening.

Robert



[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux PPP]     [Linux FS]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Linmodem]     [Device Mapper]     [Linux Kernel for ARM]

  Powered by Linux