Re: PNP device interrupt type?

Re: PNP device interrupt type?

[Shaohua Li]

Hi,
Sorry, I wrongly cc-ed the maillist address in previous email.

On Wed, 2005-09-21 at 23:16 +0800, Bjorn Helgaas wrote:
> On Wednesday 21 September 2005 8:59 am, Krzysztof Oledzki wrote: 
> > On Wed, 21 Sep 2005, Bjorn Helgaas wrote: 
> >  
> > > On Tuesday 20 September 2005 7:32 pm, Li, Shaohua wrote: 
> > >> Is it possible PNP devices use level trigger interrupt? 
> > >> IIRC, PNP devices always use edge trigger interrupt under x86, 
> > >> how about the IA64 case? 
> > > 
> > > I'm not aware of any reason why ACPI devices should always 
> > > be edge triggered on ia64. 
> > > 
> > >> If PNP devices always use edge trigger 
> > >> interrupt, 
> > >> we might ignore BIOS setting. 
> > >> We have a bug BIOS assign wrong interrupt info to RTC 
> > >> http://bugzilla.kernel.org/show_bug.cgi?id=5243 
> > > 
> > > ACPI can describe any combination of edge/level, high/low, 
> > > so I think it would be a bad idea to throw away the information 
> > > the firmware is giving us. 
> > > 
> > > We might have to figure out ways to work around firmware 
> > > defects.  But that seems better to me than just ignoring 
> > > what the firmware tells us.  That will lead to situations 
> > > where the hardware and firmware are perfectly legal and 
> > > correct, but Linux doesn't work (i.e., the hardware uses 
> > > level triggered interrupts for some device, and Linux ignores 
> > > that and treats it as edge-triggered). 
> >  
> > As far as i understand question, it was not about *ALL* ACPI devices
> but  
> > only about PNP ones.
> 
> What is the difference between a "PNP" ACPI device and a "non-PNP" 
> ACPI device?  It looks to me like PNPACPI will expose all ACPI 
> devices as PNP devices (with a couple exceptions, like things that 
> don't have any _CRS method).
> 
> > And IMO the real problem is only RTC on x86 so the   
> > workaround can only force this type of interrupt.
> 
> Any workaround should be applied as narrowly as possible, to 
> minimize the chance of breaking a platform that legitimately 
> chooses to use a level-triggered interrupt.  If there's a 
> spec or convention that requires RTC to be edge-triggered 
> on x86, I don't object to reflecting that in the code somehow.
Ok, maybe we could do this workaround for x86 and report a warning.
Let's see if it breaks anything.

Thanks,
Shaohua



-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. 
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php

Re: PNP device interrupt type?

[Krzysztof Oledzki]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2467 bytes --]



On Thu, 22 Sep 2005, Shaohua Li wrote:

