Brian C. Huffman <bhuffman@graze.net> reports: > I have an Intel DP43BF motherboard with 4 PCI slots, 2 PCIe x1 and 1 PCIe x16 > slots. With 2.6.36-rc2-git5 (as well as stable 2.6.34 and .35), the kernel > doesn't see my conventional PCI devices. They can be seen with dmidecode > but do not show up with lspci. I've tried pci=noacpi, pci=use_crs and while > it takes the options, it doesn't change the visibility of the devices. > These same devices (a PVR250,Maudio Delta DiO, and Fusion HD DVB card) > previously worked with another motherboard. Brian determined that the devices work correctly under Windows XP SP2, and they also work under Linux if we use "pci=assign-busses". The bug here is that Linux should be smart enough to work even without "pci=assign-busses".
Created attachment 29802 [details] dmesg (devices not detected) dmesg where we don't find the conventional PCI devices.
Created attachment 29812 [details] dmesg (devices detected) Here's a log with "pci=assign-busses", where we do detect the devices.
If this is still seen with modern kernels please update/re-open the bug, thanks
The bug is still there with behaviour exactly as specified by reporter. Tested with linux-3.4.9 (gentoo), DP43BF motherboard and Intel PRO/1000 NICs. With pci=assign-busses lspci shows devices properly, without it nothing is in the list.
On Fri, Sep 7, 2012 at 2:40 PM, <bugzilla-daemon@bugzilla.kernel.org> wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=18412 > --- Comment #4 from VL <vl.homutov@gmail.com> 2012-09-07 21:40:04 --- > The bug is still there with behaviour exactly as specified by reporter. > > Tested with linux-3.4.9 (gentoo), DP43BF motherboard and Intel PRO/1000 NICs. > With pci=assign-busses lspci shows devices properly, without it nothing > is in the list. Anybody who wants to help with bugs like this, feel free :) There are a number of open regressions and bugs in the PCI subsystem of https://bugzilla.kernel.org/ I spend a lot of time looking at these bugs, and that reduces the time I have to review and apply patches.
On Fri, Sep 7, 2012 at 2:52 PM, Bjorn Helgaas <bhelgaas@google.com> wrote: > On Fri, Sep 7, 2012 at 2:40 PM, <bugzilla-daemon@bugzilla.kernel.org> wrote: >> https://bugzilla.kernel.org/show_bug.cgi?id=18412 > >> --- Comment #4 from VL <vl.homutov@gmail.com> 2012-09-07 21:40:04 --- >> The bug is still there with behaviour exactly as specified by reporter. >> >> Tested with linux-3.4.9 (gentoo), DP43BF motherboard and Intel PRO/1000 >> NICs. >> With pci=assign-busses lspci shows devices properly, without it nothing >> is in the list. VL, I rebased for-pci-busn-alloc branch to current pci-next please check if could fix the problem. git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git for-pci-busn-alloc http://git.kernel.org/?p=linux/kernel/git/yinghai/linux-yinghai.git;a=shortlog;h=refs/heads/for-pci-busn-alloc Thanks Yinghai
Thank you, I'll give it a try and report results
On Fri, Sep 7, 2012 at 3:15 PM, Yinghai Lu <yinghai@kernel.org> wrote: > On Fri, Sep 7, 2012 at 2:52 PM, Bjorn Helgaas <bhelgaas@google.com> wrote: >> On Fri, Sep 7, 2012 at 2:40 PM, <bugzilla-daemon@bugzilla.kernel.org> >> wrote: >>> https://bugzilla.kernel.org/show_bug.cgi?id=18412 >> >>> --- Comment #4 from VL <vl.homutov@gmail.com> 2012-09-07 21:40:04 --- >>> The bug is still there with behaviour exactly as specified by reporter. >>> >>> Tested with linux-3.4.9 (gentoo), DP43BF motherboard and Intel PRO/1000 >>> NICs. >>> With pci=assign-busses lspci shows devices properly, without it nothing >>> is in the list. > > VL, > > I rebased for-pci-busn-alloc branch to current pci-next > > please check if could fix the problem. > > git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git > for-pci-busn-alloc > > > http://git.kernel.org/?p=linux/kernel/git/yinghai/linux-yinghai.git;a=shortlog;h=refs/heads/for-pci-busn-alloc > also you could try attached patch Thanks Yinghai
Created attachment 79461 [details] check bus range to reject invalid one. it seems attachment from mail get dropped by bugzilla.
I confirm that this kernel: git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git solves problem.
Created attachment 79481 [details] dmesg, lspci and other info on old and tested kernels The tarball contains output of dmesg, lspci, lshw, dmidecode and uname commands for 3.4.9 with and without pci-assign-busses option passed and 3.5 from git provided by yinghai
Thanks! The dmesg logs are incomplete and don't start early enough to show exactly what fixed the problem. But I suspect the problem is that the BIOS left the 00:1e.0 bridge programmed like this (from the gentoo-3.4.9 kernel): pci 0000:00:1e.0: PCI bridge to [bus 20-08] (subtractive decode) where the bus number range is clearly wrong. With Yinghai's kernel we reset that to [bus 08]. I assume you're using the "for-pci-busn-alloc" branch of Yinghai's tree. There are things on that branch that I'm not comfortable with yet, so we need to identify the specific change that fixes your box. Given the [bus 20-08] range, I suspect that the patch in comment #9 may fix it, and that's something we could apply. Can you try just that patch on top of a 3.5 or 3.6-rc4 kernel?
Created attachment 79521 [details] full dmesg,lspci,lshw,uname with adn without suggested patch Two sets of outputs for 3.5.3 gentoo kernel with and without suggested patch applied.
> Given the [bus 20-08] range, I suspect that the patch in comment #9 may fix > it, > and that's something we could apply. Can you try just that patch on top of a > 3.5 or 3.6-rc4 kernel? yes, this patch fixes the problem. I've increased kernel buffer length and got full dmesg outputs -attached. In which kernel version do you think we'll have this patch applied? Thank you!
This patch should appear in v3.7 if everything goes well.
Merged to upstream here, will appear in v3.7-rc1: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=1965f66e7db08d1ebccd24a59043eba826cc1ce8
Now upstream in v3.7.
yes, works great with 3.7.9 here. Thanks again for great work!