x86, Calgary: Increase max PHB number
in [Kernel]
|
Prev: Add a pair of system calls to make extended file stats available
Next: usb_main_dev: remove casts from void*
From: Andrew Morton on 29 Jun 2010 19:00 On Fri, 25 Jun 2010 15:29:50 GMT "tip-bot for Darrick J. Wong" <djwong(a)us.ibm.com> wrote: > Commit-ID: 499a00e92dd9a75395081f595e681629eb1eebad > Gitweb: http://git.kernel.org/tip/499a00e92dd9a75395081f595e681629eb1eebad > Author: Darrick J. Wong <djwong(a)us.ibm.com> > AuthorDate: Thu, 24 Jun 2010 14:26:47 -0700 > Committer: Ingo Molnar <mingo(a)elte.hu> > CommitDate: Fri, 25 Jun 2010 16:14:58 +0200 > > x86, Calgary: Increase max PHB number arch/x86/kernel/pci-calgary_64.c: In function 'calgary_init_one': arch/x86/kernel/pci-calgary_64.c:1059: warning: comparison is always false due to limited range of data type from BUG_ON(dev->bus->number >= MAX_PHB_BUS_NUM); with http://userweb.kernel.org/~akpm/stuff/config-akpm2.txt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: H. Peter Anvin on 30 Jun 2010 17:40 On 06/29/2010 03:51 PM, Andrew Morton wrote: > On Fri, 25 Jun 2010 15:29:50 GMT > "tip-bot for Darrick J. Wong" <djwong(a)us.ibm.com> wrote: > >> Commit-ID: 499a00e92dd9a75395081f595e681629eb1eebad >> Gitweb: http://git.kernel.org/tip/499a00e92dd9a75395081f595e681629eb1eebad >> Author: Darrick J. Wong <djwong(a)us.ibm.com> >> AuthorDate: Thu, 24 Jun 2010 14:26:47 -0700 >> Committer: Ingo Molnar <mingo(a)elte.hu> >> CommitDate: Fri, 25 Jun 2010 16:14:58 +0200 >> >> x86, Calgary: Increase max PHB number > > arch/x86/kernel/pci-calgary_64.c: In function 'calgary_init_one': > arch/x86/kernel/pci-calgary_64.c:1059: warning: comparison is always false due to limited range of data type > > from > > BUG_ON(dev->bus->number >= MAX_PHB_BUS_NUM); > > with > > http://userweb.kernel.org/~akpm/stuff/config-akpm2.txt This comes from: /* * The maximum PHB bus number. * x3950M2 (rare): 8 chassis, 48 PHBs per chassis = 384 * x3950M2: 4 chassis, 48 PHBs per chassis = 192 * x3950 (PCIE): 8 chassis, 32 PHBs per chassis = 256 * x3950 (PCIX): 8 chassis, 16 PHBs per chassis = 128 */ #define MAX_PHB_BUS_NUM 384 Clearly there can't be 384 busses with standard PCI numbering (bus numbers are 8 bits). That means either that the number 384 is just wrong, or it means that there are multiple PCI domains involved, and that the BUG_ON() should be something else. Furthermore, in get_tce_space_from_tar() we have: for (bus = 0; bus < MAX_PHB_BUS_NUM; bus++) { struct calgary_bus_info *info = &bus_info[bus]; unsigned short pci_device; u32 val; val = read_pci_config(bus, 0, 0, 0); pci_device = (val & 0xFFFF0000) >> 16; .... which assumes the bus is a PCI bus number, no domain involved. Does this mean the limit should be 256 (in which case we can just drop the BUG_ON()), or is there support for domains which should be in this code but isn't? -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Darrick J. Wong on 30 Jun 2010 17:50 On Wed, Jun 30, 2010 at 02:31:44PM -0700, H. Peter Anvin wrote: > On 06/29/2010 03:51 PM, Andrew Morton wrote: > > On Fri, 25 Jun 2010 15:29:50 GMT > > "tip-bot for Darrick J. Wong" <djwong(a)us.ibm.com> wrote: > > > >> Commit-ID: 499a00e92dd9a75395081f595e681629eb1eebad > >> Gitweb: http://git.kernel.org/tip/499a00e92dd9a75395081f595e681629eb1eebad > >> Author: Darrick J. Wong <djwong(a)us.ibm.com> > >> AuthorDate: Thu, 24 Jun 2010 14:26:47 -0700 > >> Committer: Ingo Molnar <mingo(a)elte.hu> > >> CommitDate: Fri, 25 Jun 2010 16:14:58 +0200 > >> > >> x86, Calgary: Increase max PHB number > > > > arch/x86/kernel/pci-calgary_64.c: In function 'calgary_init_one': > > arch/x86/kernel/pci-calgary_64.c:1059: warning: comparison is always false due to limited range of data type > > > > from > > > > BUG_ON(dev->bus->number >= MAX_PHB_BUS_NUM); > > > > with > > > > http://userweb.kernel.org/~akpm/stuff/config-akpm2.txt > > This comes from: > > /* > * The maximum PHB bus number. > * x3950M2 (rare): 8 chassis, 48 PHBs per chassis = 384 > * x3950M2: 4 chassis, 48 PHBs per chassis = 192 > * x3950 (PCIE): 8 chassis, 32 PHBs per chassis = 256 > * x3950 (PCIX): 8 chassis, 16 PHBs per chassis = 128 > */ > #define MAX_PHB_BUS_NUM 384 > > Clearly there can't be 384 busses with standard PCI numbering (bus > numbers are 8 bits). That means either that the number 384 is just > wrong, or it means that there are multiple PCI domains involved, and > that the BUG_ON() should be something else. > > Furthermore, in get_tce_space_from_tar() we have: > > for (bus = 0; bus < MAX_PHB_BUS_NUM; bus++) { > struct calgary_bus_info *info = &bus_info[bus]; > unsigned short pci_device; > u32 val; > > val = read_pci_config(bus, 0, 0, 0); > pci_device = (val & 0xFFFF0000) >> 16; > > ... which assumes the bus is a PCI bus number, no domain involved. > > Does this mean the limit should be 256 (in which case we can just drop > the BUG_ON()), or is there support for domains which should be in this > code but isn't? Yes, it should be 256. Some time ago there was talk of building 8-node x3950M2s with PCI domain support, but the final word now is that nobody will ever have more than 4 nodes. The BUG_ON can be dropped, too. I'll send a patch shortly that incorporates both updates. (Honestly I sort of wonder if the Calgary code should be removed entirely, but that's a whole different battle....) --D -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: H. Peter Anvin on 30 Jun 2010 19:10
On 06/30/2010 02:49 PM, Darrick J. Wong wrote: > Newer systems (x3950M2) can have 48 PHBs per chassis and 4 chassis, so bump the > limits up and provide an explanation of the requirements for each class. Since > we can't have more than 256 PCI buses in these systems, we don't need the array > check. The 384-entry patch is already upstream. Can you send a patch relative to current -linus? -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |