a question about interrupt of IDE controller( bug 5637)

a question about interrupt of IDE controller( bug 5637)

[Zhao Yakui]

Hi, All
	I have a question about the interrupt of IDE controller. There is a
regression between 2.6.13 and 2.6.12. More details can be found in the
following link:
	http://bugzilla.kernel.org/show_bug.cgi?id=5637
	
	When the IDE controller works in legacy mode, the default IRQ for Ide0
interface is 14 and IRQ for Ide1 interface is 15. The default interrupt
mode for IRQ14/15 is edge/high. If the interrupt of some PCI devices is
routed to IRQ14 or 15 and the interrupt mode is switched to Low/Level,
an exception will appear.(If the I/O APIC is used as the Interrupt
controller, IRQ14/15 nobody cared for. If the I8259 is used as the
interrupt controller, maybe some IDE interrupts will be lost). 
		
	In the Bug 5637: When the system works in acpi mode, there is no PCI
interrupt router for IDE pci device in ACPI tables and OS will guess an
interrupt for IDE PCI device, which is obtained from IDE PCI
configuration space(The IRQ number is 15). OS will register the IRQ 15
using acpi_register_gsi and switch the interrupt mode of IRQ 15 to
Low/level. Because the interrupt mode for IRQ 15 is uncorrect, there
will be interrupt flood and the system reports: IRQ 15 nobody cared.
	
	How to fix this issue? Is IRQ 14/15 always reserved for the IDE
device?  

Thanks.
	

	
	
	

Re: a question about interrupt of IDE controller( bug 5637)

[Alan Cox]

> 	When the IDE controller works in legacy mode, the default IRQ for Ide0
> interface is 14 and IRQ for Ide1 interface is 15. The default interrupt
> mode for IRQ14/15 is edge/high. If the interrupt of some PCI devices is
> routed to IRQ14 or 15 and the interrupt mode is switched to Low/Level,
> an exception will appear.(If the I/O APIC is used as the Interrupt
> controller, IRQ14/15 nobody cared for. If the I8259 is used as the
> interrupt controller, maybe some IDE interrupts will be lost). 

Yes.

> 	In the Bug 5637: When the system works in acpi mode, there is no PCI
> interrupt router for IDE pci device in ACPI tables and OS will guess an
> interrupt for IDE PCI device, which is obtained from IDE PCI
> configuration space(The IRQ number is 15). OS will register the IRQ 15
> using acpi_register_gsi and switch the interrupt mode of IRQ 15 to
> Low/level. Because the interrupt mode for IRQ 15 is uncorrect, there
> will be interrupt flood and the system reports: IRQ 15 nobody cared.
> 	
> 	How to fix this issue? Is IRQ 14/15 always reserved for the IDE
> device?

No.

If the IDE device is in legacy mode then the IRQ is fixed at 14/15 for
the two channels. If it is in PCI mode then the PCI and ACPI routing
applies. This is defined in the header of the IDE device.

Class STORAGE:IDE

Programming class bit 0 -> channel 0 is legacy (0x1F0, 0x3F6, 14)
Programming class bit 2 -> channel 1 is legacy (0x170, 0x376. 15)

Re: a question about interrupt of IDE controller( bug 5637)

[Zhao Yakui]

