diff mbox

Kernel panic - not syncing: Irrecoverable deferred error trap

Message ID 20100403.011632.111570804.davem@davemloft.net
State Accepted
Delegated to: David Miller
Headers show

Commit Message

David Miller April 3, 2010, 8:16 a.m. UTC 
From: Frans van Berckel <fberckel@xs4all.nl>
Date: Sat, 03 Apr 2010 09:09:41 +0200

> On Fri, 2010-04-02 at 23:47 -0700, David Miller wrote:
>> Frans, please retry your test case, but please add
>> "of_debug=1 ofpci_debug=1" to the kernel command line
>> options.
>> 
>> Send the kernel log you get as a result, thanks!
> 
> Attached the boot log

I see the problem.

The XVR-1200 has extra PCI subfunction devices representing secondary
and further monitors attached to the card.

These nodes are special and we should not try to drive them.

Out of curiosity do you have multiple monitors hooked up to the
XVR-1200 device, or just one?

I bet this might explain the XVR-600 failures I could not reproduce,
as seen by Paul Cao, CC:'d.  Paul if you had two monitors hooked up to
your XVR-600, try next time installing with just one monitor attached.

Frans, if you could test the patch below I'd really appreciate it.

Also, once you get this working, please send me "prtconf -pv" output
for this machine with both of these graphics cards in it.

Thanks again for your reports and all of your help so far!

--------------------
sunxvr500: Ignore secondary output PCI devices.

These just represent the secondary and further heads attached to the
card, and they have different sets of PCI bar registers to map.

So don't try to drive them in the main driver.

Reported-by: Frans van Berckel <fberckel@xs4all.nl>
Signed-off-by: David S. Miller <davem@davemloft.net>

--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Frans van Berckel April 3, 2010, 3:13 p.m. UTC | #1 
On Sat, 2010-04-03 at 01:16 -0700, David Miller wrote:
> I see the problem.
> 
> The XVR-1200 has extra PCI subfunction devices representing secondary
> and further monitors attached to the card.
> 
> These nodes are special and we should not try to drive them.
> 
> Out of curiosity do you have multiple monitors hooked up to the
> XVR-1200 device, or just one?

Ahhh ahhm ... choose a other option, non monitors is hooked up.

> I bet this might explain the XVR-600 failures I could not reproduce,
> as seen by Paul Cao, CC:'d.  Paul if you had two monitors hooked up to
> your XVR-600, try next time installing with just one monitor attached.
> 
> Frans, if you could test the patch below I'd really appreciate it.

Gonna do this compile run next. Just a 2.6.26 or 2.6.34?

> Also, once you get this working, please send me "prtconf -pv" output
> for this machine with both of these graphics cards in it.

As promised, will do.

> Thanks again for your reports and all of your help so far!

And thanks supporting us!

--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
David Miller April 3, 2010, 10:12 p.m. UTC | #2 
From: Frans van Berckel <fberckel@xs4all.nl>
Date: Sat, 03 Apr 2010 17:13:46 +0200

> On Sat, 2010-04-03 at 01:16 -0700, David Miller wrote:
>> Out of curiosity do you have multiple monitors hooked up to the
>> XVR-1200 device, or just one?
> 
> Ahhh ahhm ... choose a other option, non monitors is hooked up.

Ok, so the device node we need to ignore seems to show up
on any card that supports multihead at all, regardless of
whether there are monitors attached to the inputs.

And this set of cards would include at least the XVR-1200

>> I bet this might explain the XVR-600 failures I could not reproduce,
>> as seen by Paul Cao, CC:'d.  Paul if you had two monitors hooked up to
>> your XVR-600, try next time installing with just one monitor attached.
>> 
>> Frans, if you could test the patch below I'd really appreciate it.
> 
> Gonna do this compile run next. Just a 2.6.26 or 2.6.34?

It doesn't matter, either way works to test this fix.

Thanks again.
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
David Miller April 4, 2010, 8:01 a.m. UTC | #3 
From: Frans van Berckel <fberckel@xs4all.nl>
Date: Sun, 04 Apr 2010 09:45:13 +0200

> Good new, it boots ... attaching 
> 
> xvr-1200-booting-now.txt
> prtconf-pv+sb2000+xvr1000+xvr1200.txt

Thanks so much for testing.
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff --git a/drivers/video/sunxvr500.c b/drivers/video/sunxvr500.c
index 4cd5049..3803745 100644
--- a/drivers/video/sunxvr500.c
+++ b/drivers/video/sunxvr500.c
@@ -242,11 +242,27 @@  static int __devinit e3d_set_fbinfo(struct e3d_info *ep)
 static int __devinit e3d_pci_register(struct pci_dev *pdev,
 				      const struct pci_device_id *ent)
 {
+	struct device_node *of_node;
+	const char *device_type;
 	struct fb_info *info;
 	struct e3d_info *ep;
 	unsigned int line_length;
 	int err;
 
+	of_node = pci_device_to_OF_node(pdev);
+	if (!of_node) {
+		printk(KERN_ERR "e3d: Cannot find OF node of %s\n",
+		       pci_name(pdev));
+		return -ENODEV;
+	}
+
+	device_type = of_get_property(of_node, "device_type", NULL);
+	if (!device_type) {
+		printk(KERN_INFO "e3d: Ignoring secondary output device "
+		       "at %s\n", pci_name(pdev));
+		return -ENODEV;
+	}
+
 	err = pci_enable_device(pdev);
 	if (err < 0) {
 		printk(KERN_ERR "e3d: Cannot enable PCI device %s\n",
@@ -265,13 +281,7 @@  static int __devinit e3d_pci_register(struct pci_dev *pdev,
 	ep->info = info;
 	ep->pdev = pdev;
 	spin_lock_init(&ep->lock);
-	ep->of_node = pci_device_to_OF_node(pdev);
-	if (!ep->of_node) {
-		printk(KERN_ERR "e3d: Cannot find OF node of %s\n",
-		       pci_name(pdev));
-		err = -ENODEV;
-		goto err_release_fb;
-	}
+	ep->of_node = of_node;
 
 	/* Read the PCI base register of the frame buffer, which we
 	 * need in order to interpret the RAMDAC_VID_*FB* values in