Re: Changeset "acpi: disable PCI links at boot again, fix ELCR" -> on-board nic adapter not working

Re: Changeset "acpi: disable PCI links at boot again, fix ELCR" -> on-board nic adapter not working

[Linus Torvalds]

On Tue, 21 Jun 2005, Norbert Federa wrote:
> 
> The difference basically is:
> 2.6.10-rc2-bk7:  ACPI: IRQ9 SCI: Level Trigger.
> 2.6.10-rc2-bk8:  ACPI: setting ELCR to 0200 (from 8a20)

Ok. The original 8a20 mask is irq's 15, 11, 9, and 5. The new mask starts 
out with irq9 (SCI) set up, and we should set the others to level as we 
discover them (and enable them) as PCI interrupts.

Looking at your irq list:

	  0:      54460          XT-PIC  timer
	  1:        168          XT-PIC  i8042
	  2:          0          XT-PIC  cascade
**	  5:          0          XT-PIC  ehci_hcd
**	  9:          0          XT-PIC  acpi
**	 11:          0          XT-PIC  uhci_hcd
	 12:         89          XT-PIC  i8042
	 14:         45          XT-PIC  ide0
**	 15:          0          XT-PIC  uhci_hcd, uhci_hcd, eth0

all of those other three irq's should definitely have triggered, and you
should have ended up with exactly the same ELCR setting in the end. Sadly,
we don't actually print out those changes, but since it's the on-board NIC
adapter that's not working, I'll ignore the other irq's and just look at
irq15. However, it would be interesting to know if you've tried the USB
controllers at all? It sounds like _none_ of those should work either..

The VIA Rhine driver clearly sets up its IRQ and ACPI is happy:

	via-rhine.c:v1.10-LK1.2.0-2.6 June-10-2004 Written by Donald Becker
	ACPI: PCI interrupt 0000:00:12.0[A]: no GSI - using IRQ 15

(the USB drivers do the same things), and I think the magic note here is 
the "no GSI".

That, in turn, causes the code to not call "acpi_register_gsi()", and that 
in turn means that it never does the "eisa_set_level_irq()" call either.

I bet this appended one-liner will fix your problem.

Norbert, can you confirm?

Len, ACPI people, any reason not to do this?

		Linus