On Tue, 2007-12-04 at 12:38 +0000, Alan Cox wrote:
> > 	When the IDE controller works in legacy mode, the default IRQ for Ide0
> > interface is 14 and IRQ for Ide1 interface is 15. The default interrupt
> > mode for IRQ14/15 is edge/high. If the interrupt of some PCI devices is
> > routed to IRQ14 or 15 and the interrupt mode is switched to Low/Level,
> > an exception will appear.(If the I/O APIC is used as the Interrupt
> > controller, IRQ14/15 nobody cared for. If the I8259 is used as the
> > interrupt controller, maybe some IDE interrupts will be lost). 
> 
> Yes.
> 
> > 	In the Bug 5637: When the system works in acpi mode, there is no PCI
> > interrupt router for IDE pci device in ACPI tables and OS will guess an
> > interrupt for IDE PCI device, which is obtained from IDE PCI
> > configuration space(The IRQ number is 15). OS will register the IRQ 15
> > using acpi_register_gsi and switch the interrupt mode of IRQ 15 to
> > Low/level. Because the interrupt mode for IRQ 15 is uncorrect, there
> > will be interrupt flood and the system reports: IRQ 15 nobody cared.
> > 	
> > 	How to fix this issue? Is IRQ 14/15 always reserved for the IDE
> > device?
> 
> No.
> 
> If the IDE device is in legacy mode then the IRQ is fixed at 14/15 for
> the two channels. If it is in PCI mode then the PCI and ACPI routing
> applies. This is defined in the header of the IDE device.
> 
> Class STORAGE:IDE
> 
> Programming class bit 0 -> channel 0 is legacy (0x1F0, 0x3F6, 14)
> Programming class bit 2 -> channel 1 is legacy (0x170, 0x376. 15)
Thanks for the response.
When IDE device works in legacy mode, the IRQ of IDE is fixed at 14/15
for the two channel. But IDE controller is a PCI device, OS will assign
an interrupt number for the PCI device in which IDE controller resides.
This is realized by calling ide_pci_enable, which will call
pcibios_enable_irq. 
In the bug5637 OS registers the IRQ 15 in the initialization phase of
PCI IDE controller and the interrupt mode is Low/level. So the problem
appears.

Re: a question about interrupt of IDE controller( bug 5637)

[Alan Cox]

> When IDE device works in legacy mode, the IRQ of IDE is fixed at 14/15
> for the two channel. But IDE controller is a PCI device, OS will assign
> an interrupt number for the PCI device in which IDE controller resides.
> This is realized by calling ide_pci_enable, which will call
> pcibios_enable_irq. 

And pcibios_enable_irq should see interrupt in as 0 in that case. It also
knows about this but it seems the ACPI one doesn't.

I don't have a problem system but this would be my guess as to what we need

--- drivers/acpi/pci_irq.c~	2007-12-05 14:07:47.389727744 +0000
+++ drivers/acpi/pci_irq.c	2007-12-05 14:07:47.389727744 +0000
@@ -429,6 +429,13 @@
 					  &polarity, &link,
 					  acpi_pci_allocate_irq);
 