> Hi,
> Sorry, I wrongly cc-ed the maillist address in previous email.
>
> On Wed, 2005-09-21 at 23:16 +0800, Bjorn Helgaas wrote:
>> On Wednesday 21 September 2005 8:59 am, Krzysztof Oledzki wrote:
>>> On Wed, 21 Sep 2005, Bjorn Helgaas wrote:
>>>
>>>> On Tuesday 20 September 2005 7:32 pm, Li, Shaohua wrote:
>>>>> Is it possible PNP devices use level trigger interrupt?
>>>>> IIRC, PNP devices always use edge trigger interrupt under x86,
>>>>> how about the IA64 case?
>>>>
>>>> I'm not aware of any reason why ACPI devices should always
>>>> be edge triggered on ia64.
>>>>
>>>>> If PNP devices always use edge trigger
>>>>> interrupt,
>>>>> we might ignore BIOS setting.
>>>>> We have a bug BIOS assign wrong interrupt info to RTC
>>>>> http://bugzilla.kernel.org/show_bug.cgi?id=5243
>>>>
>>>> ACPI can describe any combination of edge/level, high/low,
>>>> so I think it would be a bad idea to throw away the information
>>>> the firmware is giving us.
>>>>
>>>> We might have to figure out ways to work around firmware
>>>> defects.  But that seems better to me than just ignoring
>>>> what the firmware tells us.  That will lead to situations
>>>> where the hardware and firmware are perfectly legal and
>>>> correct, but Linux doesn't work (i.e., the hardware uses
>>>> level triggered interrupts for some device, and Linux ignores
>>>> that and treats it as edge-triggered).
>>>
>>> As far as i understand question, it was not about *ALL* ACPI devices
>> but
>>> only about PNP ones.
>>
>> What is the difference between a "PNP" ACPI device and a "non-PNP"
>> ACPI device?  It looks to me like PNPACPI will expose all ACPI
>> devices as PNP devices (with a couple exceptions, like things that
>> don't have any _CRS method).
>>
>>> And IMO the real problem is only RTC on x86 so the
>>> workaround can only force this type of interrupt.
>>
>> Any workaround should be applied as narrowly as possible, to
>> minimize the chance of breaking a platform that legitimately
>> chooses to use a level-triggered interrupt.  If there's a
>> spec or convention that requires RTC to be edge-triggered
>> on x86, I don't object to reflecting that in the code somehow.
> Ok, maybe we could do this workaround for x86 and report a warning.
> Let's see if it breaks anything.

Is there something ready to test? Patches, etc? ;)

Best regards,


 			Krzysztof Olędzki

Re: PNP device interrupt type?

[Shaohua Li]

On Sat, 2005-10-01 at 21:44 +0200, Krzysztof Oledzki wrote:
> 
> On Thu, 22 Sep 2005, Shaohua Li wrote:
> 
> > Hi,
> > Sorry, I wrongly cc-ed the maillist address in previous email.
> >
> > On Wed, 2005-09-21 at 23:16 +0800, Bjorn Helgaas wrote:
> >> On Wednesday 21 September 2005 8:59 am, Krzysztof Oledzki wrote:
> >>> On Wed, 21 Sep 2005, Bjorn Helgaas wrote:
> >>>
> >>>> On Tuesday 20 September 2005 7:32 pm, Li, Shaohua wrote:
> >>>>> Is it possible PNP devices use level trigger interrupt?
> >>>>> IIRC, PNP devices always use edge trigger interrupt under x86,
> >>>>> how about the IA64 case?
> >>>>
> >>>> I'm not aware of any reason why ACPI devices should always
> >>>> be edge triggered on ia64.
> >>>>
> >>>>> If PNP devices always use edge trigger
> >>>>> interrupt,
> >>>>> we might ignore BIOS setting.
> >>>>> We have a bug BIOS assign wrong interrupt info to RTC
> >>>>> http://bugzilla.kernel.org/show_bug.cgi?id=5243
> >>>>
> >>>> ACPI can describe any combination of edge/level, high/low,
> >>>> so I think it would be a bad idea to throw away the information
> >>>> the firmware is giving us.
> >>>>
> >>>> We might have to figure out ways to work around firmware
> >>>> defects.  But that seems better to me than just ignoring
> >>>> what the firmware tells us.  That will lead to situations
> >>>> where the hardware and firmware are perfectly legal and
> >>>> correct, but Linux doesn't work (i.e., the hardware uses
> >>>> level triggered interrupts for some device, and Linux ignores
> >>>> that and treats it as edge-triggered).
> >>>
> >>> As far as i understand question, it was not about *ALL* ACPI devices
> >> but
> >>> only about PNP ones.
> >>
> >> What is the difference between a "PNP" ACPI device and a "non-PNP"
> >> ACPI device?  It looks to me like PNPACPI will expose all ACPI
> >> devices as PNP devices (with a couple exceptions, like things that
> >> don't have any _CRS method).
> >>
> >>> And IMO the real problem is only RTC on x86 so the
> >>> workaround can only force this type of interrupt.
> >>
> >> Any workaround should be applied as narrowly as possible, to
> >> minimize the chance of breaking a platform that legitimately
> >> chooses to use a level-triggered interrupt.  If there's a
> >> spec or convention that requires RTC to be edge-triggered
> >> on x86, I don't object to reflecting that in the code somehow.
> > Ok, maybe we could do this workaround for x86 and report a warning.
> > Let's see if it breaks anything.
> 
> Is there something ready to test? Patches, etc? ;)
Sorry for the long delay. Does this workaround work for you?

