Re: [git pull] PCI changes for 2.6.34

[Yinghai Lu]

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/