linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Thumshirn <johannes.thumshirn@men.de>
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: Johannes Thumshirn <johannes.thumshirn@men.de>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	Yinghai Lu <yinghai@kernel.org>
Subject: Re: PCI reset problem
Date: Thu, 29 Aug 2013 17:07:23 +0200	[thread overview]
Message-ID: <20130829150723.GA32730@jtlinux> (raw)
In-Reply-To: <CAErSpo56RszdMQDOY8xCmz=1QP-osUGA71V56t9X9zY4rNAYew@mail.gmail.com>

On Thu, Aug 29, 2013 at 06:01:43AM -0600, Bjorn Helgaas wrote:
> On Thu, Aug 29, 2013 at 2:29 AM, Johannes Thumshirn
> <johannes.thumshirn@men.de> wrote:
> > On Wed, Aug 28, 2013 at 10:50:58AM -0600, Bjorn Helgaas wrote:
> >> [+cc Yinghai]
> >>
> >> On Wed, Aug 28, 2013 at 7:33 AM, Johannes Thumshirn
> >> <johannes.thumshirn@men.de> wrote:
> >> > Hi List,
> >> >
> >> > I have a rather odd problem with a PCIe swicht/bridge which does not get
> >> > enumerated correctly. If I issue _two_ manual rescans of the PCI bus via sysfs,
> >> > everything get setup correctly. To work around the problem I decided to make a
> >> > platform specific PCI quirk (for the embedded system I'm on, to not break
> >> > anything else) and issue the pci_rescan_bus() myself as a "final" fixup. However
> >> > this does not have any effect at all.
> >> >
> >> > Does anyone have an idea what I could do wrong?
> >>
> >> A rescan doesn't really do anything differently from the initial
> >> boot-time scan.  Maybe there's an issue with the switch taking a long
> >> time to respond after reset?  But that doesn't seem likely, because if
> >> you do manual rescans via sysfs, that should give plenty of time and
> >> you wouldn't have to do it *twice*.
> >>
> >> Maybe there's some resource or bus number allocation issue such that
> >> we don't even get down to the problem switch the first couple of
> >> times?
> >>
> >> > Example:
> >> > root@generic-powerpc:~# lspci -tv
> >> > -[0000:00]---00.0-[01]--
> >> > root@generic-powerpc:~# echo 1 > /sys/bus/pci/rescan
> >> > [...]
> >> > root@generic-powerpc:~# lspci -tv
> >> > -[0000:00]---00.0-[01-05]----00.0-[02-05]--+-01.0-[03]--
> >> >                                            +-02.0-[04]--
> >> >                                            \-03.0-[05]--
> >> > root@generic-powerpc:~# echo 1 > /sys/bus/pci/rescan
> >> > [...]
> >> > root@generic-powerpc:~# lspci -tv
> >> > -[0000:00]---00.0-[01-05]----00.0-[02-05]--+-01.0-[03]----00.0  Silicon Image, Inc. SiI 3132 Serial ATA Raid II Controller
> >> >                                            +-02.0-[04]--
> >> >                                            \-03.0-[05]--+-00.0  Pericom Semiconductor Device 400e
> >> >                                                         +-00.1  Pericom Semiconductor Device 400e
> >> >                                                         \-00.2  Pericom Semiconductor Device 400f
> >>
> >> I bet that's what's happening: the first lspci shows the 00:00.0
> >> bridge leading only to bus 01.  The second lspci shows 00:00.0 leading
> >> to [bus 01-05], so its bus number aperture has been reconfigured.
> >>
> >> On x86 the BIOS typically configures all the bridges so we can see all
> >> the devices.  But it looks like your platform doesn't, and the Linux
> >> paths that do similar configuration are not as well exercised.
> >>
> >
> > I'll have a look into my U-Boot again as well, maybe I can resolve it there.
> >
> >> Can you collect a complete dmesg log including initial boot and your
> >> manual sysfs rescansand attach it to a new bugzilla report at
> >> https://bugzilla.kernel.org/enter_bug.cgi?component=PCI&product=Drivers
> >> ?  There might be some generic way we can fix this.
> >>
> >
> > I can do, though I have to say, it's a 3.8 Kernel from Freescale's SDK. I
> > don't really know if mainline wants to care about it.
>
> I don't think much has changed in this area since then, so I think
> this issue is still relevant.
>
> On x86 there's a boot command option "pci=assign-busses".  I don't
> think the boot option is implemented for other arches, so you'll
> probably have to change the source to accomplish the same thing.  Take
> a look at pcibios_assign_all_busses() for your platform.  If it
> doesn't already return "true", try changing it so it does.  It looks
> like we should try to assign bus numbers when
> pcibios_assign_all_busses() is true.
>
> Bjorn

Unfortunately this didn't change anything at all. As well as adding the
PCI_REASSIGN_ALL_RSRC flag. But while testing I've found the
ppc_md.pcibios_fixup_resources hook. I'll try to manually assign resources in
there or clear them and call the pci core's ressource allocation code. I'll post
an update once I make any progress.

Johannes

  reply	other threads:[~2013-08-29 15:07 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-28 13:33 PCI reset problem Johannes Thumshirn
2013-08-28 16:50 ` Bjorn Helgaas
2013-08-29  8:29   ` Johannes Thumshirn
2013-08-29 12:01     ` Bjorn Helgaas
2013-08-29 15:07       ` Johannes Thumshirn [this message]
2013-08-29 15:52         ` Bjorn Helgaas
2013-08-30  8:01           ` Johannes Thumshirn
2013-08-30 13:40             ` Bjorn Helgaas
2013-08-30 13:58               ` Johannes Thumshirn
2013-08-30 19:46             ` Yinghai Lu
2013-09-02  8:00               ` Johannes Thumshirn
2013-09-02 22:18                 ` Yinghai Lu
2013-09-03  9:55                   ` Johannes Thumshirn
2013-09-03 19:38                     ` Yinghai Lu
2013-09-04  8:10                       ` Johannes Thumshirn
2013-08-29 17:40     ` Yinghai Lu

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=20130829150723.GA32730@jtlinux \
    --to=johannes.thumshirn@men.de \
    --cc=bhelgaas@google.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=yinghai@kernel.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).