--- a/drivers/pnp/pnpacpi/rsparser.c	2005-10-10 09:25:31.000000000 +0800
+++ b/drivers/pnp/pnpacpi/rsparser.c	2005-10-10 09:22:13.000000000 +0800
@@ -89,6 +89,12 @@ pnpacpi_parse_allocated_irqresource(stru
 		return;
 
 	res->irq_resource[i].flags = IORESOURCE_IRQ;  // Also clears _UNSET flag
+#ifdef CONFIG_X86
+	if (gsi < 16 && edge_level != ACPI_EDGE_SENSITIVE) {
+		pnp_err("Legacy IRQ %d should be edge trigger\n", gsi);
+		edge_level = ACPI_EDGE_SENSITIVE;
+	}
+#endif
 	irq = acpi_register_gsi(gsi, edge_level, active_high_low);
 	if (irq < 0) {
 		res->irq_resource[i].flags |= IORESOURCE_DISABLED;




-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl

Re: PNP device interrupt type?

[Krzysztof Oledzki]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 4697 bytes --]



On Mon, 10 Oct 2005, Shaohua Li wrote:

> On Sat, 2005-10-01 at 21:44 +0200, Krzysztof Oledzki wrote:
>>
>> On Thu, 22 Sep 2005, Shaohua Li wrote:
>>
>>> Hi,
>>> Sorry, I wrongly cc-ed the maillist address in previous email.
>>>
>>> On Wed, 2005-09-21 at 23:16 +0800, Bjorn Helgaas wrote:
>>>> On Wednesday 21 September 2005 8:59 am, Krzysztof Oledzki wrote:
>>>>> On Wed, 21 Sep 2005, Bjorn Helgaas wrote:
>>>>>
>>>>>> On Tuesday 20 September 2005 7:32 pm, Li, Shaohua wrote:
>>>>>>> Is it possible PNP devices use level trigger interrupt?
>>>>>>> IIRC, PNP devices always use edge trigger interrupt under x86,
>>>>>>> how about the IA64 case?
>>>>>>
>>>>>> I'm not aware of any reason why ACPI devices should always
>>>>>> be edge triggered on ia64.
>>>>>>
>>>>>>> If PNP devices always use edge trigger
>>>>>>> interrupt,
>>>>>>> we might ignore BIOS setting.
>>>>>>> We have a bug BIOS assign wrong interrupt info to RTC
>>>>>>> http://bugzilla.kernel.org/show_bug.cgi?id=5243
>>>>>>
>>>>>> ACPI can describe any combination of edge/level, high/low,
>>>>>> so I think it would be a bad idea to throw away the information
>>>>>> the firmware is giving us.
>>>>>>
>>>>>> We might have to figure out ways to work around firmware
>>>>>> defects.  But that seems better to me than just ignoring
>>>>>> what the firmware tells us.  That will lead to situations
>>>>>> where the hardware and firmware are perfectly legal and
>>>>>> correct, but Linux doesn't work (i.e., the hardware uses
>>>>>> level triggered interrupts for some device, and Linux ignores
>>>>>> that and treats it as edge-triggered).
>>>>>
>>>>> As far as i understand question, it was not about *ALL* ACPI devices
>>>> but
>>>>> only about PNP ones.
>>>>
>>>> What is the difference between a "PNP" ACPI device and a "non-PNP"
>>>> ACPI device?  It looks to me like PNPACPI will expose all ACPI
>>>> devices as PNP devices (with a couple exceptions, like things that
>>>> don't have any _CRS method).
>>>>
>>>>> And IMO the real problem is only RTC on x86 so the
>>>>> workaround can only force this type of interrupt.
>>>>
>>>> Any workaround should be applied as narrowly as possible, to
>>>> minimize the chance of breaking a platform that legitimately
>>>> chooses to use a level-triggered interrupt.  If there's a
>>>> spec or convention that requires RTC to be edge-triggered
>>>> on x86, I don't object to reflecting that in the code somehow.
>>> Ok, maybe we could do this workaround for x86 and report a warning.
>>> Let's see if it breaks anything.
>>
>> Is there something ready to test? Patches, etc? ;)
> Sorry for the long delay. Does this workaround work for you?
>
> --- a/drivers/pnp/pnpacpi/rsparser.c	2005-10-10 09:25:31.000000000 +0800
> +++ b/drivers/pnp/pnpacpi/rsparser.c	2005-10-10 09:22:13.000000000 +0800
> @@ -89,6 +89,12 @@ pnpacpi_parse_allocated_irqresource(stru
> 		return;
>
> 	res->irq_resource[i].flags = IORESOURCE_IRQ;  // Also clears _UNSET flag
> +#ifdef CONFIG_X86
> +	if (gsi < 16 && edge_level != ACPI_EDGE_SENSITIVE) {
> +		pnp_err("Legacy IRQ %d should be edge trigger\n", gsi);
> +		edge_level = ACPI_EDGE_SENSITIVE;
> +	}
> +#endif
> 	irq = acpi_register_gsi(gsi, edge_level, active_high_low);
> 	if (irq < 0) {
> 		res->irq_resource[i].flags |= IORESOURCE_DISABLED;
>

Not sure... It seems that this check may be to wide - ACPI IRQ #9 seems to 
be LEVEL on all my mainboards and the same is for ide2 & ohci_hcd on a 
different mainboard (ServerWorks):

   0:        154  404777113    IO-APIC-edge  timer
   8:          0       1352    IO-APIC-edge  rtc
   9:          0          0   IO-APIC-level  acpi
  14:          0         13    IO-APIC-edge  ide0


   0: 2107479012          0    IO-APIC-edge  timer
   1:      17349          0    IO-APIC-edge  i8042
   8:          1          0    IO-APIC-edge  rtc
   9:          0          0   IO-APIC-level  acpi
  12:      13394          0    IO-APIC-edge  i8042
  14:         20          0    IO-APIC-edge  ide0

   0: 1751027335          0          0          0  local-APIC-edge  timer
   1:       1299          0          0          0    IO-APIC-edge  i8042
   8:          1          0          0          0    IO-APIC-edge  rtc
   9:          0          0          0          0   IO-APIC-level  acpi, ohci_hcd:usb1
  11:         24          0          0          0   IO-APIC-level  ide2
  12:        474          0          0          0    IO-APIC-edge  i8042


Shouldn't we better force edge_level only for IRQ #8 and maybe #6, #1, #0. 
AIAFK they cannot be assigned to a PCI device?

Best regards,

 			Krzysztof Olędzki

Re: PNP device interrupt type?

[Krzysztof Oledzki]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1360 bytes --]



On Mon, 10 Oct 2005, Shaohua Li wrote:
<CUT>
> Sorry for the long delay. Does this workaround work for you?
>
> --- a/drivers/pnp/pnpacpi/rsparser.c	2005-10-10 09:25:31.000000000 +0800
> +++ b/drivers/pnp/pnpacpi/rsparser.c	2005-10-10 09:22:13.000000000 +0800
> @@ -89,6 +89,12 @@ pnpacpi_parse_allocated_irqresource(stru
> 		return;
>
> 	res->irq_resource[i].flags = IORESOURCE_IRQ;  // Also clears _UNSET flag
> +#ifdef CONFIG_X86
> +	if (gsi < 16 && edge_level != ACPI_EDGE_SENSITIVE) {
> +		pnp_err("Legacy IRQ %d should be edge trigger\n", gsi);
> +		edge_level = ACPI_EDGE_SENSITIVE;
> +	}
> +#endif
> 	irq = acpi_register_gsi(gsi, edge_level, active_high_low);
> 	if (irq < 0) {
> 		res->irq_resource[i].flags |= IORESOURCE_DISABLED;
>
>

Sorry for the long delay, this patch requires 2.6.14-rc kernel so it 
took me much longer to test it. And yes, it works for me. Thank you.

Patched 2.6.14-rc4 kernel logs:

* pnp: PnP ACPI init
* pnp: Legacy IRQ 8 should be edge trigger
* 
* pnp: PnP ACPI: found 12 devices

Only one comment - we should remove this \n from the error message since 
pnp_err adds it automatically:

./linux/pnp.h:#define pnp_err(format, arg...) printk(KERN_ERR "pnp: " format "\n" , ## arg)

Are there any chances for putting this patch into 2.6.15?

Best regards,

 			Krzysztof Olędzki

Re: PNP device interrupt type?

[Krzysztof Oledzki]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1276 bytes --]



On Mon, 10 Oct 2005, Shaohua Li wrote:
> --- a/drivers/pnp/pnpacpi/rsparser.c	2005-10-10 09:25:31.000000000 +0800
> +++ b/drivers/pnp/pnpacpi/rsparser.c	2005-10-10 09:22:13.000000000 +0800
> @@ -89,6 +89,12 @@ pnpacpi_parse_allocated_irqresource(stru
> 		return;
>
> 	res->irq_resource[i].flags = IORESOURCE_IRQ;  // Also clears _UNSET flag
> +#ifdef CONFIG_X86
> +	if (gsi < 16 && edge_level != ACPI_EDGE_SENSITIVE) {
> +		pnp_err("Legacy IRQ %d should be edge trigger\n", gsi);
> +		edge_level = ACPI_EDGE_SENSITIVE;
> +	}
> +#endif
> 	irq = acpi_register_gsi(gsi, edge_level, active_high_low);
> 	if (irq < 0) {
> 		res->irq_resource[i].flags |= IORESOURCE_DISABLED;
>
>

It seems that this workaround solved this problem only partially. CPUs are 
no longer flooded by interrupts (Thanks, thanks!) but hwclock no longer 
works. IRQ count for CPU is increase by one but hwclock fails. Strange.

# cat /proc/interrupts |grep rtc;hwclock; cat /proc/interrupts|grep rtc
   8:          4          0          0          0    IO-APIC-edge  rtc
select() to /dev/rtc to wait for clock tick timed out
   8:          5          0          0          0    IO-APIC-edge  rtc

# cat /proc/irq/8/smp_affinity
1

Best regards,


 				Krzysztof Olędzki

RE: PNP device interrupt type?

[Li, Shaohua]

Hi,
>
>On Mon, 10 Oct 2005, Shaohua Li wrote:
>
>> On Sat, 2005-10-01 at 21:44 +0200, Krzysztof Oledzki wrote:
>>>
>>> On Thu, 22 Sep 2005, Shaohua Li wrote:
>>>
>>>> Hi,
>>>> Sorry, I wrongly cc-ed the maillist address in previous email.
>>>>
>>>> On Wed, 2005-09-21 at 23:16 +0800, Bjorn Helgaas wrote:
>>>>> On Wednesday 21 September 2005 8:59 am, Krzysztof Oledzki wrote:
>>>>>> On Wed, 21 Sep 2005, Bjorn Helgaas wrote:
>>>>>>
>>>>>>> On Tuesday 20 September 2005 7:32 pm, Li, Shaohua wrote:
>>>>>>>> Is it possible PNP devices use level trigger interrupt?
>>>>>>>> IIRC, PNP devices always use edge trigger interrupt under x86,
>>>>>>>> how about the IA64 case?
>>>>>>>
>>>>>>> I'm not aware of any reason why ACPI devices should always
>>>>>>> be edge triggered on ia64.
>>>>>>>
>>>>>>>> If PNP devices always use edge trigger
>>>>>>>> interrupt,
>>>>>>>> we might ignore BIOS setting.
>>>>>>>> We have a bug BIOS assign wrong interrupt info to RTC
>>>>>>>> http://bugzilla.kernel.org/show_bug.cgi?id=5243
>>>>>>>
>>>>>>> ACPI can describe any combination of edge/level, high/low,
>>>>>>> so I think it would be a bad idea to throw away the information
>>>>>>> the firmware is giving us.
>>>>>>>
>>>>>>> We might have to figure out ways to work around firmware
>>>>>>> defects.  But that seems better to me than just ignoring
>>>>>>> what the firmware tells us.  That will lead to situations
>>>>>>> where the hardware and firmware are perfectly legal and
>>>>>>> correct, but Linux doesn't work (i.e., the hardware uses
>>>>>>> level triggered interrupts for some device, and Linux ignores
>>>>>>> that and treats it as edge-triggered).
>>>>>>
>>>>>> As far as i understand question, it was not about *ALL* ACPI
devices
>>>>> but
>>>>>> only about PNP ones.
>>>>>
>>>>> What is the difference between a "PNP" ACPI device and a "non-PNP"
>>>>> ACPI device?  It looks to me like PNPACPI will expose all ACPI
>>>>> devices as PNP devices (with a couple exceptions, like things that
>>>>> don't have any _CRS method).
>>>>>
>>>>>> And IMO the real problem is only RTC on x86 so the
>>>>>> workaround can only force this type of interrupt.
>>>>>
>>>>> Any workaround should be applied as narrowly as possible, to
>>>>> minimize the chance of breaking a platform that legitimately
>>>>> chooses to use a level-triggered interrupt.  If there's a
>>>>> spec or convention that requires RTC to be edge-triggered
>>>>> on x86, I don't object to reflecting that in the code somehow.
>>>> Ok, maybe we could do this workaround for x86 and report a warning.
>>>> Let's see if it breaks anything.
>>>
>>> Is there something ready to test? Patches, etc? ;)
>> Sorry for the long delay. Does this workaround work for you?
>>
>> --- a/drivers/pnp/pnpacpi/rsparser.c	2005-10-10 09:25:31.000000000
>+0800
>> +++ b/drivers/pnp/pnpacpi/rsparser.c	2005-10-10 09:22:13.000000000
>+0800
>> @@ -89,6 +89,12 @@ pnpacpi_parse_allocated_irqresource(stru
>> 		return;
>>
>> 	res->irq_resource[i].flags = IORESOURCE_IRQ;  // Also clears
_UNSET
>flag
>> +#ifdef CONFIG_X86
>> +	if (gsi < 16 && edge_level != ACPI_EDGE_SENSITIVE) {
>> +		pnp_err("Legacy IRQ %d should be edge trigger\n", gsi);
>> +		edge_level = ACPI_EDGE_SENSITIVE;
>> +	}
>> +#endif
>> 	irq = acpi_register_gsi(gsi, edge_level, active_high_low);
>> 	if (irq < 0) {
>> 		res->irq_resource[i].flags |= IORESOURCE_DISABLED;
>>
>
>Not sure... It seems that this check may be to wide - ACPI IRQ #9 seems
to
>be LEVEL on all my mainboards and the same is for ide2 & ohci_hcd on a
>different mainboard (ServerWorks):
>
>   0:        154  404777113    IO-APIC-edge  timer
>   8:          0       1352    IO-APIC-edge  rtc
>   9:          0          0   IO-APIC-level  acpi
>  14:          0         13    IO-APIC-edge  ide0
>
>
>   0: 2107479012          0    IO-APIC-edge  timer
>   1:      17349          0    IO-APIC-edge  i8042
>   8:          1          0    IO-APIC-edge  rtc
>   9:          0          0   IO-APIC-level  acpi
>  12:      13394          0    IO-APIC-edge  i8042
>  14:         20          0    IO-APIC-edge  ide0
>
>   0: 1751027335          0          0          0  local-APIC-edge
timer
>   1:       1299          0          0          0    IO-APIC-edge
i8042
>   8:          1          0          0          0    IO-APIC-edge  rtc
>   9:          0          0          0          0   IO-APIC-level
acpi,
>ohci_hcd:usb1
>  11:         24          0          0          0   IO-APIC-level  ide2
>  12:        474          0          0          0    IO-APIC-edge
i8042
>
>
>Shouldn't we better force edge_level only for IRQ #8 and maybe #6, #1,
#0.
>AIAFK they cannot be assigned to a PCI device?
IDE, OHCI, ACPI's IRQs should not be shared by PNP devices. So the IRQs
should never be passed to the check.
PS. Does the machine work at WinXP? If not, we'd better not apply the
workaround.

Thanks,
Shaohua


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl

RE: PNP device interrupt type?

[Krzysztof Oledzki]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 5452 bytes --]



On Tue, 11 Oct 2005, Li, Shaohua wrote:

> Hi,
>>
>> On Mon, 10 Oct 2005, Shaohua Li wrote:
>>
>>> On Sat, 2005-10-01 at 21:44 +0200, Krzysztof Oledzki wrote:
>>>>
>>>> On Thu, 22 Sep 2005, Shaohua Li wrote:
>>>>
>>>>> Hi,
>>>>> Sorry, I wrongly cc-ed the maillist address in previous email.
>>>>>
>>>>> On Wed, 2005-09-21 at 23:16 +0800, Bjorn Helgaas wrote:
>>>>>> On Wednesday 21 September 2005 8:59 am, Krzysztof Oledzki wrote:
>>>>>>> On Wed, 21 Sep 2005, Bjorn Helgaas wrote:
>>>>>>>
>>>>>>>> On Tuesday 20 September 2005 7:32 pm, Li, Shaohua wrote:
>>>>>>>>> Is it possible PNP devices use level trigger interrupt?
>>>>>>>>> IIRC, PNP devices always use edge trigger interrupt under x86,
>>>>>>>>> how about the IA64 case?
>>>>>>>>
>>>>>>>> I'm not aware of any reason why ACPI devices should always
>>>>>>>> be edge triggered on ia64.
>>>>>>>>
>>>>>>>>> If PNP devices always use edge trigger
>>>>>>>>> interrupt,
>>>>>>>>> we might ignore BIOS setting.
>>>>>>>>> We have a bug BIOS assign wrong interrupt info to RTC
>>>>>>>>> http://bugzilla.kernel.org/show_bug.cgi?id=5243
>>>>>>>>
>>>>>>>> ACPI can describe any combination of edge/level, high/low,
>>>>>>>> so I think it would be a bad idea to throw away the information
>>>>>>>> the firmware is giving us.
>>>>>>>>
>>>>>>>> We might have to figure out ways to work around firmware
>>>>>>>> defects.  But that seems better to me than just ignoring
>>>>>>>> what the firmware tells us.  That will lead to situations
>>>>>>>> where the hardware and firmware are perfectly legal and
>>>>>>>> correct, but Linux doesn't work (i.e., the hardware uses
>>>>>>>> level triggered interrupts for some device, and Linux ignores
>>>>>>>> that and treats it as edge-triggered).
>>>>>>>
>>>>>>> As far as i understand question, it was not about *ALL* ACPI
> devices
>>>>>> but
>>>>>>> only about PNP ones.
>>>>>>
>>>>>> What is the difference between a "PNP" ACPI device and a "non-PNP"
>>>>>> ACPI device?  It looks to me like PNPACPI will expose all ACPI
>>>>>> devices as PNP devices (with a couple exceptions, like things that
>>>>>> don't have any _CRS method).
>>>>>>
>>>>>>> And IMO the real problem is only RTC on x86 so the
>>>>>>> workaround can only force this type of interrupt.
>>>>>>
>>>>>> Any workaround should be applied as narrowly as possible, to
>>>>>> minimize the chance of breaking a platform that legitimately
>>>>>> chooses to use a level-triggered interrupt.  If there's a
>>>>>> spec or convention that requires RTC to be edge-triggered
>>>>>> on x86, I don't object to reflecting that in the code somehow.
>>>>> Ok, maybe we could do this workaround for x86 and report a warning.
>>>>> Let's see if it breaks anything.
>>>>
>>>> Is there something ready to test? Patches, etc? ;)
>>> Sorry for the long delay. Does this workaround work for you?
>>>
>>> --- a/drivers/pnp/pnpacpi/rsparser.c	2005-10-10 09:25:31.000000000
>> +0800
>>> +++ b/drivers/pnp/pnpacpi/rsparser.c	2005-10-10 09:22:13.000000000
>> +0800
>>> @@ -89,6 +89,12 @@ pnpacpi_parse_allocated_irqresource(stru
>>> 		return;
>>>
>>> 	res->irq_resource[i].flags = IORESOURCE_IRQ;  // Also clears
> _UNSET
>> flag
>>> +#ifdef CONFIG_X86
>>> +	if (gsi < 16 && edge_level != ACPI_EDGE_SENSITIVE) {
>>> +		pnp_err("Legacy IRQ %d should be edge trigger\n", gsi);
>>> +		edge_level = ACPI_EDGE_SENSITIVE;
>>> +	}
>>> +#endif
>>> 	irq = acpi_register_gsi(gsi, edge_level, active_high_low);
>>> 	if (irq < 0) {
>>> 		res->irq_resource[i].flags |= IORESOURCE_DISABLED;
>>>
>>
>> Not sure... It seems that this check may be to wide - ACPI IRQ #9 seems
> to
>> be LEVEL on all my mainboards and the same is for ide2 & ohci_hcd on a
>> different mainboard (ServerWorks):
>>
>>   0:        154  404777113    IO-APIC-edge  timer
>>   8:          0       1352    IO-APIC-edge  rtc
>>   9:          0          0   IO-APIC-level  acpi
>>  14:          0         13    IO-APIC-edge  ide0
>>
>>
>>   0: 2107479012          0    IO-APIC-edge  timer
>>   1:      17349          0    IO-APIC-edge  i8042
>>   8:          1          0    IO-APIC-edge  rtc
>>   9:          0          0   IO-APIC-level  acpi
>>  12:      13394          0    IO-APIC-edge  i8042
>>  14:         20          0    IO-APIC-edge  ide0
>>
>>   0: 1751027335          0          0          0  local-APIC-edge
> timer
>>   1:       1299          0          0          0    IO-APIC-edge
> i8042
>>   8:          1          0          0          0    IO-APIC-edge  rtc
>>   9:          0          0          0          0   IO-APIC-level
> acpi,
>> ohci_hcd:usb1
>>  11:         24          0          0          0   IO-APIC-level  ide2
>>  12:        474          0          0          0    IO-APIC-edge
> i8042
>>
>>
>> Shouldn't we better force edge_level only for IRQ #8 and maybe #6, #1,
> #0.
>> AIAFK they cannot be assigned to a PCI device?
> IDE, OHCI, ACPI's IRQs should not be shared by PNP devices. So the IRQs
> should never be passed to the check.
OK. I wasn't aware of this.

> PS. Does the machine work at WinXP? If not, we'd better not apply the
> workaround.

Don't know. It is a dual P4 Xeon Server first powered by Linux 2.4.x and 
now by 2.6.x. I don't have any possibility to install and test WinXP. I'll 
check your patch and let you know what happens. Thank you.


Best regards,

 			Krzysztof Olędzki