Hi Tony, Thanks for looking at this. > > - expose "physical id" field, even on CPUs that are not > > multi-core / multi-threaded. Now we know what sockets > > Madisons live in too. > > This sounds like a good idea. But this patch didn't work for me > to achieve that on my HP 2620. /proc/cpuinfo with this patch looks > like this: > > processor : 0 > ... > physical id: 4294967295 > > processor : 1 > ... > physical id: 4294967295 > > > So both my Madison cpus are apparently sharing the same socket! That > big decimal number is just "-1" printed as an unsigned. I spent some time looking at this and also talked with our low-end firmware guys, and think I understand what's going on now. First, on HP low-end platforms, like your rx2620, SAL_PHYSICAL_ID_INFO is hard coded to return 0. I missed this because I tested on low-end and high-end with Montes, and on high-end with Madisons. I must have missed low-end Madison based platforms. :( Based on that information, I will have to rethink my approach. Second, SAL_PHYSICAL_ID_INFO did not show up until SAL 3.2, which I think is why you got -1. On my rx2620, I have a relatively modern firmware which does have the SAL call, and I get 0 for each physical id (with Madisons). In identify_cpu(), we initialize c->socket_id to -1 because we expect that value to get overwritten later, in identify_siblings(). If you look at my patch, identify_siblings() calls ia64_sal_physical_id_info(), and then returns if we get a failure. You should have seen this printk: printk(KERN_ERR "ia64_sal_pltid failed with %ld\n", status); Can you verify that you saw that in your dmesg? I think the status should be -1, due to not-implemented. Thanks. /ac - To unsubscribe from this list: send the line "unsubscribe linux-ia64" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|