---
diff --git a/drivers/acpi/pci_irq.c b/drivers/acpi/pci_irq.c
--- a/drivers/acpi/pci_irq.c
+++ b/drivers/acpi/pci_irq.c
@@ -435,6 +435,7 @@ acpi_pci_irq_enable (
 		/* Interrupt Line values above 0xF are forbidden */
 		if (dev->irq >= 0 && (dev->irq <= 0xF)) {
 			printk(" - using IRQ %d\n", dev->irq);
+			eisa_set_level_irq(dev->irq);
 			return_VALUE(0);
 		}
 		else {


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

Re: Changeset "acpi: disable PCI links at boot again, fix ELCR" -> on-board nic adapter not working

[Linus Torvalds]

On Wed, 22 Jun 2005, Linus Torvalds wrote:
> 
> Len, ACPI people, any reason not to do this?

Apart from the obvious, ie that it's x86[-64] only, of course.

I guess one thing to do would be to call "acpi_register_gsi()" with the 
arguments set to the default PCI values of level/active-low. I don't know 
what the impact of that is, though - what all is "acpi_register_gsi()" 
supposed to do, and how confused migh it get by being called for an irq 
that isn't actually looked up using ACPI methods?

If calling acpi_register_gsi() is ok, then that's probably the preferred 
thing, and solves the architecture issue too..

		Linus


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

Re: Changeset "acpi: disable PCI links at boot again, fix ELCR" -> on-board nic adapter not working

[Norbert Federa]

Linus Torvalds wrote:
> 
> On Tue, 21 Jun 2005, Norbert Federa wrote:
> 
>>The difference basically is:
>>2.6.10-rc2-bk7:  ACPI: IRQ9 SCI: Level Trigger.
>>2.6.10-rc2-bk8:  ACPI: setting ELCR to 0200 (from 8a20)
> 
> 
> Ok. The original 8a20 mask is irq's 15, 11, 9, and 5. The new mask starts 
> out with irq9 (SCI) set up, and we should set the others to level as we 
> discover them (and enable them) as PCI interrupts.
> 
> Looking at your irq list:
> 
> 	  0:      54460          XT-PIC  timer
> 	  1:        168          XT-PIC  i8042
> 	  2:          0          XT-PIC  cascade
> **	  5:          0          XT-PIC  ehci_hcd
> **	  9:          0          XT-PIC  acpi
> **	 11:          0          XT-PIC  uhci_hcd
> 	 12:         89          XT-PIC  i8042
> 	 14:         45          XT-PIC  ide0
> **	 15:          0          XT-PIC  uhci_hcd, uhci_hcd, eth0
> 
> all of those other three irq's should definitely have triggered, and you
> should have ended up with exactly the same ELCR setting in the end. Sadly,
> we don't actually print out those changes, but since it's the on-board NIC
> adapter that's not working, I'll ignore the other irq's and just look at
> irq15. However, it would be interesting to know if you've tried the USB
> controllers at all? It sounds like _none_ of those should work either..
> 
> The VIA Rhine driver clearly sets up its IRQ and ACPI is happy:
> 
> 	via-rhine.c:v1.10-LK1.2.0-2.6 June-10-2004 Written by Donald Becker
> 	ACPI: PCI interrupt 0000:00:12.0[A]: no GSI - using IRQ 15
> 
> (the USB drivers do the same things), and I think the magic note here is 
> the "no GSI".
> 
> That, in turn, causes the code to not call "acpi_register_gsi()", and that 
> in turn means that it never does the "eisa_set_level_irq()" call either.
> 
> I bet this appended one-liner will fix your problem.
> 
> Norbert, can you confirm?
> 
> Len, ACPI people, any reason not to do this?
> 
> 		Linus
> 
> ---
> diff --git a/drivers/acpi/pci_irq.c b/drivers/acpi/pci_irq.c
> --- a/drivers/acpi/pci_irq.c
> +++ b/drivers/acpi/pci_irq.c
> @@ -435,6 +435,7 @@ acpi_pci_irq_enable (
>  		/* Interrupt Line values above 0xF are forbidden */
>  		if (dev->irq >= 0 && (dev->irq <= 0xF)) {
>  			printk(" - using IRQ %d\n", dev->irq);
> +			eisa_set_level_irq(dev->irq);
>  			return_VALUE(0);
>  		}
>  		else {
> 

Everything confirmed.
I've added the one-liner to 2.6.12 and the on-board nic is working
fine now. Also your assumption wrt the usb-controllers was right.

-- Norbert


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

Re: Changeset "acpi: disable PCI links at boot again, fix ELCR" -> on-board nic adapter not working

[Linus Torvalds]

On Thu, 23 Jun 2005, Norbert Federa wrote:
> 
> Everything confirmed.
> I've added the one-liner to 2.6.12 and the on-board nic is working
> fine now. Also your assumption wrt the usb-controllers was right.

Len, acpi-developers, please tell me which one you prefer.

		Linus

diff --git a/drivers/acpi/pci_irq.c b/drivers/acpi/pci_irq.c
--- a/drivers/acpi/pci_irq.c
+++ b/drivers/acpi/pci_irq.c
@@ -435,6 +435,12 @@ acpi_pci_irq_enable (
 		/* Interrupt Line values above 0xF are forbidden */
 		if (dev->irq >= 0 && (dev->irq <= 0xF)) {
 			printk(" - using IRQ %d\n", dev->irq);
+/* Pick one! */
+#if 1
+			acpi_register_gsi(dev->irq, ACPI_LEVEL_SENSITIVE, ACPI_ACTIVE_LOW);
+#else
+			eisa_set_level_irq(dev->irq);
+#endif
 			return_VALUE(0);
 		}
 		else {


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

Re: Re: Changeset "acpi: disable PCI links at boot again, fix ELCR" -> on-board nic adapter not working

[Bjorn Helgaas]

On Friday 24 June 2005 12:01 pm, Linus Torvalds wrote:
> 
> On Thu, 23 Jun 2005, Norbert Federa wrote:
> > 
> > Everything confirmed.
> > I've added the one-liner to 2.6.12 and the on-board nic is working
> > fine now. Also your assumption wrt the usb-controllers was right.
> 
> Len, acpi-developers, please tell me which one you prefer.

I haven't heard from Len for a while, maybe he's on vacation?

My preference is to use acpi_register_gsi() rather than
calling eisa_set_level_irq() directly.

> diff --git a/drivers/acpi/pci_irq.c b/drivers/acpi/pci_irq.c
> --- a/drivers/acpi/pci_irq.c
> +++ b/drivers/acpi/pci_irq.c
> @@ -435,6 +435,12 @@ acpi_pci_irq_enable (
>  		/* Interrupt Line values above 0xF are forbidden */
>  		if (dev->irq >= 0 && (dev->irq <= 0xF)) {
>  			printk(" - using IRQ %d\n", dev->irq);
> +/* Pick one! */
> +#if 1
> +			acpi_register_gsi(dev->irq, ACPI_LEVEL_SENSITIVE, ACPI_ACTIVE_LOW);
> +#else
> +			eisa_set_level_irq(dev->irq);
> +#endif
>  			return_VALUE(0);
>  		}
>  		else {


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

Re: Re: Changeset "acpi: disable PCI links at boot again, fix ELCR" -> on-board nic adapter not working

[Linus Torvalds]

On Fri, 24 Jun 2005, Bjorn Helgaas wrote:
> 
> My preference is to use acpi_register_gsi() rather than
> calling eisa_set_level_irq() directly.

Ok. Norbert, just because I'm anal, can you verify that that version also
fixes it before I commit it?

		Linus

> 
> > diff --git a/drivers/acpi/pci_irq.c b/drivers/acpi/pci_irq.c
> > --- a/drivers/acpi/pci_irq.c
> > +++ b/drivers/acpi/pci_irq.c
> > @@ -435,6 +435,12 @@ acpi_pci_irq_enable (
> >  		/* Interrupt Line values above 0xF are forbidden */
> >  		if (dev->irq >= 0 && (dev->irq <= 0xF)) {
> >  			printk(" - using IRQ %d\n", dev->irq);
> > +/* Pick one! */
> > +#if 1
> > +			acpi_register_gsi(dev->irq, ACPI_LEVEL_SENSITIVE, ACPI_ACTIVE_LOW);
> > +#else
> > +			eisa_set_level_irq(dev->irq);
> > +#endif
> >  			return_VALUE(0);
> >  		}
> >  		else {
> 


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

Re: Re: Changeset "acpi: disable PCI links at boot again, fix ELCR" -> on-board nic adapter not working

[Norbert Federa]

Linus Torvalds wrote:
> 
> On Fri, 24 Jun 2005, Bjorn Helgaas wrote:
> 
>>My preference is to use acpi_register_gsi() rather than
>>calling eisa_set_level_irq() directly.
> 
> 
> Ok. Norbert, just because I'm anal, can you verify that that version also
> fixes it before I commit it?
> 
> 		Linus
> 

Verified. Calling acpi_register_gsi() does also fix the
problem with the on-board via-rhine nic.

Linus, one thing to note regarding your assumption about
the usb-controllers which I forgot to mention:

<LT>However, it would be interesting to know if you've tried the
<LT>USB controllers at all? It sounds like _none_ of those should
<LT>work either..

You were right with this assumption for kernel 2.6.10-rc2-bk8.
Without the above on-liner neither the usb controllers nor the
on-board-nic did work on 2.6.10-rc2-bk8. But they _did_ work on
2.6.12-vanilla _without_ having to call acpi_register_gsi() or
eisa_set_level_irq() directly.

-- Norbert



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

Re: Re: Changeset "acpi: disable PCI links at boot again, fix ELCR" -> on-board nic adapter not working

[Alexander Nyberg]

> > My preference is to use acpi_register_gsi() rather than
> > calling eisa_set_level_irq() directly.
> 
> Ok. Norbert, just because I'm anal, can you verify that that version also
> fixes it before I commit it?

It appears this change:

diff --git a/drivers/acpi/pci_irq.c b/drivers/acpi/pci_irq.c
--- a/drivers/acpi/pci_irq.c
+++ b/drivers/acpi/pci_irq.c
@@ -435,6 +435,7 @@ acpi_pci_irq_enable (
                /* Interrupt Line values above 0xF are forbidden */
                if (dev->irq >= 0 && (dev->irq <= 0xF)) {
                        printk(" - using IRQ %d\n", dev->irq);
+                       acpi_register_gsi(dev->irq, ACPI_LEVEL_SENSITIVE, ACPI_ACTIVE_LOW);
                        return_VALUE(0);
                }
                else {


Caused some problems reported at:
http://bugme.osdl.org/show_bug.cgi?id=4824

Will the acpi guys reassign this bug to them?



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

Re: Re: Changeset "acpi: disable PCI links at boot again, fix ELCR" -> on-board nic adapter not working

[Linus Torvalds]

On Sat, 2 Jul 2005, Alexander Nyberg wrote:
> 
> It appears this change:
> 
> diff --git a/drivers/acpi/pci_irq.c b/drivers/acpi/pci_irq.c
> --- a/drivers/acpi/pci_irq.c
> +++ b/drivers/acpi/pci_irq.c
> @@ -435,6 +435,7 @@ acpi_pci_irq_enable (
>                 /* Interrupt Line values above 0xF are forbidden */
>                 if (dev->irq >= 0 && (dev->irq <= 0xF)) {
>                         printk(" - using IRQ %d\n", dev->irq);
> +                       acpi_register_gsi(dev->irq, ACPI_LEVEL_SENSITIVE, ACPI_ACTIVE_LOW);
>                         return_VALUE(0);
>                 }

Yes, that guy has:


	ACPI: PCI Interrupt 0000:00:10.0[A]: no GSI - using IRQ 0

and the fix is obvious: we should _not_ consider "irq 0" to be a valid 
irq, it's a sign that we don't have any irq at all.

I bet the correct thing to do is to change the "dev->irq >= 0" to 
"dev->irq > 0".

		Linus


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click