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

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

---

@@ -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

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

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

Linus

@@ -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

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.

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

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

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

It appears this change:

@@ -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