linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Ayman El-Khashab <AymanE@tanisys.com>
Cc: linuxppc-dev@ozlabs.org
Subject: RE: Problems with PCI-E devices not being detected with switch
Date: Sat, 18 Oct 2008 08:19:00 +1100	[thread overview]
Message-ID: <1224278340.7654.103.camel@pasglop> (raw)
In-Reply-To: <16691A8B34B5D9458EA3A1C37A11555A0137F829@tanisys-ex2.Tanisys.Local>

On Fri, 2008-10-17 at 09:54 -0500, Ayman El-Khashab wrote:
> Benjamin Herrenschmidt wrote:
> > On Thu, 2008-10-16 at 10:01 -0500, Ayman El-Khashab wrote:
> >> Benjamin Herrenschmidt wrote:
> >>> On Wed, 2008-10-15 at 10:47 -0500, Ayman El-Khashab wrote:
> >>> 
> >>> Note for people on CC: This is a problem on 460EX on a canyonland
> >>> using the 4x port. 
> >>> 
> > 
> > Ok, can you send me a full dmesg log with "debug" on the kernel
> > command line after adding a #define DEBUG 1 to the top of
> > drivers/pci/probe.c please ? (before the batch of #include).  
> > 
> 
> Yes, it is below.  I saw the #define DEBUG 1 turned on these messages
> below, but I am not sure how to verify that I correctly added the 
> "debug" to the kernel arguments.  (In u-boot I added them to the end
> of the ramargs variable)

Can you try this (untested) patch and send me the resulting dmesg log
(along with whether it helps).

I think I know what the problem is. This isn't the "proper" solution
that should be implemented but it might help with the generic code
detecting that something is wrong and fixing it up.

I'll look at doing something better next week.

The problem I -think- is the bus numbers in the switch don't get reset
by the PCI-E reset below the root complex. Thus when the kernel probes,
it finds non sensical numbers in there that don't fit the range assigned
to the parent bus.

We can force the kernel to renumber everything with a flag but that will
cause problems with the root complex on 4xx due to other considerations
(that we need to fix too, mainly the way we limit config space to a
subset of bus numbers, we need to switch to dynamic fixmap for config
space to solve that).

If my theory is correct, this patch should help the kernel detect that
something is wrong on the switch and reconfigure it.

Cheers,
Ben.

Index: linux-work/drivers/pci/probe.c
===================================================================
--- linux-work.orig/drivers/pci/probe.c	2008-10-18 08:10:25.000000000 +1100
+++ linux-work/drivers/pci/probe.c	2008-10-18 08:14:14.000000000 +1100
@@ -536,19 +536,27 @@
 	int is_cardbus = (dev->hdr_type == PCI_HEADER_TYPE_CARDBUS);
 	u32 buses, i, j = 0;
 	u16 bctl;
+	int broken = 0;
 
 	pci_read_config_dword(dev, PCI_PRIMARY_BUS, &buses);
 
 	dev_dbg(&dev->dev, "scanning behind bridge, config %06x, pass %d\n",
 		buses & 0xffffff, pass);
 
+	/* Check if setup is sensible at all */
+	if ((buses & 0xff) != bus->number ||
+	    ((buses >> 8) & 0xff) != <= bus->number) {
+		dev_dbg(&dev->dev, "bus configuration doesn't match, reconfiguring\n");
+		broken = 1;
+	}
+
 	/* Disable MasterAbortMode during probing to avoid reporting
 	   of bus errors (in some architectures) */ 
 	pci_read_config_word(dev, PCI_BRIDGE_CONTROL, &bctl);
 	pci_write_config_word(dev, PCI_BRIDGE_CONTROL,
 			      bctl & ~PCI_BRIDGE_CTL_MASTER_ABORT);
 
-	if ((buses & 0xffff00) && !pcibios_assign_all_busses() && !is_cardbus) {
+	if ((buses & 0xffff00) && !pcibios_assign_all_busses() && !is_cardbus && !broken) {
 		unsigned int cmax, busnr;
 		/*
 		 * Bus already configured by firmware, process it in the first
@@ -586,7 +594,7 @@
 		 * do in the second pass.
 		 */
 		if (!pass) {
-			if (pcibios_assign_all_busses())
+			if (pcibios_assign_all_busses() || broken)
 				/* Temporarily disable forwarding of the
 				   configuration cycles on all bridges in
 				   this bus segment to avoid possible

  parent reply	other threads:[~2008-10-17 21:19 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-15 15:47 Problems with PCI-E devices not being detected with switch Ayman El-Khashab
2008-10-16  5:20 ` Benjamin Herrenschmidt
2008-10-16  8:03   ` Stefan Roese
2008-10-16  8:29     ` Benjamin Herrenschmidt
2008-10-16  8:48       ` Stefan Roese
2008-10-16  8:58         ` Benjamin Herrenschmidt
2008-10-16 15:01   ` Ayman El-Khashab
2008-10-16 21:19     ` Benjamin Herrenschmidt
2008-10-17  0:10     ` Benjamin Herrenschmidt
2008-10-17  7:22       ` Stefan Roese
2008-10-17 14:54       ` Ayman El-Khashab
2008-10-17 21:05         ` Benjamin Herrenschmidt
2008-10-17 21:19         ` Benjamin Herrenschmidt [this message]
2008-10-20 21:03           ` Ayman El-Khashab
2008-10-20 21:57             ` Benjamin Herrenschmidt
2008-10-20 22:14               ` Ayman El-Khashab
2008-10-20 22:55                 ` Benjamin Herrenschmidt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1224278340.7654.103.camel@pasglop \
    --to=benh@kernel.crashing.org \
    --cc=AymanE@tanisys.com \
    --cc=linuxppc-dev@ozlabs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).