Re: pnp bug in 2.6.27-rc1 (ad1816a / mpu401 / parport_pc issue)

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
From: Bjorn Helgaas
Date: Tuesday, August 12, 2008 - 11:10 am

On Tuesday 12 August 2008 05:17:26 am Uwe Bugla wrote:

Thanks a lot for your detailed observations.

Your dmesg logs are still missing the interesting part at the beginning.
Can you find the entire log in /var/log/messages or something similar?

These lines are from your case C log, but the same thing probably
happened in case B:

  parport_pc 00:0a: reported by Plug and Play ACPI
  parport0: PC-style at 0x378, irq 7 [PCSPP(,...)]
  parport_pc 00:0a: driver attached
  parport1: PC-style at 0x278 [PCSPP(,...)]

We found parport0 via PNPACPI, but you mentioned that parport1 is a
non-PNP ISA card with jumpers on it.  In that case, the parport_pc
driver doesn't try to use an IRQ unless one is specified with a
module parameter.  It's possible the driver could guess somehow,
but I don't know enough to propose any changes here.

I think you could use "options parport_pc io=0x278 irq=5", i.e.,
you probably only need to tell the driver about the non-PNP
device.


The only difference here is that the MPU has no IRQ.  You can see from
the log how all the possibilities (5, 7, 9, 10, 11, 15) are already
used by ad1816a, parport0, and some PCI devices.

With IRQs 5 & 7 reserved for ISA use, PCI device 00:08.0 (aic7xxx)
uses IRQ 11.  With no IRQs reserved, that device uses IRQ 10.  Without
the beginning of the log, I can't tell whether Linux or the BIOS
changed that assignment.

PNP is supposed to notice IRQs that are in use by active PNP
devices, as well as those that could possibly be used, so we can try
to avoid them when we configure PCI interrupt links.  But it looks
like some of this logic is missing from ISAPNP.  Can you try the
experimental patch below to see whether it helps?  It won't change
parport, of course, but you might get an MPU IRQ.


I don't think the kernel has enough information to make a different
decision.  The kernel doesn't know anything about the configuration
of the non-PNP ISA card.  I think you'd have to use a boot parameter
like "pnp_reserve_irq=5" to tell Linux that it can't use IRQ 5 when
it configures the sound card.


Yes, that would be good.  But I think the only way to achieve this
reliably is to use the "pnp_reserve_irq=5" kernel parameter and the
"options parport_pc io=0x278 irq=5" module parameter.  Otherwise the
kernel doesn't know how the jumpers on the ISA parport card are set.


I think we ought to just remove this message completely and add a
new message when the driver claims a device, something like the
attached patch does.


I find Linux sound completely incomprehensible myself.  Fortunately,
it's easy for me to live without it :-)

Bjorn


diff --git a/drivers/pnp/isapnp/core.c b/drivers/pnp/isapnp/core.c
index 101a835..27596f0 100644
--- a/drivers/pnp/isapnp/core.c
+++ b/drivers/pnp/isapnp/core.c
@@ -42,6 +42,7 @@
 #include <linux/init.h>
 #include <linux/isapnp.h>
 #include <linux/mutex.h>
+#include <linux/pci.h>
 #include <asm/io.h>
 
 #include "../base.h"
@@ -110,6 +111,7 @@ MODULE_LICENSE("GPL");
 static unsigned char isapnp_checksum_value;
 static DEFINE_MUTEX(isapnp_cfg_mutex);
 static int isapnp_csn_count;
+static int isapnp_get_resources(struct pnp_dev *dev);
 
 /* some prototypes */
 
@@ -421,7 +423,7 @@ static struct pnp_dev *__init isapnp_parse_device(struct pnp_card *card,
 	dev->capabilities |= PNP_READ;
 	dev->capabilities |= PNP_WRITE;
 	dev->capabilities |= PNP_DISABLE;
-	pnp_init_resources(dev);
+	isapnp_get_resources(dev);
 	return dev;
 }
 
@@ -920,6 +922,8 @@ static int isapnp_get_resources(struct pnp_dev *dev)
 	}
 	for (i = 0; i < ISAPNP_MAX_IRQ; i++) {
 		ret = isapnp_read_word(ISAPNP_CFG_IRQ + (i << 1)) >> 8;
+		if (ret)
+			pcibios_penalize_isa_irq(ret, 1);
 		pnp_add_irq_resource(dev, ret,
 				     ret == 0 ? IORESOURCE_DISABLED : 0);
 	}
diff --git a/sound/drivers/mpu401/mpu401.c b/sound/drivers/mpu401/mpu401.c
index 5b996f3..61c6157 100644
--- a/sound/drivers/mpu401/mpu401.c
+++ b/sound/drivers/mpu401/mpu401.c
@@ -124,6 +124,8 @@ static int __devinit snd_mpu401_probe(struct platform_device *devptr)
 		return err;
 	}
 	platform_set_drvdata(devptr, card);
+	dev_info(&devptr->dev, "MPU401 UART at port %#lx, IRQ %d\n",
+		 port[dev], irq[dev]);
 	return 0;
 }
 
@@ -206,6 +208,8 @@ static int __devinit snd_mpu401_pnp_probe(struct pnp_dev *pnp_dev,
 		pnp_set_drvdata(pnp_dev, card);
 		snd_mpu401_devices++;
 		++dev;
+		dev_info(&pnp_dev->dev, "MPU401 UART at port %#lx, IRQ %d\n",
+			 port[dev], irq[dev]);
 		return 0;
 	}
 	return -ENODEV;
@@ -271,9 +275,6 @@ static int __init alsa_card_mpu401_init(void)
 		pnp_registered = 1;
 
 	if (!snd_mpu401_devices) {
-#ifdef MODULE
-		printk(KERN_ERR "MPU-401 device not found or device busy\n");
-#endif
 		snd_mpu401_unregister_all();
 		return -ENODEV;
 	}
--
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
Re: pnp bug in 2.6.27-rc1 (ad1816a / mpu401 / parport_pc i ..., Bjorn Helgaas, (Tue Aug 12, 11:10 am)