From: Yinghai Lu <yinghai@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [git pull] PCI changes for 2.6.34
Date: Sun, 28 Feb 2010 14:41:37 -0800 [thread overview]
Message-ID: <4B8AF121.2060106@kernel.org> (raw)
In-Reply-To: <alpine.LFD.2.00.1002281314110.3637@localhost.localdomain>
On 02/28/2010 01:19 PM, Linus Torvalds wrote:
>
>
> On Sun, 28 Feb 2010, Yinghai wrote:
>>
>> Maybe we need to put back pci=try=num back
>> And set pci_try_num=1 by default
>
> Well, why does your patch trigger any changes at all in the first place?
> The old situation was fine. All the resources were mapped.
>
> Sure, there were ROM resources that aren't even enabled, but that is
> _normal_. Iirc, several graphics chips actually alias the ROM resources
> with the regular memory-mapped IO resource, ie you can't even map both of
> them at the same time at some separate address, because the hardware
> shares address decoding resources.
>
> There's a reson PCI ROM resources are treated specially by the kernel.
>
> And as far as I can see, all the other resources are already allocated
> even without your patch. So there is some fundamental _bug_ there. This is
> not about enabling/disabling your patch, this is about your patch
> apparently simply being wrong.
>
looks like
[ 0.942502] pci 0000:04:00.0: reg 10: [mem 0xc6000000-0xc6ffffff]
[ 0.942510] pci 0000:04:00.0: reg 14: [mem 0xe0000000-0xefffffff 64bit pref]
[ 0.942519] pci 0000:04:00.0: reg 1c: [mem 0xc4000000-0xc5ffffff 64bit]
[ 0.942523] pci 0000:04:00.0: reg 24: [io 0x3000-0x307f]
[ 0.942528] pci 0000:04:00.0: reg 30: [mem 0xfffe0000-0xffffffff pref]
[ 0.942558] pci 0000:03:00.0: PCI bridge to [bus 04-04]
[ 0.942613] pci 0000:03:00.0: bridge window [io 0x3000-0x3fff]
[ 0.942616] pci 0000:03:00.0: bridge window [mem 0xc4000000-0xc6ffffff]
[ 0.942619] pci 0000:03:00.0: bridge window [mem 0xe0000000-0xefffffff 64bit pref]
[ 0.942657] pci 0000:05:00.0: reg 10: [mem 0xc2000000-0xc2ffffff]
[ 0.942665] pci 0000:05:00.0: reg 14: [mem 0xd0000000-0xdfffffff 64bit pref]
[ 0.942675] pci 0000:05:00.0: reg 1c: [mem 0xc0000000-0xc1ffffff 64bit]
[ 0.942679] pci 0000:05:00.0: reg 24: [io 0x2000-0x207f]
[ 0.942684] pci 0000:05:00.0: reg 30: [mem 0xfffe0000-0xffffffff pref]
[ 0.942715] pci 0000:03:02.0: PCI bridge to [bus 05-05]
[ 0.942770] pci 0000:03:02.0: bridge window [io 0x2000-0x2fff]
[ 0.942773] pci 0000:03:02.0: bridge window [mem 0xc0000000-0xc2ffffff]
[ 0.942777] pci 0000:03:02.0: bridge window [mem 0xd0000000-0xdfffffff 64bit pref]
later
[ 0.977506] pci 0000:04:00.0: no compatible bridge window for [mem 0xfffe0000-0xffffffff pref]
[ 0.977575] pci 0000:05:00.0: no compatible bridge window for [mem 0xfffe0000-0xffffffff pref]
that trigger the reallocating...
it seems old code
1. read out from pci rom bar
2. disable it, if it is enabled, but don't registered it
3. before pci_assign_unassigned..., will check PCI_ASSIGN_ROMS, and could register it...
3. to allocate for ROM bar together with other bar, for disabled or enabled but don't have PCI_ASSIGN_ROMS
4. it will not update the BAR if old setting is not enabled by BIOS.
looks like we should not allocate for those ROM bar at first place?
YH
next prev parent reply other threads:[~2010-02-28 22:43 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-26 17:39 [git pull] PCI changes for 2.6.34 Jesse Barnes
2010-02-28 20:34 ` Linus Torvalds
2010-02-28 20:46 ` Linus Torvalds
2010-02-28 21:11 ` Yinghai
2010-02-28 21:19 ` Linus Torvalds
2010-02-28 22:41 ` Yinghai Lu [this message]
2010-02-28 23:49 ` [git pull] PCI changes for 2.6.34 - pci rom rom fail list Yinghai Lu
2010-03-01 6:28 ` Jesse Barnes
2010-03-01 16:05 ` Linus Torvalds
2010-03-01 16:35 ` Jesse Barnes
2010-03-01 17:38 ` Jesse Barnes
2010-02-28 23:51 ` [git pull] PCI changes for 2.6.34 -- pci_try_num Yinghai Lu
2010-03-01 1:16 ` [git pull] PCI changes for 2.6.34 Arjan van de Ven
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=4B8AF121.2060106@kernel.org \
--to=yinghai@kernel.org \
--cc=jbarnes@virtuousgeek.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=torvalds@linux-foundation.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