As far as I know, you're violating PCIe spec.
PCIe base spec (rev1.0a) states that a device must start link training
within 80ms
after a fundamental reset and that each device must be ready to accept config
requests within 100ms after fundamental reset.
Regards,
Stijn
On Sun, Jan 30, 2011 at 4:07
Elie De Brauwer wrote:
> On 01/28/11 19:37, Matias Garcia wrote:
>> I'm running a vanilla linux 2.6.37 kernel on a Freescale P2020 dual-core
>> processor, and have the following conundrum: I configure the FPGA which
>> brings up a PCIe interface to the processor. I scan both PCI buses on
>> the sys
When converting to the new cpumask code I screwed up:
- if (cpu_isset(cpu, numa_cpumask_lookup_table[node])) {
- cpu_clear(cpu, numa_cpumask_lookup_table[node]);
+ if (cpumask_test_cpu(cpu, node_to_cpumask_map[node])) {
+ cpumask_set_cpu(cpu, node_to_cpumas
There is no need to start up the timer and monitor topology changes on a
dedicated processor partition, so disable it.
Signed-off-by: Anton Blanchard
---
Index: linux-2.6/arch/powerpc/mm/numa.c
===
--- linux-2.6.orig/arch/powerpc/m
The rest of the NUMA code expects an OF associativity property with
the first cell containing the length. Without this fix all topology changes
cause us to misparse the property and put the cpu into node 0.
Signed-off-by: Anton Blanchard
---
Index: linux-2.6/arch/powerpc/mm/numa.c
=
The hypervisor uses unsigned 1 byte counters to signal topology changes to
the OS. Since they can wrap we need to check for any difference, not just if
the hypervisor count is greater than the previous count.
Signed-off-by: Anton Blanchard
---
Index: linux-2.6/arch/powerpc/mm/numa.c
===
VPHN supports up to 8 distance fields but the number of entries in
ibm,associativity-reference-points signifies how many are in use.
Don't look at all the VPHN counts, only distance_ref_points_depth
worth.
Since we already cap our distance metrics at MAX_DISTANCE_REF_POINTS,
use that to size the
Hi,
> FWIW, I looked at Anton's logs, and I don't think the boot failed, per
> se. I think it may have timed out (but not positive on that). I was
> able to boot 2.6.27-git17 on the exact same box, albeit it locks up
> at a later point (the sd abort I e-mailed about in a follow-up).
This fail bi
