Bug 18412

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!