+	if (irq < 0) {
+		/* IDE legacy mode controller IRQs are magic. Why do compat
+		   extensions always make such a nasty mess */
+		if (dev->class >> 8 == PCI_CLASS_STORAGE_IDE && 
+						(dev->class & 0x05) == 0)
+			return 0;
+	}
 	/*
 	 * No IRQ known to the ACPI subsystem - maybe the BIOS / 
 	 * driver reported one, then use it. Exit in any case.

Re: a question about interrupt of IDE controller( bug 5637)

[Sergei Shtylyov]

Hello.

Alan Cox wrote:

>>When IDE device works in legacy mode, the IRQ of IDE is fixed at 14/15
>>for the two channel. But IDE controller is a PCI device, OS will assign
>>an interrupt number for the PCI device in which IDE controller resides.
>>This is realized by calling ide_pci_enable, which will call
>>pcibios_enable_irq. 

> And pcibios_enable_irq should see interrupt in as 0 in that case. It also

    Should doesn't mean it actually does. I've just looked at my 82801DB 
configuration, see yourself:

[root@wasted etc]# lspci -x -s 0:1f.1
00:1f.1 IDE interface: Intel Corp. 82801DB ICH4 IDE (rev 02)
00: 86 80 cb 24 07 00 80 02 02 8a 01 01 00 00 00 00
10: 01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00
20: 01 f0 00 00 00 00 00 20 00 00 00 00 43 10 89 80
30: 00 00 00 00 00 00 00 00 00 00 00 00 09 01 00 00

    The controller is in legacy mode (programming i/f is 0x8a), yet it 
requests IRQ (interrupt pin = 1) and got assigned IRQ9.

MBR, Sergei

Re: a question about interrupt of IDE controller( bug 5637)

[Zhao Yakui]

On Wed, 2007-12-05 at 14:18 +0000, Alan Cox wrote:
> > When IDE device works in legacy mode, the IRQ of IDE is fixed at 14/15
> > for the two channel. But IDE controller is a PCI device, OS will assign
> > an interrupt number for the PCI device in which IDE controller resides.
> > This is realized by calling ide_pci_enable, which will call
> > pcibios_enable_irq. 
> 
> And pcibios_enable_irq should see interrupt in as 0 in that case. It also
> knows about this but it seems the ACPI one doesn't.
> 
> I don't have a problem system but this would be my guess as to what we need
> 
> --- drivers/acpi/pci_irq.c~	2007-12-05 14:07:47.389727744 +0000
> +++ drivers/acpi/pci_irq.c	2007-12-05 14:07:47.389727744 +0000
> @@ -429,6 +429,13 @@
>  					  &polarity, &link,
>  					  acpi_pci_allocate_irq);
>  
> +	if (irq < 0) {
> +		/* IDE legacy mode controller IRQs are magic. Why do compat
> +		   extensions always make such a nasty mess */
> +		if (dev->class >> 8 == PCI_CLASS_STORAGE_IDE && 
> +						(dev->class & 0x05) == 0)
> +			return 0;
> +	}
>  	/*
>  	 * No IRQ known to the ACPI subsystem - maybe the BIOS / 
>  	 * driver reported one, then use it. Exit in any case.
The above patch can fix the issue in bug 5637. But if the interrupt of
other PCI device is routed to 14/15, this patch won't fix it.
Thanks.

Re: a question about interrupt of IDE controller( bug 5637)

[Zhao Yakui]

On Wed, 2007-12-05 at 14:18 +0000, Alan Cox wrote:
> > When IDE device works in legacy mode, the IRQ of IDE is fixed at 14/15
> > for the two channel. But IDE controller is a PCI device, OS will assign
> > an interrupt number for the PCI device in which IDE controller resides.
> > This is realized by calling ide_pci_enable, which will call
> > pcibios_enable_irq. 
> 
> And pcibios_enable_irq should see interrupt in as 0 in that case. It also
> knows about this but it seems the ACPI one doesn't.
> 
> I don't have a problem system but this would be my guess as to what we need
> 
> --- drivers/acpi/pci_irq.c~	2007-12-05 14:07:47.389727744 +0000
> +++ drivers/acpi/pci_irq.c	2007-12-05 14:07:47.389727744 +0000
> @@ -429,6 +429,13 @@
>  					  &polarity, &link,
>  					  acpi_pci_allocate_irq);
>  
> +	if (irq < 0) {
> +		/* IDE legacy mode controller IRQs are magic. Why do compat
> +		   extensions always make such a nasty mess */
> +		if (dev->class >> 8 == PCI_CLASS_STORAGE_IDE && 
> +						(dev->class & 0x05) == 0)
> +			return 0;
> +	}
>  	/*
>  	 * No IRQ known to the ACPI subsystem - maybe the BIOS / 
>  	 * driver reported one, then use it. Exit in any case.
The above patch can fix the issue in Bug5637. But if IDE controller
works in legcay mode and PRT tells us the interrupt for some PCI devices
is 14/15, should we make it pci-like interrupt(level trigger, low
active)? 
Thanks.

Re: a question about interrupt of IDE controller( bug 5637)

[Alan Cox]

> The above patch can fix the issue in Bug5637. But if IDE controller
> works in legcay mode and PRT tells us the interrupt for some PCI devices
> is 14/15, should we make it pci-like interrupt(level trigger, low
> active)? 

If that occurs the BIOS is broken.

Alan