From: Andreas Noever <andreas.noever@gmail.com>
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: Dirk Gouders <dirk@gouders.net>, Yinghai Lu <yinghai@kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Linux Kernel <linux-kernel@vger.kernel.org>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>
Subject: Re: [BUG] Bisected Problem with LSI PCI FC Adapter
Date: Mon, 22 Sep 2014 16:53:05 +0200 [thread overview]
Message-ID: <CAMxnaaWS+nxBM0gdLo0Qv3-x4fVwT0ePTr20miZvnpJUMgQ-NQ@mail.gmail.com> (raw)
In-Reply-To: <CAErSpo4Z1s7u08W6o+8Yxu7-QYN6YS9zt11=hH535YFYAwVKNw@mail.gmail.com>
On Mon, Sep 22, 2014 at 4:25 PM, Bjorn Helgaas <bhelgaas@google.com> wrote:
> On Sat, Sep 20, 2014 at 12:41 PM, Dirk Gouders <dirk@gouders.net> wrote:
>> Bjorn Helgaas <bhelgaas@google.com> writes:
>>
>>> On Sat, Sep 13, 2014 at 09:41:34PM +0200, Dirk Gouders wrote:
>>>> So, I did some tests on the VX50 which probably wasn't the worst idea,
>>>> because it behaves different than the test machine.
>>>>
>>>> Summary:
>>>>
>>>> 1) Bjorn's back pocket patch works on the VX50.
>>>>
>>>> On the test machine it causes a trace, mount_root has to do with
>>>> it. I tried to use netconsole but it complained the interface were
>>>> not ready.
>>>
>>> OK, that's good. I put this revert patch in for-linus for v3.17. I regard
>>> this as a temporary fix, not the real solution. My guess is the test
>>> machine doesn't boot because you're missing a driver, so not related to the
>>> revert patch.
>>
>> I assumed my limit-host-bridge-aperture-and-ignore-bridges-patch on top
>> of your patch caused this, so I took a closer look.
>>
>> Your patch works fine with current rc5+ on the test machine -- with and
>> without my additional patch.
>
> Great, thanks for testing that!
>
>> Other various today's test results (VX50) will be appended to bugzilla
>> in a few moments.
>
> The Windows Server 2008 boot shows that Windows reconfigures the
> 00:0e.0 bridge so it fits inside the [bus 00-07] aperture reported by
> the host bridge _CRS, and the LSI FC adapter is not enumerated at all.
> That's basically the same behavior that prompted your bug report.
> This suggests that Windows does *not* reset the secondary bus when
> changing the bridge configuration.
>
> For v3.17, I reverted 1820ffdccb9b ("PCI: Make sure bus number
> resources stay within their parents bounds"). For the future, I think
> we should do a quirk to fix the _CRS, similar to what Andreas has
> posted, and apply 1820ffdccb9b again.
>
> But I think the quirk should be specific to this system and BIOS. I
> don't want to add a workaround that silently covers up Linux and BIOS
> bugs. The reason amd_bus.c exists is because Linux was not smart
> enough to pay attention to _CRS. Linux is now pretty good at that, so
> the reason for amd_bus.c is mostly gone. I don't want to add new
> dependencies on amd_bus.c that will prevent us from phasing it out.
Why not always trust amd_bus over _CRS? Is there a scenario in which
amd_bus is wrong?
Are these methods (like _CRS) meant to set limits for us, or are they
simply used to report the configuration decisions made by the BIOS? So
if _CRS says that the window is [00-07] would it be ok for us to
simply increase it (possibly after reprogramming the registers in
amd_bus)?
next prev parent reply other threads:[~2014-09-22 14:53 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-03 10:57 [BUG] Bisected Problem with LSI PCI FC Adapter Dirk Gouders
2014-09-03 12:28 ` Andreas Noever
2014-09-03 12:47 ` Dirk Gouders
2014-09-03 15:54 ` Andreas Noever
2014-09-04 6:09 ` Dirk Gouders
2014-09-11 13:43 ` Dirk Gouders
2014-09-11 17:30 ` Bjorn Helgaas
2014-09-11 19:26 ` Yinghai Lu
2014-09-11 20:33 ` Dirk Gouders
2014-09-11 20:42 ` Bjorn Helgaas
2014-09-11 21:24 ` Dirk Gouders
2014-09-11 22:51 ` Bjorn Helgaas
2014-09-11 23:50 ` Dirk Gouders
2014-09-12 11:11 ` Dirk Gouders
2014-09-12 20:05 ` Dirk Gouders
2014-09-12 20:37 ` Andreas Noever
2014-09-12 20:38 ` Bjorn Helgaas
2014-09-12 20:39 ` Yinghai Lu
2014-09-12 20:54 ` Dirk Gouders
2014-09-12 21:49 ` Yinghai Lu
2014-09-12 22:05 ` Dirk Gouders
2014-09-12 23:09 ` Yinghai Lu
2014-09-13 0:11 ` Dirk Gouders
2014-09-13 1:59 ` Yinghai Lu
2014-09-13 4:07 ` Bjorn Helgaas
2014-09-13 9:30 ` Dirk Gouders
2014-09-13 19:41 ` Dirk Gouders
2014-09-14 10:42 ` Andreas Noever
2014-09-14 10:44 ` Andreas Noever
2014-09-14 11:40 ` Dirk Gouders
2014-09-14 13:16 ` Andreas Noever
2014-09-14 14:24 ` Dirk Gouders
2014-09-19 18:39 ` Bjorn Helgaas
2014-09-20 18:41 ` Dirk Gouders
2014-09-22 14:25 ` Bjorn Helgaas
2014-09-22 14:53 ` Andreas Noever [this message]
2014-09-22 15:23 ` Bjorn Helgaas
2014-09-19 17:12 ` Bjorn Helgaas
2014-09-19 15:03 ` Dirk Gouders
2014-09-19 18:21 ` Dirk Gouders
2014-09-11 20:35 ` Dirk Gouders
2014-09-11 20:42 ` Linus Torvalds
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=CAMxnaaWS+nxBM0gdLo0Qv3-x4fVwT0ePTr20miZvnpJUMgQ-NQ@mail.gmail.com \
--to=andreas.noever@gmail.com \
--cc=bhelgaas@google.com \
--cc=dirk@gouders.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=torvalds@linux-foundation.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).