On Thu, Aug 29, 2013 at 1:29 AM, Johannes Thumshirn <johannes.thumshirn@xxxxxx> wrote: > On Wed, Aug 28, 2013 at 10:50:58AM -0600, Bjorn Helgaas wrote: >> [+cc Yinghai] ... >> > 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 ... >> 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*. Can you confirm that? If you wait long enough, and you only need issue one rescan? >> >> 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. let us know if you can test other kernel. If so, i would rebase pci-busn-alloc branch, so you could test on it. Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
